de documents XML, se positionne à un niveau d’abstraction assez élevé puisqu’au dessus de XSLT. Son expressivité est cependant proche de celle de ce dernier si l’on tient compte de la possibilité d’exprimer la plupart des prédicats et paramètres non capturés directement par le langage visuel sous forme textuelle (la spécification textuelle se fait dans une fenêtre résumant les propriétés de l’entité sélectionnée comme nous le verrons dans le chapitre 7). Il est ainsi relativement simple de générer des feuilles de transfor-mation XSLT à partir de programmes VXT. La distance entre VXT et Circus est plus grande, ce dernier se trouvant à un niveau d’abstraction inférieur à celui de XSLT. Proposer un mode Circus dans VXT est cependant intéressant pour plusieurs raisons. Premièrement, VXT représente une interface visuelle conviviale pour l’utilisateur débutant non familier avec Circus qui lui permet de créer des transformations sans avoir à apprendre la syntaxe du langage et sans devoir spécifier ou choisir une technique de trans-formation. Le mode Circus est aussi un moyen pour l’utilisateur familier avec XSLT de faire la transition entre les deux langages, puisque VXT peut aussi être utilisé pour générer des transformations partielles, c’est-à-dire des squelettes de code que l’utilisateur finira de remplir manuellement.
FIG. 4.22 : XSLDebugger : un environnement de développement intégré pour XSLT
Ce n’est cependant pas au niveau de l’expressivité que nous pensons pouvoir bénéficier des techniques de programmation visuelle, mais plutôt par rapport aux aspects cognitifs et à la facilité d’utilisation et de compréhension du langage. Il semble donc plus judicieux de comparer VXT aux autres approches visuelles pour la transformation de documents XML. Comme nous allons le voir, il existe un très grand nombre d’environnements visuels offrant une interface graphique au-dessus de XSLT mais dans lesquels la transformation est toujours exprimée directement au moyen de ce dernier. Ces environnements, com-merciaux pour la plupart, sont intéressants mais assez éloignés de la solution que nous proposons et difficiles à comparer. Nous allons donc dans cette section surtout nous concentrer sur les autres langages de programmation visuels permettant la spécification de transformations de documents XML.
4.5.1 Environnements de développement intégrés
Nous avons vu dans l’introduction de ce chapitre que les environnements de développement intégrés pour XML sont équivalents à ce que nous avons nommé VPE (Visual Programming Environments) dans le chapitre 3. Ces outils sont donc à rapprocher de Visual C++ [160] ou JBuilder [29] pour Java qui proposent un environnement de développement graphique au-dessus d’un langage de programmation textuel avec des fonctionnalités évoluées pour la mise au point et la création de l’interface utilisateur du programme lui-même. Comme dans ces environnements, le programme est représenté et doit être spécifié au moyen du langage sous-jacent. Dans le cadre de la transformation de documents XML, il s’agit la plupart du temps de XSLT (certains outils comme Omnimark [206] proposent leur propre langage de transformation). Ainsi, même si l’environnement graphique améliore la lisibilité du code en colorant les mots-clés du langage, nous sommes avec ces outils encore loin des approches de programmation visuelle.
Autres travaux 129 On retiendra cependant quelques éléments intéressants, présents dans un ou plusieurs des environ-nements principaux dont nous citons quelques exemples : XML Spy [4], eXcelon Stylus Studio [94], XSLDebugger [201] et Near & Far Designer [149].
– Un mécanisme qui, lors de la création d’une transformation XSLT, propose uniquement les élé-ments autorisés dans une liste de constructeurs en fonction de l’endroit où l’utilisateur veut insérer son nouvel élément dans la feuille de transformation. Ce mécanisme est à rapprocher de l’interac-tion contrainte proposée par VXT et qui sera détaillée dans le chapitre 7 traitant de l’environnement d’édition associé à notre langage.
– Une représentation graphique des structures source et cible, utilisant des arbres standard comme le JTree Java qui peuvent être développés, ou des formalismes visuels spécifiquement conçus pour la représentation de schémas de documents (DTD dans le cas de Near & Far, DTD et XML Schema dans le cas de eXcelon Stylus Studio). Ces représentations utilisent des diagrammes nœuds/arcs plus ou moins évolués. Comparés à notre langage visuel pour la représentation d’instances de documents et de DTD, ces formalismes semblent moins unifiés (la distance entre une instance et la classe de document semble plus grande). Ils semblent aussi plus complexes et difficiles à lire, ne reposant souvent que sur une simple translation en objets graphiques des constructions syntaxiques des versions textuelles, ce qui peut aussi poser des problèmes de résistance au facteur d’échelle, surtout si l’environnement ne propose pas de fonctions de navigation avancées (zoom et mécanismes de déplacement automatique).
– Des fonctionnalités de mise au point des transformations, comme les mécanismes d’exécution pas à pas avec identification de la règle sélectionnée pour le nœud courant dans l’arbre source et du fragment produit dans l’arbre résultat (figure 4.22). Nous verrons que l’environnement associé à VXT propose un mécanisme similaire pour l’évaluation progressive des transformations.
– Un mode de transformation dirigé par la cible dans lequel l’instance cible est représentée dans sa version formatée (quand il s’agit par exemple de documents XHTML) avec des références à des instructions d’extraction et de transformation qui peuvent être engendrées à partir d’actions de drag & drop de l’utilisateur.
– Des fonctions de génération de transformation à partir d’exemples d’association entre éléments source et cible fournis par l’utilisateur, à rapprocher des techniques de programmation par démon-stration abordées dans l’introduction de ce chapitre. Les environnements de programmation par démonstration ne sont pas détaillés ici car ils sont très éloignés de VXT. Destinés avant tout à un public ayant des compétences très limitées en programmation, ils tendent à cacher les aspects programmatiques de la transformation et sont peu expressifs. Au contraire, VXT représente expli-citement la transformation et est destiné à un public de programmeurs.
4.5.2 Xing
Xing [86, 87, 88] de M. Erwig, est présenté comme un langage visuel destiné aux non-programmeurs (end-users) pour l’expression de requêtes et de transformations sur des documents XML. L’outil propose une représentation des documents appelée document metaphor qui consiste à emboîter les éléments les uns dans les autres comme pour les treemaps mais où seuls les nœuds de type élément sont représentés graphiquement (voir figure 4.23 (a)). Ce formalisme fait un usage très limité du potentiel des
représenta-FIG. 4.23 : Xing
tions graphiques18et ne permet pas de représenter les classes de documents comme les DTD, qui peuvent tout de même être utilisées, lors de la construction des requêtes, afin de ne proposer lors de l’insertion de nouveaux éléments que ceux autorisés par la DTD.
Les requêtes sont exprimées par des règles visuelles reprenant le formalisme précédent étendu par de nouvelles constructions textuelles et visuelles. La requête présentée dans la figure 4.23 (b) utilise par exemple le symbole * dans la partie gauche pour exprimer le fait que le nom de l’élément est indifférent, de manière similaire à XPath. L’absence de liens entre partie gauche et partie droite implique l’utili-sation de références (appelées ici alias) pour identifier dans la partie droite les données extraites de la partie gauche. Ainsi, comme le montre la figure 4.23 (c), il est parfois nécessaire d’utiliser des labels supplémentaires (pub) ce qui alourdit la représentation.
Une différence majeure par rapport aux règles de transformation VXT est que les patterns Xing re-présentant des conditions de sélection dans la partie gauche des règles sont par défaut copiés dans le résultat. Aussi, la première version de Xing ne permet pas d’exprimer des sous-patterns représentant des conditions de sélection mais qui ne doivent pas être transférés dans le résultat. Cette restriction impor-tante implique une limitation sévère de l’expressivité et semble avoir été relevée dans un article à paraître [88]. Ce dernier fait mention d’une nouvelle construction qui permettra d’exprimer des sous-patterns qui ne doivent être considérés que comme des conditions de sélection. Leur représentation est cependant assez lourde du fait de la non-utilisation des couleurs, impliquant l’ajout d’une nouvelle notation.
Enfin, Xing propose des fonctionnalités pour la restructuration des données extraites du document source, à savoir la possibilité de grouper des éléments et un mécanisme d’agrégation. Aussi, le langage offre la possibilité d’utiliser les références basées sur les attributs XML ID et IDREF dans les requêtes, qu’il représente alors par des flèches reliant les nœuds impliqués. Les règles ne peuvent par contre pas être combinées (il n’est par exemple pas possible d’appeler une autre règle sur une partie des données
Autres travaux 131
FIG. 4.24 : XML-GL : représentation XML-GDM d’une DTD
extraites avant de placer le résultat en partie droite). Xing est présenté comme un langage de requête pour XML, ce qui le rend proche de langages textuels comme XML Query, contrairement à VXT qui est présenté comme un langage de transformation pour XML, donc proche de XSLT. Les capacités de restructuration des langages de requête tendent cependant à rendre floue la frontière entre langage de requête et langage de transformation. Ainsi, la constatation faite dans le cadre de la comparaison entre XSLT et les langages de requête XML (section 2.4.1), reste vraie si l’on compare VXT à Xing ; c’est-à-dire que l’expressivité de VXT est plus grande que celle de Xing au niveau des opérations de transformation alors que c’est le contraire au niveau des opérations de sélection et d’extraction.
4.5.3 XML-GL
XML-GL [47, 59], développé par S. Comai, est un autre langage visuel de requête pour XML. Les requêtes sont formulées visuellement au moyen d’un formalisme de représentation basé sur les graphes, la syntaxe et la sémantique des requêtes étant définies par des structures et des opérations de graphes.
XML-GL se base sur XML-GDM (XML Graphical Data Model), un modèle de données visuel basé sur les diagrammes nœuds/arcs pour la représentation de la structure d’instances de documents XML et de DTD (figure 4.24). GL est alors défini comme un langage de requête sur des données XML-GDM. Ainsi, comme dans VXT, l’unification du formalisme pour la représentation des instances, des DTD et des requêtes rend la création de ces dernières plus facile du fait de la ressemblance visuelle des différentes entités manipulées. Comparé au langage pour la visualisation de documents XML et de DTD proposé dans VXT, ce type de représentation semble un peu plus complexe à lire et plus sensible au fac-teur d’échelle. L’utilisation de diagrammes nœuds/arcs, plus courants que les treemaps, peut cependant rendre la représentation plus naturelle pour un certain nombre d’utilisateurs.
Comme Xing, XML-GL est plus un langage de requête qu’un langage de transformation. Il offre cependant une expressivité plus élevée. Les requêtes XML-GL sont visuellement représentées par deux graphes XML-GDM côte à côte séparés par une ligne verticale. La figure 4.25 donne un exemple de
FIG. 4.25 : Requête XML-GL
requête qui sélectionne les éléments order contenant un livre dont le titre est «Introduction to XML» et qui doivent être envoyés à une adresse dans Los Angeles. La partie droite indique que pour chaque élément de type order vérifiant ces conditions, la requête produit un élément order avec seulement les informations précédentes. Le graphe de gauche représente les opérations de sélection et d’extraction, alors que le graphe de droite correspond aux opérations de construction du résultat (création de nouveaux éléments et insertion des données extraites). La liaison entre partie gauche et droite se fait aussi de manière similaire aux aliases de Xing par l’emploi du même label de chaque côté. Les cas d’ambiguïté sont résolus de manière différente, en liant graphiquement par un segment les nœuds des parties gauche et droite.
Comme précédemment, il n’est pas possible de faire appel à d’autres règles dans la partie droite, ce qui limite l’expressivité du point de vue de la transformation des données19. Par contre, XML-GL offre des possibilités de restructuration comme le tri, l’agrégation et le groupement, et gère aussi les attributs ID/IDREF. Comparé à VXT, XML-GL est plus puissant du point de vue de l’expression des conditions de sélection, mais il ne permet pas d’exprimer des transformations (restructurations) aussi complexes. XML-GL, comme Xing, semble donc plus adapté au traitement de données XML provenant de bases de données, alors que VXT est plus intéressant dans le cadre de documents XML exprimés dans des vocabulaires tels que DocBook, MathML, ou XHTML.
4.5.4 Approche basée sur les grammaires de graphes
Zhang et Deng proposent une approche visuelle pour la conception et la transformation de documents multimédia XML [238] basée sur un formalisme appartenant aux grammaires de graphes : les RGG (Reserved Graph Grammar) [237]. Ce formalisme permet d’exprimer une grammaire pour la structure XML et peut donc remplacer en partie les DTD (il semble cependant moins expressif). La validation se fait par l’application récursive d’un ensemble de règles de réécriture décrivant les contraintes sur la
Autres travaux 133 := 3:N 2:D 1:H Museum[1] h1[2] img[3] 1:H Museum[1] N D Name[2] Direction[3] M M
FIG. 4.26 : Exemple de régle de réécriture de graphe
structure (figure 4.26 en ne tenant pas compte des constructions pointillées). La partie droite représente un motif (pattern) exprimant des conditions de sélection de nœuds du document source ; la partie gauche représente la production de la règle (le sens de lecture est inversé par rapport aux autres langages). Les transformations sont quant à elles exprimées par une version étendue de ces mêmes règles de réécriture, qui appliquées sur la structure source, transforment celle-ci en un document résultat (figure 4.26 en tenant compte des constructions pointillées).
Cette approche est intéressante d’un point de vue théorique, car elle propose une méthode innovante et purement visuelle pour la validation et la transformation de structures XML. Elle semble par contre assez peu exploitable sur le plan pratique. L’utilisateur doit en effet manipuler des concepts assez peu intuitifs propres aux grammaires de graphes et plus particulièrement aux RGG, comme le mécanisme de marquage des nœuds (nombres préfixant les vertices dans les règles). D’autre part, un certain nombre d’opérations comme la création de nouveaux attributs dans le résultat ou le réarrangement de contenu textuel sont spécifiées par des actions directement en langage Java, ce qui rend la spécification de trans-formations réalistes extrêmement lourde. Enfin, si l’on considère la validation et la transformation de documents XML en général, les solutions standard à base d’analyseurs XML validants et de moteurs XSLT sont probablement bien plus performantes que l’approche décrite ici.
4.5.5 Environnement d’édition et fonctionnalités proposées
Dans les trois langages visuels décrits précédemment, il est assez peu fait mention de l’environnement d’édition et des fonctionnalités associées. Pourtant, dans le cadre des langages de programmation visuels, l’environnement d’édition est une partie importante de la solution, puisque c’est de lui que va dépendre par exemple la viscosité du langage. L’environnement peut aussi proposer des fonctionnalités aidant le programmeur dans sa tâche, comme des notations secondaires dynamiques, des fonctions de navigation adaptées ou des mécanismes guidant l’utilisateur dans la spécification des programmes afin de prévenir certains types d’erreur. C’est aussi dans cet environnement qu’a lieu la mise au point (debugging) et souvent l’exécution des programmes.
Comme nous le verrons dans la partie «Applications» de ce mémoire, nous avons conçu un environne-ment d’édition et d’exécution pour VXT. Cet environneenvironne-ment intègre des fonctionnalités qui aident l’utili-sateur dans sa tâche au niveau de la spécification et de la mise au point des transformations. Par exemple, l’interaction est contrainte au niveau de l’édition des VPMEs afin d’empêcher l’utilisateur de créer des
l’utilisation de la DTD pour faciliter la création des requêtes, sans donner de détails concrets. Les envi-ronnements de développement intégrés fournissent quant à eux de nombreuses fonctionnalités puisque c’est ce qui représente leur principale valeur ajoutée par rapport à XSLT.