Implémentation dun parseur validant pour YML/DML Travail de Master Présentation finale Catherine Pugin 21 avril 2005

2 Plan Introduction générale Rappel sur les langages YML et DML Aspects théoriques de la validation Conception du parseur Tests et gestion des erreurs Conclusion générale

3 Introduction générale (1) Projet YML+ Révision des langages de la famille XML.

4 Introduction générale (2) Situation du projet Révision du langage XML et des langages de modélisation (DTD / XML Schema). Création du langage YML et du langage de modélisation DML. Adaptation du parseur Xerces pour tester la conformité des documents. Implémentation dun parseur conformant spécifique aux langages YML et DML. Implémentation du parseur validant spécifique.

5 Le langage YML (1) Critiques adressées à XML Nœuds textes du texte sur deux lignes Balises Asymétrie : Balises complexes : Entité : é Commentaire :

6 Le langage YML (2) Solutions apportées par YML Balises symétriques / {entité} Nœuds textes clairs [un texte] [un texte]# Relation entre instance et modèle simplifiée

7 Le langage DML (1) Critique des DTD Syntaxe non-XML. Aucune possibilité de typage. Mauvaise définition du contenu mixte. Critique de XML Schema Manque de simplicité.

8 Le langage DML (2) Objectifs du langage DML Syntaxe simple, basée sur YML. Meilleure définition du contenu mixte Minimum de types prédéfinis Un seul type prédéfini : string Possibilité de définir ses propres types. Favoriser la modularité. Écrire un méta-modèle, un DML auto- descriptif.

9 Un exemple simple (1) movie.dml <=eltref name="director" ref="per:person"=>

10 Un exemple simple (2) person.dml

11 Un exemple simple (3) movie.yml [Star Wars] [Georges] [Lucas] [Indiana Jones] [Steven] [Spielberg]

12 La validation (1) Aspects théoriques DML = langage formel. Les lettres de son alphabet sont les valeurs des attributs name des déclarations délément. Un document DML peut donc être représenté par une grammaire darbre et à partir de là par un automate darbre.

13 La validation (2) Limplémentation des automates darbres est relativement complexe. On utilise donc à la place une hiérarchie dautomates déterministes à états finis. Un automate est construit pour chaque déclaration délément et pour la déclaration de la racine. Il représente le sous-arbre de la déclaration qui sétend jusquaux premières déclarations délément.

14 La validation (3) Un automate est décrit par Q = {0,1,2} Σ = {child-1, child-2} δ = 0 x child-1 -> 1 ; 1 x child-2 -> 2 q0 = 0; F = {2} 0 1 child-1 2 child-2

15 La validation (4) Linstance YML est le mot qui doit être accepté par lensemble des automates. Chaque automate accepte un sous-mot, une partie de linstance. Quand tous les sous-mots sont acceptés, linstance est validée.

16 Conception Informations nécessaires Quelles sont les informations utiles dans un document DML ? Séquence et occurrence des éléments Attributs associés à chaque élément Types définis Entités définies Importations

17 Conception Architecture générale Document YML Parseur conformant Modèle DML principal Trois phases de validation Parseur conformant

18 Conception Validation en trois phases Traitement du document DML Création des automates Validation de linstance YML

19 Conception Phase 1 : Traitement du DML But : récupération des informations contenues dans les documents importés. Référencement délément, de structure, dattributs. Définitions de types, dentités. Gestion des préfixes. Construction dun arbre complet à partir de la racine root.

20 Traitement du DML Correspondance entre préfixes (1) Les documents importés dans le modèle principal doivent être définis comme espaces de nommage dans linstance. Instance YML Modèle DML principal

21 Traitement du DML Correspondance entre préfixes (2) Les préfixes ne sont pas obligatoirement les mêmes. Il faut garder une table de correspondance entre les préfixes. Préfixe YMLPréfixe DMLURI personperperson.dml

22 Traitement du DML Référencement Les référencements concernent : Les structures Les listes dattributs Les éléments Quand on rencontre une déclaration de type, ou, il faut la remplacer par la définition correspondante. La correspondance se fait entre lattribut ref de la déclaration appelante et lattribut name de la définition.

23 Traitement du DML Référencement per:firstNameper:familyName firstNamefamilyName id per:id

24 Traitement du DML Résultat

25 Traitement du DML Types … NamePattern int[0-9] yml:string\w*

26 Conception Phase 2 : Création des automates But : représentation de la séquentialité et de loccurrence des déclarations déléments. Un automate est construit pour chaque déclaration. Il représente le sous- arbre de lélément, qui sétend jusquaux premières déclarations délément. Construction récursive des automates.

27 Création des automates Automates simples 4 automates simples pour chacune des 4 occurrences ( once, optional, many, free ) ONCE OPTIONA L MANY FREE

