Accélération de l’adoption des vocabulaires XML

La source: http://xfront.com/accelerating-adoption-of-XML-vocabularies/

par Roger L. Costello

Vous voulez accélérer l’adoption de votre vocabulaire XML? L’une des solutions consiste à obliger tout le monde à l’utiliser. Mais cela entraînera bientôt du ressentiment et de la rébellion. Une meilleure solution consiste à créer quelque chose que les utilisateurs voudront vraiment utiliser sans nécessiter un investissement important en temps ou en argent et leur permettant de commencer à interagir immédiatement. Voici comment:

1. Lorsque vous créez votre vocabulaire XML, spécifiez non seulement la signification du balisage, mais également son comportement dans les applications qui le traitent.
    2. Spécifiez les règles de conformité.
    3. Créez une suite de tests.
    4. Créez une application qui implémente le comportement.
    5. Validez l’application par rapport à la suite de tests.
    6. Rendez l’application accessible au monde entier.

Idéalement, plusieurs implémentations de l’application seront créées (chacune avec le même comportement, bien sûr!). Ainsi, les utilisateurs peuvent sélectionner une implémentation en fonction de ses performances, de sa taille ou du langage de programmation dans lequel elle a été implémentée.

C’est tout! Faites cela et votre vocabulaire XML peut être rapidement adopté.

Exemple: considérons le vocabulaire XSLT. La spécification XSLT spécifie non seulement la signification de chaque élément et attribut, mais également leur comportement. La spécification XSLT contient des règles de conformité. Il existe une suite de tests XSLT. Une application (appelée processeur XSLT) a été créée pour implémenter le comportement spécifié dans la spécification XSLT. En fait, plusieurs implémentations de l’application ont été créées: Xalan, Saxon, Sableton et autres.

Permettez-moi de préciser un peu plus ce que je veux dire par «spécifier le comportement» Considérons à nouveau XSLT. La spécification XSLT indique que l’élément <xsl: for-each> identifie une collection de nœuds. C’est le sens. Il indique également qu’une application conforme doit parcourir chaque nœud identifié par l’attribut select (l’élément for-each a un attribut select) et exécuter les éléments contenus dans <xsl: for-each>. C’est le comportement. Ainsi, la spécification XSLT spécifie comment une application doit se comporter sur l’élément <xsl: for-each>. Idem pour tout le vocabulaire XSLT.

La spécification de schéma XML spécifie bien le comportement des validateurs de schéma XML. Par exemple, il spécifie que, pour une déclaration d’élément dans un schéma XML, un validateur doit vérifier que le document d’instance XML contient le nombre correct d’occurrences d’un élément et que son contenu est du type correct. Ainsi, il spécifie comment le validateur doit se comporter sur le vocabulaire de schéma XML. Ainsi, « spécifier le comportement » signifie décrire « pour cet élément (ou attribut) dans le vocabulaire, l’application doit faire ceci, ceci et cela. »

L’erreur que font les gens lors de la création d’un vocabulaire XML est qu’ils ne spécifient pas son comportement. Ils laissent le « monde » décider du comportement à adopter. HTML en est un exemple classique. Les développeurs de navigateurs devaient décider du comportement à adopter. Ils avaient des idées très différentes sur le comportement à adopter. En conséquence, IE, Firefox et les autres navigateurs se sont tous comportés différemment. Il leur a fallu 10 ans avant de finalement converger vers une compréhension commune du comportement. Si la spécification HTML avait indiqué le comportement, fourni des règles de conformité et une suite de tests, nous aurions eu des navigateurs se comportant de manière identique il y a 10 ans.

Voici une chose à prendre en compte lors de la spécification du comportement: votre vocabulaire XML sera-t-il introduit dans l’application sous la forme d’un document XML ou de deux documents XML? (Ou plus?) Prenons quelques exemples pour voir ce que je veux dire:

  • Les applications de navigateur traitent un document (un document HTML)
  • Les validateurs de schéma XML traitent deux documents (un document de schéma XML et un document XML)
  • Les processeurs XSLT traitent deux documents (un document XSLT et un document XML)

Dans ces exemples, les applications sont les suivantes: navigateur, validateur de schéma XML et processeur XSLT. Ces applications traitent un vocabulaire XML. En fonction du vocabulaire XML, une application peut nécessiter un document d’entrée ou deux documents d’entrée (ou plus).

Interopérabilité des données

J’ai souvent entendu dire: « Pour assurer l’interopérabilité des données, chaque application doit interpréter / comprendre le vocabulaire XML de la même manière. »

Quel meilleur moyen de garantir la même interprétation / compréhension que d’utiliser la même application!

En utilisant la même application, nous pouvons obtenir une parfaite interopérabilité des données. REMARQUE: lorsque je dis « la même application », je parle d’un ensemble d’implémentations. Ainsi, Xalan, Saxon et Sabletron sont tous la même application – ils sont tous des processeurs XSLT. Utiliser la même application ne signifie pas, par exemple, que tout le monde utilise Xalan. Une personne peut utiliser Xalan, une autre utilise Saxon et une autre Sabletron. C’est bon; ils ont tous le même comportement; ils suivent tous les règles de conformité XSLT; ils passent tous la suite de tests XSLT.

Voici un exemple pour illustrer comment l’interopérabilité des données est réalisée par l’utilisation partagée de la même application.

Exemple: considérons XSLT. Je peux créer un document XSLT et l’exécuter sur mon processeur XSLT. Je peux vous envoyer le document XSLT et vous l’exécutez sur votre processeur XSLT. Nous avons le même comportement. Nous sommes parfaitement d’accord sur ce que signifie l’élément <xsl: for-each> et sur son comportement. Idem pour tous les autres éléments et attributs du vocabulaire XSLT. Nous avons interopéré avec succès. Qu’est-ce qui a permis cela? Réponse: Ce qui a permis l’interopérabilité, c’est le fait que nous utilisons la même application. (Encore une fois, je dois souligner que cela ne signifie pas que nous utilisons la même implémentation de l’application; vous utilisez peut-être Xalan et moi, peut-être que nous utilisons Saxon; ce n’est pas grave; ce sont deux processeurs XSLT.)

Je peux créer un deuxième document XSLT et vous l’envoyer. Là encore, notre interopérabilité est parfaite. Et un troisième document XSLT. Et ainsi de suite. L’application du processeur XSLT facilite la création, l’échange et l’exécution sans discontinuité de différentes transformations XSLT avec une parfaite compréhension / interopérabilité.

Résumer

Voici les points principaux:

1. Lorsque vous créez un vocabulaire XML, spécifiez le comportement du vocabulaire XML. Spécifiez les exigences de conformité. Créez une suite de tests. Implémentez des applications conformes, chacune ayant le même comportement (les implémentations peuvent varier en taille, en performance, en langage de programmation, etc.). Tout le monde utilise les implémentations.
    2. L’interopérabilité des données n’est pas assurée par une compréhension partagée du vocabulaire XML. L’interopérabilité des données est obtenue par l’utilisation partagée de l’application du vocabulaire XML.
    3. Créer un vocabulaire XML sans spécifier son comportement est une mauvaise idée. Il s’agit au mieux d’une recette d’interopérabilité des données différée, au pire d’une interopérabilité des données défaillante.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *