Fragment simplifié de la transformation MathMLc2p

courant, c’est-à-dire par rapport au nœud source effectivement sélectionné par la règle. Ce nœud, appelé nœud contextuel, est référencé dans les expressions XPath par un point9(.) ou au moyen de l’axe self. Enfin, XSLT offre plusieurs primitives de contrôle, pour effectuer des branchements conditionnels (xsl:if, xsl:choose), itérer sur un ensemble (xsl:for−each), effectuer des classements (xsl:sort) et stocker des valeurs (xsl:variable, variables dont il n’est pas possible de modifier la valeur après initialisation (one-time assignement variables)).

Ainsi, dans la figure 2.7, la première règle, qui sélectionne les éléments math ayant comme parent un élément informalequation, produit (ligne 6) dans la structure cible, lorsqu’elle est déclenchée, un élément math. Le contenu de cet élément est alors engendré par l’application des règles de transformation dont l’expression retient les éléments fils du nœud contextuel (qui est un élément math du document source). La deuxième règle donne un exemple de référence au nœud contextuel : elle sélectionne les éléments ci et produit un élément mi dont le contenu est la valeur textuelle du nœud contextuel (élément cisélectionné). Enfin, la troisième règle produit un élément mrow dont le contenu est défini par l’itération sur l’ensemble des éléments fils de apply (sauf le premier, qui correspond à l’élément eq, et le dernier qui est traité en dehors de la boucle de manière à ne pas avoir un signe = de trop). Les règles de transformation sont appelées sur chacun de ces éléments10auxquels est ensuite ajouté un élément mo.

9Là aussi nous retrouvons la notation des chemins de fichiers UNIX, le double point (..) permettant quant à lui de référencer le nœud parent.

10Notons que dans le contexte d’une boucle for−each, le point (.) dans une expression XPath ne fait plus référence au nœud sélectionné par la règle mais pointe sur la variable d’itération de la boucle.

Les capacités de restructuration de plus en plus puissantes de ces langages et l’utilisation de XPath pour l’identification des fragments, de par le recouvrement [146] qu’elles engendrent du point de vue de l’expressivité, tendent à rendre floue la frontière entre langage de requête et langage de transformation pour XML. De nombreux problèmes peuvent être résolus par les deux types de langages, et il est donc difficile d’établir une classification. Il semble cependant que les langages de requête offrent une expres-sivité et un degré d’optimisation plus grands au niveau de la requête, en proposant des constructions comme le select . . . from . . . where de SQL et des mécanismes d’agrégation, alors que les langages de transformation offrent des capacités de restructuration des données extraites plus poussées, permettant notamment l’appel des règles de transformation à partir du corps d’autres règles et la manipulation du contenu des documents. Nous positionnons ainsi clairement VXT comme un langage visuel de trans-formation XML, alors que XML-GL [47, 59] est considéré comme un langage visuel de requête XML (VXT sera comparé aux solutions existantes dans la section 4.5).

2.4.2 Le modèle DOM

Comme nous l’avons dit précédemment, la syntaxe commune à tous les langages fondés sur XML et le fait que ce dernier soit un standard non propriétaire permet la conception et l’utilisation par n’importe qui de composants de traitement comme les analyseurs syntaxiques (parsers). Cependant, pour que ces composants soient interchangeables et utilisables dans différents contextes applicatifs, il est nécessaire que leur interface de sortie soit elle-aussi standard, c’est-à-dire que le résultat engendré soit le même quel que soit l’analyseur utilisé. Il existe deux standards principaux définis indépendamment : DOM (Document Object Model [71]) et SAX (Simple API for XML [98]).

SAX est une interface fondée sur les événements : l’analyseur parcourt le document source et engendre des événements envoyés à l’application cliente. Ces événements sont relatifs à la structure du document source : par exemple, un événement est envoyé à chaque fois que l’analyseur rencontre une balise ou-vrante ou une balise fermante, ou bien lorsqu’il rencontre un nœud de type texte. SAX ne fournit donc pas le document source sous la forme d’une structure, mais sous la forme d’un flot d’événements. C’est donc à l’application cliente de construire une représentation plus exploitable de la structure du document (qui peut être partielle) en fonction de ses besoins.

DOM est une interface programmatique normalisée permettant de manipuler la structure des docu-ments XML (ajout, suppression, modification de la structure et du contenu de l’arbre). Contrairement à

Les techniques et les outils de transformation 41 SAX, DOM s’appuie sur une représentation complète de la structure du document. Cette approche est plus coûteuse au niveau de la consommation de ressources (mémoire), mais elle offre une représentation intégrale et structurée du document, dans laquelle il est plus facile de naviguer et qui est plus facile à manipuler que des événements SAX. Une représentation DOM est donc plus apte à servir de base pour la transformation des documents qu’un flot d’événements SAX. Il existe des implémentations de DOM dans différents langages de programmation généralistes, comme Java, Python, C ou ECMAScript. La combinaison de DOM avec un langage généraliste offre ainsi une solution très expressive puisqu’elle donne accès à toutes les fonctionnalités du langage sous-jacent et offre à l’utilisateur un contrôle très important sur la structure XML. Mais il s’agit d’une approche de très bas niveau comparée à XSLT, puisqu’elle ne définit pas de modèle de transformation a priori. Elle est donc beaucoup plus lourde à mettre en œuvre, puisque l’utilisateur doit prendre en charge le parcours des structures, la création et l’attachement des nouveaux nœuds dans la structure cible, ou encore les tests de sélection des nœuds (les sélecteurs XPath doivent être remplacés par ce qu’ils sont en réalité, une combinaison de parcours et de tests booléens sur le type, le contenu et le contexte (ancêtres et frères) des nœuds de l’arbre).

2.4.3 Le langage Circus

Circus [220, 223, 219, 183] est un langage de programmation spécialisé dans la manipulation de structures de données, et est en ce sens adapté à la manipulation de documents XML, même s’il ne se limite pas uniquement à ce type de structures. Le langage fournit les constructions et opérations communément proposées par les langages généralistes (opérations mathématiques, de manipulation de chaînes, abstractions procédurales, etc.), mais aussi des constructions programmatiques comme le filtrage structurel et un système de types très riche. Ainsi, Circus se positionne, dans le monde XML, à un niveau d’abstraction intermédiaire entre XSLT et des solutions de plus bas niveau telles que DOM combiné à un langage généraliste comme Java. Nous détaillons certaines constructions du langage, que nous utiliserons par la suite puisque Circus est une des deux cibles possibles pour l’exportation des programmes exprimés avec notre langage visuel (VXT).

Système de types

Circus propose un système de types incluant des types de données primitifs (booléens, chaînes de ca-ractères, nombres entiers et flottants) ainsi que des types structurés (multi-ensembles, séquences, tuples, enregistrements et dictionnaires), des types énumérés et des types récursifs. Il est d’autre part possible de définir de nouveaux types par l’union de types existants (opérateur |).

La figure 2.8 contient les déclarations de types permettant de modéliser les structures XML. Le type principal est XMLTree, un type récursif formé par une union de types. Il permet de modéliser les éléments non vides attribués (ligne 5), les éléments non vides sans attribut (ligne 6), les éléments vides attribués (ligne 7), les éléments vides sans attributs (ligne 8) et les autres nœuds terminaux (ligne 9), à savoir les nœuds texte (PCdata et Cdata), les commentaires, et les processing instructions. Le champ label contient le nom de l’élément, le champ attr est un dictionnaire contenant les attributs (couples nom-valeur), et le champ sub est une séquence de nœuds représentant le contenu de l’élément. Il sera possible de déclarer des variables typées au moyen du mot-clé var (lignes 11 à 13, qui représentent un fragment de l’instance de document DocBook de la figure 2.2).

13. hlabel=’section’, sub=[...] i ]i.