¿Cuáles son las mejores prácticas para diseñar esquemas XML?

Question

Como desarrollador de software aficionado (todavía estoy en el mundo académico), he escrito algunos esquemas para documentos XML. Me encuentro rutinariamente con flubs de diseño que causan documentos XML de aspecto feo porque no estoy del todo seguro de cuál es exactamente la semántica de XML.

Mis suposiciones:

<property> value </property> 

propiedad = valor

<property attribute="attval"> value </property> 

Una propiedad con un descriptor especial, el atributo.

<parent> 
    <child> value </child> 
</parent> 

El elemento primario tiene una característica "niño" que tiene el valor "valor".

<tag /> 

"Etiqueta" es una marca o se traduce directamente en un texto. No estoy seguro de esto.

<parent> 
    <child /> 
</parent> 

"child" describe "parent." "niño" es una bandera o booleano. No estoy seguro de este, tampoco.

La ambigüedad surge si quieres hacer algo como que representan las coordenadas cartesianas:

<coordinate x="0" y="1 /> 

<coordinate> 0,1 </coordinate> 

<coordinate> <x> 0 </x> <y> 1 </y> </coordinate> 

¿Cuál de ellos es más correcto? Me inclinaría hacia el tercero en función de mi concepción actual del diseño de esquema XML, pero realmente no lo sé.

¿Cuáles son algunos recursos que describen sucintamente cómo diseñar efectivamente esquemas xml?

Answer 1

Ver el tutorial:

• "XML Schemas: Best Practices" por Roger Costello.

también recomiendo:

• Priscilla Walmsley 's libro "Definitive XML Schema".

• Jeni Tennison 's XML Schema pages

Answer 2

Mirar las relaciones de los datos que intenta representar es el mejor enfoque que he encontrado.

Answer 3

XML es un tanto subjetivo en términos de diseño: no creo que haya directrices exactas sobre cómo se deben diseñar los elementos y atributos, pero tiendo a usar elementos para representar "cosas" y atributos para representar atributos/propiedades singulares de ellos.

En términos del ejemplo de coordenadas, cualquiera sería perfectamente aceptable, pero mi inclinación sería ir con <coordinate x="" y=""/> porque es algo más escueto, y hace que el documento sea un poco más legible si tiene muchos de ellos.

Lo más importante, sin embargo, es el espacio de nombres del esquema. Asegúrese de que (a) tenga uno, y (b) tenga una versión allí para poder cambiar las cosas en el futuro y emitir una nueva versión. Las versiones pueden ser fechas o números, p.

http://company.com/2008/12/something/somethingelse/ 
urn:company-com:2008-12:something:somethingelse 

http://company.com/v1/something/somethingelse/ 
urn:company-com:v1:something:somethingelse 

Answer 4

a menudo me encuentro luchando con el mismo problema, pero me parece que en la práctica no importa realmente, XML es sólo datos.

Dicho esto, generalmente prefiero el enfoque "si dice algo sobre el nodo es un atributo, de lo contrario es un nodo secundario".

En su ejemplo que volvería para:

<coordinate> 
    <x>0</x> 
    <y>1</y> 
</coordinate> 

porque el X e Y son propiedad de una coordenada, en realidad no dice nada sobre el xml, pero sobre el objeto representado por el mismo.

Answer 5

Al diseñar un formato basado en XML, a menudo es bueno pensar en lo que está representando. Intente burlarse de algunos datos XML que se ajusten al propósito que desea. Una vez que tenga algo con lo que esté satisfecho y que cumpla con sus requisitos, desarrolle el esquema para validarlo.

Al diseñar un formato, tiendo a usar elementos para contener contenido de datos y atributos para aplicar características a los datos como un id, un nombre, un tipo o algún otro metadato sobre los datos que contiene un elemento.

En ese sentido, una representación XML de coordenadas pueden ser:

<coordinate type="cartesian"> 
    <ordinate name="x">0</ordinate> 
    <ordinate name="y">1</ordinate> 
</coordinate> 

Esto dirige a distintos sistemas de coordenadas. Si supieras que siempre estarían cartesiano, una mejor aplicación podría ser:

<coordinate> 
    <x>0</x> 
    <y>1</y> 
</coordinate> 

Por supuesto, este último podría dar lugar a un esquema más detallado que necesitaría cada tipo de elemento que se declara (aunque yo espero un complejo tipo fue definido para realmente hacer el trabajo duro para estos elementos).

Al igual que en la programación, a menudo hay múltiples maneras de lograr los mismos fines, pero no hay lo correcto y lo incorrecto en muchas situaciones, solo que mejor y peor. Lo importante es mantener la coherencia y tratar de ser intuitivo para que, cuando los demás vean tu esquema, puedan comprender lo que intentabas lograr.

