Réalisation d une plateforme Web de certification de documents XML

Transcription

1 Rémi Godard Vivian Perez Florian Pérugini Bertrand Vitrant Professeur responsable du projet : Mr Fabrice LEFEVRE Rapport de projet Réalisation d une plateforme Web de certification de documents XML Université d Avignon Année 2007/2008 Département Informatique

2 SOMMAIRE 1 Introduction La mission L organisation du travail La reprise de l'existant Introduction Algorithme de comparaison de XyDiff Notre algorithme de comparaison Conclusion Les orientations choisies Les choix de langages Un comparateur à un niveau La répartition du travail Les fonctionnalités Fonctionnalités de l utilisateur Dépôt de fichier à comparer Consultation des résultats Fonctionnalités du rédacteur Dépôt d un fichier modèle Gestion des fichiers Récupération des fichiers Fonctionnalités de l administrateur Ajout d un nouveau profil Modification des profils existants Les données Le problème de la sécurité Identification à l'aide du LDAP Identification selon le profil La réalisation du projet Introduction La création de la plateforme Web La réalisation de toutes les fonctionnalités La mise en forme CSS Javascript - Ajax La création du comparateur XML Les différentes étapes dans l'avancement Le choix de l'architecture de l'arbre des différences Les difficultés rencontrées et leurs solutions Les documents XML générés par OpenOffice La ressemblance des nœuds et le choix du meilleur La présentation des résultats La présentation des résultats en terme XML La présentation des résultats avec transparence du XML La validation des programmes Tests La validation de la plateforme La validation du comparateur Conclusion ANNEXES

3 1 Introduction Durant l année, nous avons dû réaliser un projet qui se décomposait en deux parties principales. La première phase consistait à réaliser un cahier des charges de notre projet ainsi que prévoir les outils nécessaires au développement, et faire un planning prévisionnel. De plus une prévision de la répartition du travail devait être fournie. La seconde étape consistait à concevoir ce projet qui s intitule «Réalisation d une plateforme Web de certification de documents XML». Ce rapport traitera donc de la conception de la plateforme et du comparateur XML. Nous présenterons la mission à réaliser, l organisation au sein du groupe, les solutions choisies ainsi que celles qui auraient pu être envisagées, les fonctionnalités de l'application, les modèles de données, la sécurité de la plateforme, la reprise de l existant, la réalisation du projet ainsi que les difficultés que nous avons rencontrées, puis la présentation des résultats et les tests de validation. 2 La mission Le but de ce projet a été de réaliser une plateforme Web permettant de certifier des documents XML. Afin de permettre l utilisation à distance, nous avons choisi de mettre à disposition le comparateur XML sur une plateforme Web. Le document testé sera comparé à un document modèle qui aura été préalablement déposé. Le comparateur doit être générique afin de comparer divers documents à partir du moment où leur structure est basée sur le langage XML. Par exemple les fichiers au format OpenDocument de la suite OpenOffice sont en réalité des archives, qui contiennent des fichiers XML décrivant le document. Ils peuvent donc être comparés. Cette plateforme permet essentiellement selon le profil de l'utilisateur de déposer un fichier modèle ou de comparer un document. Deux cas ont été choisis afin de tester la compatibilité des documents avec notre comparateur XML : la correction des examens rendus par les étudiants passant l évaluation C2I (Certification Informatique et Internet), la validation de format des fiches de compte rendu de projet des étudiants en M1 de l IUP GMI d Avignon 3

