La transformation de données en information

Une fois que les modèles terrain et attendu sont mis à jour, il faut extraire l’infor- mation provenant de la comparaison de leur données. En effet, que l’un ou l’autre des modèles nous apprenne que 18 blessés sont qualifiés d’Urgence Absolue, qu’un hélico- ptère est disponible, que les équipes de pompiers viennent d’arriver sur le terrain, etc. ne nous indique rien quant à la pertinence des activités et moyens mis en place pour résoudre la crise à un instant t.

II.2.2.1 Comparer les données

Il faut pouvoir confronter les données du modèle terrain avec les données du modèle

attendu. C’est cette comparaison qui pourra informer les acteurs de la collaboration d’un

éventuel écart entre le planifié et le réalisé.

Notre hypothèse de travail est que les modèles terrain et attendu sont décrits sous forme d’instances du modèle de la crise. Or nos modèles étant des instances d’ontologies au format OWL (OWL Web Ontology Language) [McGuinness and Van Harmelen, 2004], cela signifie que nos modèles sont écrits en XML (eXtensible Markup Language) [W3C, 2008]. Il nous faut donc pouvoir comparer des arbres de données hiérarchisées.

Dans le cas présent, nous recherchons un moyen de comparer des nœuds XML entre eux et de conclure à leur ajout, suppression ou modification entre les deux modèles. Notons que l’ordre des nœuds dans une même branche n’est pas une propriété intéres- sante dans cette étude. En effet, les fichiers XML des modèles de situation ont vocation à stocker les données : ces arbres peuvent être désordonnés, i.e. l’ordre d’écriture entre des nœuds frères et soeurs importe peu. Par contre l’ordre des relations parent-enfant est toujours crucial. Le cas aurait été différent si ces fichiers XML servait de base à une restitution graphique des données (site web) : l’ordre des relations parent-enfant et l’ordre des relations frères-soeurs auraient été aussi important l’un que l’autre.

Au sens strict, nous cherchons donc les similarités entre les modèles terrain et attendu plus qu’une identité comme l’indique la Figure II.15.

Dans ce domaine, la littérature scientifique s’est d’abord intéressée à la comparaison de données contenues dans des fichiers plats (type texte). C’est ce qui a amené à la création du bien connu algorithme et utilitaire diff. Il est embarqué dès 1974 dans la cinquième distribution d’Unix et un article le présentant est publié en 1976 [Hunt and McIllroy, 1976]. diff compare les documents ligne à ligne et relève les différences. Il se base sur l’algorithme de Hunt–McIlroy qui est une résolution d’un problème de plus longue sous-séquence commune (LCS, Longuest Common Subsequence). Son usage premier était

FigureII.15 – Similarité entre deux documents XML

dédié au suivi des évolutions du code source des programmes informatiques ainsi que les modifications apportées à des documents techniques.

II.2.2.2 La comparaison d’arbres XML

De nos jours, le succès de XML en tant que format pivot pour l’échange de données a renouvelé l’intérêt des travaux de recherche dans le domaine de la comparaison de don- nées : vérification de l’intégrité de fichiers, gestion de version de documents, surveillance de données, etc. Il s’agit désormais de tirer parti de la nature même des documents XML –à savoir des données organisées de façon arborescente– pour détecter les différences13

entre deux documents écrits en XML et de ne plus comparer les fichiers ligne à ligne. Nous en profitons pour noter que lorsque nous parlons de supprimer un nœud d’un document XML, il s’agit de supprimer l’intégralité du nœud : le nœud courant et ses descendants, comme expliqué dans le modèle de Selkow [Selkow, 1977].

Nous avons pu trouver dans la littérature scientifique deux études poussées des diffé- rents algorithmes et outils de comparaison de documents XML : l’une menée par [Cobéna et al., 2000], l’autre par [Peters, 2005] (qui actualise l’étude menée par Cobéna). Après avoir éliminé les algorithmes et outils menant une comparaison ligne à ligne, ceux ne permettant pas la comparaison sur des arbres désordonnés et ceux n’étant plus utilisés, nous pouvons étudier les solutions suivantes.

