Elemento XML vs Elemento XML

En el trabajo, se nos pide que creemos archivos XML para pasar datos a otra aplicación fuera de línea que luego creará un segundo archivo XML para volver a pasar con el fin de actualizar algunos de nuestros datos. Durante el proceso, hemos estado discutiendo con el equipo de la otra aplicación sobre la estructura del archivo XML.

La muestra que se me ocurrió es esencialmente algo así como:

     

El otro equipo dijo que esto no era un estándar de la industria y que los atributos solo deberían usarse para metadatos. Ellos sugirieron:

   something something something  something something    

La razón por la que sugerí la primera es que el tamaño del archivo creado es mucho más pequeño. Habrá aproximadamente 80000 elementos que estarán en el archivo durante la transferencia. Su sugerencia en realidad resulta ser tres veces más grande que la que sugerí. Busqué el misterioso “Industry Standard” que se mencionó, pero lo más parecido que pude encontrar fue que los atributos XML solo deberían usarse para metadatos, pero dijo que el debate era sobre lo que en realidad era metadatos.

Después de la larga explicación (lo siento), ¿cómo se determina qué es un metadato, y cuando se diseña la estructura de un documento XML, cómo se debe decidir cuándo usar un atributo o un elemento?

Yo uso esta regla de oro:

  1. Un atributo es algo que es autónomo, es decir, un color, una identificación, un nombre.
  2. Un Elemento es algo que tiene o podría tener atributos propios o contener otros elementos.

Entonces el tuyo está cerca. Hubiera hecho algo como:

EDITAR : actualizó el ejemplo original basado en los comentarios a continuación.

   something XYX  YYZ   

Algunos de los problemas con los atributos son:

  • los atributos no pueden contener valores múltiples (los elementos secundarios pueden)
  • los atributos no son fácilmente expandibles (para futuros cambios)
  • los atributos no pueden describir las estructuras (los elementos secundarios pueden)
  • los atributos son más difíciles de manipular por código de progtwig
  • los valores de atributo no son fáciles de probar contra un DTD

Si usa atributos como contenedores para datos, termina con documentos que son difíciles de leer y mantener. Intenta usar elementos para describir datos. Use atributos solo para proporcionar información que no sea relevante para los datos.

No termine así (no es así como debe usarse XML):

   

Fuente: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

“XML” significa “lenguaje de marcado extensible”. Un lenguaje de marcado implica que los datos son texto, marcados con metadatos sobre estructura o formato.

XHTML es un ejemplo de XML utilizado de la manera que se pretendía:

 

El Jefe insists that you MUST complete your project by Friday.

Aquí, la distinción entre elementos y atributos es clara. Los elementos de texto se muestran en el navegador y los atributos son instrucciones sobre cómo mostrarlos (aunque hay algunas tags que no funcionan de esa manera).

La confusión surge cuando XML no se utiliza como un lenguaje de marcado, sino como un lenguaje de serialización de datos , en el que la distinción entre “datos” y “metadatos” es más vaga. Por lo tanto, la elección entre elementos y atributos es más o menos arbitraria, a excepción de las cosas que no se pueden representar con atributos (ver la respuesta de Feenster).

Elemento XML vs Atributo XML

XML se trata de un acuerdo. Primero difiera de cualquier esquema XML existente o convenciones establecidas dentro de su comunidad o industria.

Si realmente está en una situación para definir su esquema desde cero, aquí hay algunas consideraciones generales que deberían informar la decisión de elemento contra atributo :

   Content    Hierarchical    
  1. Has
  2. order
Can reference to re-use For humans Extreme use leads to document bloat Unique or non-unique names SAX parse: read later DTD: no default value

Puede depender de tu uso. El XML que se utiliza para representar datos estructurados generados a partir de una base de datos puede funcionar bien, y los valores de campo finalmente se colocan como atributos.

Sin embargo, XML utilizado como un mensaje de transporte a menudo sería mejor usar más elementos.

Por ejemplo, digamos que tenemos este XML como se propone en la respuesta:

   XYX  YYZ    

