Quelles sont les meilleures pratiques pour la conception de schémas XML ?

Question

En tant que développeur de logiciels amateur (je suis toujours dans le milieu universitaire), j'ai écrit quelques schémas pour des documents XML. Il m'arrive régulièrement de rencontrer des problèmes de conception qui rendent les documents XML peu esthétiques, car je ne suis pas tout à fait certain de la sémantique exacte du XML.

Mes hypothèses :

<property> value </property>

propriété = valeur

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

Une propriété avec un descripteur spécial, l'attribut.

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

Le parent a une caractéristique "enfant" qui a la valeur "valeur".

<tag />

"Tag" est un drapeau ou cela se traduit directement par du texte. Je ne suis pas sûr de ce point.

<parent>
  <child />
</parent>

"enfant" décrit "parent". "child" est un drapeau ou un booléen. Je ne suis pas sûr non plus sur ce point.

L'ambiguïté apparaît si l'on veut faire quelque chose comme représenter des coordonnées cartésiennes :

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

<coordinate> 0,1 </coordinate>

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

Laquelle de ces options est la plus correcte ? Je pencherais pour la troisième, compte tenu de ma conception actuelle de la conception des schémas XML, mais je ne sais vraiment pas.

Quelles sont les ressources qui décrivent succinctement comment concevoir efficacement des schémas xml ?

Answer 1