DeltaXML Core DeltaXML Core est un produit commercialisé à l’origine par Mon-

sell EDM Ltd., puis par DeltaXML [DeltaXML, 2013]. Il permet de détecter les diffé- rences entre des arbres désordonnés ainsi que de fusionner les documents entre eux, qu’il s’agisse d’arbres ordonnés ou désordonnés. Il permet la détection des opérations d’inser- tion, de modification, de suppression mais pas de déplacement. Cette dernière n’est pas vitale dans le cadre de nos travaux, d’autant que nous ne nous attachons pas à respecter l’ordre des nœuds au niveau frères-soeurs.

En sortie, DeltaXML fournit un fichier δ qui résume des différences détectées entre les deux documents. Bien que puissant [Cobéna et al., 2000], son défaut majeur est le format de sortie du récapitulatif des différences. Il est écrit dans un format propriétaire qui rend l’exploitation du récapitulatif ardu ce qui, associé à sa licence commerciale, rend son usage rédhibitoire dans le cadre de travaux de recherche.

XyDiff XyDiff a été développé par Cobéna au sein de l’INRIA [Cobéna et al., 2004]

[Cobéna et al., 2000]. Son algorithme permet de détecter des sous-arbres identiques entre les deux documents ce qui améliore son efficacité en terme de performance et de gestion de la mémoire. Outre la gestion des quatre opérations (ajout, suppression, mise à jour, déplacement), il permet d’ignorer les espaces entre les balises ainsi que les caractères de formatage.

La sortie de XyDiff fournit un fichier XyDelta qui représente les différences entre les deux documents. Le contenu du fichier indique tous les nœuds concernés par une différence et les références en leur affectant un identifiant unique XID. Le fichier de sortie est peu lisible sans l’aide du logiciel et n’en permet pas une exploitation en dehors du cadre de XyDiff.

XMLUnit XMLUnit [Bacon and Martin, 2013] est une extension du framework JU-

nit14 _{[Beck and Gamma, 2013]. Il facilite les tests unitaires portant sur les documents}

XML afin d’en vérifier l’intégrité au niveau de la structure et du contenu [Glover, 2006]. Ceci est particulièrement utile dans le développement et le test de logiciels qui génèrent du contenu XML, ou qui sérialisent/désérialisent des documents XML.

La comparaison effectuée par XMLUnit entre deux flux XML (contrôle et test) a pour résultat : identique, similaire, différent. L’unité de mesure utilisée par la comparaison est la différence. Les différences peuvent être récupérables ou irrécupérables. Deux flux XML peuvent être :

• Identiques s’il n’y a strictement aucune différence entre eux,

• Similaires s’il n’y a que des différences récupérables entre eux (exemple : l’ordre des nœuds au sens d’un même nœud parent),

• Différent s’il y a la moindre différence irrécupérable entre eux (exemple : absence d’un nœud, valeur différente pour le même attribut d’un même nœud).

XMLUnit permet également de récupérer la liste de toutes les différences identifiées entre le document XML de contrôle et le document XML de test en mémorisant l’expression XPath permettant de remonter au nœud incriminé. La liste des différences est très sim- plement accessible via un objet et une méthode Java mis à disposition par l’API de XMLUnit.

Le tableau ci-dessous (II.6) récapitule les différentes caractéristiques étudiées dans la couverture des outils de comparaison de documents XML. Il apparaît clairement que XMLUnit est le candidat qui satisfait le plus grand nombre de nos critères de choix.

Solution Désordonné Opérations + - ∼

δ exploitable Licence

DeltaXMLCore Oui Oui Non Commerciale

XyDiff Oui Oui (+ dépla-

cement)

Non Open Source

XMLUnit Oui Oui Oui Open Source

Table II.6 – Synthèse de la couverture des critères pour le choix d’un outil de compa- raison de documents XML