4 3 L organisation du travail Un planning prévisionnel a été rédigé lors de la première phase du projet (pendant le premier semestre), il aura été bien respecté dans l ensemble. Nous avons modifié et ajouté quelques étapes, comme la présentation des résultats d une comparaison ou l intégration de l annuaire LDAP de l université d Avignon. Notre groupe était composé de quatre personnes, le travail a été reparti entre ces quatre membres. Un des objectifs notamment était que tout le monde conçoive le comparateur de près ou de loin. La conception du projet s est découpée en deux grandes parties : La réalisation de la plateforme Web La réalisation du comparateur XML. Une fois le projet fini, différents rapports ont été rédigés comme les documentations techniques pour ceux qui reprendront ou utiliseront le projet, un manuel d utilisateur qui explique le fonctionnement de la plateforme ainsi que ses fonctionnalités et enfin un rapport reprenant l ensemble de ce qui a été fait ce semestre. Planning du second semestre 4 La reprise de l'existant 4.1 Introduction Il était important, avant de commencer à réaliser notre comparateur, de vérifier si des applications ne proposaient pas déjà de comparer deux documents XML, ou quelque chose qui s en approche. Il était en effet intéressant d étudier une application ressemblante à la nôtre pour plusieurs raisons : Gagner en visibilité, ce qui permet d améliorer la compréhension, voire la modélisation, et éviter des erreurs classiques Gagner du temps sur des aspects sur lesquels on bloque S inspirer de ce qui a déjà été fait et éviter de faire une partie qui a déjà été traitée Fabrice Lefèvre nous a informés de l existence d une application permettant de contrôler différentes versions d un document OpenOffice, Office Version Control. En théorie, celle-ci permet de distinguer les différences entre deux versions d un document OpenOffice, d appliquer un patch (correspondant à une mise à jour) sur un document, ou au contraire d inverser un patch (correspondant au rétablissement d une version antérieure). En réalité, cette application ne fonctionne pas avec des documents OpenOffice, mais seulement avec des fichiers XML purs. De plus la documentation est très mauvaise (le projet a été arrêté), il a donc été difficile d étudier Office Version Control. L aspect le plus intéressant est qu il utilise XyDiff. XyDiff est un outil développé par l INRIA (Institut National de Recherche en Informatique et Automatique) qui permet de comparer plusieurs versions d un document XML, ou de comparer deux documents XML ayant la même structure. Nous pensions donc au début que l étudier pourrait nous aider à améliorer notre comparateur, notamment et surtout au sujet de la comparaison d une séquence de nœuds. En effet notre comparateur s arrête à un niveau. Le problème est que dans l outil XyDiff, la comparaison ne se faisant que sur le contenu, il est supposé que la structure 4

5 (l arborescence des nœuds XML) soit la même pour les deux fichiers comparés. Ce qui éloigne beaucoup cet outil du nôtre. Nous avons quand même voulu observer le fonctionnement de XyDiff, pour savoir si nous pouvions nous inspirer de certaines parties. Ceci n a pas été facile, car l outil nécessite d être paramétré, et bien qu il soit complexe, il n existe pourtant aucune documentation. Le principe de XyDiff consiste à créer un fichier XML, puis créer aléatoirement un patch de mise à jour et à l appliquer sur une copie de ce fichier. Ces deux fichiers sont donc ressemblants, ont la même structure et peuvent être comparés. Il est en théorie également possible de comparer deux fichiers XML de notre choix, mais ceci ne fonctionne pas, et sans documentation, nous avons renoncé à tenter de corriger l erreur. Nous avons donc étudié l algorithme de comparaison de deux arbres XML utilisé par XyDiff et l avons comparé au nôtre. 4.2 Algorithme de comparaison de XyDiff Classe : XMLCompareEngine Fonction : compare(noeud1, Noeud2) Etapes Test si les deux nœuds sont nuls (si oui => ERREUR) Tests sur les types de nœuds (si différents => ERREUR) o Type : élément Comparaison des noms de nœuds Comparaison des attributs : appel de compareattributes(listatt1, listatt2) Test si Noeud1 et Noeud2 ont des fils Si aucun des deux : Sortie fonction Si un des fils et l autre non : ERREUR Si les deux ont des fils : Continue On récupère le premier fils de chaque nœud Boucle sur les fils de Noeud1 Incrémentation de fils2 o Si fils2 nul : ERREUR Appel récursif de compare sur fils1 et fils2 A la fin de la boucle, s il y a encore des fils2 : ERREUR o Type : texte, CDATA Test si Noeud1 et Noeud2 sont des chaînes de caractères Comparaison des valeurs de Noeud1 et Noeud2 o Type : Commentaire Vérification que les commentaires sont égaux o Type : Entité Non traité : ERREUR o Type : différent (inconnu) Non traité : ERREUR Fonction : compareattributes(listatt1, ListAtt2) Etapes Comparaison du nombre d attributs Parcours des attributs (par rapport à ListAtt1) o Test si ListAtt2 possède l attribut correspondant à ListAtt1(indice) Si non : ERREUR o Test de l égalité des valeurs de ListAtt1(indice) et ListAtt2(indice) 5

