tutorial - ¿Debo usar Elementos o Atributos en XML?

para que sirven los dtd en xml (13)

Esta pregunta ya tiene una respuesta aquí:

XML attribute vs XML element 20 respuestas

Estoy aprendiendo acerca de los atributos XML de W3Schools .

El autor menciona lo siguiente (el énfasis es mío):

Elementos XML vs. Atributos
<person sex="female"> <firstname>Anna</firstname> <lastname>Smith</lastname> </person>
<person> <sex>female</sex> <firstname>Anna</firstname> <lastname>Smith</lastname> </person>
En el primer ejemplo, el sexo es un atributo. En el último, el sexo es un elemento. Ambos ejemplos brindan la misma información.
No hay reglas sobre cuándo usar los atributos y cuándo usar los elementos. Los atributos son útiles en HTML. En XML, mi consejo es evitarlos. Use elementos en su lugar.
Evitar los atributos XML?
Algunos de los problemas con el uso de atributos son:
los atributos no pueden contener múltiples valores (los elementos pueden)
los atributos no pueden contener estructuras de árbol (los elementos pueden)
los atributos no son fácilmente expandibles (para futuros cambios)
Los atributos son difíciles de leer y mantener. Usa elementos para datos. Use atributos para información que no es relevante para los datos.

Entonces, ¿el punto de vista del autor es famoso, o es esta la mejor práctica en XML?

¿Deben evitarse los atributos en XML?

W3Schools también mencionó lo siguiente (el énfasis es mío):

Atributos XML para metadatos
A veces, las referencias de ID se asignan a los elementos. Estos ID se pueden usar para identificar elementos XML de forma muy similar a los atributos de ID en HTML. Este ejemplo demuestra esto:
<messages> <note id="501"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don''t forget me this weekend!</body> </note> <note id="502"> <to>Jani</to> <from>Tove</from> <heading>Re: Reminder</heading> <body>I will not</body> </note> </messages>
El ID de arriba es solo un identificador, para identificar las diferentes notas. No es una parte de la nota en sí misma.
Lo que trato de decir aquí es que los metadatos (datos sobre datos) deben almacenarse como atributos, y que los datos en sí mismos deben almacenarse como elementos.

Aquí hay otra cosa a tener en cuenta al decidir sobre un formato XML: si recuerdo correctamente, los valores de los atributos "id" no deben ser todos numéricos, deben cumplir las reglas para los nombres en XML. Y, por supuesto, los valores deben ser únicos. Tengo un proyecto que debe procesar archivos que no cumplen estos requisitos (aunque son XML limpios en otros aspectos), lo que hizo que el procesamiento de los archivos sea más intrincado.

El uso de atributos o elementos generalmente se decide por los datos que intenta modelar.

Por ejemplo, si cierta entidad es PARTE de los datos, entonces es aconsejable convertirla en un elemento. Por ejemplo, el nombre del empleado es una parte esencial de los datos del empleado.

Ahora bien, si desea transmitir METADATA sobre los datos (algo que proporciona información adicional sobre los datos) pero no es realmente parte de los datos, entonces es mejor hacerlo un atributo. Por ejemplo, supongamos que cada empleado tiene un GUID necesario para el procesamiento de back-end, luego hacerlo un atributo es mejor. (GUID no es algo que transmite información realmente útil a alguien que mira el xml, pero podría ser necesario para otros fines)

No existe una regla como tal que diga que algo debe ser un atributo o un elemento.

No es necesario EVITAR atributos a toda costa ... A veces son más fáciles de modelar que los elementos. Realmente depende de los datos que intentas representar.

Es debido a ese tipo de basura que debes evitar w3schools. En todo caso, eso es incluso peor que las cosas espantosas que tienen sobre JavaScript.

Como regla general, sugeriría que el contenido, es decir, los datos que se espera sean consumidos por un usuario final (ya sea una lectura humana o una máquina que recibe información para el procesamiento), se contienen mejor dentro de un elemento. Los metadatos, por ejemplo, un ID asociado con un contenido, pero solo de valor para uso interno en lugar de mostrarlo al usuario final, deben estar en un atributo.

Este es un ejemplo donde los atributos son datos sobre datos.

Las bases de datos se nombran por su atributo ID.

El atributo "tipo" de la base de datos denota lo que se espera encontrar dentro de la etiqueta de la base de datos.

<databases> <database id=''human_resources'' type=''mysql''> <host>localhost</host> <user>usrhr</user> <pass>jobby</pass> <name>consol_hr</name> </database> <database id=''products'' type=''my_bespoke''> <filename>/home/anthony/products.adb</filename> </database> </databases>