Ahora queremos enviar el elemento ITEM a un dispositivo para imprimir el código de barras, sin embargo, hay una opción de tipos de encoding. ¿Cómo representamos el tipo de encoding requerido? Repentinamente nos damos cuenta, algo tardíamente, de que el código de barras no era un valor automático único, sino que puede ser calificado con la encoding requerida cuando se imprime.

   something XYX  YYZ   

El punto es que a menos que construyas algún tipo de XSD o DTD junto con un espacio de nombres para arreglar la estructura en piedra, lo mejor será que dejes abiertas tus opciones.

IMO XML es más útil cuando se puede flexionar sin romper el código existente que lo usa.

Utilizo las siguientes pautas en mi diseño de esquema con respecto a los atributos frente a los elementos:

  • Use elementos para texto de larga ejecución (generalmente los de cadenas o tipos de cadenas normalizadas)
  • No use un atributo si hay una agrupación de dos valores (p. Ej., EventStartDate y eventEndDate) para un elemento. En el ejemplo anterior, debe haber un nuevo elemento para “evento” que puede contener los atributos startDate y endDate.
  • Business Date, DateTime y los números (por ejemplo, recuentos, cantidad y tasa) deben ser elementos.
  • Los elementos de tiempo no comerciales, como la última actualización, caducan deben ser atributos.
  • Los números no comerciales, como los códigos hash y los índices, deben ser atributos. * Use elementos si el tipo será complejo.
  • Use atributos si el valor es un tipo simple y no se repite.
  • xml: id y xml: lang debe ser atributos que hagan referencia al esquema XML
  • Prefiere los atributos cuando sea técnicamente posible.

La preferencia por los atributos es que proporciona lo siguiente:

  • único (el atributo no puede aparecer varias veces)
  • el orden no importa
  • las propiedades anteriores son heredables (esto es algo que el modelo de contenido “todo” no admite en el lenguaje de esquema actual)
  • La ventaja es que son menos prolijas y usan menos ancho de banda, pero esa no es realmente una razón para preferir los atributos sobre los elementos.

Añadí cuando era técnicamente posible porque hay veces donde el uso de atributos no es posible. Por ejemplo, las opciones de conjunto de atributos. Por ejemplo, el uso (startDate y endDate) xor (startTS y endTS) no es posible con el lenguaje de esquema actual

Si XML Schema comienza a permitir que el modelo de contenido “todo” se restrinja o extienda, probablemente lo descartaría.

No hay una respuesta universal a esta pregunta (estuve muy involucrado en la creación de la especificación W3C). XML se puede utilizar para muchos propósitos: los documentos tipo texto, los datos y el código declarativo son tres de los más comunes. También lo uso mucho como modelo de datos. Hay aspectos de estas aplicaciones donde los atributos son más comunes y otros donde los elementos secundarios son más naturales. También hay características de varias herramientas que hacen que sea más fácil o más difícil de usar.

XHTML es un área donde los atributos tienen un uso natural (por ejemplo, en class = ‘foo’). Los atributos no tienen orden y esto puede facilitar que algunas personas desarrollen herramientas. Los atributos OTOH son más difíciles de escribir sin un esquema. También encuentro que los atributos de espacio de nombres (foo: bar = “zork”) a menudo son más difíciles de administrar en varios conjuntos de herramientas. Pero eche un vistazo a algunos de los idiomas W3C para ver la mezcla que es común. SVG, XSLT, XSD, MathML son algunos ejemplos de lenguajes conocidos y todos tienen una gran cantidad de atributos y elementos. Algunos idiomas incluso permiten más de una forma de hacerlo, por ejemplo

 ; 

o

  bar; ; 

Tenga en cuenta que estos NO son equivalentes sintácticamente y requieren soporte explícito en las herramientas de procesamiento)

Mi consejo sería echar un vistazo a la práctica común en el área más cercana a su aplicación y también considerar qué herramientas desea aplicar.

