Évolutions futures

IsaViz est distribué publiquement par le W3C depuis le mois de mars 2002. La version actuelle (1.1) est basée sur une version améliorée de XVTM utilisant la technique de dessin XOR mode [135] qui amé-liore de façon considérable le taux de rafraîchissement dans certains cas particuliers. Cette amélioration a été apportée en réponse à la demande de certains utilisateurs qui avaient à manipuler de gros modèles, comme le schéma RDF pour P3P [155], constitué de 852 ressources, 1517 littéraux et 4346 propriétés, ce qui correspond en termes de glyphes XVTM à 6715 objets de type VText, 852 ellipses, 1517 rectangles et 4346 chemins constitués de courbes de Bézier (soit 13430 glyphes indépendants), prouvant ainsi que notre boîte à outils est capable de gérer un grand nombre d’objets graphiques tout en maintenant un taux de rafraîchissement acceptable. La mise à disposition publique de l’outil nous a permis de tester la robus-tesse de l’implémentation et d’expérimenter certains concepts offerts par la XVTM dans une application

représentations de très bonne qualité compte tenu du fait qu’il s’agit d’un agencement automatique, mais les utilisateurs aimeraient une représentation du graphe plus avancée, qui tienne en quelque sorte compte de la sémantique du graphe, par exemple de manière à mettre mieux en évidence les éléments centraux du modèle.

Pour arriver à cette fin, nous envisageons, dans le cadre des nouvelles fonctionnalités à incorporer dans l’environnement, un mécanisme plus ou moins équivalent aux feuilles de style. L’utilisateur pourrait spé-cifier un ensemble de règles de présentation (couleur, forme du glyphe, épaisseur du trait) à appliquer aux nœuds et aux arcs du graphe en fonction par exemple du type de propriété ou de la classe à laquelle appartient la ressource. Comme nous l’avons vu dans le chapitre 3, cette différenciation visuelle des éléments du modèle permettrait à l’utilisateur d’appréhender plus facilement et plus rapidement le mo-dèle. Des utilisateurs ont aussi suggéré l’utilisation d’agencements alternatifs groupant certains couples propriétés/valeurs associés à une ressource dans un tableau. Cette représentation faciliterait la lecture du modèle en effectuant des regroupements et en minimisant le nombre d’arcs dans le diagramme. Les litté-raux et les ressources multimédia (images, vidéo) pourraient aussi être affichés sous leur forme naturelle plutôt que d’être symbolisés par une ellipse étiquetée par une URI.

Édition

Du point de vue de l’édition, nous envisageons dans un premier temps deux nouvelles fonctionnali-tés. La première proposerait à l’utilisateur une forme d’interaction contrainte plus poussée utilisant les informations du schéma RDF associé au modèle édité quand un tel schéma existe. Il serait par exemple possible d’utiliser les propriétés rdfs:domain et rdfs:range définies pour un type de propriété afin d’em-pêcher l’utilisateur de désigner, comme sujet ou objet des affirmations utilisant cette propriété, une res-source appartenant à une classe en dehors du domaine sur lequel est définie la propriété. Afin encore une fois de ne pas trop fortement contraindre l’interaction et ainsi frustrer l’utilisateur, cette fonctionnalité pourrait prendre la forme de simples suggestions faites dans un mode non intrusif.

La seconde fonctionnalité est un générateur de fragments de modèle. Quand un modèle contient beau-coup de fragments ayant la même structure, il est intéressant de pouvoir engendrer les parties statiques de cette structure automatiquement (à l’aide de templates) de manière à ce que l’utilisateur n’ait qu’à spécifier les parties variant d’une instance à l’autre. Les fonctions de couper/copier/coller visuelles sont un premier pas dans cette direction, mais nécessitent tout de même plus d’opérations d’édition que si l’utilisateur pouvait engendrer d’un simple clic un ensemble de ressources et de propriétés.

Environnement interactif pour la

spécification de programmes VXT

Nous avons proposé dans le chapitre 4 un langage de programmation visuel pour la spécification de transformations de documents XML. Nous avons présenté les constructions du langage, et nous avons donné une définition formelle de sa syntaxe et de sa traduction vers le langage XSLT. Nous n’avons par contre pas développé les aspects interactifs du langage, c’est-à-dire l’édition, l’exécution et la mise au point des programmes VXT. Or, encore plus que pour les langages de programmation textuels, l’envi-ronnement de développement associé à un langage visuel représente une composante importante de la solution et est souvent intimement lié au langage lui-même.

