¿Cuál elegir: atributo XML o subnodo?

Queremos exportar algunos datos de nuestra base de datos como XML. Por ejemplo, una Personpuede tener age, namey algunas otras propiedades.

Tenemos dos opciones para definir el formato XML.

Opción # 1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

Opción # 2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

Entonces, ¿cuál es la diferencia entre la definición de subnodo o atributo? ¿Y cuál es el beneficio de cada elección?

No hay documentación clara / mejores prácticas para esto, pero considere las alternativas, ya que tiene:

Como texto del elemento:

• puede ser más fácil mostrar los datos como xhtml, etc., donde el contenido de texto se considera texto, en lugar de marcado o metadatos.
• puede haber más de uno Si necesita contenido secundario con varias filas de edad o nombre, los atributos no permitirán esto
• si necesita metadatos a nivel de fila, tiene la opción de usar los atributos de <name>o <age>para este propósito

Como atributos:

• el XML es más compacto
• XSLT y DocTypes son más simples de especificar
• no tiene que preocuparse por los espacios en blanco (relleno, sangría, saltos de línea) u otros elementos que se pueden introducir (comentarios, PI) en áreas PCDATA (texto del elemento)
• ¡Sólo puede haber uno! no tiene que preocuparse por el contenido secundario que contiene múltiples ageatributos.

He pasado mucho tiempo trabajando con XML y, en mi opinión, para la comunicación de datos pura, los atributos deben usarse siempre que sea posible. Si es probable que el XML se use para la presentación (XSLT, xhtml, etc.), entonces puede ser mejor como contenido de texto (pero no necesariamente).

Principios del diseño XML: cuándo usar elementos versus atributos por Uche Ogbuji de IBM es probablemente uno de los mejores recursos en la materia.

La esencia de la decisión es que los atributos son cosas "hechas". No puede cambiarlos, modificarlos o anidarlos. Son independientes del orden y distintos dentro del elemento (no puede tener dos de la misma cosa).

Si alguna de estas restricciones es algo que puede cambiar, convierta los datos en un nodo secundario del XML.

En su ejemplo, tiene una persona que tiene un nombre y una edad. Tengo nombre, segundo nombre y apellido ... y un apodo. Y algunas personas tienen apellidos de soltera, múltiples segundos nombres u honoríficos: ¿cómo pondrían a John Ronald Reuel Tolkien en una estructura así?

Y entonces tenemos a alguien que tiene dos segundos nombres que tienen un orden para ellos. Esto debería mostrar claramente que no, un atributo no es la mejor opción para esto.

_{No puedo encontrarlo actualmente, pero en el documento vinculado anterior hay una declaración de que los nombres son cosas que requieren un poco de reflexión que conducen a "Espero ampliar el tratamiento de los nombres de las personas en el marcado en un artículo futuro". Si alguien tiene una pista sobre esto, deje un comentario o edítelo en este lugar.}

Por otro lado, la edad es algo que tiene una estructura bastante fija (sugeriría el cumpleaños en lugar de un número entero). Como tal, representar esta información en un formato bien conocido y comprendido tiene sentido en un atributo. Una persona tiene uno y solo un cumpleaños y no hay "pedidos" que desee conservar.

Uche Ogbuji identifica tres principios básicos en el diseño adecuado de un formato xml. Las siguientes son citas abreviadas del documento vinculado anterior.

• Principio de información estructurada
  Si la información se expresa de forma estructurada, especialmente si la estructura puede ser extensible, use elementos. Por otro lado: si la información se expresa como un token atómico, use atributos
• Principio de legibilidad
  Si la información está destinada a ser leída y entendida por una persona, utilice elementos. Si la información es más fácil de entender y digerir por una máquina, use atributos.
• Principio de enlace elemento / atributo
  Use un elemento si necesita que su valor sea modificado por otro atributo

Por lo tanto, los nombres deben ser elementos: son datos estructurados que no son un token atómico, es más probable que sean leídos por un humano que una computadora y pueden ser modificados por otro atributo en el nombre mismo.

Las fechas deben ser atributos: son datos que son un token atómico, es más probable que sean leídos por una computadora que un ser humano (y luego transformados al formato preferido del ser humano si es necesario ), y por último, es poco probable que sean modificados por otro atributos en ellos.

Otra consideración más allá de las de rolfl es el número de campos.
Más de una pequeña cantidad de atributos se convierte en un desastre y es difícil de leer (eso supone que desea que su xml sea legible para los humanos, pero como programador querrá hacer eso para probar al menos).

Además, si espera que la estructura de datos de uno de los campos cambie con el tiempo, no lo convierta en un atributo.
Por ejemplo, su campo de nombre. Quizás en el futuro esto se convierta

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

Si espera que suceda algo así, convertirlo en un atributo significaría más código de refactorización más adelante.

Para la etiqueta de Personas, es normal tener más etiquetas de Persona, tiene sentido, una lista de Personas tiene algunas entidades, no atributos.

La historia es diferente para la Persona y sus componentes. Una persona no contiene un nombre, el nombre es un atributo de la persona, por lo que me quedaría con atributos en lugar de nuevas etiquetas. Las etiquetas son útiles cuando tienes cosas repetitivas como Direcciones, no puedes hacerlo con atributos.

Si pensamos en contexto HTML, no tiene una entrada con una etiqueta de nombre con un valor, ¿verdad?