28 Création des automates Illustration (1)

29 Création des automates Illustration (2) 01 fils1

30 Création des automates Illustration (3)

31 Création des automates Illustration (4) 23 fils2 45 fils3

32 Création des automates Illustration (5)

33 Création des automates Illustration (6) 23 fils2 45 fils3 6

34 Création des automates Illustration (7)

35 Création des automates Illustration (8) 3 fils2 5 fils3 0 1 fils1 null 6

36 Création des automates Application à lexemple 0 1 per:firstName 3 per:familyName 0 textNode = true

37 Création des automates Les automates sont stockés dans une table avec : Le nom de lélément quils représentent. Le nom du père de cet élément. 0 Nom de lélémentNom du pèreAutomate per:firstNamedirector

38 Conception Récupération des données (1) Les attributs sont également stockés dans une table. Nom de lattribut Nom de lélément Nom de lélément père TypePatternUtilisation per:iddirectormovieint[0-9]required

39 Conception Récupération des données (2) Les entités définies dans le DML principal sont stockées dans une table. Nom de lentitéValeur eacuteé

40 Conception Récupération des données (3) Les nœuds textes peuvent être typés. On stocke dans une table lélément père du nœud texte et le type. Nom de lélémentType du texte elementtext-type

41 Conception Phase 3 : Validation Pour la validation de linstance, nous disposons : des automates des différentes tables Attributs Entités Correspondance entre les préfixes Nœuds textes

42 Validation Généralités Le parcours de larbre YML se fait de manière top-down. Pour chaque noeud : Choix de lautomate correspondant. Itération sur les fils du nœud. Modification du préfixe si nécessaire. Validation de lélément. Validation des attributs.

43 Validation Illustration (1) Choix de lautomate : état courant = 0. [Star Wars] [Georges] [Lucas] 01 title 3 director

44 Validation Illustration (2) Itération sur les nœuds fils. Lélément title est accepté par lautomate. [Star Wars] [Georges] [Lucas] 01 title 3 director

45 Validation Illustration (3) Lélément director est accepté par lautomate. [Star Wars] [Georges] [Lucas] 01 title 3 director

46 Validation Illustration (4) Validation des attributs. Modification du préfixe : person:id -> per:id Recherche de lattribut dans la table. [Star Wars] [Georges] [Lucas] per:iddirectormovieint[0-9]required

47 Validation Illustration (5) Validation des attributs. Vérification de la valeur de lattribut [0-9] -> 1 [Star Wars] [Georges] [Lucas] per:iddirectormovieint[0-9]required

48 [Star Wars] [Georges] [Lucas] Validation Illustration (6) Validation du sous-arbre Modification des préfixes person:firstName -> per:firstName person:familyName -> per:familyName 0 1 per:firstName 3 per:familyName

49 Validation Illustration (7) Létat courant est terminal. Le sous-arbre est accepté. [Star Wars] [Georges] [Lucas] 02 title 3 director

50 Implémentation en 2 mots Implémentation en Java. Utilisation de lAPI JDOM. Quelques adaptations sont nécessaires : Nœud root supérieur : YML_ROOT. Séquence -- interdite dans les commentaires. Output XML.

51 Gestion des erreurs 2 gestions des erreurs possibles : Arrêt à la première erreur Lors dune erreur, on remonte dun niveau et on continue la validation sur les frères. La seconde solution a été choisie. Vision globale du document.

52 Tests Une base de test a été créée spécialement pour le parseur. Elle comporte une série dapplications YML pour tester les différentes erreurs possibles. Une application complète et réaliste traitant de la Formule 1 en fait également partie. Créée initialement en XML et XML Schema. Traduite et adaptée aux langages YML et DML.

53 Tests (erreurs) La difficulté de tester un parseur validant vient du fait quil faut répertorier toutes les erreurs possibles. Une très bonne connaissance du DML est donc indispensable.

54 Conclusion générale (1) Des modifications ont été apportées au DML en cours de route afin de rendre le méta-modèle déterministe. On a ainsi pu constater la simplicité dadaptation du parseur. On peut donc valider une instance par rapport à son modèle DML, ou un modèle DML par rapport au méta-modèle de la même manière.

55 Conclusion générale (2) Des améliorations sont encore envisageables pour le parseur : Meilleure gestion des préfixes. Meilleure localisation des automates. Meilleure relation entre les 2 parseurs. Les versions futures des langages YML et DML entraîneront bien évidemment des modifications pour les deux parseurs.

56 Conclusion générale (3) Malgré ces remarques, la combinaison des deux parseurs rend les langages YML et DML complètement fonctionnels. Ils répondent complètement à lutilisation requise actuellement qui est la validation des instances et des modèles.

57 Merci de votre attention !