Le code source de la plupart des langages textuels peut en effet être modifié avec n’importe quel éditeur de texte et ensuite compilé par une ligne de commande ou depuis un environnement de développement. Ce n’est pas le cas des programmes visuels, qui nécessitent souvent l’utilisation d’un éditeur spécifique. Il serait possible d’envisager conceptuellement l’édition de programmes visuels dans un éditeur de des-sin vectoriel (voire d’images bitmap même si cela semble assez peu réaliste), c’est-à-dire n’ayant aucune connaissance de la sémantique du contenu des images. Mais, au-delà de la plus grande difficulté d’édi-tion des programmes, il serait nécessaire de procéder à une analyse très poussée en plusieurs étapes de la représentation du programme afin de pouvoir l’exécuter. Il faudrait réaliser une analyse lexicale, puis syntaxique de l’image, nécessitant la définition d’une grammaire visuelle complète et d’algorithmes de reconnaissance des structures graphiques employées. Il s’agit là d’une méthode envisageable mais qui nécessite un effort très important de formalisation et d’implémentation et n’est possible que pour cer-tains langages. En effet, même s’il existe des formalismes grammaticaux assez puissants pour modéliser des contraintes syntaxiques multidimensionnelles très complexes (par exemple les Constraint Multiset Grammars [118]), ces formalismes restent difficiles à manipuler et d’un point de vue plus pratique le coût d’exécution de l’analyse grammaticale est souvent élevé.

La relative simplicité de VXT, comparé par exemple à LabView, et le fait que nous avons déjà défini formellement sa syntaxe, en utilisant un formalisme relativement simple (les grammaires relationnelles de Wittenburg [235]), nous permettraient d’implémenter un analyseur de règles de transformation VXT représentées sous forme d’image ou de dessin vectoriel. Nous avons cependant préféré concevoir un en-vironnement d’édition dédié à VXT dans la lignée des éditeurs spécialisés associés à LabView [11, 127] ou Prograph [65]. Ces éditeurs ont une certaine connaissance du langage, et construisent une représen-tation du programme en mémoire au fur et à mesure que l’utilisateur ajoute et modifie des composants. Grâce à cette connaissance de VXT par l’environnement, nous allons pouvoir définir un mode d’édition spécialisé réduisant la viscosité (voir chapitre 3) et capturant les contraintes syntaxiques définies par la grammaire visuelle directement au niveau de l’interaction, empêchant ainsi la création de règles mal for-mées, à la manière des éditeurs syntaxiques pour langages de programmation textuels (syntax directed editors) tels que le Cornell Program Synthesizer [207] et Alice Pascal [208]. La construction dynamique du programme en mémoire au court de l’édition (en rapport avec la liveness abordée dans l’état de l’art, chapitre 3) va quant à elle nous permettre de proposer des fonctionnalités d’aide à la mise au point, comme l’exécution des transformations depuis l’environnement et l’évaluation progressive de certaines parties des programmes.

appelée ici VPMEs, affiche sur deux couches indépendantes la structure source et l’ensemble des VPMEs (ici trois) de la transformation (comme nous l’avons vu dans le chapitre 4, les opérations de sélection et d’extraction ont été regroupées pour chaque règle en une seule expression représentant la notion de fil-trage : la VPME : Visual Pattern-Matching Expression). Chaque règle de transformation est entièrement représentée dans sa propre fenêtre (par exemple t#0), en reprenant la VPME en partie gauche et en affi-chant la production en partie droite. Trois fenêtres regroupent les fonctions de recherche et de navigation dans la structure, la palette d’icônes pour la construction des VPMEs et des productions, et les proprié-tés (modifiables) du nœud sélectionné (fenêtres VXT, Template et Node Properties). Enfin, la dernière fenêtre (Result) est utilisée lors de la mise au point des transformations et affiche une vue structurale du résultat obtenu. Nous allons voir dans ce chapitre quelles sont les raisons qui nous ont poussé à choisir cette représentation peu orthodoxe des règles de transformation.