Une recommandation générale (mais importante !) est de ne jamais stocker plusieurs éléments logiques de données dans un seul nœud (qu'il s'agisse d'un nœud de texte ou d'un nœud d'attribut). Sinon, vous finirez par avoir besoin de votre propre logique d'analyse syntaxique. sur le dessus de la logique d'analyse XML que vous obtenez normalement gratuitement de votre framework.

Donc, dans votre exemple de coordonnées, <coordinate x="0" y="1" /> et <coordinate> <x>0</x> <y>1</y> </coordinate> sont toutes deux raisonnables pour moi.

Mais <coordinate> 0,1 </coordinate> n'est pas très bonne, car elle stocke deux éléments logiques de données (la coordonnée X et la coordonnée Y) dans un seul nœud XML, ce qui oblige le consommateur à analyser les données. à l'extérieur de de leur analyseur XML. Et si la division d'une chaîne de caractères par une virgule est assez simple, il reste quelques ambiguïtés, comme ce qui se passe s'il y a une virgule supplémentaire à la fin.

Answer 2

Voir le tutoriel :

• " Schémas XML : Meilleures pratiques " par Roger Costello .

Je recommande aussi :

• Priscilla Walmsley Le livre " Schéma XML définitif ".

• Jeni Tennison 's Pages de schéma XML

Answer 3

Je suis d'accord avec le conseil de cdragon ci-dessous pour éviter l'option #2. Le choix entre les options 1 et 3 est en grande partie une question de style. J'aime utiliser des attributs pour ce que je considère comme des attributs de l'entité, et des éléments pour ce que je considère comme des données. Parfois, il est difficile de classer les choses. Néanmoins, aucun des deux n'est "mauvais".

Et puisque nous parlons de conception de schémas, j'ajouterai mon grain de sel concernant le niveau de réutilisation (maximale) que je préfère (des éléments et des types), ce qui peut également faciliter le référencement "logique" externe de ces entités dans, par exemple, un dictionnaire de données stocké dans une base de données.

Notez que si le schéma "Garden of Eden" offre le maximum de réutilisation, il implique également le plus de travail. Au bas de cet article, j'ai fourni des liens vers les autres schémas abordés dans la série de blogs.

- L'approche du Jardin d'Eden http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

Utilise une approche modulaire en définissant tous les éléments de manière globale et, comme dans l'approche du store vénitien, toutes les définitions de type sont déclarées de manière globale. Chaque élément est défini globalement comme un enfant immédiat du nœud et son attribut de type peut être défini comme l'un des types complexes nommés.

<?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>

L'avantage de cette approche est que les schémas sont réutilisables. Puisque les éléments et les types sont définis globalement, ils peuvent être réutilisés. Cette approche offre le maximum de contenu réutilisable. L'inconvénient est que le schéma est verbeux. Cette conception serait appropriée lorsque vous créez des bibliothèques générales dans lesquelles vous pouvez vous permettre de ne pas faire d'hypothèses sur la portée des éléments et des types du schéma et leur utilisation dans d'autres schémas, en particulier en ce qui concerne l'extensibilité et la modularité.

Puisque chaque type et élément distinct a une définition globale unique, ces particules/composants canoniques peuvent être reliés de manière univoque à des identifiants dans une base de données. Et si, à première vue, le maintien des associations entre les particules/composants XSD textuels et la base de données peut sembler une tâche manuelle fastidieuse et permanente, SQL Server 2005 peut en fait générer des identifiants de composants de schéma canoniques via l'instruction

CREATE XML SCHEMA COLLECTION

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

À l'inverse, pour construire un schéma à partir des particules canoniques, SQL Server 2005 fournit la fonction

SELECT xml_schema_namespace function

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

ca-non-i-cal Relatif aux mathématiques. (d'une équation, d'une coordonnée, etc.) "sous sa forme la plus simple ou standard". http://dictionary.reference.com/browse/canonical

D'autres schémas, plus faciles à construire, mais moins fiables et plus "dénormalisés/redondants", sont notamment les suivants

- L'approche de la poupée russe http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

Le schéma comporte un seul élément global - l'élément Root. Tous les autres éléments et types sont imbriqués progressivement plus profondément, ce qui lui donne son nom, car chaque type s'insère dans celui qui le précède. Puisque les éléments de cette conception sont déclarés localement, ils ne seront pas réutilisables par le biais des instructions import ou include.

- L'approche de la tranche de salami http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

Tous les éléments sont définis globalement mais les définitions de type sont définies localement. De cette façon, d'autres schémas peuvent réutiliser les éléments. Avec cette approche, un élément global et son type défini localement fournissent une description complète du contenu de l'élément. Cette "tranche" d'informations est déclarée individuellement, puis regroupée et peut également être reconstituée pour construire d'autres schémas.

- L'approche du store vénitien http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

Similaire à l'approche de la poupée russe dans la mesure où elles utilisent toutes deux un seul élément global. L'approche Venetian Blind décrit une approche modulaire en nommant et en définissant toutes les définitions de type globalement (par opposition à l'approche Salami Slice qui déclare les éléments globalement et les types localement). Chaque type défini globalement décrit une "lamelle" individuelle et peut être réutilisé par d'autres composants. En outre, tous les éléments déclarés localement peuvent être qualifiés ou non d'espace de nom (les lamelles peuvent être "ouvertes" ou "fermées") en fonction du paramètre de l'attribut elementFormDefault en haut du schéma.

Answer 4

Le XML est quelque peu subjectif en termes de conception. Je ne pense pas qu'il existe de directives exactes sur la manière dont les éléments et les attributs doivent être disposés, mais j'ai tendance à utiliser les éléments pour représenter les "choses" et les attributs pour représenter les attributs/propriétés de ces choses.

En ce qui concerne l'exemple des coordonnées, l'un ou l'autre serait parfaitement acceptable, mais j'aurais tendance à opter pour <coordinate x="" y=""/> car il est un peu plus laconique et rend le document un peu plus lisible si vous en avez beaucoup.

Le plus important, cependant, est l'espace de noms du schéma. Assurez-vous (a) que vous en avez un et (b) que vous y avez une version afin de pouvoir modifier les choses à l'avenir et publier une nouvelle version. Les versions peuvent être des dates ou des nombres, par ex.

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 5

Je ne connais pas de bonne ressource d'apprentissage sur la façon de concevoir des modèles de documents XML (les schémas ne sont qu'une façon formelle de spécifier les modèles de documents).

À mon avis, l'un des aspects cruciaux du XML est qu'il ne s'agit pas d'un langage, mais d'une syntaxe. Et chaque modèle de document est un langage distinct.

Les différentes cultures utiliseront chacune le XML à leur manière. Même au sein des spécifications du W3C, vous pouvez sentir l'odeur de Lisp dans les noms séparés par des tirets de XSLT, et celle de Java dans les noms en casse de chameau de XML Schema. De même, des domaines d'application différents exigeront des idiomes XML différents.

Modèles de documents narratifs tels que HTML ou DocBook ont tendance à placer le texte imprimable dans les nœuds de texte et les métadonnées dans les noms et attributs des éléments.

Des modèles de documents plus orientés objet, tels que SVG n'utilisent pas ou peu les nœuds de texte, mais uniquement les éléments et les attributs.

Mes règles de base personnelles pour la conception de modèles de documents sont les suivantes :

• Si c'est le genre de soupe de l'étiquette libre qui nécessite contenu varié utilisent HTML et DocBook comme sources d'inspiration. Les autres règles ne sont pertinentes que dans le cas contraire.
• Si une valeur doit être composite ou hiérarchique, utilisez des éléments. Les données XML ne devraient pas nécessiter d'analyse supplémentaire, à l'exception des idiomes établis tels que les IDREFS qui sont de simples séquences séparées par des espaces.
• Si une valeur doit apparaître plus d'une fois, utilisez des éléments.
• Si une valeur doit être affinée ou enrichie ultérieurement, utilisez des éléments.
• Si une valeur est clairement atomique (booléen, nombre, date, identifiant, étiquette simple), et qu'elle ne peut apparaître qu'une seule fois, utilisez un attribut.

Une autre façon de le dire pourrait être :

• Si c'est narratif, ce n'est pas orienté objet.
• S'il est orienté objet, modélisez les objets comme des éléments et les attributs atomiques comme des attributs.

EDIT : Certaines personnes semblent aimer renoncer entièrement aux attributs. Il n'y a rien mauvais avec lui, mais je ne l'aime pas car il gonfle les documents et les rend inutilement difficiles à lire et à écrire à la main.