REC-DOM-Level-1-19981001


Notes de production (non-normatives)

Editeur
Gavin Nicol, Inso EPS

La spécification DOM est un très bon exemple de la puissance d'utilisation de XML : tous les documents HTML, les correspondances Java, les correspondances en IDL de l'OMG, et les correspondances sous forme de scripts ECMA sont générés à partir d'un seul et même ensemble de fichiers source XML. Cette section met en valeur la manière dont la présente spécification a été écrite en XML, et comment ont en été dérivés plusieurs des travaux.

1. La Définition de Type de Document (DTD)

Cette spécification a été entièrement écrite en XML, en utilisant une DTD largement basée sur celle utilisée par le groupe de travail sur la spécification XML. La différence majeure entre la DTD utilisée par le groupe de travail XML et la DTD utilisée pour cette spécification est le rajout dans la DTD d'un module pour les spécifications d'interfaces.

Ce module pour les spécifications des interfaces est une traduction appauvrie de la spécification de la Forme Étendue de Backus-Naur (EBNF) de la syntaxe de l'IDL de l'OMG vers une syntaxe de DTD XML. En plus de cette transposition, la possibilité de décrire les interfaces a été ajoutée, créant ainsi une forme limitée de programmation littérale appliquée à la définition des interfaces.

Bien que ce module de la DTD soit suffisant pour les besoins du groupe de travail sur DOM, il est très pauvrement typé, signifiant qu'il y a très peu de contraintes mises sur les spécifications de type (l'information de type est effectivement traitée come une chaîne banale). Dans une DTD conçue pour une communication d'objet à objet, des contraintes plus strictes sur les types de données serait certainement bénéfique.

2. Le processus de production

La spécification DOM est écrite en utilisant XML. Tous les documents sont valides au sens de XML. La version HTML de la spécification, l'index des objets, le code source Java, les définitions en IDL de l'OMG et la définition des scripts ECMA sont obtenus par conversion de la spécification en XML.

L'outil actuellement utilisé pour cette conversion est COST de Joe English. COST prend le sortie ESIS de nsgmls, crée une représentation interne, puis permet à des scripts, et à un gestionnaire d'évènements d'être exécutés sur cette structure de donnée interne. Les évènements peuvent prendre la forme de motifs du document auxquels ont associe des traitements : quand le motif est rencontré à l'occasion du parcours le sens préfixe d'un sous-arbre du document, l'action correspondante est exécutée. Cela est le coeur du processus de conversion. Des scripts sont utilisés pour relier différents composants du document. Par exemple, chacune des principales sources de données dérivée (code Java code etc...) est créée par l'exécution d'un script, qui à son tour déclanche l'exécution d'un ou plusieurs évènements. Les scripts et les gestionnaires d'évènement sont spécifiés en utilisant TCL.

La version courante de COST a été quelque peu modifiée par rapport à la version publique disponible. En particulier, elle tourne désormais correctment sous Windows 32-bit, utilise TCL 8.0, et gère correctement la sensibilité à la casse de XML (quoiqu'elle ne pourait pas gérer correctement le balisage natif du langage).

Nous aurions également pu utiliser Jade, de James Clark. Comme COST, Jade permet l'utilisation de motifs et de règles associées, mais Jade repose sur DSSSL, un standard international, contrairement à COST. Jade est plus puissant que COST dans bien des cas, mais des expériences passées de l'éditeur avec Cost faisait qu'il lui était plus facile de l'utiliser que Jade. Une future version ou niveau de la spécification DOM pourrait être produite en utilisant Jade ou un processeur XSL.

Le jeu complet des fichiers sources XML sont disponibles à l'adresse : http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/xml-source.zip

3. Définitions des objets

Come il a été écrit, toutes les définitions d'objets sont spécifiées en XML. Les correspondances en Java, en IDL OMG, et en scripts ECMA sont toutes générées automatiquement à partir du code source XML.

Cela est possible parce que l'information spécifiée en XML est un sur-ensemble de ce que ces autres syntaxes ont besoin. C'est une remarque générale, et le même genre de technique peut être appliquée à beaucoup d'autres domaines : à partir de structures riches, des traitements et des conversions puissantes sont possible. En ce qui concerne Java et l'IDL de l'OMG, il s'agit très simplement de renommer des mots clés de la syntaxiques; pour les scripts ECMA, le processus est un peu plus compliqué.

La définition typique d'un objet en XML resemble à ceci :

<interface name="foo">
  <descr><p>Description goes here...</p></descr>
  <method name="bar">
    <descr><p>Description goes here...</p></descr>
    <parameters>
      <param name="baz" type="DOMString" attr="in">
        <descr><p>Description goes here...</p></descr>
      </param>
    </parameters>
    <returns type="void">
       <descr><p>Description goes here...</p></descr>
    </returns>
    <raises>
       <!-- Throws no exceptions -->  
    </raises>
  </method>
</interface>

D'un premier abord, c'est un peu verbeux, mais pas differement de l'IDL de l'OMG. En fait, quand la spécification a été originellement convertie pour utiliser XML, les définitions de l'IDL de l'IDL de l'OMG ont été automatiquement convertis dans le code source XML correspondant en utilisant les outils de manipulation de texte communs sous Unix.