Atributo XML vs elemento XML

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 para 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 así como:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

El otro equipo dijo que esto no era estándar de la industria y que los atributos solo deberían usarse para metadatos. Ellos 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 80000 elementos que estarán en el archivo durante la transferencia. Su sugerencia en realidad resulta ser tres veces mayor que la que 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 lo que en realidad eran metadatos.

Después de la larga explicación (perdón), ¿cómo determina qué son los metadatos, y al diseñar la estructura de un documento XML, cómo debe decidir cuándo utilizar un atributo o un elemento?

Yo uso esta regla general:

1. Un atributo es algo que es autónomo, es decir, un color, una identificación, un nombre.
2. Un elemento es algo que tiene o podría tener atributos propios o contener otros elementos.

Entonces el tuyo está cerca. Hubiera 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>

Algunos de los problemas con los atributos son:

• los atributos no pueden contener múltiples valores (los elementos secundarios pueden)
• los atributos no son fácilmente expandibles (para futuros cambios)
• los atributos no pueden describir estructuras (los elementos secundarios sí pueden)
• los atributos son más difíciles de manipular por código de programa
• los valores de los atributos no son fáciles de probar contra un DTD

Si usa atributos como contenedores para datos, terminará con documentos que son difíciles de leer y mantener. Intenta usar elementos para describir datos. Use atributos solo 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>

Fuente: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" significa " Lenguaje de marcado extensible ". Un lenguaje de marcado implica que los datos son texto, marcados con metadatos sobre estructura o formato.

XHTML es un ejemplo de XML utilizado de la forma 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 mostrarlos (aunque hay algunas etiquetas que no funcionan de esa manera).

La confusión surge cuando XML se usa no como un lenguaje de marcado, sino como un lenguaje de serialización de datos , en el cual la distinción entre "datos" y "metadatos" es más vaga. Por lo tanto, la elección entre elementos y atributos es más o menos arbitraria, excepto para las cosas que no se pueden representar con atributos (ver la respuesta de feenster).

Elemento XML vs Atributo XML

XML tiene que ver con el acuerdo. Primero diferir a cualquier esquema XML existente o convenciones establecidas dentro de su comunidad o industria.

Si realmente está en una situación para definir su esquema desde cero, aquí hay algunas consideraciones generales que deberían informar la decisión de 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. El XML que se utiliza para representar datos estructurados generados a partir de una base de datos puede funcionar bien, en última instancia, los valores de campo se colocan como atributos.

Sin embargo, el XML utilizado como transporte de mensajes a menudo sería mejor utilizando más elementos.

Por ejemplo, digamos que teníamos este XML como se propuso 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, algo tardíamente, de que el código de barras no era un único valor automático, sino que puede estar calificado con la codificación requerida cuando se imprime.

   <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 arreglar la estructura en piedra, es mejor que deje sus opciones abiertas.

IMO XML es más útil cuando se puede flexionar sin romper el código existente que lo usa.

Utilizo las siguientes pautas en mi diseño de esquema con respecto a los atributos frente a los elementos:

• Use elementos para texto de larga ejecución (generalmente los de tipo cadena o normalizedString)
• No use un atributo si hay una agrupación de dos valores (por ejemplo, eventStartDate y eventEndDate) para un elemento. En el ejemplo anterior, debe haber un nuevo elemento para "evento" que puede contener los atributos startDate y endDate.
• Fecha comercial, fecha y hora y números (por ejemplo, recuentos, cantidad y tasa) deben ser elementos.
• Los elementos de tiempo no comerciales, como la última actualización, caduca deben ser atributos.
• Los números no comerciales, como los códigos hash y los índices, deben ser atributos. * Utilice elementos si el tipo será complejo.
• Use 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 es que 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 contenido "todo" no admite en el lenguaje de esquema actual)
• La ventaja es que son menos detallados y usan menos ancho de banda, pero esa no es realmente una razón para preferir los atributos sobre los elementos.

Agregué cuando era técnicamente posible porque hay momentos en que el uso de atributos no es posible. Por ejemplo, las opciones de conjunto de atributos. Por ejemplo, usar (startDate y endDate) xor (startTS y endTS) no es posible con el lenguaje de esquema actual

Si el esquema XML comienza a permitir que el modelo de contenido "todo" sea restringido o extendido, entonces probablemente lo descartaría

En caso de duda, KISS : ¿por qué mezclar atributos y elementos cuando no tienes una razón clara para usar atributos? Si luego decides definir un XSD, eso también terminará siendo más limpio. Luego, si incluso más tarde decide generar una estructura de clase a partir de su XSD, eso también será más simple.