6 4.3 Notre algorithme de comparaison Fonction : parcoursarbre (NoeudModele, NoeudTeste) Etapes Test si les deux nœuds sont nuls Sinon test si le nœud modèle est nul Alors insertion. Sinon test si le nœud testé est nul Alors délétion. Sinon les deux nœuds ne sont pas nuls : - Compare (noeudmodele, noeudteste), qui effectue une comparaison sur les types et noms de nœuds, et sur le nombre et la valeur de leurs attributs. Elle indique s il y a substitution, insertion, délétion ou si les nœuds sont identiques. - Si le nœud modèle a des fils et l autre non : * Délétion de tous les fils. - Si le nœud testé a des fils et l autre non : * Insertion de tous les fils. -Si les deux nœuds ont des fils : * On créé les listes des fils des nœuds modèle et testé. * On créé une boucle afin de parcourir tous les fils modèles. Pour chacun d entre eux, tous les fils testés présents dans la liste sont parcourus et celui qui est le plus ressemblant est choisi. La fonction parcoursarbre () est rappelée, paramétrée du nœud modèle et du nœud testé sélectionné. * Lorsque tous les nœuds modèles on été parcourus, on regarde s il reste des nœuds testés. Si c est le cas, il y a une insertion. 4.4 Conclusion L algorithme utilisé par XyDiff est donc plus simple et moins performant que le nôtre, à l exception, au départ, des différents types de nœuds qui étaient mieux gérés. Nous avons donc intégré à notre comparateur cette approche par type. Le temps de calcul du comparateur est devenu, grâce à cette approche, beaucoup moins important. Nous avons donc réellement amélioré notre comparateur XML grâce à l étude de l outil XyDiff, même si ce n est pas sur l aspect que nous pensions avant l étude. En effet, nous nous sommes inspirés de XyDiff pour la comparaison par type de nœud, alors que nous pensions l étudier pour réussir à comparer une séquence de nœuds. 6

7 5 Les orientations choisies Durant la réalisation du projet, il a fallu faire un certain nombre de choix que ce soit pour la conception ou l organisation. Nous vous présentons les principaux ci-dessous : 5.1 Les choix de langages La plateforme Web a été développée à l aide du langage PHP. Nous sommes basés sur la norme XHTML 1.1 pour éditer les pages Web. Le langage JavaScript a été utilisé également pour un certain nombre de scripts, associés parfois à la méthode AJAX. Quant au comparateur XML, nous avons choisi de le développer en PHP, pour des raisons de facilité d intégration à la plateforme, celle-ci étant en PHP. De plus, PHP5 propose les APIs DOM et XSL nécessaires au développement de notre comparateur. Il aurait été possible de développer le comparateur en Java qui propose également différentes solutions pour les fichiers XML, comme l API JAXP. 5.2 Un comparateur à un niveau Lors de notre avancement nous avons réalisé la difficulté à comparer des fichiers assez différents. Une fois que le nœud comparé est différent de celui testé, le but est de regarder si les fils de ceux-ci, sont identiques ou non. S ils le sont, le nœud testé doit être associé au modèle afin de «raccrocher» dans les arbres. C est pourquoi nous avons choisi de faire la comparaison sur un seul niveau : si une différence est repérée, on regarde le nœud suivant, s il est toujours différent on considère que tout le sous-arbre est différent. Sinon on recommence à comparer à partir de ce nœud. Une solution pour optimiser cette comparaison serait de travailler sur des séquences de nœuds modèles, et d effectuer des recherches dans tout l arbre testé. Nous n avons pas implémenté cette méthode par manque de temps. 5.3 La répartition du travail Afin d avancer efficacement le projet, nous avons décidé de découper le projet en deux phases de réalisation : la plateforme Web le module de comparaison Ces dernières n avaient rien en commun et pouvaient être développées en parallèles. Une fois les deux parties terminées, le comparateur a été intégré à la plateforme. Ceci a pris plus de temps que ce que nous avions prévu, mais s est passé dans de bonnes conditions. Cette solution nous a permis d optimiser le rendement et de prendre de l avance dès le début du second semestre. 7

