Atributo XML frente a elemento XML
https://stackoverflow.com/questions/33746
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
En el trabajo se nos pide que creemos archivos XML para pasar datos a otra aplicación fuera de línea que luego creará un segundo archivo XML para pasar de vuelta y actualizar algunos de nuestros datos.Durante el proceso hemos estado discutiendo con el equipo de la otra aplicación sobre la estructura del archivo XML.
La muestra que se me ocurrió es esencialmente algo como:
<INVENTORY>
<ITEM serialNumber="something" location="something" barcode="something">
<TYPE modelNumber="something" vendor="something"/>
</ITEM>
</INVENTORY>
El otro equipo dijo que esto no era un estándar de la industria y que los atributos solo deberían usarse para metadatos.Sugirieron:
<INVENTORY>
<ITEM>
<SERIALNUMBER>something</SERIALNUMBER>
<LOCATION>something</LOCATION>
<BARCODE>something</BARCODE>
<TYPE>
<MODELNUMBER>something</MODELNUMBER>
<VENDOR>something</VENDOR>
</TYPE>
</ITEM>
</INVENTORY>
La razón por la que sugerí la primera es que el tamaño del archivo creado es mucho más pequeño.Habrá aproximadamente 80.000 elementos en el archivo durante la transferencia.Su sugerencia en realidad resulta ser tres veces mayor que la que yo sugerí.Busqué el misterioso "Estándar de la industria" que se mencionó, pero lo más cercano que pude encontrar fue que los atributos XML solo deberían usarse para metadatos, pero dije que el debate era sobre qué eran realmente metadatos.
Después de la larga explicación (lo siento), ¿cómo se determina qué son los metadatos y, al diseñar la estructura de un documento XML, cómo se debe decidir cuándo utilizar un atributo o un elemento?
Solución
Yo uso esta regla general:
- Un Atributo es algo autónomo, es decir, un color, un ID, un nombre.
- Un Elemento es algo que tiene o podría tener atributos propios o contener otros elementos.
Entonces el tuyo está cerca.Habría hecho algo como:
EDITAR:Se actualizó el ejemplo original según los comentarios a continuación.
<ITEM serialNumber="something">
<BARCODE encoding="Code39">something</BARCODE>
<LOCATION>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
Otros consejos
Algunos de los problemas con los atributos son:
- los atributos no pueden contener múltiples valores (los elementos secundarios sí pueden)
- los atributos no se pueden ampliar fácilmente (para cambios futuros)
- los atributos no pueden describir estructuras (los elementos secundarios sí pueden)
- Los atributos son más difíciles de manipular mediante el código del programa.
- Los valores de los atributos no son fáciles de probar con una DTD.
Si utiliza atributos como contenedores de datos, terminará con documentos que son difíciles de leer y mantener.Intente utilizar elementos para describir datos.Utilice atributos sólo para proporcionar información que no sea relevante para los datos.
No termines así (no es así como se debe usar XML):
<note day="12" month="11" year="2002"
to="Tove" to2="John" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>
"XML" significa "eXtensible" Margen Idioma".Un lenguaje de marcado implica que los datos son texto, marcado con metadatos sobre estructura o formato.
XHTML es un ejemplo de XML utilizado de la manera prevista:
<p><span lang="es">El Jefe</span> insists that you
<em class="urgent">MUST</em> complete your project by Friday.</p>
Aquí, la distinción entre elementos y atributos es clara.Los elementos de texto se muestran en el navegador y los atributos son instrucciones sobre cómo para mostrarlas (aunque hay algunas etiquetas que no funcionan de esa manera).
La confusión surge cuando XML no se utiliza como lenguaje de marcado, sino como serialización de datos lenguaje, en el que la distinción entre "datos" y "metadatos" es más vaga.Entonces, la elección entre elementos y atributos es más o menos arbitraria, excepto en el caso de cosas que no poder ser representado con atributos (ver la respuesta de Feenster).
Elemento XML frente a atributo XML
XML tiene que ver con el acuerdo. En primer lugar, respete los esquemas XML existentes o las convenciones establecidas dentro de su comunidad o industria.
Si realmente se encuentra en una situación para definir su esquema desde cero, aquí hay algunas consideraciones generales que deberían informar al decisión elemento vs atributo:
<versus>
<element attribute="Meta content">
Content
</element>
<element attribute="Flat">
<parent>
<child>Hierarchical</child>
</parent>
</element>
<element attribute="Unordered">
<ol>
<li>Has</li>
<li>order</li>
</ol>
</element>
<element attribute="Must copy to reuse">
Can reference to re-use
</element>
<element attribute="For software">
For humans
</element>
<element attribute="Extreme use leads to micro-parsing">
Extreme use leads to document bloat
</element>
<element attribute="Unique names">
Unique or non-unique names
</element>
<element attribute="SAX parse: read first">
SAX parse: read later
</element>
<element attribute="DTD: default value">
DTD: no default value
</element>
</versus>
Puede depender de su uso.XML que se utiliza para representar datos estructurados generados a partir de una base de datos puede funcionar bien si, en última instancia, los valores de campo se colocan como atributos.
Sin embargo, XML utilizado como transporte de mensajes suele ser mejor si utiliza más elementos.
Por ejemplo, digamos que tenemos este XML como se propone en la respuesta: -
<INVENTORY>
<ITEM serialNumber="something" barcode="something">
<Location>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
</INVENTORY>
Ahora queremos enviar el elemento ITEM a un dispositivo para imprimir el código de barras; sin embargo, hay una variedad de tipos de codificación.¿Cómo representamos el tipo de codificación requerido?De repente nos damos cuenta, un poco tarde, de que el código de barras no era un valor automático único sino que podía estar calificado con la codificación requerida al imprimirse.
<ITEM serialNumber="something">
<barcode encoding="Code39">something</barcode>
<Location>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>
El punto es que, a menos que construya algún tipo de XSD o DTD junto con un espacio de nombres para fijar la estructura en piedra, es mejor que deje sus opciones abiertas.
En mi opinión, XML es más útil cuando se puede flexionar sin romper el código existente al usarlo.
Utilizo las siguientes pautas en el diseño de mi esquema con respecto a atributos vs.elementos:
- Use elementos para el texto de ejecución larga (generalmente los de la cadena o los tipos de string normalizados)
- No utilice un atributo si hay una agrupación de dos valores (p. ej.eventStartDate y eventEndDate) para un elemento.En el ejemplo anterior, debe haber un nuevo elemento para el "evento" que puede contener los atributos de inicio y fecha final.
- Fecha comercial, fecha, hora y números (p. ej.Los recuentos, la cantidad y la tasa) deben ser elementos.
- Los elementos de tiempo no comerciales, como la última actualización, vencen los atributos.
- Los números no comerciales, como códigos hash e índices, deben ser atributos.* Utilice elementos si el tipo será complejo.
- Utilice atributos si el valor es de tipo simple y no se repite.
- xml:id y xml:lang deben ser atributos que hagan referencia al esquema XML
- Prefiere atributos cuando sea técnicamente posible.
La preferencia por los atributos proporciona lo siguiente:
- único (el atributo no puede aparecer varias veces)
- el orden no importa
- las propiedades anteriores son heredables (esto es algo que el modelo de "todo" el contenido no admite en el lenguaje de esquema actual)
- La ventaja es que son menos detallados y consumen menos ancho de banda, pero esa no es realmente una razón para preferir atributos a elementos.
yo añadí cuando sea técnicamente posible porque hay ocasiones donde el uso de atributos no es posible.Por ejemplo, opciones de conjuntos de atributos.Por ejemplo, el uso (startDate y endDate) xor (startTS y endTS) no es posible con el lenguaje de esquema actual.
Si el esquema XML comienza a permitir que se restrinja o amplíe el modelo de "todo" el contenido, entonces probablemente lo eliminaría.
No existe una respuesta universal a esta pregunta (estuve muy involucrado en la creación de la especificación W3C).XML se puede utilizar para muchos propósitos: documentos tipo texto, datos y código declarativo son tres de los más comunes.También lo uso mucho como modelo de datos.Hay aspectos de estas aplicaciones donde los atributos son más comunes y otros donde los elementos secundarios son más naturales.También hay características de varias herramientas que facilitan o dificultan su uso.
XHTML es un área donde los atributos tienen un uso natural (p. ej.en clase = 'foo').Los atributos no tienen orden y esto puede facilitar que algunas personas desarrollen herramientas.Los atributos OTOH son más difíciles de escribir sin un esquema.También encuentro que los atributos con espacios de nombres (foo:bar="zork") suelen ser más difíciles de administrar en varios conjuntos de herramientas.Pero eche un vistazo a algunos de los lenguajes del W3C para ver la combinación común.SVG, XSLT, XSD, MathML son algunos ejemplos de lenguajes conocidos y todos tienen una gran cantidad de atributos y elementos.Algunos idiomas incluso permiten hacerlo en más de una forma, p.
<foo title="bar"/>;
o
<foo>
<title>bar</title>;
</foo>;
Tenga en cuenta que estos NO son equivalentes sintácticamente y requieren soporte explícito en las herramientas de procesamiento)
Mi consejo sería echar un vistazo a las prácticas comunes en el área más cercana a su aplicación y también considerar qué conjuntos de herramientas desea aplicar.
Finalmente asegúrese de diferenciar los espacios de nombres de los atributos.Algunos sistemas XML (p. ej.Linq) representan espacios de nombres como atributos en la API.En mi opinión, esto es feo y potencialmente confuso.
En caso de duda, BESO - ¿Por qué mezclar atributos y elementos cuando no tienes una razón clara para usar atributos?Si luego decide definir un XSD, terminará siendo más limpio también.Luego, si más adelante decides generar una estructura de clases a partir de tu XSD, eso también será más sencillo.
¡La pregunta del millón!
En primer lugar, no se preocupe demasiado por el rendimiento ahora.Se sorprenderá de lo rápido que un analizador xml optimizado analizará su xml.Más importante aún, ¿cuál es su diseño para el futuro?A medida que XML evolucione, ¿cómo se mantendrá el acoplamiento flexible y la interoperabilidad?
Más concretamente, puedes hacer que el modelo de contenido de un elemento sea más complejo, pero es más difícil extender un atributo.
Utilice elementos para datos y atributos para metadatos (datos sobre los datos del elemento).
Si un elemento aparece como predicado en sus cadenas seleccionadas, tiene una buena señal de que debería ser un atributo.Del mismo modo, si un atributo nunca se utiliza como predicado, entonces tal vez no sean metadatos útiles.
Recuerde que se supone que XML es legible por máquinas, no por humanos, y para documentos grandes, XML se comprime muy bien.
Otros han explicado cómo diferenciar atributos de elementos, pero desde una perspectiva más general, poner todo en atributos porque hace que el XML resultante sea más pequeño es incorrecto.
XML no está diseñado para ser compacto sino para ser portátil y legible por humanos.Si desea reducir el tamaño de los datos en tránsito, utilice otra cosa (como buffers de protocolo de google).
Es discutible de cualquier manera, pero sus colegas tienen razón en el sentido de que el XML debe usarse para "marcar" o metadatos alrededor de los datos reales.Por tu parte, tienes razón en que a veces es difícil decidir dónde está la línea entre metadatos y datos al modelar tu dominio en XML.En la práctica, lo que hago es fingir que todo lo que hay en el marcado está oculto y que solo los datos fuera del marcado son legibles.¿Tiene el documento algún sentido en ese sentido?
XML es notoriamente voluminoso.Para el transporte y el almacenamiento, se recomienda encarecidamente la compresión si puede permitirse la potencia de procesamiento.XML se comprime bien, a veces fenomenalmente bien, debido a su repetitividad.He comprimido archivos grandes a menos del 5% de su tamaño original.
Otro punto para reforzar su posición es que mientras el otro equipo discute sobre estilo (en el sentido de que la mayoría de las herramientas XML manejarán un documento de todos los atributos tan fácilmente como un documento exclusivamente #PCDATA), usted está discutiendo aspectos prácticos.Si bien el estilo no puede ignorarse por completo, los méritos técnicos deberían tener más peso.
Ambos métodos para almacenar las propiedades de un objeto son perfectamente válidos.Hay que apartarse de consideraciones pragmáticas.Intente responder la siguiente pregunta:
- ¿Qué representación conduce a un análisis/generación de datos más rápido?
- ¿Qué representación conduce a una transferencia de datos más rápida?
¿Importa la legibilidad?
...
Es en gran medida una cuestión de preferencia.Utilizo elementos para agrupar y atributos para datos siempre que sea posible, ya que lo veo 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 se representan fácilmente dentro de, digamos, 20 a 30 caracteres o que contienen muchas comillas u otros caracteres que deben escaparse, entonces diría que es hora de dividir 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>
¿Qué tal aprovechar nuestra intuición de orientación a objetos, obtenida con mucho esfuerzo?Normalmente encuentro que es sencillo pensar qué es un objeto y cuál es un atributo del objeto o a qué objeto se refiere.
Lo que intuitivamente tenga sentido como objetos, encajará como elementos.Sus atributos (o propiedades) serían atributos para estos elementos en xml o elemento secundario con atributo.
Creo que para casos más simples, como en el ejemplo, la analogía de la orientación de objetos funciona bien para determinar cuál es el elemento y cuál es el atributo de un elemento.
Sólo un par de correcciones a alguna mala información:
@John Ballinger:Los atributos pueden contener cualquier dato de carácter.< > & " ' deben escaparse a <>&"y ', respectivamente.Si utiliza una biblioteca XML, ella se encargará de ello por usted.
Demonios, un atributo puede contener datos binarios como una imagen, si realmente lo deseas, simplemente codificándolo en base64 y convirtiéndolo en un dato:URL.
@feenster:Los atributos pueden contener varios elementos separados por espacios en el caso de IDS o NAMES, que incluirían números.Quisquilloso, pero esto puede terminar ahorrando espacio.
El uso de atributos puede mantener a XML competitivo con JSON.Ver Marcado de grasa:Recortar el mito del margen de grasa una caloría a la vez.
Siempre me sorprenden los resultados de este tipo de discusiones.Para mí, existe una regla muy simple para decidir si los datos pertenecen a un atributo o como contenido y es si los datos tienen una subestructura navegable.
Entonces, por ejemplo, el texto sin marcado siempre pertenece a los atributos.Siempre.
Las listas pertenecen a la subestructura o al contenido.El texto que con el tiempo pueda incluir subcontenido estructurado incrustado pertenece al contenido.(En mi experiencia, hay relativamente poco de esto (texto con marcado) cuando se usa XML para el almacenamiento o intercambio de datos).
El esquema XML escrito de esta manera es conciso.
Siempre que veo casos como <car><make>Ford</make><color>Red</color></car>, Pienso para mis adentros "caramba, ¿pensó el autor que habría subelementos dentro del elemento make?" <car make="Ford" color="Red" /> es significativamente más legible, no hay dudas sobre cómo se manejarían los espacios en blanco, etc.
Teniendo en cuenta sólo las reglas de manejo de espacios en blanco, creo que esta fue la intención clara de los diseñadores de XML.
Esto es muy claro en HTML donde se pueden ver claramente las diferencias de atributos y marcas:
- Todos los datos están entre marcas.
- Se utilizan atributos para caracterizar estos datos (p. ej.formatos)
Si solo tiene datos puros como XML, hay una diferencia menos clara.Los datos pueden ubicarse entre marcas o atributos.
=> La mayoría de los datos deben estar entre las marcas.
Si desea utilizar atributos aquí:Podrías dividir los datos en dos categorías:Datos y "metadatos", donde los metadatos no forman parte del registro que desea presentar, sino cosas como "versión de formato", "fecha de creación", etc.
<customer format="">
<name></name>
...
</customer>
También se podría decir:"Utilice atributos para caracterizar la etiqueta, utilice etiquetas para proporcionar los datos en sí".
Estoy de acuerdo con feenster.Manténgase alejado de los atributos si puede.Los elementos son amigables con la evolución y más interoperables entre los kits de herramientas de servicios web.Nunca encontrará estos kits de herramientas serializando sus mensajes de solicitud/respuesta usando atributos.Esto también tiene sentido ya que nuestros mensajes son datos (no metadatos) para un conjunto de herramientas de servicios web.
Los atributos pueden volverse difíciles de gestionar con el tiempo, créanme.Siempre me mantengo alejado de ellos personalmente.Los elementos son mucho más explícitos y legibles/utilizables tanto para los analizadores como para los usuarios.
La única vez que los usé fue para definir la extensión de archivo de una URL de activo:
<image type="gif">wank.jpg</image> ...etc etc
Supongo que si sabes al 100% que no será necesario expandir el atributo, podrías usarlos, pero ¿cuántas veces lo sabes?
<image>
<url>wank.jpg</url>
<fileType>gif</fileType>
</image>
