xml - partir - html lang es-ar
Atributo XML vs elemento XML (20)
Elemento XML vs atributo XML
XML tiene que ver con el acuerdo. Primero, difiera a cualquier esquema XML existente o convenciones establecidas dentro de su comunidad o industria.
Si está realmente en una situación para definir su esquema desde cero, aquí hay algunas consideraciones generales que deben informar la decisión del elemento frente al 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>
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 transferir 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 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. 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 más grande 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 dijo que el debate era sobre lo que realmente eran metadatos.
Después de la larga explicación (lo siento), ¿cómo determina qué son los metadatos y, al diseñar la estructura de un documento XML, cómo debería decidir cuándo usar un atributo o un elemento?
"XML" significa "lenguaje de marcado extensible". Un lenguaje de marcado implica que los datos son texto, marcados con metadatos sobre la estructura o el formato.
XHTML es un ejemplo de XML utilizado de la forma en que fue pensado:
<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 que la distinción entre "datos" y "metadatos" es más vaga. Así que la elección entre elementos y atributos es más o menos arbitraria, excepto por cosas que no se pueden representar con atributos (vea la respuesta de Feenster).
¡La pregunta del millón!
En primer lugar, no te preocupes demasiado por el rendimiento ahora. se sorprenderá de la rapidez con la que un analizador xml optimizado desgarrará su xml. lo que es más importante, ¿cuál es su diseño para el futuro: a medida que el XML evoluciona, cómo mantendrá el acoplamiento e interoperabilidad sueltos?
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.
¿Qué tal si aprovechamos nuestra intuición de orientación a objetos ganados? Por lo general, me parece sencillo pensar cuál es un objeto y cuál es un atributo del objeto o a qué objeto se refiere.
Cualquiera que sea intuitivamente tenga sentido como los objetos deben 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 a objetos funciona bien para averiguar cuál es el elemento y cuál es el atributo de un elemento.
Algunos de los problemas con los atributos son:
- los atributos no pueden contener varios valores (los elementos secundarios pueden)
- los atributos no son fácilmente expandibles (para cambios futuros)
- los atributos no pueden describir estructuras (los elementos hijos 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 una DTD
Si usa atributos como contenedores para datos, terminará con documentos que son difíciles de leer y mantener. Trate de usar elementos para describir los 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>
Ambos métodos para almacenar las propiedades del objeto son perfectamente válidos. Debes alejarte de las consideraciones pragmáticas. Intenta responder la siguiente pregunta:
- ¿Qué representación conduce a una generación más rápida de análisis de datos?
- ¿Qué representación conduce a una transferencia de datos más rápida?
¿Importa la legibilidad?
...
Cuando tenga dudas, KISS : ¿por qué mezclar atributos y elementos cuando no tiene una razón clara para usarlos? Si luego decides definir un XSD, eso también terminará siendo más limpio. Entonces, si incluso más tarde decides generar una estructura de clase desde tu XSD, eso también será más simple.
Es discutible de cualquier manera, pero sus colegas tienen razón en el sentido de que el XML debe usarse para "marcado" o metadatos alrededor de 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 cuando modela su dominio en XML. En la práctica, lo que hago es fingir que todo lo que está en el marcado está oculto, y que solo se pueden leer los datos que están fuera del marcado. ¿Tiene el documento algún sentido de esa manera?
XML es notoriamente voluminoso Para el transporte y almacenamiento, la compresión es muy recomendable si puede pagar la potencia de procesamiento. XML se comprime bien, a veces fenomenalmente bien, debido a su repetitividad. He hecho comprimir archivos grandes a menos del 5% de su tamaño original.
Otro punto para reforzar su posición es que mientras el otro equipo está discutiendo sobre el estilo (en la medida en que la mayoría de las herramientas XML manejarán un documento de todos los atributos con la misma facilidad que un documento de todos los # PCDATA), está discutiendo aspectos prácticos. Si bien el estilo no puede ser totalmente ignorado, los méritos técnicos deberían tener más peso.
Es en gran parte una cuestión de preferencia. Uso elementos para agrupar y atributos para datos cuando sea posible, ya que veo que esto es 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 unos 20-30 caracteres o contienen muchas comillas u otros caracteres que necesitan escaparse, entonces diría que es hora de desglosar los elementos ... posiblemente con bloques de 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>
Esto está muy claro en HTML, donde se pueden ver claramente las diferencias de atributos y marcas:
- Todos los datos están entre marcas
- 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í: podría dividir los datos en dos categorías: Datos y "metadatos", donde los metadatos no forman parte del registro que desea presentar, pero hay cosas como "versión del 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ías estos kits de herramientas serializando tus mensajes de solicitud / respuesta usando atributos. Esto también tiene sentido ya que nuestros mensajes son datos (no metadatos) para un kit de herramientas de servicio web.
Los atributos pueden volverse difíciles de administrar con el tiempo, confía en mí. Siempre me alejo de ellos personalmente. Los elementos son mucho más explícitos y legibles / utilizables tanto por analizadores como por usuarios.
La única vez que los he usado 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 que el atributo no necesita ser expandido al 100%, podrías usarlo, pero ¿cuántas veces lo sabes?
<image>
<url>wank.jpg</url>
<fileType>gif</fileType>
</image>
No hay una respuesta universal a esta pregunta (participé activamente en la creación de la especificación W3C). XML se puede usar para muchos propósitos: los documentos tipo 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 class = ''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 nombre (foo: bar = "zork") a menudo son más difíciles de administrar en varios conjuntos de herramientas. Pero eche un vistazo a algunos de los lenguajes 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 manera de hacerlo, por ejemplo,
<foo title="bar"/>;
o
<foo>
<title>bar</title>;
</foo>;
Tenga en cuenta que estos no son sintácticamente equivalentes y requieren soporte explícito en las herramientas de procesamiento)
Mi consejo sería tener en cuenta 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.
XML no está diseñado para ser compacto, sino para ser portátil y legible para humanos. Si desea reducir el tamaño de los datos en tránsito, utilice otra cosa (como los buffers de protocolo de Google ).
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 con valores de campo que 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 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, algo tardíamente, de que el código de barras no era un solo valor automático, sino que podría calificarse con la codificación requerida cuando se imprimió.
<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 construyas algún tipo de XSD o DTD junto con un espacio de nombres para arreglar la estructura en piedra, es mejor que te sirvan dejando abiertas tus opciones.
IMO XML es más útil cuando puede flexionarse sin romper el código existente al usarlo.
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.
Así, por ejemplo, el texto sin marcas siempre pertenece a los atributos. Siempre.
Las listas pertenecen a la subestructura o al contenido. El texto que puede incluir con el tiempo el contenido parcial incorporado incrustado pertenece al contenido. (En mi experiencia, hay relativamente poco de esto, texto con marcado, cuando se utiliza 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> , creo que "a mi vez, el autor pensaba que iba a haber subelementos dentro del hacer elemento? " <car make="Ford" color="Red" /> es significativamente más legible, no hay duda sobre cómo se manejaría el espacio en blanco, etc.
Teniendo en cuenta solo las reglas de manejo de espacios en blanco, creo que esta fue la clara intención de los diseñadores XML.
Solo un par de correcciones a alguna mala información:
@ John Ballinger: los atributos pueden contener cualquier dato de personaje. <> & "''debe escaparse a & lt; & gt; & amp; & quot; y & apos; respectivamente. Si usa una biblioteca XML, se encargará de eso por usted.
Demonios, un atributo puede contener datos binarios, como una imagen, si realmente quieres, solo codificándolos en base64 y convirtiéndolos en datos: URL.
@feenster: los atributos pueden contener varios elementos separados por espacios en el caso de IDS o NOMBRES, que incluirían números. Nitpicky, pero esto puede terminar ahorrando espacio.
El uso de atributos puede mantener XML competitivo con JSON. Consulte el apartado de marcas de grasa: recorte el mito de las marcas de grasa de una en una .
Utilice elementos para datos y atributos para metadatos (datos sobre los datos del elemento).
Si un elemento se muestra como un 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 usa como predicado, entonces tal vez no sea metadatos útiles.
Recuerde que se supone que XML debe ser legible por una máquina y no legible para humanos, y para documentos grandes, XML se comprime muy bien.
Utilizo las siguientes pautas en mi diseño de esquema con respecto a los atributos frente a los elementos:
- Use elementos para el texto de ejecución larga (generalmente aquellos de tipo string o normalizedString)
- No use un atributo si hay 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.
- La fecha comercial, la hora y los números (por ejemplo, conteos, cantidad y tasa) deben ser elementos.
- Los elementos de horario no comercial, como la última actualización, caducan en deben ser atributos.
- Los números no comerciales, como los códigos hash y los índices, deben ser atributos. * Use elementos si el tipo será complejo.
- Use atributos si el valor es un 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 detalladas y usan menos ancho de banda, pero eso no es realmente una razón para preferir los atributos sobre los elementos.
Agregué cuando sea 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, use (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 eliminaría.
Yo uso esta regla de oro:
- Un atributo es algo que es autónomo, es decir, un color, una identificación, un nombre.
- Un elemento es algo que tiene o podría tener atributos propios o contener otros elementos.
Así que el tuyo está cerca. Habría hecho algo como:
EDITAR : Se actualizó el ejemplo original basado en los comentarios a continuación.
<ITEM serialNumber="something">
<BARCODE encoding="Code39">something</BARCODE>
<LOCATION>XYX</LOCATION>
<TYPE modelNumber="something">
<VENDOR>YYZ</VENDOR>
</TYPE>
</ITEM>