valida - ¿Cuáles son las mejores prácticas para diseñar esquemas XML?
xml validator (14)
A menudo me encuentro luchando con el mismo problema pero me parece que en la práctica no importa, xml solo son datos.
Dicho esto, generalmente prefiero el enfoque "si dice algo sobre el nodo es un atributo, de lo contrario es un paso secundario".
En tu ejemplo, yo iría por:
<coordinate>
<x>0</x>
<y>1</y>
</coordinate>
porque xey son propiedades de una coordenada, en realidad no dicen nada sobre el xml, sino sobre el objeto representado por él.
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 padre tiene un "hijo" característico que tiene el valor "valor".
<tag />
"Etiqueta" es una bandera o se traduce directamente en texto. No estoy seguro de esto.
<parent>
<child />
</parent>
"niño" describe "padre". "niño" es una bandera o booleano. No estoy seguro de este, tampoco.
La ambigüedad surge si quieres hacer algo como representar coordenadas cartesianas:
<coordinate x="0" y="1 />
<coordinate> 0,1 </coordinate>
<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>
¿Cuál de esos es el más correcto? Me inclinaría hacia el tercero en función de mi concepción actual del diseño de esquemas XML, pero realmente no sé.
¿Cuáles son algunos recursos que describen sucintamente cómo diseñar efectivamente esquemas xml?
Acepto el consejo de w / cdragon a continuación para evitar la opción n. ° 2. La elección entre # 1 y # 3 es en gran medida 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 estamos en el 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 "Jardín del Edén" 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 enfoque del Jardín del Edén http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx
Utiliza un enfoque modular al definir todos los elementos de forma global y, al igual que el enfoque de persiana veneciana, todas las definiciones de tipo se declaran globalmente. 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 se crean 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, especialmente en lo que se refiere a la extensibilidad y la modularidad.
Como cada tipo y elemento distinto tiene una única definición global, estas partículas / componentes canónicos se pueden relacionar uno a uno con los identificadores de una base de datos. Y si bien a primera vista puede parecer una tediosa tarea manual en curso mantener las asociaciones entre las partículas / componentes textuales XSD y la base de datos, SQL Server 2005 puede de hecho generar identificadores de componentes de esquema canónico a través de la declaración
CREATE XML SCHEMA COLLECTION
http://technet.microsoft.com/en-us/library/ms179457.aspx
Por el contrario, para construir un esquema a partir de las partículas canónicas, SQL Server 2005 proporciona el
SELECT xml_schema_namespace function
http://technet.microsoft.com/en-us/library/ms191170.aspx
ca · no · relacionado con las Matemáticas. (de una ecuación, coordenadas, etc.) "en la forma más simple o estándar" http://dictionary.reference.com/browse/canonical
Otros patrones de esquema más fáciles de construir, pero menos recuperables / más "desnormalizados / redundantes" incluyen
• El enfoque de Russian Doll http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx
El esquema tiene un solo 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 de Salami Slice http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx
Todos los elementos se definen globalmente, pero las definiciones de tipo 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 nuevamente y también se puede reconstruir para construir otros esquemas.
• El enfoque de Persianas venecianas http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx
Al igual que el enfoque de la muñeca rusa en que ambos usan un solo 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.
Al diseñar un formato basado en XML, a menudo es bueno pensar sobre 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 el 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 para las coordenadas podría ser:
<coordinate type="cartesian">
<ordinate name="x">0</ordinate>
<ordinate name="y">1</ordinate>
</coordinate>
Esto abastece a diferentes sistemas de coordenadas. Si supiera que siempre serán cartesianos, una mejor implementación podría ser:
<coordinate>
<x>0</x>
<y>1</y>
</coordinate>
Por supuesto, esto último podría conducir a un esquema más detallado, ya que cada tipo de elemento necesitaría declararse (aunque espero que se haya definido un tipo complejo para realmente hacer el trabajo duro para estos elementos).
Al igual que en la programación, a menudo existen múltiples formas de lograr los mismos fines, pero no existe lo correcto y lo incorrecto en muchas situaciones, solo que es 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 contra 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.
En nuestros proyectos Java, a menudo utilizamos 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 restringe 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 Coordinate Clase con dos atributos y con el tipo apropiado como se declaró en el esquema.
Fui designado para escribir un conjunto de esquemas XML para integrar los sistemas de mi compañía 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 gustaban casi todas las referencias. El mejor lugar con recomendaciones de diseño que encontré fue de Microsoft.
La mejor referencia es Patrones de diseño de esquemas XML: evitando la complejidad . Aquí encontrarás este consejo sensato:
parece que a muchos autores de esquemas les sería más útil comprender y utilizar un subconjunto eficaz de las características proporcionadas por el Esquema XML del W3C en lugar de tratar de comprender todos los aspectos esotéricos y minuciosos del lenguaje.
y dar explicaciones detalladas de las siguientes pautas:
- Por qué deberías usar declaraciones de elementos globales y locales
- Por qué debería usar declaraciones de atributos globales y locales
- Por qué debería entender cómo los espacios de nombres XML afectan el esquema XML del W3C
- Por qué siempre debe establecer elementFormDefault en "calificado"
- Por qué deberías usar grupos de atributos
- Por qué deberías usar grupos de modelos
- Por qué debería usar los tipos simples incorporados
- Por qué deberías usar tipos complejos
- Por qué no deberías usar declaraciones de notación
- Por qué deberías usar los grupos de sustitución cuidadosamente
- Por qué debería preferir key / keyref / unique sobre ID / IDREF para restricciones de identidad
- Por qué deberías usar esquemas de camaleón cuidadosamente
- Por qué no deberías usar valores predeterminados o fijos, especialmente para los tipos de xs: QName
- Por qué debería usar restricción y extensión de tipos simples
- Por qué debería usar la extensión de tipos complejos
- Por qué debería usar la restricción de tipos complejos cuidadosamente
- Por qué deberías usar tipos abstractos cuidadosamente
- Utilice comodines para proporcionar puntos de extensibilidad bien definidos
- No use la redefinición de grupo o tipo
Mi consejo sobre su consejo es que cuando dicen "usar con cuidado" , simplemente debes 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.
Otros dos artículos agradables en este sitio son:
- Patrones de diseño de esquema: lidiar con el cambio
- Patrones de diseño de esquemas XML: ¿la derivación de tipos complejos es innecesaria?
Y un consejo que es omnipresente es especificar sus 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.
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 la forma de subelemento, 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 (es decir, ocultar el espacio de nombres )
Mira las relaciones de los datos que intentas representar es el mejor enfoque que he encontrado.
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 idea 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 una manera 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 nodos de texto y metadatos en los nombres y atributos de los elementos.
Los modelos de documento más 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 generales para el diseño de modelos de documentos son algo como esto:
- Si es el tipo de sopa de etiqueta gratuita que requiere contenido mixto , utilice 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 ocurrir 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, entonces use un atributo.
Otra forma de decirlo podría ser:
- Si es narrativo, no está 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 tiene nada de malo , pero me desagrada, ya que hincha los documentos y los hace innecesarios, difíciles de leer y escribir a mano.
No hay nada intrínsecamente incorrecto en el uso de 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 anterior de Rob Wells es correcta: depende de las relaciones que estás tratando de modelar.
Cada vez que claramente nunca habrá nada más que una relación 1: 1, un atributo puede ser más limpio.
Supongo que depende de cuán compleja o simple sea la estructura.
Haré xey como atributo, a menos que xey tengan sus propios detalles
Puede ver HTML o cualquier otra forma de marcado, que se usa para definir cosas (XAML en el 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 xey no se repiten, pueden ser atributos.
Digamos que las coordenadas tienen múltiples xey, supongo que xml no permite múltiples atributos con el mismo nombre para un nodo. En ese caso, tendrá que usar nodos secundarios.
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 sobre la lógica de análisis XML que normalmente obtiene de forma gratuita de su marco.
Así que en tu ejemplo de coordenadas, <coordinate x="0" y="1" /> y <coordinate> <x>0</x> <y>1</y> </coordinate> son razonables para mí.
Pero <coordinate> 0,1 </coordinate> no es muy bueno, porque está almacenando dos datos lógicos (la coordenada X y la coordenada Y) en un solo nodo XML, lo que obliga al consumidor a analizar los datos externos. de su analizador XML. 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.
XML es algo 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.
Sin embargo, lo más importante es el espacio de nombres del esquema. Asegúrese de que (a) tenga una, 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, por ejemplo
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
Aquí hay una gran lista de métodos para diseñar una gramática XML.
Como se indicó anteriormente, es una práctica subjetiva, pero este sitio brinda algunas direcciones útiles, como "utilizar este patrón para resolver el problema X" ... o "las ventajas y desventajas son ...".