Devoir XML / XSLT / Unicode Frédérik Bilhaut Université de Caen Département d'informatique Les fichiers fournis pour réaliser le devoir sont à récupérer ici : http://www.info.unicaen.fr/~fbilhaut/ens/radi/devoir.tgz 1. Représentation HTML / Unicode de partitions de tablâ Les tablâ sont un instrument de percussion indien. Traditionnellement, la musique écrite pour cet instrument se note en Hindi, en faisant correspondre à chaque note une syllabe de l'aphasyllabaire appelé «Devanāgarī». Cet alphasyllabaire est bien-sûr supporté par Unicode, et l'objectif de cette partie du devoir est de transformer une partition de tabla écrite en XML en une représentation HTML encodée en Unicode. 1.1. Données à transformer Nous allons ici nous limiter au cas où une partition contient un titre et surtout une séquence de mesure contenant chacune une séquence de notes. Voici un exemple de document à transformer (il vous est fourni dans «tabla/entree.xml») : <?xml version="1.0" encoding="utf-8"?> <tabla> <titre>exemple</titre> <mesure> <note>dha</note> <note>dha</note> <temps> <note>ti</note> <note>ra</note> </temps> <temps> <note>ki</note> <note>ta</note> </temps> </mesure> </tabla> 1
La racine du document est «tabla», le titre est donné par une balise «titre» unique et chaque mesure par une balise «mesure». Chaque note est donnée par un élément «note» qui contient une représentation alphabétique de la syllabe Hindi qui la représente, par ex. «Dha» ou «Ta». À chacune de ces notes correspond une notation traditionnelle composée d'une ou plusieurs syllabes Devanāgarī. Par exemple, le nom «Dha» est associé à la syllabe «आ». La table de correspondance entre les noms de syllabes et les caractères Devanāgarī correspondants vous est donnée dans le fichier «tabla/tabla-bols.txt». Il s'agit d'un fichier texte encodé en UTF-8, contenant les syllabes qu'il vous est demandé de gérer dans le cadre de ce devoir. On notera que les notes peuvent parfois être encapsulées dans des balises «temps». Cela signifie que plusieurs notes doivent être jouées dans une seule et même pulsation. Dans ce cas, la notation traditionnelle consiste à souligner ladite suite de note (cf. exemple de sortie plus bas). Inversement, lorsqu'un temps ne contient qu'une seule note, l'usage de la balise «temps» n'est pas obligatoire (mais néanmoins possible). 1.2. Résultat attendu L'image suivante montre un exemple de sortie que l'on pourrait obtenir à partir des données ci-dessus. Le titre apparaît en tête du document. Les notes sont simplement affichées à la suite les unes des autres, sous forme de syllabes Devanāgarī, et les mesures sont séparées par des barres verticales. On souhaite en outre faire apparaître les numéros de chaque mesure. Comme explicité plus haut, les notes qui appartiennent à un même temps sont soulignées ensemble. Pour simplifier, on ne cherchera pas gérer les sauts de ligne. 1.3. Méthode L'intégralité du traitement doit être réalisé en XSLT. Vous êtes libre de choisir le moteur que vous utiliserez pour tester votre feuille, même si vous aurez probablement intérêt à utiliser «xsltproc», qui est déjà présent sur beaucoup de systèmes. Pour la génération du HTML, une solution simple consiste à produire une table contenant une seule ligne et autant de colonnes que de mesures. On obtiendra par suite les barres de mesure en demandant l'affichage des bords droit et gauche des cellules. Le numéro de chaque mesure pourra être inséré à l'aide de la balise «sup». Si possible, les paramètres d'affichage (tailles de police, bordures, marges, etc.) seront spécifiés dans une feuille de style CSS (interne ou externe). Pour plus de lisibilité de la feuille XSLT, les syllabes Devanāgarī devront y apparaître littéralement (on évitera de les spécifier par un code) ; cette feuille sera donc elle-même codée en Unicode. Il est donc fortement conseillé d'utiliser un éditeur qui vous permettra de spécifier les encodages des différents fichiers manipulés. Si votre système ne supporte pas le caractères Devanāgarī par défaut, une police de caractères adaptée vous est fournie dans le fichier «tabla/jaipurunicodenflc.ttf». Pour l'installer sous une distribution Linux, il suffit généralement de copier ce fichier dans votre répertoire «.fonts» (attention à ne pas oublier le point, c'est un répertoire caché). 2. Représentation en SVG d'une analyse syntaxique en dépendances Nous développons et utilisons au laboratoire une plate-forme générique de traitement automatique des langues, appelée LinguaStream, qui permet notamment de combiner des ensembles de tâches sous la forme 2
de chaînes de traitements 1. Au sein de cette plate-forme, les documents et les résultats des analyses sont toujours représentés au format XML. La plate-forme en elle-même peut traiter des documents indépendamment de leur schéma, tout en rajoutant ses propres balises au sein d'un un espace de nommage spécifique. Parmi les différents composants susceptibles de constituer une chaîne de traitement, on trouve un système d'analyse syntaxique exploitant le logiciel Syntex (Bourigault & Fabre). Rappelons qu'une analyse syntaxique (en dépendances) consiste à identifier, au sein d'une phrase, des relations de rection entre des mots ou groupes de mots. Par exemple, dans la phrase «Le chat mange la souris», le mot «chat» est régi par le mot «mange» selon une relation «sujet-verbe». L'objectif de cette partie du devoir est d'écrire une feuille XSLT capable de transformer les données XML représentant l'analyse syntaxique d'une ou plusieurs phrases en une représentation SVG. Note : la familiarisation avec SVG fait partie du travail à réaliser dans le cadre de ce devoir, mais seuls les rudiments vous seront nécessaires. 2.1. Données à transformer Les documents XML que vous devez transformer contiennent à la fois les phrases analysées, découpées en mot, et les relations syntaxiques que ces derniers entretiennent. Un exemple de document vous est fourni dans le fichier «syntaxe/entree.xml», dont voici un extrait : <?xml version="1.0" encoding="utf-8"?> <document xmlns:ls="http://www.linguastream.org/lsd/2.0" xmlns:lsr="http://www.linguastream.org/lsr/2.0"> <sentence> </sentence> <ls:b type="word" id="22">le</ls:b> <ls:b type="word" id="23">corpus</ls:b> <ls:b type="word" id="24">est</ls:b> <ls:b type="word" id="25">découpé</ls:b> <lsr:relation type="determinant"> <lsr:target type="word" id="22" dir="from" /> <lsr:target type="word" id="23" dir="to" /> </lsr:relation> <lsr:relation type="sujet_verbe"> <lsr:target type="word" id="23" dir="from" /> <lsr:target type="word" id="24" dir="to" /> </lsr:relation> </document> On constatera en premier lieu que trois espaces de nommage différents cohabitent dans ce document. L'espace de nommage «vide» correspond aux balises qui marquent la structure du document original ; les balises «document» et «sentence», marquent respectivement la racine du document et les phrases. L'espace ici préfixé «ls» correspond aux marquage des unités entre lesquelles on tisse des relations, en 1 Cf. http://www.linguastream.org 3
l'occurrence des mots. Enfin, l'espace préfixé «lsr» contient les balises utilisées pour représenter les relations proprement dites. Le marquage des mots est très simple : chaque balise «b» identifie une unité, l'attribut «type» spécifiant son type (ici il ne sera question que de mots, unités ici typées «word»), et l'attribut «id» spécifiant un identifiant pour chaque unité (cet identifiant sera utilisé pour définir les extrémités des relations) La spécification des relations fait appel à une suite de balises «relation», dont chacune est idenfiée par un type et correspond à une dépendance syntaxique entre deux mots. Pour chaque relation, nous trouvons deux balises «target» dont chacune correspond à une extrémité. En l'ocurrence ces extrémités correspondent à des mots, spécifiés par leur identifiant dans l'attribut «id». L'attribut «dir» permet quant à lui de savoir si on désigne la source («from») ou la destination («to») de la relation, ce qui permettra in fine de représenter des arcs orientés. On remarquera qu'il s'agit d'une certaine forme de graphe, où les noeuds sont les mots et les arcs les relations syntaxiques. 2.2. Résultat attendu Nous souhaitons représenter graphiquement les phrases et les relations associées, en SVG. Pour simplifier, les phrases seront représentées verticalement, les mots les uns en dessous des autres ; pour des raisons évidentes, cela facilite grandement le dessin des arcs entre les mots. Ces derniers seront représentés à l'aide de courbe de Bézier fléchées. Les différentes phrases seront représentées les unes à côté des autres. Chaque relation est étiquetée par son type. Idéalement, à chaque type de relation correspondra une couleur différente. Le résultat obtenu devrait ressembler à cela (un exemple de fichier SVG résultat vous est fourni dans le fichier «syntaxe/exemple-sortie.svg») : 4
2.3. Méthode Là encore, l'intégralité du traitement doit être réalisée en XSLT. On notera que le codage de cette feuille de transformation nécessite de jongler entre cinq espaces de nommage : celui de XSLT bien-sûr, celui de SVG (les balises que vous générez), plus les trois espaces du document d'entrée : «ls», «lsr», et l'espace de nom par défaut qui est utilisé pour les balises «document» et «sentence». Pour vous faciliter la tâche, le squelette de la feuille de style à réaliser vous est fourni dans le fichier «syntaxe/squelette.xslt». Sur la plan graphique, on simplifiera grandement le problème en considérant comme fixés les écarts verticaux entre les mots, les écarts horizontaux entre les phrases, la taille des polices ainsi que celle des marges latérales allouées au tracé des relations. On veillera cependant à ce que ces différentes distances soient paramétrables (au niveau de la feuille de style). À noter que toutes les grandeurs, y compris les tailles de polices, seront spécifiées en utilisant une seule et même unité, par exemple l'unité «pixel» (en SVG, ces pixels sont de toute façon «virtuels», leur taille effective étant dépendante du facteur de zoom). Les propriétés d'affichage qui dépendent de chaque relation (la couleur notamment) seront préférablement spécifiées dans une feuille de style CSS, qu'elle soit intégrée au document SVG ou non. Le fonctionnement des styles en SVG est tout à fait analogue à leur fonctionnement en HTML. Reportez-vous si nécessaire à l'exemple de sortie SVG qui vous est fourni. Le tracé des arcs peut se faire à l'aide de courbes de Bézier cubiques qui sont traçables très facilement en SVG. Comme on le voit dans l'illustration ci-dessous, une telle courbe est au minimum définie par les coordonnées de ses deux extrémités, et de deux «points de contrôle» qui vont permettre de déterminer sa courbure. De façon approximative, on peut voir une telle courbe comme s'inscrivant au sein d'un rectangle spécifié par ces quatre points. <svg:path d="m100,200 C100,100 400,100 400,200"/> Les autres éléments du tracé ne posent pas de problème particulier : les extrémités des flèches peuvent être tracées à l'aide de simples triangles, donnés par des chemins («svg:path») à trois points 2. L'affichage du texte se fait à l'aide de la balise «text», dont vous gagnerez à exploiter l'attribut «text-anchor». Répétons que globalement, seuls les rudiments de SVG sont nécessaires à la réalisation de ce devoir, que vous pourrez acquérir à peu de frais en étudiant l'exemple de sortie qui vous est fourni. Pour visualiser les résultats obtenus, vous pourrez utiliser une version raisonnablement récente de Firefox, ou bien tout autre application supportant le format SVG (Amaya, Inkscape,...). Précisons enfin que le travail à réaliser peut l'être de façon assez concise (de l'ordre de 60 lignes de XSLT). 3. Modalités de remise du devoir Ce devoir sera réalisé individuellement ou en binôme. Il devra être remis au plus tard le 20 novembre 2006, sous la forme d'un rapport argumenté, incluant les feuilles XSLT dans leur intégralité, et faisant apparaître clairement les résultats obtenus. Barème : 5 points sur 20 pour la première partie et 15 points pour la seconde. 2 À titre de question subsidiaire, vous pourrez chercher le moyen d'adapter leur orientation à celle de la courbe. 5