Siempre debe versionar sus esquemas y asegurarse de que el XML escrito en su esquema lo indique como tal. Si no hace una versión adecuada del XML, hacer adiciones al esquema mientras soporta XML escrito en el esquema anterior será mucho más difícil.

Answer 6

Supongo que depende de cuán compleja o simple sea la estructura.
haré x e y como atributo, a menos que x e y tienen sus propios detalles

Usted puede mirar en HTML o cualquier otra forma de marcado, que se utiliza para definir las cosas (XAML en caso de WPF, MXML en caso de flash) para comprender por qué se elige algo como atributo en comparación con un nodo secundario)

si x e y no se van a repetir, pueden ser atributos.

Digamos que las coordenadas tienen múltiples x e y, supongo que xml no permite múltiples atributos con el mismo nombre para un nodo. En ese caso, tendrá que usar nodos secundarios.

Answer 7

No hay nada intrínsecamente incorrecto al usar un elemento o subelemento por cada valor que quiera representar.

La consideración principal es que a veces es más limpio usar un atributo. Como un elemento solo puede tener un atributo de un nombre de pila, tiene una cardinalidad 1: 1. Si representas los datos como un elemento secundario, puedes usar la cardinalidad que quieras (o estar abierto a extenderla más tarde).

La respuesta de Rob Wells anterior es correcta: depende de las relaciones que intenta modelar.

En cualquier momento que claramente nunca va a haber nada más que una relación 1: 1, un atributo puede ser más limpio.

Answer 8

No conozco ningún buen recurso de aprendizaje sobre cómo diseñar modelos de documentos XML (los esquemas son solo una forma formal de especificar modelos de documentos).

En mi opinión, una visión crucial para XML es que no es un lenguaje: es una sintaxis. Y cada modelo de documento es un idioma separado.

Diferentes culturas usarán cada una de XML de forma especial. Incluso dentro de las especificaciones W3C puede oler Lisp en nombres separados por guiones de XSLT, y Java en camelCaseNames of XML Schema. Del mismo modo, los diferentes dominios de aplicación requerirán diferentes expresiones idiomáticas de XML.

Los modelos de documentos narrativos como HTML o DocBook tienden a poner texto imprimible en los nodos de texto y los metadatos en los nombres y atributos de los elementos.

Más modelos de documentos orientados a objetos como SVG hacen poco o ningún uso de los nodos de texto y en su lugar solo usan elementos y atributos.

Mis reglas personales de oro para el diseño de modelos de documentos más o menos así:

• Si se trata de la clase de la libre-de sopa de etiqueta que requiere mixed content, utiliza HTML y DocBook como fuentes de inspiración. Las otras reglas solo son relevantes de lo contrario.
• Si un valor va a ser compuesto o jerárquico, use elementos. Los datos XML no deberían requerir más análisis, excepto los modismos establecidos, como IDREFS, que son secuencias simples separadas por espacios.
• Si un valor puede necesitar aparecer más de una vez, use elementos.
• Si un valor puede necesitar ser refinado aún más, o enriquecido más tarde, use elementos.
• Si un valor es claramente atómico (booleano, número, fecha, identificador, etiqueta simple) y puede ocurrir a lo sumo una vez, utilice un atributo.

Otra forma de decir que podría ser:

• Si se trata de la narrativa, no es orientado a objetos.
• Si está orientado a objetos, modele objetos como elementos y atributos atómicos como atributos.

EDITAR: Algunas personas parecen querer renunciar por completo a los atributos. No hay nada incorrecto con él, pero no me gusta, ya que hincha los documentos y los hace innecesarios difíciles de leer y escribir a mano.

Answer 9

Una recomendación general (¡pero importante!) Es nunca almacenar múltiples piezas lógicas de datos en un solo nodo (ya sea un nodo de texto o un nodo de atributo). De lo contrario, terminará necesitando su propia lógica de análisis además de la lógica de análisis XML que normalmente obtiene de forma gratuita de su marco de trabajo.

Así que en su ejemplo de coordenadas, <coordinate x="0" y="1" /> y <coordinate> <x>0</x> <y>1</y> </coordinate> son a la vez razonable para mí.

Pero <coordinate> 0,1 </coordinate> no es muy buena, porque es el almacenamiento de dos piezas lógicas de datos (la coordenada X y la coordenada Y) en una sola XML nodo-forzando el consumidor para analizar los datos fuera de su XML analizador Y si bien dividir una cadena por comas es bastante simple, todavía hay algunas ambigüedades, como qué pasa si hay una coma adicional al final.

Answer 10

Acepto el siguiente consejo de cdragon para evitar la opción # 2. La elección entre # 1 & # 3 es en gran parte una cuestión de estilo. Me gusta usar atributos para lo que considero atributos de la entidad y elementos para lo que considero datos. A veces, es difícil de clasificar. Sin embargo, ninguno está "equivocado".

