¿Cómo debería estructurar su archivo xml?

Question

Al crear un nuevo archivo xml, ¿cómo se estructura el archivo correctamente o de la mejor manera posible? Por estructura, que puede no ser la mejor palabra en este caso, me refiero a cómo se elige entre hacer que un elemento o un atributo de un elemento. Por ejemplo, si se crea un archivo Person.xml que contiene una lista de las personas, es mejor hacer algo como:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Doe</LastName> 
    <Age>23</Age> 
</Person> 

o es mejor hacer algo como esto o lo hace siquiera importa?

<Person FirstName="John" LastName="Doe" Age="23"></Person> 

Answer 1

archivos XML debe (no para iniciar una guerra santa) la siguiente estructura:

Si se trata de datos, o algo que se puede cambiar, entonces debería ser así:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Smith</LastName> 
    <Age>23</Age> 
</Person> 

Si es un atributo de la cosa Person entonces debería ser así:

Hay varias razones para esta práctica, no menos importante de los cuales incluye la facilidad de f Ixing XSLT Transforms cada vez que cambie su método de recuperación de datos Persona.

Esa es realmente la parte importante: los atributos definen la información sobre los datos (el tipo de persona), y los datos son algo que debe rellenar esos agujeros. Si decide cómo va a cambiar la forma en que rellena esos huecos, se vuelve más difícil si los ha convertido en "atributos" en lugar de "datos" cuando desea Transformar su XML más adelante.

Answer 2

Es más o menos algo subjetivo.

Answer 3

Realmente no importa, pero la forma en que decido es: si algo podría considerarse una entidad en sí misma (en este ejemplo, Persona, lo hago un elemento. Si es algo que modifica la entidad (o un atributo de la entidad), que hacen que sea un atributo

Ejemplo:.

<Person FirstName="John" LastName="Doe" Age="23"> 
    <Clothing wet="No"> 
     <Shirt colour="Red" /> 
    </Clothing> 
</Person> 

Answer 4

me parece esto es algo parecido a Chevy vs Ford, o Windows vs Mac OS no hay ganador claro para todos. situaciones, y la mera pregunta puede generar una "discusión" altamente volátil con los participantes correctos.;) ​​

La respuesta corta es que cualquiera puede ser apropiado dependiendo de la situación. A veces, el factor decisivo es incluso qué biblioteca elige para leer o actualizar los datos en el XML.

Answer 5

Aquí es una pretty good article sobre los princeiples de diseño XML:

• Principles of XML design: When to use elements versus attributes

Answer 6

La primera es la forma verbosa de hacer las cosas: Todo es un elemento. Esta es una forma común en que las personas hacen esto simplemente porque es muy fácil de ver y analizar.

Sin embargo, los atributos se introdujeron por este motivo: son fragmentos de información sobre el elemento. Entonces, tu segundo ejemplo es perfectamente aceptable.De hecho, incluso podría acortarlo:

<Person FirstName="John" LastName="Doe" Age="23" /> 

Probablemente haga lo segundo.

La única ocasión en la que no desearía esto es si necesita tener más datos xml en el interior, o secciones formateadas largas.

Answer 7

En general, desea que los elementos representen la información "real" que está modelando, y los atributos de reserva para la información "meta", que califica el contenido.

Answer 8

Independientemente del gusto personal, aquí está el conjunto fundamental de cuestiones:

utilizar atributos para asignar valores a los nombres únicos en el pedido no es significativo. De lo contrario, usa elementos.

• Valores: números, cadenas, fechas, etc., pero no objetos de varias propiedades.
• Nombres únicos: cada nombre de atributo en un elemento debe ser único. Si una cosa representada por un elemento puede tener más de un Foo asociado con ella, Foo no debería ser un atributo.
• El pedido no es significativo: la aplicación no puede depender de los valores que se presenten a los procesos en un orden en particular.

Un ejemplo: si desea datos de ida y vuelta entre (digamos) ADO.NET y XML, ¿debe almacenar valores de columna en atributos o elementos? (No importa por un momento que ADO.NET haga esto por usted). Bueno, los nombres de las columnas se asignan a los valores de manera única, y los valores de columna son tipos de datos fácilmente serializables. Muy seguro, ¿por qué no hacer esto?

<Person FirstName="John" MiddleName="Q." LastName="Smith"/> 

Pero en realidad esa es una transformación destructora de la información. El orden en que aparecen las columnas en un registro de ADO.NET es significativo. Si hay algo en la columna 2 antes de su transformación, debería estar en la columna 2 después. Convertirlos en atributos perderá esta información. (Sé que una implementación DOM, por ejemplo, que recupera los atributos en orden alfabético por el nombre.)

Esta es la razón por ADO.NET representa filas de este tipo, aunque es prolijo:

<Person> 
    <FirstName>John</FirstName> 
    <MiddleName>Q.</MiddleName> 
    <LastName>Smith</LastName> 
</Person> 

En cuanto a la la sabiduría común de que los elementos son para información, y los atributos son para metainformación: a menudo es un buen consejo. A menudo, también es superstición lo que los llevará a lugares malos.

Por un lado, la metainformación puede necesitar contener múltiples valores asociados con el mismo nombre. Es posible, por ejemplo, querer etiquetar un elemento con una lista de páginas que se van a usar:

<Person Pages="B1,B2,B3,B4"> 
    <FirstName>John... 

vez ha tratado de escribir una plantilla XSLT que analiza una lista separada por comas? Aprenderá mucho al hacerlo, pero probablemente no sea algo que quiera saber.

Por otro lado, los diseñadores de XML que no saben a qué se enfrentan, permiten que estos consejos los lleven a poner un atributo que debería ser realmente en el nombre de la etiqueta del elemento. Por ejemplo:

<Person Type="Employee"> 
    <SSN>123-45-6789</SSN> 
    <Extension>123</Extension> 
</Person> 
<Person Type="Customer"> 
    <PhoneNumber>123-456-7890</PhoneNumber> 
    <BillingAddress>... 

y así sucesivamente.¿Adivina qué sucede cuando intenta escribir un esquema que impone reglas diferentes en los elementos Person basados ​​en el atributo Type? Fracaso. Los esquemas están vinculados al nombre del elemento. Todos los elementos Person deben tener el mismo esquema. En este caso, los elementos deben llamarse Employee y Customer.