8 6 Les fonctionnalités La plateforme Web propose différentes fonctionnalités selon le type de profil connecté. On distingue trois profils : Administrateur rédacteur utilisateur 6.1 Fonctionnalités de l utilisateur Dépôt de fichier à comparer Une fois connecté à la plateforme, l utilisateur choisit le modèle de comparaison, puis dépose son fichier Consultation des résultats L utilisateur peut consulter les résultats d une comparaison. Si le document modèle auquel se réfère un document à comparer possède une date de limite de dépôt, celle-ci doit être passée pour que la consultation puisse être faite. 6.2 Fonctionnalités du rédacteur Le rédacteur possède les droits de l utilisateur, en plus des droits suivants Dépôt d un fichier modèle Une fois connecté à la plateforme, le rédacteur peut y charger un fichier modèle. Etant donné que plusieurs modèles peuvent être déposés, le rédacteur donne une désignation à chaque modèle ajouté pour l identifier. Il doit de plus paramétrer plusieurs options : fixer ou non une date limite de dépôt de document à comparer fixer ou non la comparaison du contenu des documents choisir si l utilisateur ayant déposé un fichier à comparer a le droit de consulter le résultat de la comparaison Gestion des fichiers Le rédacteur peut modifier ou supprimer un fichier modèle, supprimer des fichiers testés, des fichiers résultats ou des archives Récupération des fichiers Il est proposé au rédacteur de télécharger sous forme d archive un ou plusieurs documents modèles, ou l ensemble des documents à comparer ou résultats associés à un document modèle. 8

9 6.3 Fonctionnalités de l administrateur L administrateur possède les droits de l utilisateur et du rédacteur, en plus des droits décrits ci-dessous Ajout d un nouveau profil L administrateur peut ajouter un nouvel profil (utilisateur, rédacteur ou administrateur) à la plateforme Web. Celui-ci sera inscrit dans la base de données interne Modification des profils existants L administrateur peut modifier ou supprimer un profil. Dans le cas de la modification, il est possible de changer l identifiant et le mot de passe. 9

10 7 Les données En cours de réalisation de la plateforme, nous avons modifié certaines fonctionnalités et ajouté quelques options mineures, et il a fallu modifier la base de données. Nous avons jugé que la table «admin_appli» liant un administrateur à une utilisation n était plus nécessaire étant donné qu un administrateur l est pour toute l application. Nous l avons donc supprimée. Ensuite nous avons ajouté ou supprimé quelques colonnes dans certaines tables. Par exemple, l ajout de l option de comparaison du contenu pour un document modèle a eu pour conséquence l ajout du champ «suppr_contenu» dans la table «doc_modele». Le modèle physique de données tel que nous l avons conçu au premier semestre, n a tout de même subi aucun changement majeur. 10

11 8 Le problème de la sécurité Il était nécessaire d identifier les utilisateurs afin d assurer la sécurité de la plateforme. Cette dernière offre la possibilité de déposer des fichiers modèles ou encore de consulter des résultats, il est donc évident qu un simple utilisateur ne puisse pas accéder à ces fonctionnalités. Dans le cadre de l université, il nous est possible de faire une connexion à l annuaire LDAP, qui est un annuaire recensant toutes les personnes de l université. Si l utilisateur ne fait pas partie de la faculté, alors on recherche s il fait partie de la base de données interne de la plateforme. 8.1 Identification à l'aide du LDAP Dans le cadre de la certification C2I, les utilisateurs sont des étudiants, il était donc nécessaire de faire une identification par rapport à ce dernier. Après identification dans le LDAP, on retrouve diverses informations sur l utilisateur : Son nom Son prénom Son profil Son adresse La donnée la plus importante pour la plateforme est le profil, car c est elle qui détermine quelles fonctionnalités seront disponibles pour l utilisateur qui se connecte. Par exemple, un utilisateur authentifié «student» ne pourra que déposer des fichiers à comparer et consulter les résultats d une comparaison. Il existe cinq profils dans le LDAP : student, attribué aux étudiants (connecté en tant qu utilisateur) employee, attribué aux professeurs (connecté en tant que rédacteur) faculty, attribué au personnel administratif (connecté en tant que rédacteur) researcher, attribué aux doctorants (connecté en tant qu utilisateur) affiliate, attribué aux invités (connecté en tant qu utilisateur) 8.2 Identification selon le profil Dans le cas où l utilisateur qui se connecte est inscrit sur l annuaire LDAP, et si c est sa première connexion à la plateforme, son profil sera enregistré dans la base de données interne, pour qu il puisse déposer des documents (de quelque type qu ils soient). Dans le cas contraire, on recherche s il fait partie de la base de données interne de la plateforme. Dans cette base de données, il existe aussi différents profils que l on a détaillés ci-dessus ainsi que les fonctionnalités qui leur sont associées. 11

