E.11 Complétude de la fonction T R
2.5 Expression d’un choix dans XML Schema et dans Schematron
La figure 2.4 contient le fragment de XML Schema DocBook exprimant les mêmes contraintes que le fragment de DTD précédent. Figure est défini comme un type structuré (ligne 1) ; la cardinalité est exprimée au moyen de deux attributs (minOccurs et maxOccurs, lignes 3 et 4), et il est possible d’utiliser des groupes d’éléments et d’attributs (lignes 5, 6 et 10), qui d’une certaine manière remplacent les entités paramètres internes des DTD. Le type des attributs peut être modélisé au moyen de n’importe quel type de données de base (ou d’une de ses extensions/restrictions), et il est possible de définir des valeurs par défaut (ligne 9). Les XML Schema sont très riches du point de vue de l’expressivité, mais sont plus verbeux que les DTD et plus difficiles à maîtriser (la recommandation du W3C, séparée en deux documents, représente plus de 300 pages [209, 25]).
Schematron
Schematron [129] repose sur le concept de règles. Un schéma Schematron définit un ensemble de mo-tifs structurels (patterns) qui décrivent des contraintes, sous forme de règles, à vérifier par les instances de document. Schematron utilise une syntaxe XML. Le processus de validation, illustré avec l’exemple de droite de la figure 2.5, est relativement simple et peut être implémenté en XSLT. Pour chaque règle, l’attri-but context (une expression XPath, voir section 2.4.1) identifie un ensemble de nœuds dans la structure du document à valider (ici des éléments personne) sur lesquels des contraintes doivent être vérifiées. Ces contraintes sont représentées par des assertions exprimées au moyen d’autres expressions XPath, et sont vérifiées pour chaque élément de l’ensemble identifié précédemment par l’attribut context. Dans notre exemple, nous vérifions que les éléments personne (ligne 1) contiennent exactement un élément fils (ligne 3), et que cet élément fils est de type homme ou femme (ligne 2).
figure 2.5 illustre la définition du contenu d’un élément comme un simple choix (l’élément personne doit contenir soit un élément homme soit un élément femme). Elle est donnée en XML Schema (approche grammaticale) et en Schematron (approche système de règles). Même si XML Schema a tendance a être plus verbeux, nous voyons que l’expression du choix, située à un niveau d’abstraction plus élevé, est plus simple dans ce langage. Elle ne nécessite la déclaration que d’un choix et de ses options, alors que la règle Schematron a besoin d’exprimer une contrainte sur le type des options et une contrainte sur leur occurence.
Autres solutions et combinaison des approches
En réponse au manque d’expressivité des DTD et à la trop grande complexité des XML Schema, J. Clark et M. Murata ont développé RELAX-NG [56], produit de la fusion de TREX (Tree Regular Expressions for XML [55]) et RELAX (REgular LAnguage description for XML [168]). RELAX-NG se veut facile à apprendre et simple à utiliser. Il supporte les espaces de noms, propose des mécanismes d’importation et d’inclusion, et tente de traiter les éléments et les attributs de manière aussi uniforme que possible. RELAX-NG ne définit pas ses propres types de données, mais permet l’utilisation d’un système existant, comme les datatypes de XML Schema. D’autres propositions ont été faites, comme DCD (Document Content Description [34]) ou DSD (Document Structure Description [134]) ; celles-ci semblent être plus ou moins abandonnées mais ont influencé la conception des langages précédents.
L’expressivité et la facilité d’utilisation varient beaucoup en fonction du langage de schéma employé et du type de contraintes à modéliser. Comme nous l’avons vu précédemment, Schematron et les XML Schema permettent la formulation de contraintes très différentes. La complexité des XML Schema, due à leur grande expressivité qui n’est pas toujours nécessaire, rend les tâches de spécification de schéma et de validation plus difficiles, et il peut être plus intéressant d’utiliser RELAX-NG. Les différents langages sont donc complémentaires. Pour ces raisons, il semble intéressant de pouvoir utiliser différents langages de schéma en fonction des besoins. Ainsi, certains validateurs supportent l’incorporation de règles Sche-matron dans un XML Schema. Des discussions sont aussi en cours quant à la possibilité de supporter des règles Schematron dans RELAX-NG, qui rappelons le, permet déjà l’emploi d’un système de types de données externe. Une autre initiative dans cette direction est DSDL (Document Schema Definition Languages [120]), un projet en cours de développement qui permettra “d’appliquer dans un même cadre des tâches de validation différentes au même document XML pour parvenir à un résultat de validation plus complet en se reposant sur plusieurs technologies”.
Les besoins de transformations 33
2.2.3 Modularisation
Les mécanismes d’inclusion et d’importation mentionnés précédemment sont très importants dans le cadre de la modularisation des schémas. La modularisation d’un schéma consiste à séparer sa défini-tion en différentes parties plus ou moins autonomes, ce qui favorise la lisibilité, la maintenance et la réutilisation des composants. Les applications XML peuvent ainsi être combinées plus facilement, tout en conservant un schéma pour les classes de documents ainsi créées. La modularisation permet aussi de répondre en partie au problème d’adaptation [217] : les périphériques tels que les PDA (Personal Digital Assistant) et les téléphones mobiles embarquent, en général, du fait de leurs capacités limitées, des navigateurs légers ne supportant qu’un sous-ensemble des fonctionnalités proposées par un langage. Sont ainsi apparus des profils comme XHTML basic et SMIL basic, définis à partir de composants des applications XHTML 1.0 et SMIL 2.0, ou encore SVG tiny et SVG basic définis à partir de SVG. Le processus d’adaptation des documents nécessite souvent la manipulation des documents XML afin de les rendre compatibles avec le profil cible défini. Ce problème, qui peut être très complexe, est en général traité au moyen de transformations documentaires.
2.3 Les besoins de transformations
Comme nous l’avons vu précédemment, de nombreuses applications ont adopté XML comme format pour représenter, stocker et échanger les documents et les données qu’elles manipulent. La syntaxe et la structure communes à tous ces langages fondés sur XML, et le fait que ce dernier soit un standard non propriétaire, facilitent grandement les traitements appliqués à ces données, permettant l’utilisation d’ou-tils génériques tels que les analyseurs syntaxiques (parsers), les validateurs (validators), les interfaces programmatiques (API, Application Program Interface) et les moteurs de transformation. Ces langages restent cependant différents quant au type d’information qu’ils représentent, qui dépend du domaine au-quel est dédiée l’application, et aussi quant à leur manière de structurer cette information. Du fait de l’existence de ces différents langages apparaissent un certain nombre de besoins liés aux transformations de documents structurés. Ces transformations permettent la restructuration des documents, la conver-sion d’un vocabulaire à un autre, l’extraction d’information à partir de documents sources, ou encore l’enrichissement du contenu.Les applications des transformations documentaires sont diverses, mais les plus fréquentes sont celles liées à la présentation des documents. XML permet en effet de dissocier le contenu des documents de leur présentation. Les avantages de cette séparation sont multiples : elle permet par exemple de struc-turer le document source de manière purement logique, sans que des contraintes liées à la présentation ne viennent influencer ni la structure ni le contenu, comme cela peut être le cas en HTML. Elle permet aussi d’associer de multiples présentations à un même document source, par exemple en fonction du contexte d’utilisation du document (filtrage de l’information), des capacités de traitement et d’affichage des machines sur lesquelles le document est visualisé (problème d’adaptation mentionné précédemment), ou encore en fonction du médium choisi par l’utilisateur pour recevoir le document (représentation gra-phique mais aussi sonore du document). Cependant, cette séparation implique que les éléments et les attributs d’un vocabulaire XML n’ont pas forcément une sémantique de présentation. Ainsi, pour fournir une représentation d’un document utilisant un tel vocabulaire, il est nécessaire de le transformer en un
documents PDF à partir de XSL Formatting Objects). Notre document utilise deux vocabulaires : Doc-Book et MathML2.0 Content. L’application MathML est constituée de deux vocabulaires : MathML 2.0 Content et MathML 2.0 Presentation. Les vocabulaires Content et Presentation servent à représenter les expressions mathématiques de deux manières différentes : le premier se focalise sur le contenu de l’expression mathématique, en associant aux éléments du vocabulaire une sémantique d’opérations ma-thématiques précise, compréhensible par des applications telles que Maple [152] ou Mathematica [194], alors que le deuxième vocabulaire se focalise sur leur représentation, en fournissant un ensemble de symboles et de fonctions typographiques permettant de placer des parties de l’expression en indice ou en exposant, de créer des barres de fraction, etc . . . sans donner à ces éléments une sémantique d’opéra-tion mathématique. Pour représenter le document de la figure 2.2, il est donc nécessaire de convertir les fragments DocBook, par exemple en XHTML, et les fragments MathML Content en MathML Presenta-tion. Il existe pour cela des programmes de transformation, comme les DocBook XSL Stylesheets [230] et le projet db2latex (DocBook to LaTeX [45]), qui inclut notamment MathMLc2p (MathML Content to Presentation transformation [178]), une transformation XSLT écrite dans le cadre de ce travail de thèse. Cette transformation permet par exemple d’obtenir, à partir d’une modélisation MathML Content abstraite, orientée calcul, de l’expression mathématique utilisée dans la figure 2.2 (lignes 32 à 59), une version orientée vers la présentation (en LaTeX ou en MathML Presentation), qui une fois interprétée6, permettra d’obtenir un rendu de qualité tel que celui-ci :
y =
1 + arctan(n(2x − 1)) arctan(n)
2
Mais la présentation des documents XML n’est pas le seul domaine faisant appel aux transformations. Ainsi, deux applications XML créées par deux organismes indépendants pourront représenter des don-nées similaires en utilisant des jeux d’éléments et d’attributs (i.e. des vocabulaires) différents. Le besoin croissant d’échange des données, à travers le Web, entre applications implique de pouvoir convertir des données d’un langage à un autre. Ces conversions entre applications XML sont réalisées au moyen de transformations.
5Même si le vocabulaire DocBook contient quelques instructions liées à la présentation comme l’attribut align, il reste principalement un vocabulaire pour la structuration logique des documents.
6Le processus d’interprétation d’un document exprimé dans un vocabulaire de présentation et qui permet d’obtenir une représentation concrète du document s’appelle le formatage.
Les techniques et les outils de transformation 35 Les transformations sont aussi utilisées pour la création de méta-données pour le Web sémantique (voir le chapitre 6 pour plus de détails). Nous verrons par exemple dans la section 4.4.4 une transfor-mation permettant d’extraire une partie des infortransfor-mations relatives à un document DocBook (lignes 6 à 12 dans la figure 2.2) pour générer des méta-données Dublin Core exprimées en RDF/XML ([69], voir aussi le chapitre 6) qui pourront être incorporées au document XHTML mentionné précédemment. Les méta-données et RDF vont jouer un rôle de plus en plus important dans le cadre des traitements docu-mentaires, par exemple pour optimiser les recherches sur le Web ou encore dans le cadre de l’adaptation de documents avec CC/PP (Composite Capabilities/Preference Profiles [133]), un vocabulaire permet-tant de décrire le profil des appareils électroniques (capacités d’affichage, etc.) et les préférences des utilisateurs.
Enfin, nous verrons dans la section 2.4.1 que l’utilisation de XML dans les bases de données et l’émer-gence de langages de requête XML tels que XQuery [72] tendent à brouiller la frontière entre documents structurés et données, rendant accessibles de nouvelles sources d’informations XML nécessitant elles aussi des transformations lors de leur manipulation.
2.4 Les techniques et les outils de transformation
Le processus de transformation consiste à fournir un ou plusieurs documents sources à un processeur (ou moteur) de transformation (transformation engine) qui extrait une partie ou la totalité du contenu de ces documents, le modifie (recombinaison, enrichissement, filtrage, . . . ) afin de créer un ou plusieurs nouveaux documents appelés documents cibles (ou documents résultats). La transformation peut être spécifiée au moyen d’un langage de programmation généraliste associé à une API spécifique telle que DOM (voir section 2.4.2) pour faciliter la manipulation des structures, ou bien au moyen d’un langage de programmation spécialisé dans la transformation de documents structurés tel que XSLT [82] ou Om-nimark [206].Dans sa thèse, S. Bonhomme classifie les langages selon leur méthode de transformation et de géné-ration du résultat [27]. Il identifie tout d’abord deux classes de transformations :
– les transformations dirigées par la source, qui effectuent un parcours en profondeur d’abord (depth first traversal) de la structure source. La transformation est constistuée d’un ensemble de règles qui sont évaluées par rapport aux nœuds de cette structure ; les règles qui correspondent aux nœuds sont déclenchées durant le parcours et produisent un fragment du résultat, éventuellement en ex-trayant et en transformant des parties de la structure source ;
– les transformations dirigées par la cible, ou transformations par requêtes, dans lesquelles la trans-formation prend la forme d’un document assez proche du document cible mais contenant des ins-tructions d’extraction et de transformation de fragments du document source. La structure source n’est pas parcourue comme dans le cas précédent : au contraire, le processeur effectue un parcours de la structure cible, remplaçant les instructions de transformation rencontrées dans cette structure cible par les résultats associés.
Les approches précédentes, dans lesquelles l’utilisateur spécifie intégralement la transformation, sont dites explicites. Il existe aussi une autre approche des transformations, dite automatique, qui consiste à