que - Atributos XML vs Elementos
etiquetas basicas de xml (10)
Esta pregunta ya tiene una respuesta aquí:
- XML attribute vs XML element 20 respuestas
¿Cuándo debe usar atributos XML y cuándo debe usar elementos XML?
p.ej
<customData>
<records>
<record name="foo" description="bar" />
</records>
</customData>
o
<customData>
<records>
<record>
<name>foo</name>
<description>bar</description>
</record>
</records>
</customData>
Aquí hay otra estrategia que puede ayudar a distinguir elementos de atributos: pensar en objetos y tener en cuenta MVC.
Los objetos pueden tener miembros (variables de objeto) y propiedades (miembros con setters y getters). Las propiedades son muy útiles con el diseño de MVC, lo que permite el mecanismo de notificación de cambios.
Si esta es la dirección tomada, los atributos se usarán para datos internos de la aplicación que no pueden ser cambiados por el usuario; los ejemplos clásicos serán ID o DATE_MODIFIED. Por lo tanto, los elementos se usarán para datos que los usuarios puedan modificar.
Por lo tanto, lo siguiente tendría sentido considerando que el bibliotecario primero agrega un elemento del libro (o una revista), y luego puede editar su nombre, autor, ISBN, etc.
<?xml version="1.0" encoding="utf-8"?>
<item id="69" type="book">
<authors count="1">
<author>
<name>John Smith</name>
<author>
</authors>
<ISBN>123456790</ISBN>
</item>
Como regla general, evito los atributos por completo. Sí, los atributos son más compactos, pero los elementos son más flexibles y la flexibilidad es una de las ventajas más importantes de usar un formato de datos como XML. Lo que es un valor único hoy puede convertirse en una lista de valores mañana.
Además, si todo es un elemento, nunca debe recordar cómo modeló un determinado bit de información. No usar atributos significa que tiene una cosa menos en qué pensar.
Echa un vistazo a Elementos contra atributos de Ned Batchelder.
Buena explicación y una buena lista de los beneficios y desventajas de los Elementos y Atributos.
Él lo reduce a:
Recomendación: Use elementos para los datos que serán producidos o consumidos por una aplicación comercial, y atributos para los metadatos.
Importante: Consulte el comentario de @ maryisdead a continuación para obtener más información.
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"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" />
<person name="Travis" surname="Illig" age="32" />
<person name="Scott" surname="Hanselman" age="34" />
</people>
</data>
...En lugar de....
<?xml version="1.0" encoding="utf-8"?>
<data>
<people>
<person>
<name>Rory</name>
<surname>Becker</surname>
<age>30</age>
</person>
<person>
<name>Travis</name>
<surname>Illig</surname>
<age>32</age>
</person>
<person>
<name>Scott</name>
<surname>Hanselman</surname>
<age>34</age>
</person>
</people>
</data>
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"?>
<data>
<people>
<person name="Rory" surname="Becker" age="30" >
<comment>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</comment>
</person>
<person name="Travis" surname="Illig" age="32" >
<comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
</person>
<person name="Scott" surname="Hanselman" age="34" >
<comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
</person>
</people>
</data>
Hay un artículo titulado " Principios del diseño XML: cuándo usar elementos versus atributos " en el sitio web de IBM.
Aunque no parece haber muchas reglas duras y rápidas, hay algunas buenas pautas mencionadas en la publicación. Por ejemplo, una de las recomendaciones es usar elementos cuando sus datos no se deben normalizar para el espacio en blanco, ya que los procesadores XML pueden normalizar los datos dentro de un atributo, modificando así el texto sin formato.
Me encuentro refiriéndome a este artículo de vez en cuando a medida que desarrollo varias estructuras XML. Espero que esto sea útil también para otros.
editar - Desde el sitio:
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. Para documentos legibles por personas, esto generalmente significa el contenido central que se está comunicando al lector. Para los formatos de registros orientados a la máquina, esto generalmente significa los datos que provienen directamente del dominio del problema. 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. Esto evita saturar el contenido del núcleo con material auxiliar. Para los formatos de registros orientados a la máquina, esto generalmente significa notaciones específicas de la aplicación en los datos principales del dominio del problema.
Como ejemplo, he visto muchos formatos XML, por lo general de fabricación local en las empresas, donde los títulos de los documentos se colocaron en un atributo. Creo que un título es una parte tan fundamental de la comunicación de un documento que siempre debe estar en el contenido del elemento. Por otro lado, a menudo he visto casos en que los identificadores internos del producto se arrojaron como elementos en los registros descriptivos del producto. En algunos de estos casos, los atributos eran más apropiados porque el código de producto interno específico no sería de interés primario para la mayoría de los lectores o procesadores del documento, especialmente cuando el ID era de un formato muy largo o inescrutable.
Es posible que haya escuchado que los datos principales van en los elementos, los metadatos en los atributos. Los dos párrafos anteriores realmente expresan el mismo principio, pero en un lenguaje más deliberado y menos confuso.
Principio de información estructurada
Si la información se expresa en una 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. Los elementos son el motor extensible para expresar la estructura en XML. Casi todas las herramientas de procesamiento XML están diseñadas en torno a este hecho, y si descompone adecuadamente la información estructurada en elementos, descubrirá que sus herramientas de procesamiento complementan su diseño y que, por lo tanto, obtendrá productividad y capacidad de mantenimiento. Los atributos están diseñados para expresar propiedades simples de la información representada en un elemento. Si trabajas en contra de la arquitectura básica de XML ajustando la información estructurada en atributos, puedes obtener cierta concisión y conveniencia, pero probablemente pagues los costos de mantenimiento.
Las fechas son un buen ejemplo: una fecha tiene una estructura fija y, en general, actúa como un único token, por lo que tiene sentido como un atributo (preferiblemente expresado en ISO-8601). Representar nombres personales, por otro lado, es un caso en el que he visto a este principio sorprender a los diseñadores. Veo mucho los nombres en los atributos, pero siempre he sostenido que los nombres personales deben estar en el contenido del elemento. Un nombre personal tiene una estructura sorprendentemente variable (en algunas culturas puede causar confusión u ofensa al omitir honoríficos o asumir un orden de partes de nombres). Un nombre personal raramente es un token atómico. Como ejemplo, a veces es posible que desee buscar u ordenar por un nombre de pila y, a veces, por un apellido. Debo señalar que es tan problemático calzar un nombre completo en el contenido de un solo elemento como ponerlo en un atributo.
Las limitaciones de los atributos le indican dónde puede y no puede usarlos: los nombres de los atributos deben ser únicos, su orden no puede ser significativo, y tanto el nombre como el valor pueden contener solo texto. Los elementos, por el contrario, pueden tener nombres no únicos, tener un orden significativo y pueden tener contenido mixto.
Los atributos se pueden usar en dominios donde se asignan a estructuras de datos que siguen esas reglas: los nombres y valores de las propiedades en un objeto, de las columnas en una fila de una tabla, de las entradas en un diccionario. (Pero no si las propiedades no son todos tipos de valores, o las entradas en el diccionario no son cadenas).
Mi regla general personal: si un elemento puede contener solo una de esas cosas, y es un dato atómico (id, nombre, edad, tipo, etc.), debe ser un atributo, sino un elemento.
Personalmente, me gusta usar atributos para propiedades simples de un solo valor. Los elementos son (obviamente) más adecuados para tipos complejos o valores repetidos.
Para propiedades de un solo valor, los atributos conducen a un XML más compacto y a un direccionamiento más simple en la mayoría de las API.
Tiendo a utilizar elementos cuando se trata de datos que un lector humano debería conocer y atribuir cuando solo se trata de procesamiento (por ejemplo, ID). Esto significa que raramente uso atributos, ya que la mayoría de los datos son relevantes para el dominio que se modela.
Uno de los mejores elementos contra los argumentos de los elementos contra los atributos proviene de las directrices de GovTalk del Reino Unido . Esto define las técnicas de modelado utilizadas para los intercambios XML relacionados con el gobierno, pero se basa en sus propios méritos y vale la pena considerarlo.
Los esquemas DEBEN estar diseñados para que los elementos sean los principales poseedores de contenido de información en las instancias XML. Los atributos son más adecuados para contener metadatos auxiliares: elementos simples que proporcionan más información sobre el contenido del elemento. Los atributos NO DEBEN ser utilizados para calificar otros atributos donde esto podría causar ambigüedad.
A diferencia de los elementos, los atributos no pueden contener datos estructurados. Por esta razón, se prefieren los elementos como los principales titulares de contenido de información. Sin embargo, permitir el uso de atributos para mantener metadatos sobre el contenido de un elemento (por ejemplo, el formato de una fecha, una unidad de medida o la identificación de un conjunto de valores) puede hacer que un documento de instancia sea más simple y fácil de entender.
Una fecha de nacimiento puede estar representada en un mensaje como:
<DateOfBirth>1975-06-03</DateOfBirth>
Sin embargo, es posible que se requiera más información, por ejemplo, cómo se ha verificado esa fecha de nacimiento. Esto podría definirse como un atributo, haciendo que el elemento en un mensaje se vea como:
<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>
Lo siguiente sería inapropiado:
<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>
Aquí no está claro si el Código califica el atributo VerifiedBy o ValueSet. Una versión más apropiada sería:
<DateOfBirth>
<VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>
<Value ValueSet="ISO 8601">1975-06-03</Value>
</DateOfBirth>