¿Cuándo debe usar atributos XML y cuándo debe usar elementos XML?XML Attributes vs Elements
p. Ej.
<customData>
<records>
<record name="foo" description="bar" />
</records>
</customData>
o
<customData>
<records>
<record>
<name>foo</name>
<description>bar</description>
</record>
</records>
</customData>
Personalmente como el uso de los atributos de las propiedades de un solo valor simples. Los elementos son (obviamente) más adecuados para tipos complejos o valores repetidos.
Para propiedades de un solo valor, los atributos dan como resultado un XML más compacto y un direccionamiento más simple en la mayoría de las API.
La dificultad está en el xml 'cultivado orgánicamente' sin DTD o Schema determina qué será siempre una propiedad de un solo valor. – AnthonyWJones
Es en gran medida una cuestión de preferencia. Uso los elementos para la agrupación y los atributos para los datos siempre que sea posible, ya que veo esto como más compacto que la alternativa.
Por ejemplo, yo 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 contiene 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>
Las limitaciones de atributos que indican dónde se puede y no se pueden utilizar: los nombres de los atributos deben ser únicos, su orden no puede ser significativo, y tanto el nombre y el valor sólo pueden contener 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 propiedades en un objeto, de columnas en una fila de una tabla, de entradas en un diccionario. (Pero no si las propiedades no son todos los tipos de valor, o las entradas en el diccionario no son cadenas.)
Uno de los mejores argumentos de elementos contra diseño proviene del UK GovTalk guidelines. 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.
esquemas deben estar diseñados de modo que elementos son los principales tenedores de de contenido de información en el XML casos. Los atributos son más adecuados a la celebración de metadatos auxiliares: elementos simples que proporcionan más información sobre el contenido del elemento. Los atributos DEBEN NO deben usarse para calificar otros atributos donde esto podría causar ambigüedad de .
A diferencia de los elementos, los atributos no pueden contener datos estructurados. Por esta razón, se prefieren los elementos como los titulares de la información del contenido de información.Sin embargo, lo que permite el uso de atributos para mantener los metadatos de contenido de un elemento (por ejemplo, el formato de una fecha, una unidad de medida o la identificación de un conjunto de valores) pueden hacer un documento de instancia sencilla y más fácil comprender.
Una fecha de nacimiento podría estar representado en un mensaje como:
<DateOfBirth>1975-06-03</DateOfBirth>
Sin embargo, más información puede ser requiere, por ejemplo, cómo se ha verificado que la fecha de nacimiento . Esto podría ser define como un atributo, por lo que el elemento en un mensaje parezca:
<DateOfBirth VerifiedBy="View of Birth Certificate">1975-06-03</DateOfBirth>
La siguiente sería inapropiada:
<DateOfBirth VerifiedBy="View of Birth Certificate" ValueSet="ISO 8601" Code="2">1975-06-03</DateOfBirth>
No es aclare aquí si el Código califica a VerifiedBy o al ValueSet atributo. Un interpretación más apropiada sería:
<DateOfBirth>
<VerifiedBy Code="2">View of Birth Certificate</VerifiedBy>
<Value ValueSet="ISO 8601">1975-06-03</Value>
</DateOfBirth>
La URL del documento parece estar muerta, pero es un archivo aquí: http://collections.europarchive.org/tna/20060924203316/http://govtalk.gov.uk/schemasstandards/developerguide_document.asp?docnum=946 –
Hay un artículo titulado "Principles of XML design: When to use elements versus attributes" 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 haciendo referencia a este artículo de vez en cuando mientras desarrollo varias estructuras XML. Espero que esto sea útil también para otros.
edición - Desde el sitio:
Principio de contenido básico
Si se tiene en cuenta la información en cuestión a ser parte del material esencial que se expresa o se comunica en el XML, lo puso 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, generalmente de fabricación nacional en las empresas, donde los títulos de 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, utilizar 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.
It sería bueno si resumiera las "buenas pautas". –
Consulte Elements vs. attributes por Ned Batchelder.
Buena explicación y una buena lista de los beneficios y desventajas de los Elementos y Atributos.
Se hierve abajo a:
Recomendación: Usar elementos de datos que serán producidos o consumidos por una aplicación de negocios, y los atributos de metadatos.
Importante: Consulte el comentario de @ maryisdead a continuación para obtener más aclaraciones.
En realidad, él no. Es solo una cita de [Modelo de referencia ASC X12 para diseño XML] (http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf) que en realidad desarma. Lo que recomienda es: _ "Digo: use atributos a menos que realmente necesite elementos. Necesita elementos para una cosa si la cosa se puede repetir, o está estructurada, o tiene una semántica basada en su orden entre sus pares". _ – maryisdead
La cita más reveladora de Ned fue: "Segundo, ** diseñé el sistema en cuestión **, y pensé que la decisión del atributo era acertada. Todos eran tipos de datos simples, no tenían orden y solo podían aparecer. una vez. En este caso, los atributos son perfectamente razonables, y significa que ** puede evitar la sobrecarga de las etiquetas finales **. " – dbasnett
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.
Aquí hay otra estrategia que puede ayudar a distinguir los elementos de los 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 los 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.
Así que el siguiente tendría sentido teniendo en cuenta el bibliotecario primero añadir un elemento de libro (o una revista), y luego se puede editar su nombre del 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>
-1: Eso no tiene ningún sentido en absoluto: diseñar su XML basado en cómo se implementa ASP.NET MVC. –
Como regla general, evito 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 tiene que recordar cómo modeló ningún tipo de información en particular. No usar atributos significa que tiene una cosa menos en qué pensar.
¿Por qué el voto a favor? Este enfoque no tiene otra desventaja real que la verbosidad, y si te preocupa eso, entonces probablemente no deberías usar XML en primer lugar. No hay nada que puedas hacer en un atributo que no se puede hacer en un elemento, pero el reverso ciertamente no es el caso. – Dan
No soy el votante, pero esta es mi opinión. ¿Qué pasa si alguien dice "no te preocupes por todas esas etiquetas HTML de nivel de bloque como' p''li'' ol' ... Solo usa 'div' para todo. Puedes hacer todo con un' div', y nunca necesita preocuparse por la semántica detallada ". Aunque los atributos no son los mismos, en este ejemplo exacto, el efecto es similar. Pierdes valor semántico, que en el caso de XML es importante, incluso si 'funciona'. – TechZilla
Ese sería un buen argumento si hubiera un significado semántico claro asociado a los atributos frente a los elementos. El hecho de que esta pregunta continúe preguntándose una y otra vez es precisamente porque ese no es el caso. – Dan
Mi regla de oro personal: si un elemento puede contener solo una de esas cosas, y es un dato atómico (id, nombre, edad, tipo, etc.), debería ser un atributo, sino un elemento.
Debe usar las versiones de escape de < and > para poner las etiquetas. – workmad3