Y mientras hablamos del tema del diseño de esquemas, agregaré mis dos centavos con respecto a mi nivel preferido de reutilización (máxima) (de elementos y tipos), que también puede facilitar la referencia "lógica" externa de estas entidades en, por ejemplo, un diccionario de datos almacenado en una base de datos.

Tenga en cuenta que, si bien el patrón de esquema "Garden of Eden" ofrece la máxima reutilización, también implica la mayor parte del trabajo. En la parte inferior de esta publicación, proporcioné enlaces a otros patrones cubiertos en la serie de blogs.

• El jardín de Edén enfoquehttp://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

utiliza un enfoque modular mediante la definición de todos los elementos a nivel mundial y como el enfoque de persiana veneciana todas las definiciones de tipos se declaran a nivel mundial. Cada elemento se define globalmente como un elemento secundario inmediato del nodo y su atributo de tipo se puede establecer en uno de los tipos complejos nombrados.

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    elementFormDefault="qualified" attributeFormDefault="unqualified"/> 
<xs:element name="BookInformation" type="BookInformationType"/> 
    <xs:complexType name="BookInformationType"/> 
    <xs:sequence> 
     <xs:element ref="Title"/> 
     <xs:element ref="ISBN"/> 
     <xs:element ref="Publisher"/> 
     <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/> 
    </xs:sequence> 
    </xs:complexType> 
    <xs:complexType name="PeopleInvolvedType"> 
    <xs:sequence> 
     <xs:element name="Author"/> 
    </xs:sequence> 
    </xs:complexType> 
    <xs:element name="Title"/> 
    <xs:element name="ISBN"/> 
    <xs:element name="Publisher"/> 
    <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/> 
</xs:schema> 

La ventaja de este enfoque es que los esquemas son reutilizables. Dado que tanto los elementos como los tipos están definidos globalmente, ambos están disponibles para su reutilización. Este enfoque ofrece la cantidad máxima de contenido reutilizable. Las desventajas son que el esquema es detallado. Este sería un diseño apropiado cuando crea bibliotecas generales en las que no puede hacer suposiciones sobre el alcance de los elementos y tipos de esquema y su uso en otros esquemas, particularmente en lo que se refiere a extensibilidad y modularidad.

Dado que cada tipo y elemento distintos tienen una sola definición global, estas partículas/componentes canónicos se pueden relacionar uno a uno con los identificadores de una base de datos. Y aunque a primera vista puede parecer una tarea manual en curso tedioso para mantener las asociaciones entre las Pruebas XSD partículas/componentes y la base de datos, SQL Server 2005 puede, de hecho, generar identificadores de los componentes del esquema canónicas a través de la declaración

CREATE XML SCHEMA COLLECTION 

http://technet.microsoft.com/en-us/library/ms179457.aspx

a la inversa, para construir un esquema de las partículas canónicas, SQL Server 2005 proporciona la

SELECT xml_schema_namespace function 

http://technet.microsoft.com/en-us/library/ms191170.aspx

ca · non · i · cal Relacionado a Matemáticas. (de una ecuación, coordenadas, etc.) "en simple o en forma estándar" http://dictionary.reference.com/browse/canonical

Otros, más fácil de construir, pero menos resuable patrones de esquema/más "desnormalizadas/redundantes" incluyen

• El enfoque de la muñeca rusahttp://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

El esquema tiene un único elemento global: el elemento raíz. Todos los demás elementos y tipos se anidan progresivamente a mayor profundidad dándole el nombre debido a que cada tipo se ajusta al que está encima. Como los elementos de este diseño se declaran localmente, no serán reutilizables mediante las instrucciones de importación o inclusión.

• El enfoque Salami Rebanadahttp://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

Todos los elementos se definen globalmente pero las definiciones de tipos se definen localmente. De esta forma, otros esquemas pueden reutilizar los elementos. Con este enfoque, un elemento global con su tipo definido localmente proporciona una descripción completa del contenido de los elementos. Este 'segmento' de información se declara individualmente y luego se agrega de nuevo y también se puede reconstruir para construir otros esquemas.

• El enfoque persiana venecianahttp://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

Al igual que en el enfoque de la muñeca rusa en cuanto a que ambos utilizan un único elemento global. El enfoque de Persiana veneciana describe un enfoque modular nombrando y definiendo todas las definiciones de tipo de forma global (en oposición al enfoque de Salami Slice que declara los elementos globalmente y los tipos localmente). Cada tipo definido globalmente describe un "slat" individual y puede ser reutilizado por otros componentes. Además, todos los elementos declarados localmente pueden ser espacios de nombres calificados o espacios de nombres no calificados (los listones pueden "abrirse" o "cerrarse") dependiendo de la configuración del atributo elementFormDefault en la parte superior del esquema.

