Comprenons nous bien, je ne suis promotteur des activités pornographiques. Je veux parler du X de XML! Au delà du méta langage, comment utilisez vous la caractéristique d’extensibilité dans vos fichiers XML? Autrement dit, que faites vous du X?

L’inutilisation de cette caractéristique conduit à des fichiers XML, équivalent à des structures C ou des copies Cobol. De ce fait, la valeur du langage XML est négative, car il n’y a pas d’avantage à utiliser XML, en lieu et place d’autres mécanismes plus directs, plus simples, et moins onéreux à maintenir.

La caractéristique d’extensibilité peut être mise en oeuvre de plusieurs manières

Multiplicité des entrées

Si l’utilisation des balises est certes un préalable à la mise en oeuvre du méta langage, elle demeure insuffisante pour exploiter réellement le méta langage. Cette exploitation requiert la mise en oeuvre de schémas (ou type de document), afin de définir un modèle, qui structure le méta langage et ces instances. Nous nous plaçons dorénavant dans ce cas.

La caractéristique d’extensibilité peut être comprise comme la capacité à accepter un nombre indéterminé d’entrées pour la composition d’un type. Il s’agit alors de l’utilisation combinée d’une définition d’un modèle de groupe e.g. sequence, choice, any, et de l’indétermination de ses bornes limites minOccurs et maxOccurs dans ce modèle de groupe. Bien entendu, cela est stipulé dans le schéma. Généralement, l’usage du mot clef unbounded pour la borne maxOccurs suffit pour gérer cette multiplicité.

Polymorphisme des entrées

La caractéristique d’extensibilité peut et doit être comprise comme la capacité à accepter un type dérivé en lieu et place d’un type de base. L’usage conjoint de xsd:extension dans la définition d’un type et de l’attribut subtitutionGroup dans une élément permet la mise en oeuvre propre et cohérente de ce polymorphisme.

Nous aurions pu également utiliser le type générique anyType mais au détriment du contrôle de type, ce qui est rarement souhaité.

Notez que l’usage explicite de la définition d’un modèle de groupe choice permet ce polymorphisme avec un niveau de contrôle élevé des différents choix. Cette méthode directe est souvent suffisante. Réservez là pour les cas de choix réels entre alternatives disjointes mettant en oeuvre des types hétérogènes sans parties commune. Par exemple, fournir ses informations bancaires par RIB ou IBAN entre bien dans cette catégorie car chacune de ces entrées est supportée par une norme spécifique, disjointe de sa concurrente.

Une autre moyen d’arriver à du polymorphisme de type est de jongler avec les espaces de noms. Supposez que vous deviez documenter un élément du genre <xsd:element name=”bankAccountInfo” type=”bai:bankAccountInfo”>, qui exige l’import de l’espace de nom bai. Si vous différez cet import, jusqu’à la création d’un fichier instance, alors vous avez la possibilité de fixer l’import qui vous convient. On peut ainsi avoir un fichier d’import pour le développement, un autre pour l’intégration et encore un autre pour la production. L’avantage est que chaque fichier sera optimisé pour son domaine. L’inconvénient est que l’aspect ultra dynamique risque d’engendrer de nombreux problèmes à moins d’avoir du personnel, bon connaisseur de la logique XML?.

Au début, faire du X semble compliqué. Essayez et les atouts de cette approche vous séduiront. Au fait, combien de fichier XML avez vous créé, qui mettent en oeuvre le X d’XML?