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