He usado Google para buscar la pregunta exacta. Primero llegué a este artículo, http://www.ibm.com/developerworks/library/x-eleatt/index.html . Sin embargo, se sintió demasiado tiempo para una simple pregunta como tal. De todos modos, leí todas las respuestas sobre este tema y no encontré un resumen satisfactorio. Como tal, volví al último artículo. Aquí hay un resumen:

¿Cuándo uso elementos y cuándo uso atributos para presentar fragmentos de información?

Si la información en cuestión podría estar marcada con elementos, colóquela en un elemento.
Si la información es adecuada para la forma de atributo, pero podría terminar como atributos múltiples del mismo nombre en el mismo elemento, utilice elementos secundarios en su lugar.
Si se requiere que la información esté en un tipo de atributo tipo DTD estándar como ID, IDREF o ENTIDAD, use un atributo.
Si la información no debe ser normalizada para espacios en blanco, use elementos. ( Los procesadores XML normalizan los atributos de forma que pueden cambiar el texto sin procesar del valor del atributo).

Principio de contenido central

Si considera que la información en cuestión es parte del material esencial que se está expresando o comunicando en el XML, colóquelo en un elemento. Si considera que la información es periférica o incidental a la comunicación principal, o puramente para ayudar a las aplicaciones a procesar la comunicación principal, use atributos.

Principio de información estructurada

Si la información se expresa en una forma estructurada, especialmente si la estructura puede ser extensible, use elementos. Si la información se expresa como un token atómico, use atributos.

Principio de legibilidad

Si la información debe ser leída y entendida por una persona, use elementos. Si la información es entendida y digerida más fácilmente por una máquina, use atributos.

Principio de enlace elemento / atributo

Use un elemento si necesita que su valor sea modificado por otro atributo. [..] casi siempre es una idea terrible tener un atributo para modificar otro.

Este es un breve resumen de los bits importantes del artículo. Si desea ver ejemplos y una descripción completa de cada caso, consulte el artículo original.

Los puntos del autor son correctos (excepto que los atributos pueden contener una lista de valores). La pregunta es si te importan o no sus puntos.

Tu decides.

Mapeo del modelo de atributos. Un conjunto de atributos en un elemento se isomorfiza directamente en un mapa de nombre / valor en el que los valores son texto o cualquier tipo de valor serializable. En C #, por ejemplo, cualquier objeto Dictionary<string, string> se puede representar como una lista de atributos XML, y viceversa.

Este no es el caso enfáticamente con los elementos. Si bien siempre puede transformar un mapa de nombre / valor en un conjunto de elementos, no ocurre lo contrario, por ejemplo:

<map> <key1>value</key1> <key1>another value</key1> <key2>a third value</key2> </map>

Si transforma esto en un mapa, perderá dos cosas: los múltiples valores asociados con key1 , y el hecho de que key1 aparece antes de key2 .

La importancia de esto se vuelve mucho más clara si nos fijamos en el código DOM que se utiliza para actualizar la información en un formato como este. Por ejemplo, es trivial escribir esto:

foreach (string key in map.Keys) { mapElement.SetAttribute(key, map[key]); }

Ese código es conciso y no ambiguo. Contraste con, digamos:

foreach (string key in map.Keys) { keyElement = mapElement.SelectSingleNode(key); if (keyElement == null) { keyElement = mapElement.OwnerDocument.CreateElement(key); mapElement.AppendChild(keyElement); } keyElement.InnerText = value; }

Mi 0.02 cinco años después del OP es exactamente lo contrario. Dejame explicar.