No hay 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: los documentos con texto, los datos y el 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 (por ejemplo, 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 de espacio de nombres (foo: bar = "zork") son a menudo 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 mezcla que es 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 más de una forma de hacerlo, por ejemplo

<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 la práctica común 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 (por ejemplo, Linq) representan espacios de nombres como atributos en la API. En mi opinión, esto es feo y potencialmente confuso.

Otros han cubierto cómo diferenciar entre 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 disminuir el tamaño de los datos en tránsito, use otra cosa (como los búferes de protocolo de Google ).

la pregunta del millón de dólares!

En primer lugar, no te preocupes demasiado por el rendimiento ahora. se sorprenderá de lo rápido que un analizador xml optimizado va a atravesar su xml. Lo que es más importante, ¿cuál es su diseño para el futuro? A medida que evoluciona el XML, ¿cómo mantendrá el acoplamiento flexible y la interoperabilidad?

más concretamente, puede hacer que el modelo de contenido de un elemento sea más complejo, pero es más difícil extender un atributo.

Ambos métodos para almacenar las propiedades del objeto son perfectamente válidos. Debe apartarse de las consideraciones pragmáticas. Intenta responder la siguiente pregunta:

1. ¿Qué representación conduce a un análisis / generación de datos más rápido?

2. ¿Qué representación lleva a una transferencia de datos más rápida?

3. ¿Importa la legibilidad?

   ...

Use elementos para datos y atributos para metadatos (datos sobre los datos del elemento).

Si un elemento se muestra como un predicado en sus cadenas de selección, tiene una buena señal de que debería ser un atributo. Del mismo modo, si un atributo nunca se usa como predicado, entonces tal vez no sean metadatos útiles.

Recuerde que se supone que XML es legible por máquina, no legible por humanos y para documentos grandes XML comprime muy bien.

Es discutible de cualquier manera, pero sus colegas tienen razón en el sentido de que el XML debe usarse para "marcado" o metadatos en torno a los datos reales. Por su parte, tiene razón en que a veces es difícil decidir dónde está la línea entre los metadatos y los datos al modelar su dominio en XML. En la práctica, lo que hago es fingir que todo lo que está en el marcado está oculto, y solo los datos fuera del marcado son legibles. ¿Tiene algún sentido el documento de esa manera?

XML es notoriamente voluminoso. Para el transporte y el almacenamiento, la compresión es muy recomendable si puede permitirse el poder de procesamiento. XML se comprime bien, a veces fenomenalmente bien, debido a su repetitividad. He tenido archivos grandes comprimidos a menos del 5% de su tamaño original.

Otro punto para reforzar su posición es que mientras el otro equipo discute sobre el estilo (ya que la mayoría de las herramientas XML manejarán un documento con todos los atributos con la misma facilidad que un documento con # PCDATA), usted está discutiendo aspectos prácticos. Si bien el estilo no se puede ignorar por completo, los méritos técnicos deberían tener más peso.

Es en gran medida una cuestión de preferencia. Uso Elementos para la agrupación y atributos para datos cuando 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 vez 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 escapar, 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>

¿Qué hay de aprovechar nuestra intuición de orientación a objetos duramente ganada? Generalmente encuentro que es sencillo pensar cuál es un objeto y cuál es un atributo del objeto o a qué objeto se refiere.

Cualquiera que tenga sentido intuitivamente, los objetos encajarán como elementos. Sus atributos (o propiedades) serían atributos para estos elementos en xml o elemento hijo con atributo.

Creo que para casos más simples, como en el ejemplo, la analogía de orientación de objetos funciona bien para descubrir cuál es el elemento y cuál es el atributo de un elemento.

Solo un par de correcciones a alguna mala información:

@John Ballinger: los atributos pueden contener datos de cualquier personaje. <> & "'necesita escapar a & lt; & gt; & amp; & quot; y & apos;, respectivamente. Si usa una biblioteca XML, se encargará de eso.

Demonios, un atributo puede contener datos binarios como una imagen, si realmente lo desea, simplemente codificándolo en base64 y convirtiéndolo en datos: URL.

@feenster: los atributos pueden contener elementos múltiples separados por espacios en el caso de IDS o NAMES, que incluirían números. Nitpicky, pero esto puede terminar ahorrando espacio.

El uso de atributos puede mantener a XML competitivo con JSON. Ver marcado de grasa: Recortando el mito del marcado de grasa una caloría a la vez .

Siempre me sorprenden los resultados de este tipo de discusiones. Para mí, hay 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 marcas siempre pertenece a los atributos. Siempre.

Las listas pertenecen a subestructura o contenido. El texto que con el tiempo puede incluir sub-contenido 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.

Cada vez que veo casos como <car><make>Ford</make><color>Red</color></car>, pienso para mí mismo "¿creía 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ía el espacio en blanco, etc.

Dadas solo las reglas de manejo de espacios en blanco, creo que esta fue la clara intención de los diseñadores de XML.

Esto es muy claro en HTML, donde las diferencias de atributos y marcado pueden verse claramente:

1. Todos los datos están entre marcas
2. Los atributos se utilizan para caracterizar estos datos (por ejemplo, formatos)

Si solo tiene datos puros como XML, hay una diferencia menos clara. Los datos pueden estar entre marcas o como atributos.

=> La mayoría de los datos deben estar entre marcas.

Si desea utilizar los atributos aquí: puede dividir los datos en dos categorías: Datos y "metadatos", donde los metadatos no son parte del registro, desea presentarlos, pero cosas como "versión de formato", "fecha de creación" etc.

<customer format="">
     <name></name>
     ...
</customer>

También se podría decir: "Use atributos para caracterizar la etiqueta, use etiquetas para proporcionar 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 que serializan sus mensajes de solicitud / respuesta utilizando atributos. Esto también tiene sentido ya que nuestros mensajes son datos (no metadatos) para un kit de herramientas de servicios web.

Los atributos pueden volverse difíciles de manejar con el tiempo, confía en mí. Siempre me mantengo alejado de ellos personalmente. Los elementos son mucho más explícitos y legibles / utilizables tanto por los analizadores como por los usuarios.

El único momento en que los usé fue para definir la extensión del archivo de una URL de activo:

<image type="gif">wank.jpg</image> ...etc etc

Supongo que si conoce el 100%, el atributo no necesitará expandirse, podría usarlos, pero ¿cuántas veces lo sabe?

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>