12 9 La réalisation du projet Pour la réalisation du projet, on distingue deux grandes parties : la création de la plateforme Web la création du comparateur 9.1 Introduction Nous avons créé cette application dans l optique qu elle soit réellement utilisée, et nous nous sommes donnés les moyens pour arriver à cette fin. Premièrement, la plateforme Web a été développée de façon très structurée. L arborescence des répertoires de l application suit une logique, en étant composée d une partie générique, et d autres parties propres à chaque cas d utilisation, pour les graphismes et les fichiers déposés et générés (pour plus d information, cf. «Documentation technique plateforme Web»). Le code a été commenté, et respecte la norme W3C pour le XHTML 1.1, ce qui donne de la clarté et de l harmonie dans la lecture. L application est donc prête à être utilisée, et un manuel a été rédigé pour expliquer pas à pas son fonctionnement (cf. «Manuel utilisateur de la plateforme Web»). Il est également aisé de lui ajouter de nouveaux cas d utilisations, car ceux-ci sont séparés de l application elle-même. Enfin la maintenabilité est assurée car nous avons rédigé une documentation technique (cf. «Documentation technique plateforme Web»). Le comparateur, quant à lui, fonctionne de manière satisfaisante, même si nous savons qu il n est pas encore optimal (notamment au niveau de la comparaison de deux séquences nœuds, ou de l interprétation de différences entre deux fichiers XML issus d OpenOffice). Mais nous avons fait en sorte qu il puisse être amélioré, en créant une documentation technique (cf. «Documentation technique du comparateur XML»), et en le développant de manière claire et très commentée. 9.2 La création de la plateforme Web La réalisation de toutes les fonctionnalités Les diverses fonctionnalités ont été réalisées avant d intégrer le graphisme. La première étape a été de réaliser tous les formulaires avec leur traitement, puis de faire une authentification avec la possibilité de choisir une application (TP de c2i ou comptes rendus de réunion de projet). Une fois les fonctionnalités réalisées, il était nécessaire de présenter le site de façon à ce qu il s intègre aux divers modules de l UAPV La mise en forme CSS Javascript - Ajax Pour la mise en forme, nous avons utilisé le langage CSS et créé deux styles graphiques : le premier est basé sur le style du site de la plateforme pédagogique de l université d Avignon ( et concerne l application de pré-correction de TP pour la certification C2I. 12

13 le second est basé sur le style du site de l IUP GMI d Avignon et concerne l application de validation de format des fiches de comptes rendus de réunion de projet de master première année. L implémentation de la plateforme a été pensée de manière à ce que si on voulait lui ajouter une application, il suffirait alors de créer un répertoire pour cette application et de respecter l arborescence existante. Une bannière pourrait être redéfinie ainsi que le style complet même si l architecture resterait identique. Une fonction JavaScript appliquée sur le menu permet de montrer ou cacher deux fonctionnalités, à la manière de sous-menus. Certaines fonctionnalités, comme le changement des droits, utilisent des fonctions JavaScript et des requêtes AJAX. Cela permet de configurer en temps réel les profils utilisateurs sans avoir à recharger une page, ce qui est beaucoup plus agréable pour l utilisateur. Les autres fonctions JavaScript développées sont toutes destinées à rendre plus agréable la navigation sur la plateforme en évitant des chargements de pages superflus. Une fois terminée, nous avons validé la plateforme en respectant la norme W3C, pour le CSS et l XHTML

14 9.3 La création du comparateur XML Les différentes étapes dans l'avancement La première étape a consisté en créer un comparateur qui détermine si le document soumis était strictement identique au modèle ou non, les différences n étaient pas repérées et le comparateur retournait 0 ou 1. Dans un second temps, nous avons essayé de repérer des différences en avançant dans les deux arbres et en indiquant l endroit ainsi que le nœud concerné. L étape suivante a consisté en, une fois la différence trouvée, continuer la comparaison et indiquer toutes les différences repérées. Les différences étant repérées, le but a été de les organiser afin de les interpréter efficacement Le choix de l'architecture de l'arbre des différences Le but étant de présenter les différences entre les deux arbres à un utilisateur, il était nécessaire de stocker ces informations. Elles ont été classées en trois catégories dans un arbre de différence. Ces catégories sont «insertion», «délétion» et «substitution». Les nœuds qui apparaissent dans le document testé mais pas dans le document modèle sont rangés dans «insertion». Lorsque l on arrive sur un nœud du document modèle qui n apparaît pas dans le document testé, celui-ci est stocké dans «délétion». Il reste un dernier cas qui consiste à déterminer la ressemblance entre deux nœuds, car il peut y avoir à un niveau donné autant de nœuds d un coté que de l autre et qui présentent des ressemblances, dans ce cas on indiquera une «substitution». On distingue différentes substitutions entre deux nœuds : Substitution de nom Substitution d attributs, le nom ou la valeur Substitution du nombre d attributs Substitution de contenu 14

15 10 Les difficultés rencontrées et leurs solutions 10.1 Les documents XML générés par OpenOffice Lors de la conception du comparateur, nous avons commencé avec des cas très simple et qui fonctionnaient très bien. Au fur et à mesure nous avons tenté de complexifier les fichiers XML, puis nous en sommes arrivés à tester des fichiers de traitement de texte (fichiers à l extension.odt) d OpenOffice. Pour des fichiers très simples cela n a pas posé de difficulté particulière, mais pour des fichiers plus complexes les résultats se sont avérés moins satisfaisants. En analysant l arbre de différence, les résultats retournés étaient justes. le problème ne venait donc pas de la comparaison. Il s agit en fait d une génération particulière des fichiers XML par OpenOffice. En effet lors de la création d un style généré lorsque l on associe une mise en forme à un contenu (par exemple : mettre un mot en gras), OpenOffice incrémente sa liste de styles mais ne tient pas compte de l ordre dans lequel il les crée. Par exemple, si vous créez plusieurs styles dans les deux fichiers mais pas dans le même ordre, vous obtiendrez pour le style «gras souligné» la valeur P1 dans le fichier modèle et la valeur P3 dans le fichier testé. A partir de ce constat nous comparions des nœuds qui dès le départ n avaient rien en commun et donc n auraient pas dû être comparés. Il s agit alors de repérer le contenu d un style puis de chercher dans l autre fichier le style qui est appliqué au même contenu. Il n était pas prévu au départ de travailler sur les contenus des nœuds. En effet, l objectif fixé était de ne comparer des fichiers XML que sur leur structure, et non sur le contenu des nœuds de type «text». On peut facilement imaginer que la comparaison puisse être effectuée pour des styles mais pas pour du contenu, si le contenu du nœud testé ne contient ne serait-ce qu une lettre de différence ou un espace vide, le nœud qui lui est associé ne sera jamais trouvé. De plus lorsque qu un style a été créé mais n est plus utilisé dans le document, il est tout de même généré lors de la transformation en arbre, ce qui pose de grosses difficultés étant donné que le nombre de nœuds d un côté est différent de l autre. Cela peut donc éloigner deux fichiers qui ont pourtant le même contenu La ressemblance des nœuds et le choix du meilleur Lors de comparaisons, dans certains cas, certains nœuds modèle et testé se ressemblent mais ne sont pas identiques. C est pourquoi nous avons choisis d associer des nœuds selon certains critères sinon seulement deux cas auraient pu être traités, nœuds identiques ou non. Les nœuds modèle et testés sont associés en fonction de leur type, leur nom, leurs attributs (nombre et valeur) ainsi que leur contenu. Le choix d un nœud testé plutôt qu un autre est assez délicat. Nous avons décidé de donner des degrés d importances aux similitudes. Le nœud testé qui possède le degré le plus élevé est celui qui est sélectionné pour être comparé avec le nœud modèle. Bien entendu, sur un même niveau, le nœud testé qui vient d être choisi ne pourra plus l être par le nœud modèle suivant. 15

16 11 La présentation des résultats Pour la présentation des résultats, nous avons choisi d utiliser le langage XSL. Il permet de présenter sous forme HTML les nœuds d un document XML, et de modifier des nœuds à volonté à l aide des transformations XSLT et du langage XPath. Pour chaque type de nœud (insertion, délétion ou substitution), un «template» est appelé et propose une mise en forme. Deux mises en forme ont été retenues, la première consiste à interpréter l arbre des différences dans le cas où l utilisateur souhaite voir les problèmes de nœuds et la seconde où la notion de XML ne doit pas être visible, et où il faut présenter les différences sous forme de phrases explicatives La présentation des résultats en terme XML Pour un utilisateur qui a proposé un fichier XML qu il a conçu, il peut être intéressant de voir le résultat interprété en termes de nœuds. On entend par là que le fichier XSL va lui expliquer les endroits où il y a des erreurs dans son arbre, s il a commis des insertions, des délétions ou des substitutions de nœuds. Pour chaque nœud de l arbre des différences, on indiquera le nœud père qui le contient afin de pouvoir le retrouver facilement, son niveau dans l arbre et selon le type de l erreur la référence dans le fichier modèle et dans le fichier testé. Dans le cas d une insertion, on indiquera la référence du nœud ajouté dans le fichier testé. Dans le cas d une délétion, c est la référence du nœud oublié dans le fichier modèle qui sera affichée. Et dans le cas d une substitution, les deux références affichées montreront que le nœud modèle a été remplacé par le nœud testé, et vis versa La présentation des résultats avec transparence du XML Dans le cas de la certification C2I par exemple, le XML doit être complètement transparent. C est pourquoi les différences repérées doivent être expliquées à l aide de phrases le plus simple possible. Par exemple dans le cas d une substitution, on doit indiquer que le style1 a été appliqué sur le contenu «XXX» au lieu du style 2. 16

17 Voir annexe pour une meilleure visibilité. 17

18 12 La validation des programmes Tests Une validation de la plateforme et du comparateur à l aide de tests a été effectuée afin de garantir le bon fonctionnement de ces derniers. Une suite de tests a été réalisée pour s assurer de la conformité des résultats obtenus La validation de la plateforme Afin de garantir la conformité et la compatibilité de la plateforme Web, nous avons testé cette dernière sur le site du W3C (World Wide Web Consortium) jusqu à la validation, en respectant la norme XHTML 1.1 et la norme CSS. C est pourquoi les logos du W3C sont apparents sur les pages du site La validation du comparateur Des séries de tests ont été faites sur le comparateur afin de vérifier les résultats retournés. Nous vous en présentons une partie ci-dessous. 18

19 Test sur des fichiers identiques. Résultat dans l arbre des différences Le comparateur indique qu il n a pas repéré de différence. 19

20 Insertion d un joueur. Arbre modèle Arbre testé

21 Résultat dans l arbre des différences Le comparateur a repéré des insertions de nœuds. Il indique qu un nœud joueur a été ajouté du coté du fichier testé. Il indique également toutes les caractéristiques du joueur étant donné qu elles n apparaissent pas dans le fichier modèle. 21

22 Délétion d un joueur. Arbre modèle Arbre testé 22

23 Résultat dans l arbre des différences Le comparateur indique une délétion d un nœud joueur ainsi que les caractéristiques de ce nœud. Effectivement il y a un joueur en plus dans le fichier modèle. 23

24 Test avec des noms de balises identiques mais avec des contenus textes différents. Arbre modèle Arbre testé Résultat dans l arbre des différences Le comparateur repère une substitution de contenu, il indique le niveau, le type de la substitution ainsi que le nœud concerné dans le fichier modèle et dans le fichier testé. On peut ainsi retrouver rapidement que «US Open» a été remplacé par «Rolland Garros». 24

25 Test avec des noms de balises différents mais avec un nombre et des noms d attributs identiques. Arbre modèle Arbre testé Résultat dans l arbre des différences Le comparateur repère une substitution. Il indique une substitution de nom car le nombre et le nom des attributs sont identiques. A l aide des références on peut alors voir que «nomtournoi» a été remplacé par «nomtournoiatp». 25

26 Test avec des noms de balises identiques, avec un nombre d attributs identique mais avec des noms d attributs différents. Arbre modèle Arbre testé Résultat dans l arbre des différences Le comparateur repère une substitution d attributs. Il y en autant d un coté que de l autre mais en effet, l attribut «set» dans le fichier modèle a été remplacé par l attribut «nbreset» dans le fichier testé. 26

27 Test avec des noms de balises identiques, avec un nombre d attributs différent mais avec des noms d attributs en commun. Arbre modèle Arbre testé Résultat dans l arbre des différences Le comparateur indique une substitution mais cette fois avec un nombre d attributs différents. A l aide des références, on peut retrouver les nœuds et voir que le nœud «nomtournoi» a comme attributs dans le fichier modèle «set et pays» tandis que dans le fichier testé il n a que «set». 27

28 Test avec des noms de balises identiques, avec un nombre d attributs différent et des noms d attributs différents. Arbre modèle Arbre testé Résultat dans l arbre des différences Même si les attributs n ont rien en commun, le comparateur indique qu il y a une substitution de nombre d attributs. 28

29 13 Conclusion Notre comparateur de documents XML fonctionne pour les fichiers XML en général, que ce soient des fichiers XML traditionnels, ou ceux issus de la suite OpenOffice. Cependant ce comparateur pourra être amélioré en favorisant les aspects plus particuliers d OpenOffice et en interprétant de façon plus large les résultats. Ce projet nous a appris une fois de plus à gérer notre temps de travail et à travailler en groupe. C était la première fois pour nous quatre que nous avions à réaliser un projet sur toute une année, et cette expérience a été très bénéfique, dans le sens où elle nous a permis de prendre plus de recul sur notre travail, et de ne pas démarrer trop tard. En ce sens les réunions avec notre tuteur de projet à peu près tous les mois nous ont aidés à garder un rythme de travail régulier. Nous nous sommes également perfectionnés dans la maîtrise du langage XML, avec différentes variantes (XSL, XPath) et sa recommandation DOM, l ayant utilisé intensément. Notre objectif ayant été de réaliser une application générique et réutilisable, nous nous sommes aussi appliqués à fournir un outil clairement codé, commenté, et avons rédigé des documents facilitant son utilisation et sa maintenance en cas d amélioration. Ces documents sont les suivants : Documentation technique du comparateur XML Documentation technique de la plateforme Web Manuel utilisateur de la plateforme Web

30 ANNEXES 30

31 Annexe 1 - Planning du second semestre. Planning second semestre Les différentes étapes réalisées au second semestre. Légende : Vivian : V, Bertrand : B, Florian : F, Rémi : R, Tous : T Étapes Jours Groupe A - Mise en place des outils nécessaires (serveur local, etc.) 2 T B - Tests de fonctionnement des outils et des librairies 5 T C - Conception des différentes fenêtres de la plateforme Web générique 60 F - R D - Création de la base de données 40 V - B E - Mise en relation de la plateforme et de la base de données 25 V - F F - Réalisation du module «comparateur XML» Premier niveau : identique ou non 15 T G - Second niveau : repérer les différences 20 T H - Troisième niveau : lister les différences et exposer les problèmes 15 T I - Tests du comparateur XML 10 B - R J - Vérification du fonctionnement pour tout type de modèle 3 B - R K - Tests des fonctionnalités de la plateforme 2 F - R L - Intégration du module «comparateur XML» sur la plateforme Web 7 V - F M - Présentation des résultats d une comparaison 3 B - R N - Tests de l application générique 10 T O - Mise en forme de la plateforme pour l utilisation c2i 3 R P - Mise en forme de la plateforme pour l utilisation GED 1 R Q - Intégration de l annuaire LDAP de l UAPV dans la plateforme 2 V - F R - Tests de l application pour le c2i 7 B - R S - Tests de l application pour la GED 7 V - F T - Correction de bugs sur le comparateur 3 V - B U - Nouveaux tests du comparateur 3 V - B V - Rédaction du manuel d utilisation de la plateforme 3 R W - Rédaction de la documentation technique du comparateur 4 V X - Rédaction de la documentation technique de la plateforme Web 5 F Y - Rapport 5 T Z - Préparation de la soutenance (diaporama, répétitions). 4 T AA - Rendu du projet 1 T AB - Soutenance 1 T 31

32 Annexe 2 - Solutions présentées pour les documents OpenOffice