Use elementos cuando está agrupando datos similares y atributos de esos datos.
No uses elementos para todo.
Si los datos se repiten (1 a muchos), es probable que sea un elemento
Si la información nunca se repite, y solo tiene sentido cuando se correlaciona con otra cosa, es un atributo.
Si los datos no tienen otros atributos (es decir, un nombre), entonces es un atributo
Agrupe elementos similares para respaldar el análisis de colecciones (es decir, / xml / character)
Reutilizar nombres de elementos similares para admitir datos de análisis
Nunca, nunca , use números en los nombres de los elementos para mostrar la posición. (es decir, character1, character2) Esta práctica hace que sea muy difícil de analizar (vea # 6, código de análisis debe / character1, / character2, etc. no simplemente / character.

Considerado de otra manera:

Comience pensando en todos sus datos como un atributo.
Lógicamente, agrupe atributos en elementos. Si conoce sus datos, rara vez necesitará convertir atributos en un elemento. Probablemente ya sepa cuándo es necesario un elemento (recopilación o datos repetidos)
Agrupe los elementos juntos lógicamente
Cuando se encuentre con el caso que necesita expandir, agregue nuevos elementos / atributos basados en la estructura lógica de un proceso anterior. Agregar una nueva colección de elementos secundarios no "romperá" su diseño, y será más fácil de leer con el tiempo.

Por ejemplo, mirando una simple colección de libros y personajes principales, el título nunca tendrá "hijos", es un elemento simple. Cada personaje tiene un nombre y una edad.

<book title=''Hitchhiker's Guide to the Galaxy'' author=''Douglas Adams''> <character name=''Zaphod Beeblebrox'' age=''100''/> <character name=''Arthur Dent'' age=''42''/> <character name=''Ford Prefect'' age=''182''/> </book> <book title=''On the Road'' author=''Jack Kerouac''> <character name=''Dean Moriarty'' age=''30''/> <character name=''Old Bull Lee'' age=''42''/> <character name=''Sal Paradise'' age=''42''/> </book>

Podría argumentar que un libro podría tener múltiples autores. De acuerdo, simplemente expanda agregando nuevos elementos de autor (opcionalmente elimine el @ autor original). Claro, has roto la estructura original, pero en la práctica es bastante raro y fácil de solucionar. Cualquier consumidor de su XML original que asumió un único autor tendrá que cambiar de todos modos (es probable que cambien su base de datos para mover el autor de una columna en la tabla ''libro'' a una tabla ''autor'').

<book title=''Hitchhiker's Guide to the Galaxy''> <author name=''Douglas Adams''/> <author name=''Some Other Guy''/> <character name=''Zaphod Beeblebrox'' age=''100''/> <character name=''Arthur Dent'' age=''42''> <character name=''Ford Prefect'' age=''182''/> </book>

No menos importante es que poner cosas en atributos hace que el XML sea menos detallado.

Comparar

<person name="John" age="23" sex="m"/>

En contra

<person> <name> John </name> <age> <years> 23 </years> </age> <sex> m </sex> </person>

Sí, eso fue un poco parcial y exagerado, pero entiendes el punto

No puedes poner un CDATA en un atributo. En mi experiencia, tarde o temprano va a querer poner comillas simples, comillas dobles y / o documentos XML enteros en un "miembro", y si es un atributo, va a estar maldiciendo a la persona que usó atributos en su lugar de elementos.

Nota: mi experiencia con XML implicó principalmente limpiar otras personas. Estas personas parecían seguir el viejo adagio "XML es como violencia. Si usarlo no ha resuelto tu problema, entonces no has usado suficiente".

Normalmente trabajo sobre la base de que los atributos son metadatos , es decir, datos sobre los datos. Una cosa que evito es poner listas en atributos. p.ej

attribute="1 2 3 7 20"

De lo contrario, tienes un nivel extra de análisis para extraer cada elemento. Si XML proporciona la estructura y las herramientas para las listas, entonces ¿por qué imponer otro usted mismo?

Un escenario donde es posible que desee codificar con preferencia los atributos es la velocidad de procesamiento a través de un analizador SAX. Usando un analizador SAX obtendrás un elemento de devolución de llamada que contiene el nombre del elemento y la lista de atributos. Si hubiera utilizado múltiples elementos en su lugar, obtendrá varias devoluciones de llamada (una para cada elemento). ¿Cuánto de una carga / timesink esto es objeto de debate, por supuesto, pero tal vez vale la pena considerar.

Probablemente puedas ver el problema de una manera semántica.

Si los datos están más vinculados con el elemento, sería un atributo.

es decir, una ID de un elemento, lo pondría como un atributo del elemento.

Pero es cierto que al analizar atributos de un documento podría causar más dolores de cabeza que elementos.

Todo depende de usted y de cómo diseñe su Esquema.

Todo depende de para qué se usa XML. Cuando se trata principalmente de interoperabilidad entre el software y las máquinas, como los servicios web, es más fácil utilizar todos los elementos, aunque solo sea por coherencia (y algunos marcos lo prefieren de esa manera, por ejemplo, WCF). Si está destinado al consumo humano, es decir, creado y / o leído por personas, el uso prudente de los atributos puede mejorar bastante la legibilidad; XHTML es un ejemplo razonable de eso, y también XSLT y XML Schema.