Brevet FR2915818A1 — publié le 20081107

La présente invention concerne le traitement de documents de type XML et plus particulièrement des procédés et des dispositifs d'analyse et d'adaptation d'expressions de type XPath selon plusieurs versions de descriptions. Le format XML est une norme permettant de représenter des données sous une forme textuelle. Ces données sont organisées de manière hiérarchique sous la forme d'arbres. Les entités de traitement XML, ou parseurs, donnent accès aux données du document XML via cette structure d'arbre. Il existe différents types de parseurs XML. Le modèle DOM (Document Object Mode)) construit l'ensemble de l'arbre en mémoire et permet à un utilisateur de naviguer dans cet arbre composé de noeuds XML. D'autres modèles de parseurs ont été développés tels que les modèles SAX (Simple API for XML) et PULL selon lesquels un arbre n'est pas construit en mémoire. De tels parseurs permettent de naviguer dans l'arbre XML en allant de noeud XML en noeud XML, en utilisant un algorithme d'exploration en profondeur d'abord. Il ne garde en mémoire que le noeud courant de l'arbre XML. Dans ce contexte, un noeud XML peut notamment correspondre à un élément XML ouvrant, un élément XML fermant ou un élément texte. Dans l'exemple suivant, le fragment XML contient trois noeuds : un élément ouvrant, un noeud texte et un noeud fermant, Textnode Différents langages de schéma tels que XML Schema (recommandation W3C) ou Relax NG (standard ISO) permettent de définir des structures de documents XML. Des classes de documents XML sont ainsi décrites, les documents XML pouvant se conformer ou non à ces classes. Cette description est utile aux entités de traitements qui sont souvent spécialisées pour comprendre une ou plusieurs classes de documents XML. L'exemple suivant illustre deux versions différentes d'une structure de documents XML, version 1 version 2 15 Selon ces exemples, l'élément `a' comprend les éléments `b' et `c', la définition selon la seconde version ajoutant un attribut optionnel à l'élément `a'. La définition selon la première version est un sous-ensemble de la définition selon la seconde version. XPath (recommandation W3C) est un langage permettant de 20 sélectionner et d'évaluer certaines informations dans un document XML. Une première partie de ce langage permet de choisir certaines parties d'un document XML à partir d'un chemin comme le montrent les exemples suivants dans lesquels la première expression XPath sélectionne les noeuds `c' dans un élément racine `a', la deuxième expression sélectionne tous les éléments 25 enfants de l'élément racine `a' qui ont un attribut `attr' et la troisième expression sélectionne l'ensemble des noeuds texte de l'élément racine `a'. Document XML Expression XPath Résultats /a/c text_c text_c text_a /a/child::*[@attr] /a/text() text_a Une deuxième partie de ce langage permet de manipuler les parties sélectionnées du document XML. XPath offre notamment la possibilité d'effectuer des conversions, des fonctions numériques et des unions comme 10 présenté dans les exemples suivants où la première expression XPath sélectionne les noeuds 'c' dans un élément racine pour les convertir en chaînes de caractères, la deuxième expression sélectionne tous les éléments qui ont un attribut `attr' pour les convertir en nombre en y ajoutant la valeur deux et la troisième expression sélectionne l'ensemble des noeuds texte de l'élément racine 'a' et de l'élément 'c' pour les concaténer. Document XML Expression XPath Résultats string(//c) text_c text_c text_a number(//@attr)+2 3.0 /a/text()~//c/text() (text_c,text_a) Par ailleurs, WSDL (Web Services Description Language) est un langage de descriptions de services web. II permet notamment de décrire les entrées et les sorties d'un service particulier. L'exemple suivant décrit un service qui implémente une opération appelée `myOperation' prenant en entrée un document XML de type `ns:a' et générant en sortie un document XML de type `ns:b', Les fonctionnalités et les services offerts sur Internet ou par certains appareils adaptés évoluent au cours du temps. De ce fait, les langages utilisés par ces appareils, notamment les langages basés sur XML, évoluent. Par voie de conséquence, les descriptions schémas d'un langage particulier sont amenées à être modifiées. Il en est de même pour les descriptions de services WSDL qui peuvent avoir à évoluer. Les services se basant sur XML utilisent généralement des outils de conversion XML vers des structures ou objets programmatiques pour traiter des données XML. XPath est de plus en plus utilisé, directement en temps que tel via un processeur XPath ou via des langages, tels qu'XSL (XML Stylesheet Language) qui permet de transformer des documents XML en d'autres documents ou BPEL (Business Processing Execution Language) qui permet de définir des processus d'exécution. Les expressions XPath sont généralement écrites pour une classe de documents XML définie selon un schéma, c'est-à-dire selon une grammaire. Si cette grammaire évolue, l'expression XPath peut ne plus être valide, c'est-à-dire que l'expression XPath peut ne retourner aucun résultat ou des résultats faux. Ainsi, bien que l'optimisation d'expressions XPath vis-à-vis d'une grammaire et que la visualisation des résultats potentiels d'expressions XPath à partir d'une grammaire soient connues, un système basé sur XPath ne saura pas détecter une erreur de traitement due à un changement de version de la grammaire. Par ailleurs, le système ne pourra pas être adapté automatiquement ou rapidement : la personne ayant écrit et/ou modifié la grammaire n'est généralement pas la personne ayant écrit l'ensemble des expressions XPath utilisées lors du traitement. Le système peut donc difficilement s'adapter automatiquement et la mise à niveau du système est difficile à effectuer par un opérateur. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé d'analyse d'au moins une expression de type XPath pour déterminer la validité de ladite au moins une expression de type XPath au regard d'au moins une seconde version de description d'un document de type XML par rapport à une première version de description dudit document de type XML, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, -détermination d'au moins un chemin d'exploration de ladite au moins une expression de type XPath selon chacune desdites première et 30 seconde versions de ladite description dudit document de type XML ; - comparaison dudit au moins un chemin déterminé associé à ladite première version de ladite description avec ledit au moins un chemin déterminé associé à ladite seconde version de ladite description ; et, - validation ou invalidation de ladite au moins une expression de type XPath selon le résultat de ladite comparaison. Le procédé selon l'invention permet ainsi de tester la validité d'une expression de type XPath par rapport à une version particulière de description du document de type XML, par exemple une nouvelle version. Avantageusement, le procédé comprend en outre une étape d'analyse dudit au moins un chemin déterminé associé à ladite première version de ladite description pour déterminer, - une première partie de ladite expression de type XPath qui est valide selon ladite seconde version de ladite description ; - une étape de ladite expression de type XPath qui n'est pas cohérente avec ladite seconde version de ladite description ; et, - une seconde partie de ladite expression de type XPath qui n'a pas été utilisée pour déterminer ledit au moins un chemin selon ladite seconde version de ladite description, si ledit au moins un chemin déterminé associé à ladite seconde version de ladite description est incomplet. La détermination de ces éléments permet de mettre en oeuvre une étape d'analyse des différences. Selon un mode de réalisation particulier, le procédé comprend en outre de préférence les étapes suivantes pour déterminer une correspondance éventuelle entre les versions, - recherche d'un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - analyse de ladite seconde partie de ladite expression de type XPath pour déterminer si ledit élément peut correspondre à ladite seconde :30 partie de ladite expression de type XPath. Toujours selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes pour déterminer une correspondance éventuelle entre les versions, - recherche d'un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - analyse des descendants dudit élément dans ladite seconde version de ladite description selon ladite seconde partie de ladite expression de type XPath. Le procédé comprend avantageusement une étape de marquage de ladite au moins une expression de type XPath si ladite au moins une expression de type XPath est invalide. Une telle étape permet de prendre en considération le résultat de l'analyse de ladite expression de type XPath pour l'évaluer ou la mettre à jour. Selon un mode de réalisation particulier, le procédé comprenant en outre une étape d'analyse de ladite comparaison pour déterminer la possibilité de corriger automatiquement ladite au moins une expression de type XPath si ladite au moins une expression de type XPath est invalide. L'invention a également pour objet un procédé de mise à jour d'au 20 moins une expression de type XPath comprend les étapes suivantes, - analyse de Nadite au moins une expression de type XPath selon le procédé décrit précédemment ; et, - mise à jour de ladite au moins une expression de type XPath. Le procédé selon l'invention permet ainsi notamment d'adapter des 25 expressions de type XPath à de nouvelles versions de description de document de type XML. Le procédé de mise à jour tente de générer une expression de type XPath valide pour les deux versions de description. Si ce n'est pas possible, le procédé mémorise deux versions de l'expression de type XPath, chaque version de l'expression de type XPath correspondant à une version de 30 description. Ladite étape de mise à jour peut comprendre une étape de modification de ladite expression de type XPath selon une règle de modification usuelle de description su ledit au moins un chemin déterminé associé à ladite une desdites au moins deux versions de ladite description est incomplet. Alternativement, ladite étape de mise à jour comprend une étape de modification de ladite expression de type XPath selon une règle configurable si le résultat de ladite cornparaison indique une différence de résultat ou une différence de type de résultat desdits chemins déterminés associés auxdites première et seconde versions de ladite description. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de validation de ladite modification de ladite expression de type 'I0 XPath, ladite étape de validation comprenant les étapes suivantes, - présentation desdits chemins d'une expression XPath par rapport auxdites première et seconde versions de ladite description à un utilisateur ; - réception de la sélection d'au moins un chemin ; et, - mise à jour de ladite expression de type XPath selon ladite 15 sélection. L'étape de validation permet de valider les modifications automatiquement effectuées par le système et de mettre à jour les expressions qui n'ont pas pu l'être automatiquement. Le procédé permet ainsi de présenter les chemins d'une expression 20 XPath par rapport aux versions de description à l'utilisateur pour lui permettre un choix des différents chemins. Le choix étant fait par l'utilisateur, le système effectue une génération automatique de la nouvelle expression XPath valide qui constitue la mise à jour à effectuer du système d'exécution. L'étape de mise à jour permet à l'utilisateur de se concentrer 25 uniquement sur les expressions (ou parties d'expressions) nécessitant une mise à jour et sur les parties de définition du document ayant été modifiées. La validation ou l'invalidation d'un chemin est un moyen fiable et rapide pour une telle mise à jour semi-automatique. L'invention a également pour objet un procédé d'évaluation d'au 0 moins une expression de type XPath selon lequel ladite au moins une expression de type XPath est analysée selon le procédé décrit précédemment, le procédé d'évaluation comprenant au moins deux modes d'évaluation, un mode d'évaluation offrant des fonctionnalités restreintes étant utilisé pour traiter une expression de type XPath invalide. Selon un mode de réalisation particulier, le procédé d'évaluation comprenant une étape de sélection de l'une desdites première et seconde versions de ladite description selon ledit document de type XML et une étape de sélection d'au moins une expression de type XPath selon ladite version sélectionnée. De tels procédés d'évaluation permettent de déterminer la version de la description d'un document de type XML qui doit être utilisée et de choisir l'expression de type XPath à utiliser selon cette version de description. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment et un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé décrit précédemment. L'invention a également pour objet un dispositif d'analyse d'au moins une expression de type XPath pour déterminer la validité de ladite au moins une expression de type XPath au regard d'au moins une seconde version de description d'un document de type XML par rapport à une première version de description dudit document de type XML, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour déterminer au moins un chemin d'exploration de ladite au moins une expression de type XPath selon chacune desdites première et seconde versions de ladite description dudit document de type XML ; - moyens pour comparer ledit au moins un chemin déterminé associé à ladite première version de ladite description avec ledit au moins un chemin déterminé associé à ladite seconde version de ladite description ; et, - moyens pour valider ladite au moins une expression de type XPath selon le résultat de ladite comparaison. Le dispositif selon l'invention permet ainsi de tester la validité d'une expression de type XPath par rapport à une version particulière de description du document de type XML, par exemple une nouvelle version. Selon un mode de réalisation particulier, le dispositif comprend en 5 outre des moyens pour analyser ledit au moins un chemin déterminé associé à ladite première version de ladite description afin de déterminer, - une première partie de ladite expression de type XPath qui est valide selon ladite seconde version de ladite description ; - une étape de ladite expression de type XPath qui n'est pas 10 cohérente avec ladite seconde version de ladite description ; et, - une seconde partie de ladite expression de type XPath qui n'a pas été utilisée pour déterminer ledit au moins un chemin selon ladite seconde version de ladite description. Toujours selon un mode de réalisation particulier, le dispositif 15 comprend en outre les moyens suivants, - moyens pour rechercher un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - moyens pour analyser ladite seconde partie de ladite expression 20 de type XPath afin de déterminer si ledit élément peut correspondre à ladite seconde partie de ladite expression de type XPath. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre les moyens suivants, - moyens pour rechercher un élément de ladite seconde version de 25 ladite description n'appartenant pas à ladite première version de ladite description ; et, - moyens pour analyser des descendants dudit élément dans ladite seconde version de ladite description selon ladite seconde partie de ladite expression de type XPath. 30 La détermination de ces éléments permet de mettre en oeuvre une étape d'analyse des différences. Avantageusement, le dispositif comprenant en outre des moyens pour marquer ladite au moins une expression de type XPath si ladite au moins une expression de type XPath n'est pas valide. De tels moyens permettent d'optimiser des moyens d'évaluation ou de mise à jour de ladite expression XPath en prenant en considération le résultat de l'analyse de ladite expression de type XPath. Le dispositif comprend en outre de préférence des moyens pour analyser ladite comparaison afin de déterminer la possibilité de corriger automatiquement ladite au moins une expression de type XPath. L'invention a également pour objet un dispositif de mise à jour d'au moins une expression de type XPath comprenant les moyens suivants, - moyens pour analyser ladite au moins une expression de type XPath selon le dispositif décrit précédemment ; et, - moyens pour mettre à jour ladite au moins une expression de type XPath. Lesdits moyens de mise à jour peuvent comprendre des moyens pour modifier ladite expression de type XPath selon une règle de modification usuelle de description. Lesdits moyens de mise à jour peuvent également comprendre des moyens pour modifier ladite expression de type XPath selon une règle configurable. Avantageusement, le dispositif comprend en outre des moyens pour valider ladite modification de ladite expression de type XPath, lesdits moyens de validation comprenant les moyens suivants, - moyens pour présenter lesdits chemins d'une expression XPath par rapport auxdites première et seconde versions de ladite description à un utilisateur ; - moyens pour recevoir la sélection d'au moins un chemin ; et, - moyens pour mettre à jour ladite expression de type XPath selon ladite sélection. Le dispositif permet ainsi de présenter les chemins d'une expression XPath par rapport aux versions de description à l'utilisateur pour lui permettre un choix des différents chemins. Le choix étant fait par l'utilisateur, le système effectue une génération automatique de la nouvelle expression XPath valide qui constitue la mise à jour à effectuer du système d'exécution. L'invention a aussi pour objet un dispositif d'évaluation d'au moins une expression de type XPath selon lequel ladite au moins une expression de type XPath est analysée par le dispositif décrit précédemment, le dispositif d'évaluation comprenant au moins deux modes d'évaluation, un mode d'évaluation offrant des fonctionnalités restreintes étant utilisé pour traiter une expression de type XPath invalide. L'invention a également pour objet un dispositif d'évaluation d'au moins une expression de type XPath selon lequel ladite au moins une expression de type XPath est analysée par le dispositif décrit précédemment, le dispositif d'évaluation comprenant des moyens pour sélectionner l'une desdites première et seconde versions de ladite description selon ledit document de type XML et des moyens pour sélectionner au moins une expression de type XPath selon ladite version sélectionnée. De tels dispositifs d'évaluation permettent de déterminer la version de la description d'un document de type XML qui doit être utilisée et de choisir l'expression de type XPath à utiliser selon cette version de description. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 montre un exemple d'appareil permettant d'implémenter l'invention ; - la figure 2 illustre certaines étapes liées à la mise en oeuvre de l'invention ; - la figure 3 présente un exemple d'algorithme pour l'évaluation des chemins d'exploration d'une expression XPath dans différentes versions de grammaire ; - la figure 4 illustre un exemple d'algorithme pour mettre à jour une expression XPath ; - la figure 5 illustre un exemple d'algorithme d'analyse semi-automatique pour mettre à jour une expression XPath ; et, - la figure 6 présente un exemple de mise en oeuvre de l'algorithme présenté sur la figure 5. La figure 1 illustre un exemple d'appareil 100 adapté à mettre en oeuvre l'invention, tel qu'un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable ou un serveur multimédia. De préférence, l'appareil 100 comporte un bus de communication 102 auquel sont reliées, • une unité centrale de traitement 103 telle qu'un microprocesseur ; • une mémoire morte 104 ou Read Only Memory (ROM), pouvant comporter un ou plusieurs programmes "Prog" ; • une mémoire vive 106 ou Random Access Memrory (RAM), comportant des registres adaptés à mémoriser des variables et des paramètres créés et modifiés au cours de l'exécution des programmes précités ; et • une interface de communication 118 reliée à un réseau de communication distribué 120, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données. L'appareil 100 peut disposer optionnellement de l'un, de plusieurs ou de tous les dispositifs suivants : • un écran 108 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 110 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 111 ou un crayon optique, un écran tactile ou une télécommande ; • un disque dur 112 pouvant comporter des programmes et/ou des données, notamment des données traitées ou à traiter selon l'invention ; • un lecteur de disquette 114 adapté à recevoir une disquette 116 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention ; et, • un lecteur de cartes mémoire adapté à y lire ou à y écrire des données, notamment des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 100 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 100, directement ou par l'intermédiaire d'un autre élément de l'appareil 100. Le code exécutable du ou des programme(s) permettant à l'appareil 100 de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 112 ou en mémoire morte 104. Selon une variante, la disquette 116, peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 100, peuvent être stockés dans le disque dur 112. Alternativement, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 120, via l'interface 118, pour être stocké de façon identique à celle décrite précédemment. Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de l'appareil 100 avant d'être exécutés. L'unité centrale 103 contrôle l'exécution des instructions ou portions de code logiciel du ou des programme(s) selon l'invention, instructions qui sont stockées dans le disque dur 112, dans la mémoire morte 104 ou dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes stockés dans une mémoire non volatile, par exemple le disque dur 112 ou la mémoire morte 104, sont transférés dans la mémoire vive 106 (RAM), qui contient alors le code exécutable du ou des programme(s) selon l'invention, ainsi que des registres pour mémoriser les variables et les paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil comportant le dispositif selon l'invention peut également être un appareil programmé. Les instructions du ou des programme(s) mettant en oeuvre l'invention peuvent, par exemple, être implémentées dans un circuit intégré programmable ou spécifique (Application-Specific Integrated Circuit, ASIC). Une solution générale de l'invention est illustrée sur la figure 2. Cette 5 solution comprend de préférence deux phases, une phase d'analyse 200 et une phase d'exécution 205. Lors de la publication d'un nouveau schéma, ou d'une grammaire, le système analyse les différentes versions de la grammaire pour chaque expression XPath utilisée par le système afin de les comparer. Si le système 10 détecte au moins une expression XPath à traiter (étape 210), il accède une première expression XF'ath à traiter (étape 215) et analyse les versions de grammaire pour cette expression (étape 220). Cette analyse permet de déterminer si l'expression XPath doit être corrigée ou non (étape 225). Si l'expression XPath ne doit pas être corrigée, les étapes précédentes sont 15 répétées avec l'expression XPath suivante (étapes 210 à 225), si elle existe. Si l'expression XPath peut devoir être corrigée, un test est effectué pour déterminer si une correction est possible (étape 230). Si l'expression XPath peut être corrigée, le système met à jour cette expression XPath (étape 235). Si au contraire l'expression XPath ne peut pas être corrigée, cette expression 20 XPath est marquée à risque (étape 240). Les étapes 210 à 240 sont alors répétées pour tester l'ensemble des expressions XPath utilisées par le système. II est ici supposé que c'est l'entité de traitement, c'est-à-dire l'entité qui évalue l'étape 225, qui conserve en mémoire l'information liée au risque de 25 chaque expression XPath. Si les expressions XPath sont déjà compilées sous la forme d'un objet, l'indicateur peut être un champ booléen de l'objet. Dans le cas d'un processeur de type XSLT, celui-ci récupère une liste d'expressions XPath et conserve en mémoire l'information liée au risque pour la liste d'expressions XPath. 30 La phase d'exécution est ensuite mise en oeuvre. Durant cette phase, les expressions XPath sont évaluées les unes après les autres ou de façon parallèle. Si l'une des expressions XPath est marquée à risque (étape 245), l'évaluation passe en mode sécurisé (étape 250), aussi appelé mode dégradé, dans lequel aucune des expressions XPath marquées à risque n'est évaluée, seules les expressions XPath qui ne sont pas marquées à risque peuvent être évaluées. Lorsque le système fonctionne en mode dégradé, l'intervention d'un opérateur est avantageusement requise. En parallèle del'évaluation en mode sécurisé ou dégradé, les expressions XPath marquées à risque sont de préférence mises à jour de manière semi-automatique selon les données entrées par un l'opérateur pour l'exécution de ces expressions XPath (étape 255). Lorsqu'une expression XPath marquée à risque est mise à jour, le système repasse en mode d'évaluation normal et l'expression XPath est évaluée normalement (étape 260). Si l'expression XPath n'est pas marquée à risque (étape 245), l'évaluation de l'expression XPath est effectuée normalement (étape 260). L'entité de traitement ne peut pas utiliser de fonctionnalités utilisant une expression XPath marquée à risque. Dans ce cas, l'entité de traitement fonctionne en mode dégradé dans lequel moins de fonctionnalités sont offertes. Dès qu'une mise à jour est disponible, les expressions XPath marquées à risque sont mises à jour et toutes les fonctionnalités de l'entité de traitement sont de nouveau disponibles. L'invention assure ainsi la sûreté d'un système basé sur XPath face à de nouvelles versions de la grammaire utilisée ou des grammaires utilisées. Par ailleurs, il permet d'automatiser autant que faire se peut la mise à jour du système. Dans le cas où une mise à jour automatique n'est pas entièrement possible, l'adaptation à la nouvelle grammaire est assistée par le système, :25 permettant ainsi une mise à jour plus rapide du système. La phase d'analyse automatique 200 se passe de préférence en trois temps, correspondant aux étapes 220, 230 et 235 de la figure 2, respectivement. Dans un premier temps, les chemins d'exploration de l'expression XPath dans les différentes versions de la grammaire sont analysés. 30 Dans un deuxième temps, les chemins des différentes versions sont mis en relation et le type de changement de l'expression est évalué. Enfin, dans un troisième temps, la procédure de mise à jour est mise en oeuvre en fonction du type de changement. Dans un souci de clarté, le cas de deux versions de grammaire est ici décrit, par exemple une nouvelle version de grammaire et une version antérieure de grammaire. Cependant, le dispositif peut être généralisé à un ensemble fini de versions de grammaire. Une expression XPath est notamment formée de différentes étapes qui déterminent le chemin amenant aux parties du document XML sélectionnées. Un chemin d'exploration correspond à une suite ordonnée de contextes contenant les informations de grammaire et permettant de passer d'une étape XPath à une autre étape XPath. La figure 3 illustre l'évaluation des chemins d'exploration d'une expression XPath pour différentes versions d'une grammaire. Après avoir extrait de l'expression XPath une série d'étapes XPath (étape 300), un contexte est initialisé pour la première étape XPath à partir de la grammaire précédente, c'est-à-dire à partir de la version antérieure de grammaire. Il s'agit généralement de récupérer un ou plusieurs composants de la grammaire représentant la classe de documents XML sur lesquels vont s'appliquer l'expression XPath. Le chemin d'exploration est ensuite déterminé à partir de chacune des étapes de l'expression XPath (étapes 310 et 320). Un ensemble de contextes schéma est créé pour chaque étape XPath. Ces contextes permettent de passer de l'étape XPath à laquelle ils sont reliés à l'étape XPath suivante. Une itération est effectuée sur les contextes pour explorer chacun des contextes possibles (étapes 330 et 340). Pour chaque contexte, les chemins possibles d'exploration de l'étape sont évalués (étape 350). L'exploration consiste à parcourir la sous-grammaire représentée par le contexte pour satisfaire les contraintes de l'étape suivante, par exemple une étape de type enfant élément avec une contrainte sur le nom de l'élément. Les contraintes de cette étape permettent de définir un nombre fini de sous-chemins possibles dans la grammaire, ce nombre fini pouvant être nul. Un contexte représentant chaque 'sous-chemin' répondant à l'étape XPath est ajouté (étape 360). Ces contextes sont ensuite explorés par rapport à l'étape XPath suivante. Lorsque l'ensemble des étapes XPath a été analysé, les chemins d'exploration pouvant être utilisés sont obtenus (étape 370). Il convient de noter que le résultat de cette analyse contient les chemins complets conduisant à une solution potentielle ainsi que les chemins partiels qui correspondent à une sous-partie de l'expression XPath. Par exemple dans le schéma suivant, l'évaluation du chemin /a//b/d permet de déterminer un chemin complet et deux chemins partiels. Le chemin complet est marqué en souligné dans le schéma suivant, Un premier chemin partiel est marqué en souligné dans le schéma suivant, Un second chemin partiel est marqué en souligné dans le schéma suivant, :30 35 40 Pour mettre en relation les chemins d'exploration des différentes versions de la grammaire, l'ensemble des chemins complets d'une version est sélectionné et comparé à chaque chemin de l'autre version. Pour comparer deux chemins, une itération est effectuée sur chaque étape et il est vérifié que '10 les contextes permettant de passer d'une étape à une autre sont effectivement identiques. S'ils ne sont pas identiques, les deux chemins ne sont pas égaux. Si aucun chemin d'une version A ne correspond à un chemin d'une version B, ce chemin est relié au 'sous-chemin' le plus long correspondant de la version B. Il est ainsi possible de classer les chemins en plusieurs catégories : 15 - apparition d'un chemin complet ; - disparition d'un chemin complet ; - chemin complet dont le type est modifié ; et, - chemin complet identique. L'information de mise en correspondance est utilisée pour déterminer 20 la mise à jour qu'il convient d'effectuer sur l'expression XPath comme illustré sur la figure 4. II existe plusieurs possibilités : - aucune modification ; - résultats identiques avec type modifié, c'est-à-dire que le dernier contexte du chemin pointe vers un élément et ne pointe pas vers une valeur 25 simple ou inversement, le dernier contexte du chemin pointe vers une valeur simple et non vers un élément ; - nouveaux résultats sans modification du type de ces résultats, c'est-à-dire que de nouveaux chemins sont disponibles et ajoutent des données similaires aux chemins de la version antérieure de la grammaire ; 30 - nouveaux résultats avec modification du type de ces résultats, c'est-à-dire que de nouveaux chemins sont disponibles et ajoutent des données similaires aux chemins précédents (une valeur simple ou un élément vers un ensemble de valeurs simples ou d'éléments) ; ou, - absence de résultats, c'est-à-dire qu'aucun chemin complet n'est détecté dans la nouvelle version de la grammaire. Chaque cas est traité différemment. Si aucun chemin n'est complet (étape 405), des modèles de mise à jour sont accédés (étape 410). Ces modèles représentent notamment des modifications usuelles de grammaire. Ces modifications permettent de modifier l'expression XPath (étape 415). Si la mise à jour permet de récupérer les résultats tels qu'attendus par l'application (étape 420), la mise à jour est jugée comme valide (étape 430), sinon elle est jugée comme invalide (étape 425), auquel cas cette expression ne sera pas évaluée en mode sécurisé. Si de nouveaux résultats avec modification du type de ces résultats sont ajoutés (étape 435), des règles correspondant à ce cas sont accédées (étape 440). Ces règles sont configurables et permettent notamment de décider si : - les nouveaux chemins sont acceptables ; et, -il est nécessaire ou non de demander une mise à jour à l'opérateur. Ces règles sont appliquées (étape 445) et, à nouveau, si la mise à jour permet de récupérer des résultats tels qu'attendus par l'application (étape 420), c'est à dire si l'expression XPath est correctement mise à jour, la mise à jour est jugée comme valide (étape 430), sinon elle est jugée comme invalide (étape 425), auquel cas cette expression ne sera pas évaluée en mode sécurisé. Si le résultat potentiel change de type (étape 450), les règles 25 correspondant à ce cas sont accédées (étape 455). Ces règles sont configurables pour le système et permettent notamment de décider si : - les nouveaux chemins sont acceptables ; et, - il est nécessaire ou non de demander une mise à jour à l'opérateur. 30 Ces règles sont appliquées (étape 460) et, à nouveau, si la mise à jour permet de récupérer des résultats tels qu'attendus par l'application (étape 420), c'est à dire si l'expression XPath est correctement mise à jour, la mise à jour est jugée comme valide (étape 430), sinon elle est jugée comme invalide (étape 425), auquel cas cette expression ne sera pas évaluée en mode sécurisé. Si aucun des cas précédents n'est sélectionné, cela signifie qu'aucune modification n'a été ajoutée ou que de nouveaux résultats sans modification de type ont été ajoutés. Dans ces deux cas, il est considéré que l'expression XPath est directement évaluable avec la nouvelle version de grammaire. Lorsque la nouvelle version de grammaire ne permet aucun chemin 1'0 d'exploration complet, les chemins complets correspondants à la version antérieure de la grammaire sont récupérés et comparés aux chemins d'exploration incomplets de la nouvelle version de grammaire. Pour chaque chemin complet de la version antérieure, le chemin incomplet de la nouvelle version de grammaire le plus long est récupéré. Ce chemin permet notamment 1!.5 de déterminer : - une première partie de l'expression XPath qui est satisfaite par la grammaire ; - une étape de l'expression XPath qui n'est pas cohérente avec la grammaire ; et, 20 - une deuxième partie de l'expression XPath qui n'a pas été utilisée pour l'exploration de la grammaire. Il s'agit alors de modifier l'étape intermédiaire pour permettre une exploration de la grammaire qui produise des chemins complets à partir de la deuxième partie de l'expression XPath. Différents modèles de mise à jour de la 25 grammaire pointée par le contexte du chemin incomplet sont cherchés. Deux modèles courants sont ici présentés. Un premier modèle a pour objet de déterminer si le nom de l'élément a été modifié en cherchant un élément dans la nouvelle version de grammaire ne se trouvant pas dans la version antérieure. Si un tel élément est trouvé, une 30 recherche est effectuée pour déterminer si le contenu de cet élément peut correspondre à la deuxième partie de l'expression XPath. Cette modification est validée si la deuxième partie de l'expression XPath n'est pas vide et/ou si le contexte final correspond au même type que dans la version antérieure de grammaire comme illustré dans l'exemple suivant, Version 1 Version2 /a/b/@ns: b /a/c/@ns: b Un second modèle a pour objet de déterminer si le nom de l'élément a été ajouté dans un élément container en déterminant si la nouvelle version de grammaire introduit un élément supplémentaire qui englobe les éléments de la version antérieure de grammaire. De la même façon que précédemment, un élément se trouvant dans la nouvelle version de grammaire mais pas dans la version antérieure est accédé. Les enfants de cet élément sont alors explorés grâce à la dernière partie de l'expression XPath. Cette modification est validée si la deuxième partie de l'expression XPath n'est pas vide et/ou si le contexte final correspond au même type que dans la version antérieure de grammaire comme illustré dans l'exemple suivant, Version 1 Version 2 /ns:a/ns:b /ns: a/wrapper/ns: b De manière générale, il convient d'essayer de chercher le composant global, c'est-à-dire l'élément, la définition ou l'attribut, utilisé par la première étape de la dernière partie de l'expression XPath dans la version antérieure de grammaire en explorant la nouvelle version de grammaire à partir du dernier contexte des chemins incomplets à la recherche de ce composant global. Si le chemin complet apparaît sans utiliser de point d'extension et si le résultat est un ensemble, la logique de l'application n'est pas modifiée et l'expression XPath n'est pas modifiée. Un point d'extension correspond ici à une partie de la grammaire où un ensemble d'éléments et/ou d'attributs peut être ajouté sans que la présence de ces éléments et/ou attributs soient explicites dans la grammaire. Si le chemin complet correspond à l'apparition d'un point d'extension, la règle qui définit si les points d'extension sont à utiliser ou pas est mise en oeuvre. Si les points d'extension ne sont pas acceptés, il peut alors être décidé de filtrer les évènements XML correspondant à ce point d'extension ou de réécrire l'expression XPath pour éliminer le chemin correspondant à ce point d'extension. Si le chemin complet apparaît sans utiliser de point d'extension, la valeur de retour est analysée. Si cette valeur correspond à l'ensemble des autres valeurs, ce nouveau chemin est accepté et l'expression XPath n'est pas modifiée. Si le chemin ajoute une valeur ne correspondant pas aux valeurs de l'ensemble précédent, c'est-à-dire un élément alors que l'ensemble est composé de chaîne de caractères ou inversement, la règle de changement de valeur de type qui permet de déterminer si ce chemin est valide ou non est appliquée. S'il ne l'est pas, ce chemin est éliminé par la réécriture de l'expression XPath. Suivant le nombre de chemins apparaissant et disparaissant, le résultat de l'expression XPath peut passer d'un item, c'est-à-dire un élément XML ou une valeur simple, à un ensemble d'items. Très généralement, l'application utilisant l'expression XPath attend un résultat de type valeur simple ou ensemble d'items. Par exemple, dans le cas d'une conversion, via les fonctions 'string' ou 'number , uniquement la première valeur de l'ensemble est utilisée, auquel cas il convient de vérifier que les 'nouveaux' chemins ne se substituent pas au chemin utilisé précédemment. Si tel n'est pas le cas, l'expression XPath est alors réécrite pour proscrire ces nouveaux chemins. L'exemple suivant illustre une modification de type résultat, Version 1 Version 2 number(/a//b) number(/a/b) Il est aussi possible que l'application souhaite ne recevoir qu'une seule valeur et non un ensemble de valeurs. Le changement de version de grammaire peut faire apparaître un nombre plus important de chemins possibles. Dans ce cas, si le chemin de la version antérieure de grammaire existe toujours, l'expression XPath est réécrite pour éliminer les autres chemins. Si le chemin de la version antérieure n'existe plus, l'expression XPath est marquée comme à risque. Une analyse semi-automatique permet de valider et si besoin est, corriger l'analyse automatique. Elle permet par ailleurs de corriger les expressions XPath qui n'ont pas été validées ni corrigées. L'analyse semi-automatique est de préférence réalisée à l'étape 255 de la figure 2. La figure 5 illustre un exemple d'algorithme pour l'analyse semi-automatique. Une première étape consiste à effectuer la recherche telle qu'effectuée par l'analyse automatique pour déterminer les chemins d'exploration pour chaque version de grammaire (étape 500). Ces chemins sont ensuite comparés, ce qui permet de les mettre en correspondance, et présentés à l'opérateur (étape 510). La présentation indique le type de chemin (chemin préexistant, nouveau chemin ou chemin disparu) et permet à l'opérateur de sélectionner rapidement les chemins valides ainsi que de corriger rapidement les chemins qui le nécessitent (étape 520). Une étape suivante consiste à accéder l'ensemble des chemins valides et à générer une expression XPath correspondant uniquement à ces chemins (étape 530). Cette génération peut utiliser la fonction union permettant d'effectuer l'union des différents chemins. Une étape supplémentaire d'analyse peut alors être faite pour vérifier que la nouvelle expression est aussi valide pour la version antérieure de grammaire. Dans ce cas, il est vérifié si de nouveaux chemins sont créés et, si tel est le cas, ces chemins sont explicitement éliminés. La figure 6 montre un exemple de mise en oeuvre d'une analyse semi-automatique suivant une analyse automatique de deux versions d'une grammaire. Une première version de grammaire 600 comprend en particulier un élément , référencé 615-1, sélectionné par l'expression XPath /a//b. La même expression XPath utilisée avec une seconde version de grammaire 605 sélectionne trois éléments distincts, notés 615-21, 615-22 et 615-23. L'analyse automatique de ces versions de grammaire selon l'expression XPath /a//b détecte une différence de chemins d'exploration qui peut être présentée à l'opérateur pour être corrigée. Dans cet exemple, l'opérateur désélectionne la référence 615-32 parmi les références 615-31, 615-32 et 615-33, correspondant aux références 615-21, 615-22 et 615-23, respectivement, comme illustré en 610. A partir de cette étape de sélection/désélection, le système modifie l'expression XPath qui est alors /a/b. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS 1. Procédé d'analyse d'au moins une expression de type XPath pour déterminer la validité de ladite au moins une expression de type XPath au regard d'au moins une seconde version de description d'un document de type XML par rapport à une première version de description dudit document de type XML, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détermination (350) d'au moins un chemin d'exploration de ladite au moins une expression de type XPath selon chacune desdites première et seconde versions de ladite description dudit document de type XML ; - comparaison dudit au moins un chemin déterminé associé à ladite première version de ladite description avec ledit au moins un chemin déterminé associé à ladite seconde version de ladite description ; et, -validation ou invalidation (225) de ladite au moins une expression de type XPath selon le résultat de ladite comparaison. 2. Procédé selon la revendication 1 caractérisé en ce que si ledit au moins un chemin déterminé associé à ladite seconde version de ladite description est incomplet, le procédé comprend en outre une étape d'analyse dudit au moins un chemin déterminé associé à ladite première version de ladite description pour déterminer, - une première partie de ladite expression de type XPath qui est valide selon ladite seconde version de ladite description ; - une étape de ladite expression de type XPath qui n'est pas cohérente avec ladite seconde version de ladite description ; et, - une seconde partie de ladite expression de type XPath qui n'a pas été utilisée pour déterminer ledit au moins un chemin selon ladite seconde version de ladite description. 3. Procédé selon la revendication 2 caractérisé en ce qu'il comprend en outre les étapes suivantes, - recherche d'un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - analyse de ladite seconde partie de ladite expression de type XPath pour déterminer si ledit élément peut correspondre à ladite seconde partie de ladite expression de type XPath. 4. Procédé selon la revendication 2 caractérisé en ce qu'il comprend en outre les étapes suivantes, - recherche d'un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - analyse des descendants dudit élément dans ladite seconde version de ladite description selon ladite seconde partie de ladite expression de type XPath. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de marquage (240) de ladite au moins une expression de type XPath si ladite au moins une expression de type XPath est invalide. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre, si ladite au moins une expression de type XPath est invalide, une étape d'analyse de ladite comparaison pour déterminer la possibilité de corriger automatiquement (230) ladite au moins une expression de type XPath. 7. Procédé de mise à jour d'au moins une expression de type XPath caractérisé en ce qu'il comprend les étapes suivantes, - analyse de ladite au moins une expression de type XPath selon la revendication 6 ; et, mise à jour (235) de ladite au moins une expression de type XPath. 8. Procédé selon la revendication 7 caractérisé en ce que ladite étape de mise à jour comprend une étape de modification de ladite expression de type XPath selon une règle de modification usuelle de description si ledit au moins un chemin déterminé associé à ladite une desdites au moins deux versions de ladite description est incomplet. 9. Procédé selon la revendication 7 caractérisé en ce que ladite étape de mise à jour comprend une étape de modification de ladite expression de type XPath selon une règle configurable si le résultat de ladite comparaison indique une différence de résultat ou une différence de type de résultat desdits chemins déterminés associés auxdites première et seconde versions de ladite description. 10. Procédé selon la revendication 8 ou la revendication 9 comprenant en outre une étape de validation de ladite modification de ladite expression de type XPath, ladite étape de validation comprenant les étapes suivantes, - présentation desdits chemins d'une expression XPath par rapport auxdites première et seconde versions de ladite description à un utilisateur ; -réception de la sélection d'au moins un chemin ; et, - mise à jour (255) de ladite expression de type XPath selon ladite sélection. 13. Procédé d'évaluation d'au moins une expression de type XPath caractérisé en ce que ladite au moins une expression de type XPath est analysée selon le procédé de l'une quelconque des revendications précédentes, le procédé d'évaluation comprenant au moins deux modes d'évaluation, un mode d'évaluation offrant des fonctionnalités restreintes étant utilisé pour traiter une expression de type XPath invalide (250). 14. Procédé d'évaluation d'au moins une expression de type XPath caractérisé en ce que ladite au moins une expression de type XPath est analysée selon le procédé de l'une quelconque des revendications 1 à 10, le procédé d'évaluation comprenant une étape de sélection de l'une desdites première et seconde versions de ladite description selon ledit document de type XML et une étape de sélection d'au moins une expression de type XPath selon ladite version sélectionnée. 13. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes. 14. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 12. 15. Dispositif d'analyse d'au moins une expression de type XPath pour déterminer la validité de ladite au moins une expression de type XPath au regard d'au moins une seconde version de description d'un document de type XML par rapport à une première version de description dudit document de type XML, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour déterminer au moins un chemin d'exploration de ladite au moins une expression de type XPath selon chacune desdites première et seconde versions de ladite description dudit document de type XML ; - moyens pour comparer ledit au moins un chemin déterminé associé à ladite première version de ladite description avec ledit au moins un chemin déterminé associé à ladite seconde version de ladite description ; et, - moyens pour valider ladite au moins une expression de type XPath selon le résultat de ladite comparaison. 16. Dispositif selon la revendication 15 caractérisé en ce qu'il comprend en outre des moyens pour analyser ledit au moins un chemin déterminé associé à ladite première version de ladite description afin de déterminer, - une première partie de ladite expression de type XPath qui est valide selon ladite seconde version de ladite description ; - une étape de ladite expression de type XPath qui n'est pas cohérente avec ladite seconde version de ladite description ; et, - une seconde partie de ladite expression de type XPath qui n'a pas été utilisée pour déterminer ledit au moins un chemin selon ladite seconde version de ladite description. 17. Dispositif selon la revendication 16 caractérisé en ce qu'il comprend en outre les moyens suivants, - moyens pour rechercher un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - moyens pour analyser ladite seconde partie de ladite expression de type XPath afin de déterminer si ledit élément peut correspondre à ladite seconde partie de ladite expression de type XPath. 18. Dispositif selon la revendication 16 caractérisé en ce qu'il 10 comprend en outre les moyens suivants, - moyens pour rechercher un élément de ladite seconde version de ladite description n'appartenant pas à ladite première version de ladite description ; et, - moyens pour analyser des descendants dudit élément dans ladite 15 seconde version de ladite description selon ladite seconde partie de ladite expression de type XPath. 19. Dispositif selon l'une quelconque des revendications 15 à 18 comprenant en outre des moyens pour marquer ladite au moins une expression de type XPath si ladite au moins une expression de type XPath n'est pas valide. 20 20. Dispositif selon l'une quelconque des revendications 15 à 19 comprenant en outre des moyens pour analyser ladite comparaison afin de déterminer la possibilité de corriger automatiquement ladite au moins une expression de type XPath. 21. Dispositif de mise à jour d'au moins une expression de type 25 XPath caractérisé en ce qu'il comprend les moyens suivants, - moyens pour analyser ladite au moins une expression de type XPath selon la revendication 20 ; et, - moyens pour mettre à jour ladite au moins une expression de type XPath. 30 22. Dispositif selon la revendication 21 caractérisé en ce que lesdits moyens de mise à jour comprennent des moyens pour modifier ladite expression de type XPath selon une règle de modification usuelle de description. 23. Dispositif selon la revendication 21 caractérisé en ce que lesdits moyens de mise à jour comprennent des moyens pour modifier ladite expression de type XPath selon une règle configurable. 24. Dispositif selon la revendication 22 ou la revendication 23 comprenant en outre des moyens pour valider ladite modification de ladite expression de type XPath, lesdits moyens de validation comprenant les moyens suivants, - moyens pour présenter lesdits chemins d'une expression XPath par rapport auxdites première et seconde versions de ladite description à un utilisateur ; -moyens pour recevoir la sélection d'au moins un chemin ; et, - moyens pour mettre à jour ladite expression de type XPath selon ladite sélection. 27. Dispositif d'évaluation d'au moins une expression de type XPath caractérisé en ce que ladite au moins une expression de type XPath est analysée par le dispositif selon l'une quelconque des revendications 15 à 24, le dispositif d'évaluation comprenant au moins deux modes d'évaluation, un mode d'évaluation offrant des fonctionnalités restreintes étant utilisé pour traiter une expression de type XPath invalide. 28. Dispositif d'évaluation d'au moins une expression de type XPath caractérisé en ce que ladite au moins une expression de type XPath est analysée par le dispositif selon l'une quelconque des revendications 15 à 24, le dispositif d'évaluation comprenant des moyens pour sélectionner l'une desdites première et seconde versions de ladite description selon ledit document de type XML et des moyens pour sélectionner au moins une expression de type XPath selon ladite version sélectionnée.