Finalmente, asegúrese de diferenciar los espacios de nombres de los atributos. Algunos sistemas XML (por ejemplo, Linq) representan espacios de nombres como atributos en la API. IMO esto es feo y potencialmente confuso.

En caso de duda, KISS : ¿por qué mezclar atributos y elementos cuando no tienes una razón clara para usar atributos? Si más adelante decides definir un XSD, eso terminará siendo más limpio también. Entonces, si luego decides generar una estructura de clases desde tu XSD, eso también será más simple.

Otros han cubierto cómo diferenciar los atributos de los elementos, pero desde una perspectiva más general, poner todo en atributos porque hace que el XML resultante sea más pequeño es incorrecto.

XML no está diseñado para ser compacto, sino portátil y legible para el ser humano. Si desea disminuir el tamaño de los datos en tránsito, utilice otra cosa (como los búferes de protocolo de Google ).

la pregunta del millón!

En primer lugar, no se preocupe demasiado por el rendimiento ahora. se sorprenderá de la rapidez con la que un analizador xml optimizado desgarrará su xml. más importante aún, ¿cuál es su diseño para el futuro: a medida que evoluciona el XML, cómo mantendrá el acoplamiento y la interoperabilidad?

más concretamente, puede hacer que el modelo de contenido de un elemento sea más complejo, pero es más difícil extender un atributo.

Es discutible de cualquier manera, pero sus colegas tienen razón en el sentido de que el XML debe usarse para “marcado” o metadatos en torno a los datos reales. Por su parte, tiene razón en que a veces es difícil decidir dónde se encuentra la línea entre metadatos y datos al modelar su dominio en XML. En la práctica, lo que hago es pretender que cualquier cosa en el marcado está oculta, y solo los datos fuera del marcado son legibles. ¿El documento tiene algún sentido de esa manera?

XML es notoriamente voluminoso. Para el transporte y el almacenamiento, la compresión es muy recomendable si puede pagar la potencia de procesamiento. XML se comprime bien, a veces fenomenalmente bien, debido a su repetitividad. He comprimido archivos grandes a menos del 5% de su tamaño original.

Otro punto para reforzar su posición es que mientras el otro equipo discute sobre el estilo (en que la mayoría de las herramientas XML manejarán un documento con todos los atributos tan fácilmente como un documento PCDATA), usted está argumentando cuestiones prácticas. Si bien el estilo no puede ignorarse por completo, los méritos técnicos deberían tener más peso.

Es en gran medida una cuestión de preferencia. Utilizo elementos para agrupar y atributos para datos siempre que sea posible, ya que veo esto como más compacto que la alternativa.

Por ejemplo, prefiero …..

 < ?xml version="1.0" encoding="utf-8"?>        

…En lugar de….

 < ?xml version="1.0" encoding="utf-8"?>    Rory Becker 30   Travis Illig 32   Scott Hanselman 34    

Sin embargo, si tengo datos que no representan fácilmente dentro de, digamos, 20-30 caracteres o contienen muchas comillas u otros caracteres que necesitan escaparse, entonces diría que es hora de separar los elementos … posiblemente con bloques CData.

 < ?xml version="1.0" encoding="utf-8"?>    A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker   A cool guy for who has helped me out with all sorts of SVn information   Scott works for MS and has a great podcast available at http://www.hanselminutes.com     

Use elementos para datos y atributos para metadatos (datos sobre los datos del elemento).

Si un elemento se muestra como un predicado en las cadenas seleccionadas, tiene una buena señal de que debe ser un atributo. Del mismo modo, si un atributo nunca se usa como predicado, entonces tal vez no sea un metadato útil.

Recuerde que se supone que XML es legible por máquina, no legible por humanos y que para documentos grandes, XML se comprime muy bien.

¿Qué tal si aprovechamos nuestra intuición de orientación al objeto duramente ganada? Normalmente me resulta sencillo pensar qué objeto es y cuál es un atributo del objeto o a qué objeto se refiere.

Lo que intuitivamente tenga sentido como objetos, encajará como elementos. Sus atributos (o propiedades) serían atributos para estos elementos en xml o elemento hijo con atributo.