Answer 11

En nuestros proyectos Java usamos a menudo JAXB para analizar automáticamente XML y transformarlo en una estructura de objeto. Supongo que para otros idiomas tendrás algo similar. Un generador adecuado puede crear automáticamente la estructura del objeto en su lenguaje de programación elegido. Esto hace que el procesamiento de XML a menudo sea mucho más fácil, al tiempo que tiene una representación XML portátil para la comunicación entre sistemas.

Si utiliza una asignación automática de este tipo, encontrará que esto limita mucho el esquema: <coordinate> <x> 0 </x> <y> 1 </y> </coordinate> es el camino a seguir a menos que desee hacer magia especial en la traducción. Obtendrá una clase Coordinate con dos atributos x y y con el tipo apropiado según lo declarado en el esquema.

Answer 12

Here es una gran lista de métodos para el diseño de una gramática XML.

Como se indicó anteriormente, es una práctica subjetiva, pero este sitio proporciona algunas instrucciones útiles, como "utilice este patrón para resolver el problema X" ... o "las ventajas y desventajas son ...".

Answer 13

He encontrado la forma de atributo más manejable cuando se trata de coordenadas cartesianas. Mis proyectos tienden a requerir espacios de nombres múltiples, y compartir la definición de tipo de coordenadas entre espacios de nombres se pone feo en la forma de sub-elemento. En el formulario de subelementos, debe calificar los subelementos, hacer malabares con espacios de nombres en el elemento base o raíz, o de forma predeterminada con nombres de elementos no calificados (por ej. namespace hiding)

Answer 14

Fui designado para escribir un conjunto de esquemas XML para integrar los sistemas de mi empresa con nuestros clientes. He diseñado una docena de ellos hace más de 10 años y vi que muchas características de extensión en la especificación no funcionaban bien en la práctica. Antes de diseñar los nuevos, he buscado las mejores prácticas actuales (¡y he llegado aquí!).

Algunos de los consejos anteriores son útiles, pero no me gustan casi todas las referencias. El mejor lugar con recomendaciones de diseño que encontré fue de Microsoft.

La mejor referencia es XML Schema Design Patterns: Avoiding Complexity. Aquí encontrará este consejo sano:

parece que muchos autores de esquema estarían mejor servidos por comprensión y utilización de un subconjunto efectiva de las características proporcionados por W3C esquema XML en lugar de tratar de comprender todos la esoterismo y minucias del lenguaje.

y dar explicaciones detalladas de las siguientes directrices:

• ¿Por qué usted debe utilizar las declaraciones globales y locales elemento
• ¿Por qué usted debe utilizar las declaraciones globales y locales de atributos
• ¿Por qué usted debe entender cómo Los espacios de nombres XML afectan al Esquema XML W3C
• Por qué siempre debe establecer elementFormDefault en "calificado"
• Por qué debería utilizar los grupos de atributos
• ¿Por qué usted debe utilizar grupos de modelos
• ¿Por qué usted debe utilizar el incorporado en los tipos simples
• ¿Por qué usted debe utilizar los tipos complejos
• Por qué no debe usar declaraciones de notación
• ¿por qué usted debe utilizar grupos de sustitución cuidadosamente
• qué debería favorecer clave/keyref/única de Identificación/IDREF de las limitaciones de identidad
• ¿por qué usted debe utilizar esquemas camaleón cuidadosamente
• ¿Por qué no se debe utilizar por defecto o valores fijos especialmente para este tipo de xs: QName
• ¿Por qué usted debe utilizar restricción y extensión de tipos simples
• ¿Por qué usted debe usar la extensión de tipos complejos
• ¿Por qué usted debe utilizar restricción tipos de complejos cuidadosamente
• ¿Por qué usted debe utilizar tipos abstractos cuidadosamente
• Haz utilizar comodines para proporcionar puntos bien definidos de extensibilidad
• no utilice grupo o tipo redefinición

Mi consejo sobre su consejo es que cuando dicen "use con cuidado", simplemente debe evitarlo. Mi impresión es que las especificaciones del esquema no fueron escritas por los desarrolladores de software. Intentaron usar algunos conceptos de orientación de objetos, pero lo hicieron un lío. Muchos de los mecanismos de extensión son inútiles o extremadamente detallados. Realmente no entiendo cómo alguien podría haber inventado la restricción de tipos complejos.

Dos artículos más agradables en este sitio son:

• Schema Design Patterns: Dealing With Change
• XML Schema Design Patterns: Is Complex Type Derivation Unnecessary?

Y un consejo que es un fenómeno generalizado es especificar los esquemas con algo diferente a la especificación oficial. Relax NG parece el lenguaje de especificación más favorecido. Lamentablemente perderá una de las mejores características de la estandarización.