Creo que para casos más sencillos, como en el ejemplo, la analogía de orientación de objetos funciona bien para descubrir cuál es el elemento y cuál es el atributo de un elemento.

Ambos métodos para almacenar las propiedades del objeto son perfectamente válidos. Deberías apartarte de consideraciones pragmáticas. Intenta responder la siguiente pregunta:

  1. ¿Qué representación lleva a un análisis de datos más rápido \ generación?
  2. ¿Qué representación conduce a una transferencia de datos más rápida?
  3. ¿Importa la legibilidad?

Solo un par de correcciones a alguna mala información:

@John Ballinger: Las atribuciones pueden contener datos de cualquier carácter. <> y “‘deben escaparse a & lt; & gt; & amp;; y & quot ;, & apos;, respectivamente. Si usa una biblioteca XML, se encargará de eso por usted.

Demonios, un atributo puede contener datos binarios, como una imagen, si realmente lo deseas, solo con encoding base64 y convirtiéndolo en una URL de datos:

@feenster: los atributos pueden contener elementos separados por espacios en el caso de IDS o NAMES, que incluirían números. Nitpicky, pero esto puede terminar ahorrando espacio.

El uso de atributos puede mantener XML competitivo con JSON. Ver Marca de grasa: Recortar el mito de marca de grasa una caloría a la vez .

Esto es muy claro en HTML donde las diferencias de atributos y marcado se pueden ver claramente:

  1. Todos los datos están entre el marcado
  2. Los atributos se utilizan para caracterizar estos datos (por ejemplo, formatos)

Si solo tiene datos puros como XML, hay una diferencia menos clara. Los datos podrían estar entre el marcado o como atributos.

=> La mayoría de los datos deben permanecer entre el marcado.

Si desea usar atributos aquí: puede dividir los datos en dos categorías: Datos y “metadatos”, donde los metadatos no son parte del registro, desea presentarlos, pero cosas como “formato de versión”, “fecha de creación” , etc.

   ...  

También se podría decir: “Usar atributos para caracterizar la etiqueta, usar tags para proporcionar datos en sí”.

Siempre me sorprenden los resultados de este tipo de discusiones. Para mí, existe una regla muy simple para decidir si los datos pertenecen a un atributo o a un contenido, y es si los datos tienen una estructura secundaria navegable.

Entonces, por ejemplo, el texto no marcado siempre pertenece a los atributos. Siempre.

Las listas pertenecen a la subestructura o contenido. El texto que puede incluir en el tiempo sub-contenido estructurado incrustado pertenece al contenido. (En mi experiencia, hay relativamente poco de esto, texto con marcado, cuando se usa XML para almacenamiento o intercambio de datos).

El esquema XML escrito de esta manera es conciso.

Cada vez que veo casos como FordRed , me digo a mí mismo “¿Creyó el autor que habrían sub elementos en el hacer elemento? ” es significativamente más legible, no hay dudas sobre cómo se manejaría el espacio en blanco, etc.

Dadas las reglas de manejo del espacio en blanco, creo que esta fue la clara intención de los diseñadores de XML.

Estoy de acuerdo con Feenster. Aléjate de los atributos si puedes. Los elementos son amigables con la evolución y más interoperables entre los kits de herramientas del servicio web. Nunca encontraría estos kits de herramientas serializando sus mensajes de solicitud / respuesta utilizando atributos. Esto también tiene sentido ya que nuestros mensajes son datos (no metadatos) para un kit de herramientas de servicios web.

Los atributos pueden ser difíciles de administrar con el tiempo, créanme. Siempre me mantengo alejado de ellos personalmente. Los elementos son mucho más explícitos y legibles / utilizables tanto por los analizadores como por los usuarios.

La única vez que los utilicé fue definir la extensión de archivo de una url de activo:

 wank.jpg ...etc etc 

Supongo que si sabes que el 100% del atributo no será necesario expandirlo, podrías usarlo, pero ¿cuántas veces lo sabes?

  wank.jpg gif