FR2914453A1 - Procedes et dispositifs de gestion de version de traitements de documents de type xml - Google Patents

Abstract

Les procédés et les dispositifs selon l'invention permettent la sélection d'une définition pour un document XML parmi au moins deux versions de la définition selon au moins une règle de prétraitement et au moins une règle de post-traitement. Après avoir identifié l'élément racine (600), les règles de prétraitement de post-traitement sont accédées (610). Les règles de prétraitement sont appliquées au document XML (620) qui est ensuite traité (640). Les règles de post-traitement sont alors appliquées au document XML traité. La version de la définition est ensuite sélectionnée. Les règles de traitement sont définies après avoir déterminé les différences entre les versions de la définition, classé ces différences et sélectionné au moins une définition de base.

Description

La présente invention concerne le traitement de documents de type XML

(eXtensible Markup Language) et plus particulièrement des procédés et des dispositifs de gestion de version de traitements de documents de type XML. 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 clu 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 gels 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. II 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, <ns:example attribute=`value'> Textnode </ns: example> 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 2 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 <element name='a'> <element name='b' minOccurs='0%> <element name='c'/> <!--no attribute--> </element> version 2 <element name='a'> <element name='b' minOccurs='O'/> <element name='c' /> <attribute name='attr'/> </element> 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. Par ailleurs, WSDL (Web Services Description Language) est un 20 langage de descriptions de services web. Il 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', 25 <description> <interface name='mylnterface'> <operation name='myOperation'> <input element='ns:a%> <output element='ns: b7> 30 </operation> </interface> </description> 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 35 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 10 amenées à être modifiées. Il en est de même pour les descriptions de services 1NSDL qui peuvent avoir à évoluer. Ainsi, un service peut être disponible à un instant donné. Des clients sont alors développés et déployés pour interagir avec celui-ci. Dans un deuxième temps, le service évolue pour proposer de nouvelles fonctionnalités. De nouveaux clients sont alors développés et déployés. Cependant, les clients précédents peuvent toujours vouloir interagir avec le service. Un tel service doit donc de préférence pouvoir supporter les deux versions des clients de manière conjointe. A cette fin, le service devra traiter des documents XML dont la structure n'est pas parfaitement identique. Il est ici considéré le cas où l'entité de traitement effectue une première étape de conversion des données XML en une structure, aussi appelée objet programmatique, dérivée de la définition schéma. Ceci s'effectue généralement par un processeur de conversion d'un document XML vers l'objet programmatique et inversement, d'un objet programmatique vers un document XML (XML data binding en anglais). Dans ce contexte, le traitement de documents XML s'effectue généralement sur la base du nom de l'élément XML racine. Lorsque plusieurs versions du même élément racine existent, l'entité de traitement a besoin de connaître la version du document avant d'effectuer le traitement de l'ensemble du document XML. Plus généralement, le problème est ici de déterminer la version de l'entité de traitement adéquate qui utilise en entrée un document XML. Elle peut aussi produire des documents XML en réponse à un document d'entrée.

Pour traiter des documents XML, les services traduisent généralement ceux-ci en structures ou objets programmatiques qui se basent sur la définition schéma de ces documents. Si un programme essaye de traiter un document XML avec la mauvaise version du schéma, le traitement peut échouer. Plusieurs approches existent.

Si un service supporte plusieurs versions, il peut évaluer si le document XML est valide par rapport aux différentes versions. Cela peut notamment être réalisé par le biais d'une entité de validation de schéma : le document XML est validé avec chaque version de la définition schéma. II est ainsi possible d'obtenir la ou les versions compatibles avec le document XML. Il est ensuite nécessaire de choisir le processeur adapté à traduire le document XML en un objet programmatique et à le traiter. Cette solution a cependant pour inconvénient principal de nécessiter un long temps de traitement et une mémoire importante : une validation multiple ainsi que le stockage des schémas sont nécessaires. Une alternative permettant de résoudre certain de ces problèmes est présentée dans la demande de brevet US2005/0060645 qui a pour objet la validation d'un même document selon deux définitions de schémas en déterminant la différence entre les deux définitions. L'entité de validation utilise la première définition pour valider le document. Pour valider le document selon la deuxième version, l'entité de validation utilise les différences entre les définitions ainsi que le résultat de validation selon la première version. Cette invention permet ainsi l'optimisation de validation d'un même document XML selon plusieurs versions d'une définition. Cependant, cette méthode nécessitant l'application successive de plusieurs étapes de validation n'est pas optimale, notamment en terme de rapidité. L'invention a ainsi pour objet un procédé pour générer des règles de traitement pour au moins un document de type XML selon au moins deux versions de définition dudit au moins un document de type XML, ce procédé comprenant les étapes suivantes, - détermination d'au moins une différence, appelée première différence, entre lesdites au moins deux versions de définition ; - classification de ladite au moins une différence déterminée ; - obtention d'au moins une définition de base en fonction de ladite classification ; et, - génération d'au moins une règle de traitement selon au moins une différence, appelée seconde différence, antre ladite au moins une définition de base et l'une desdites au moins deux versions de définition, ladite au moins une règle de traitement étant une règle de prétraitement ou une règle de post-traitement.

L'invention permet ainsi d'analyser plusieurs versions de définition pour déterminer des règles de traitement. Ces règles de traitement peuvent être utilisées pour sélectionner efficacement une version de définition. Selon le type de différences entre les versions de définition, une 5 définition de base peut être générée à partir des versions de définition ou peut être sélectionnée parmi les versions des dléfinitions. Selon un mode de réalisation particulier, ladite étape de génération d'au moins une règle de traitement comprend une étape de génération d'une étape de test si ladite au moins une première différence est 10 une différence de type extension. Un tel test permet de déterminer ultérieurement s'il existe ou non une différence significative entre lesdites au moins deux versions de définition, l'existence ou l'absence d'une telle différence étant utilisée pour sélectionner une version de définition. Avantageusement, le procédé comprend en outre une étape de 15 génération d'une étape de localisation permettant d'atteindre la partie du document où un test peut être effectué pour déterminer l'existence ou l'absence de différence pouvant être utilisée pour sélectionner une version de définition. Toujours selon un mode de réalisation particulier, ladite étape de génération d'une étape de test est une étape de génération d'une étape XPath 20 si ladite au moins une règle de traitement est une règle de prétraitement et ladite étape de génération d'une étape de test est une étape de génération d'une étape programmatique si ladite au rnoins une règle de traitement est une règle de post-traitement. Les règles de prétraitement étant plus coûteuses que les règles de 25 post-traitement en termes de temps cle traitement et de ressources, la classification entre les règles de prétraitement et les règles de post-traitement permet d'optimiser le procédé. Toujours selon un mode de réalisation particulier ladite au moins une première différence est du type restriction ou du type extension. Une 30 restriction correspond ici à une réduction des possibilités offertes par une définition tandis qu'une extension correspond à l'ajout d'une alternative.

L'invention a également pour objet un procédé de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon au moins une règle de traitement déterminée selon le procédé décrit précédemment, ce procédé comprenant les étapes suivantes, - identification d'un élément racine ; - accès à ladite au moins aune règle de traitement ; - application de ladite au rnoins une règle de traitement ; - sélection d'une version de définition parmi lesdites au moins deux versions de ladite définition selon le résultat de ladite application de ladite au moins un règle de traitement. L'invention a aussi pour objet un procédé de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon au moins une règle de prétraitement et au moins une règle de post-traitement, ce procédé comprenant les étapes suivantes, identification d'un élément racine ; - accès à ladite au moins une règle de prétraitement et à ladite au moins une règle de post-traitement ; -application de ladite au rnoins une règle de prétraitement ; - traitement dudit document de type XML ; application de ladite au rnoins une règle de post-traitement ; - sélection d'une version de définition parmi lesdites au moins deux versions de ladite définition selon le résultat de ladite application de ladite au moins un règle de post-traitement. L'invention permet ainsi de sélectionner rapidement la version d'une définition qui doit être utilisée. Selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes si lesdites au moins deux versions de ladite définition peuvent être utilisées, - évaluation des définitions de résultats possibles pour chacune desdites au moins deux versions de ladite définition ; - analyse desdites définitions de résultats pour déterminer si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition ; et, - si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition, sélection de ladite une desdites au moins deux versions de ladite définition. Le procédé selon l'invention permet ainsi de sélectionner la version de définition la plus adaptée. Avantageusement, le procédé comprend en outre une étape de sélection de la version de ladite définition selon un critère de probabilité si l'une desdites au moins deux versions de ladite définition n'est pas une restriction de l'autre desdites au moins deux versions de ladite définition. Le procédé selon l'invention permet ainsi de sélectionner la version de définition la plus probable, c'est-à-dire notamment la version de définition qui a le plus de chance d'être comprise par le client. L'invention a également 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 pour générer des règles de traitement pour au moins un document de type XML selon au moins deux versions de définition dudit au moins un document de type XML, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour déterminer au moins une différence, appelée première différence, entre lesdites au moins deux versions de définition ; - moyens pour classifier ladite au moins une différence déterminée ; - moyens pour obtenir au moins une définition de base selon le résultat de ladite classification ; et, - moyens pour générer au moins une règle de traitement selon au moins une différence, appelée seconde différence, entre ladite au moins une définition de base et l'une desdites au moins deux versions de définition, ladite au moins une règle de traitement étant une règle de prétraitement ou une règle de post-traitement. L'invention permet ainsi d'analyser plusieurs versions de définition pour déterminer des règles de traitement. Ces règles de traitement peuvent être utilisées pour sélectionner une version de définition. Lesdits moyens pour obtenir au moins une définition de base sont avantageusement adaptés à sélectionner l'une desdites au moins deux versions de définition, selon la nature des différences entre ces versions. Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour générer une étape de test qui permet de déterminer s'il existe ou non une différence significative entre lesdites au moins deux versions de définition, l'existence ou l'absence d'une telle différence pouvant être utilisée pour sélectionner une version de définition. Avantageusement, lesdits moyens pour générer une étape de test sont adaptés à générer une étape de test XPath ou une étape de test programmatique. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour générer une étape de localisation permettant d'atteindre la partie du document où un test peut être effectué pour déterminer l'existence ou l'absence die différence, une telle différence pouvant être utilisée pour sélectionner une version de définition. Lesdits moyens pour générer une étape de localisation sont avantageusement adaptés à générer une étape de localisation XPath ou une étape de localisation programmatique. L'invention a également pour objet un dispositif de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon au moins une règle de prétraitement et au moins une règle de post-traitement, ce dispositif comprenant les moyens suivants, - moyens pour identifier un élément racine ; - moyens pour accéder à ladite au moins une règle de prétraitement et à ladite au moins une règle de post-traitement ; - moyens pour appliquer ladite au moins une règle de prétraitement ; - moyens pour traiter ledit document de type XML ; moyens pour appliquer ladite au moins une règle de post-traitement ; - moyens pour sélectionner une version de définition parmi lesdites au moins deux versions de ladite définition selon le résultat de ladite application de ladite au moins un règle de post-traitement. Avantageusement, le dispositif comprend en outre les moyens suivants, - moyens pour évaluer des définitions de résultats possibles pour chacune desdites au moins deux versions de ladite définition ; et, - moyens pour analyser lesdites définitions de résultats et pour déterminer si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition. Le dispositif selon l'invention permet ainsi de sélectionner la version de définition la plus adaptée.

Toujours de façon avantageuse, le dispositif comprend en outre des moyens pour sélectionner la version de ladite définition selon un critère de probabilité. Le dispositif selon l'invention permet ainsi de sélectionner la version de définition la plus probable. 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 illustre schématiquement certaines étapes de l'invention ; - la figure 2 montre un exemplle d'appareil permettant d'implémenter au moins partiellement l'invention ; -la figure 3 présente certaines étapes de la phase d'analyse utilisée pour générer des règles de traitement ; - la figure 4 montre un exemple d'algorithme adapté à générer des expressions XPath pour construire des règles de prétraitement ; - la figure 5 illustre un exemple d'algorithme pour générer les règles de post-traitement ; - la figure 6 illustre un exemple de mise en oeuvre de l'invention pour traiter un document XML ; et, - la figure 7 illustre un exemple d'algorithme pour déterminer la version devant être utilisée si le document XML peut correspondre à plusieurs versions et si la description WSDL est disponible.

Le principe général de l'invention est d'identifier les différences entre les versions des définitions. Les différences identifiées sont ensuite utilisées pour générer des règles de prétraitement et des règles de post-traitement. Les règles de prétraitement permettent de sélectionner la définition adaptée à traduire le document XML en un objet programmatique. Ces règles de prétraitement sont appliquées directement sur le document XML en utilisant, par exemple, un processeur XPath. Les règles de prétraitement sont alors des assertions basées sur XPath telles que définies dans Schematron (standard IISO de définition de schémas basé sur XPath permettant la détection de modèle de sous-arbres XML).

Il convient de rappeler ici qu'XPath est un langage permettant de trouver et d'évaluer certaines informations dans un document XML. Une première partie de ce langage permet de sélectionner certaines parties d'un document XML à partir d'un chemin, par exemple le chemin /description/interface//input. Une deuxième partie de ce langage permet de manipuler les parties sélectionnées du document XML, notamment pour effectuer des conversions, des fonctions numériques ou des unions. Des règles de post-traitement permettent ensuite de préciser la version de la structure ou de l'objet programmatique. Ces règles s'appliquant sur la structure ou l'objet programmatique, elles sont peu coûteuses en termes de temps de traitement et de ressources. Ainsi, l'invention permet de minimiser le nombre de règles de prétraitement qui sont coûteuses et die maximiser le nombre de règles de post- traitement qui sont peu coûteuses. La ou les définitions servant de base à l'outil de conversion XML vers l'objet programmatique sont sélectionnées en fonction de ce critère. Cette sélection permet par ailleurs généralement de minimiser le nombre de définitions et ainsi de minimiser la taille de l'outil de conversion.

La figure 1 illustre schématiquement certaines étapes de l'invention. Comme illustré, des règles de prétraitement sont tout d'abord appliquées sur le document XML (étape 100) avant que ce document ne soit converti en objet programmatique (étape 105). Des règles de post-traitement sont alors appliquées sur l'objet programmatique (étape 110). Le traitement est ensuite effectué sur celui-ci (étape 115). Les exemples suivants permettent d'illustrer ce principe. Selon un premier exemple, la première version de: la définition correspond à un sous-ensemble de la seconde version de Ira définition (la définition selon la seconde version ajoute un attribut optionnel à l'élément 'a'), version 1 : <element name='a'> <element name='b' minOccurs='0%> <element name='c' /> <!--no attribute--> </element> et version 2 : <element name='a'> <element name='b' minOccurs='0%> <element name='c'/> <attribute name='attr%> </element> Selon ce premier exemple, les règles de prétraitement et de post-traitement sont les suivantes, règles de prétraitement 30 aucune règles de post-traitement ASSERT(InstanceOf a->attr l=NULL, v1) Par défaut, le schéma le plus général, ici le schéma de la version 2, est sélectionné. Les règles de prétraitement sont ensuite sélectionnées. Dans 35 cet exemple, aucune règle de prétraitement n'est sélectionnée. Les règles de 20 25 12 post-traitement sont ensuite sélectionnées. Ici, une seule règle de post-traitement est sélectionnée. La règle de post-traitement permet de tester si la valeur 'attr' est nulle ou non dans l'objet construit. Si la valeur `attr' est nulle, la première version de la définition doit être utilisée.

En reprenant l'exemple précéclent et en ajoutant la condition selon laquelle la première version doit être conservée telle quelle (cette contrainte supplémentaire peut être due aux contraintes de déploiement ou de mise à jour des dispositifs de traitement), les première et seconde versions sont conservées et une règle de prétraitement est générée pour différencier les deux versions. La présence de l'attribut 'attr' dans le document XML est vérifiée, règles de prétraitement <assert select='a/@attr'/>v2< /assert> règles de post-traitement aucune Selon un second exemple, il existe une partie commune entre la première et la seconde versions de la définition, version 1 : <element name='a'> <element name='b' minOccurs='0%> <element name='c' /> <!--no attributes allowed--> </element> et version 2 : <element narre= a'> <!--element b removed--> <element name='c'/> <attribute name='attr%> </element> Dans cet exemple, la seconde version contient deux modifications : il 30 supprime la présence d'un élément 'b' et ajoute un attribut optionnel 'attr'. règles de prétraitement aucune règles de post-traitement ASSERT(InstanceOf a->b !=NULL, v1) 35 ASSERT(InstanceOf a->attr !=NULL, v2) 25 Dans ce cas, une définition commune qui intègre la présence de l'attribut 'attr' et celle de l'élément 'b', de façon optionnelle, est générée. Cette nouvelle définition est ainsi capable de traduire l'ensemble des documents selon les première et seconde versions. Aucune règle de prétraitement n'est alors générée et deux règles de post-traitement sont ajoutées : si la valeur de 'b' n'est pas nulle, le document XML est traité selon la première version de la définition et si la valeur de 'attr' n'est pas nulle, le document XML est traité selon la seconde version de la définition. Si les deux règles de post-traitement sont vérifiées, le document XML n'est alors pas valide, il est traité comme un document partiellement erroné. En reprenant l'exemple précédent et en ajoutant la contrainte de conserver la première définition intacte, les deux définitions sont conservées, règles de prétraitement <assert select='a/@attr%>v2< /assert> règles de post-traitement ASSERT(lnstanceOf a->b !=NULL, v1) Une règle de prétraitement est générée pour différencier les deux définitions, ici la présence ou nom de l'attribut 'attr'. Par ailleurs, une assertion de post-traitement est générée pour permettre de tester la présence ou non de l'élément 'b' dans l'objet. II est ainsi possible de détecter si le document est valide vis-à-vis des deux versions. Un appareil mettant en oeuvre l'invention ou une partie de l'invention est illustré sur la figure 2. L'appareil 200 est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable ou un serveur multimédia. Si cet appareil n'intègre pas directement un capteur numérique d'images, il peut optionnellement être connecté à différents périphériques tels que, par exemple une caméra numérique 201 (ou un convertisseur analogique numérique ou tout autre moyen de capture de vidéo) reliée à une carte graphique et fournissant à l'appareil des données multimédia.

L'appareil 200 comporte un bus de communication 202 auquel sont reliées : - une unité centrale de traitement ou microprocesseur 203 (CPU, Central Processing Unit) ; - une mémoire morte 204 (ROM, Read Only Memory) pouvant comporter les programmes "Prog" ; - une mémoire vive ou mémoire cache 206 (RAM, Random Access Memory) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, - une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données. Optionnellement, l'appareil 200 peut également disposer : - d'un écran 208 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 210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique, un écran tactile ou une télécommande ; - d'une carte d'entrée/sortie (non représentée) reliée à un microphone 222 dans le cas, par exemple, de données audio ; - d'un disque dur 212 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; - d'un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention ; et, - d'un lecteur de cartes mémoires adapté à y lire ou à y écrire 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 200 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 du l'appareil 200 directement ou par l'intermédiaire d'un autre élément de l'appareil 200.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou en mémoire morte 204. Selon une variante, la disquette 216 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 200, sera stocké dans le disque dur 212. En seconde variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 220, via l'interface 218, 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. Demanière générale, les disquettes peuvent être remplacées par des moyens de stockage d'information, lisibles par un ordinateur ou par un microprocesseur, intégrés ou non à l'appareil, éventuellement amovibles, et adaptés à 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 200 avant d'être exécutés.

L'unité centrale 203 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 212 ou dans la mémoire morte 204 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 212 ou la mémoire morte 204, sont transférés dans la mémoire vive 206 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

II convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). Comme mentionné précéclemment par référence à la figure 1, le système de mise en oeuvre de l'invention se base sur un ensemble de règles de prétraitement, de systèmes de conversion d'un document XML vers un objet programmatique et de règles de post-traitement. Le procédé décrit s'applique à un document XML entier ou à une partie d'un document XML. Dans un souci de clarté, il est ici considéré qu'un document XML est un document XML entier ou une partie de document XML.

Une phase d'analyse des définitions de schéma est effectuée avant la phase d'exécution pour déterminer les règles de prétraitement et de post-traitement. Cette phase d'analyse est de préférence réalisée une seule fois dans un environnement de développement, les résultats de l'analyse étant ensuite déployés dans l'environnement d'exécution. Cette étape d'analyse peut néanmoins être intégrée à l'environnement d'exécution, permettant ainsi une mise à jour dynamique des règles de prétraitement et de post-traitement. L'analyse présentée ici est effectuée pour chaque élément global du schéma analysé et peut aussi s'appliquer à chaque type global du schéma. La figure 3 présente certaines étapes de cette phase d'analyse. Lors de l'étape 300, les différentes versions d'une même définition (élément ou type) sont accédées. Les différences entre les versions accédées sont ensuite déterminées (étape 310). Les différences entre les versions se présentent, par exemple, sous forme d'une liste de différences comme présentées dans la suite de la description. Ces différences sont ensuite classifiées par type (étape 320), par exemple selon les extensions et les restrictions. A partir de ces informations, la ou les définitions de base sont alors sélectionnées (étape 330). Si plusieurs définitions de base existent, des règles de prétraitement, des règles de post-traitements et des instructions permettant la conversion d'un document XML se conformant à la définition de base en un objet programmatique sont générées (étapes 340, 350 et 360). L'analyse des définitions pour déterminer leurs différences (étape 310) peut être implémentée de différentes façons. Selon un mode de réalisation particulier, deux définitions sont sélectionnées, l'une étant utilisée comme référence. Un algorithme d'exploration des définitions de type profondeur est ensuite mis en oeuvre : lors de la détection d'éléments locaux de types ou de groupes identiques dans les deux définitions, l'exploration se poursuit par les enfants de ces sous-définitions. Cet algorithme n'explore pas les éléments faisant référence à des éléments globaux, ces éléments globaux étant explorés successivement. Cette exploration permet de détecter des différences dans les définitions. II peut s'agir de différences de type valeurs, attributs ou éléments telles que les différences suivantes, modifications du type simple d'un attribut ou élément ; - ajout d'attributs optionnels ou obligatoires ; suppression d'attributs optionnels ou obligatoires ; ajout d'une règle d'extension d'attribut ce qui, en XML Schema, se traduit par l'élément `anyAttribute' ; - restriction d'une règle d'extension d'attribut en un nombre fini d'attributs ; ajout d'éléments ou de groupes d'éléments optionnels ou obligatoires ; suppression d'éléments ou de groupes d'éléments optionnels ou 20 obligatoires ; remplacement d'un groupe d'éléments par un élément ; remplacement d'un élément par un groupe d'éléments ; - ajout d'une règle d'extension d'élément ce qui, en XML Schema, se traduit par l'élément 'any' ; 25 - restriction d'une règle d'extension d'élément en un ensemble fini d'éléments ; et - modifications des contraintes de répétition d'un élément ou d'un groupe. Les différences liées aux attributs sont aisées à intégrer dans 30 l'algorithme d'exploration en profondeur d'abord car tous les attributs d'un noeud sont connus à un instant donné. La détection des différences de structures d'éléments peut amener à modifier l'algorithme d'exploration en profondeur d'abord. En effet, pour certaines des différences, il est nécessaire de connaître la sous-définition suivante pour effectuer une classification correcte des différences. Lorsque l'ensemble des différences est déterminé, ces différences sont triées (étape 320), par exernple en quatre catégories : restriction, restriction inverse, extension et extension inverse. Une restriction correspond à une réduction des possibilités offertes par une définition, c'est-à-dire rendre un attribut optionnel obligatoire ou contraindre plus fortement les occurrences d'un élément. Une extension correspond à l'ajout d'une alternative, par exemple l'ajout d'un élément nouveau. Une extension inverse entre deux définitions A et B correspond à une extension de B vers A, par exemple l'enlèvement d'un élément obligatoire. Une restriction inverse entre deux définitions A et B correspond à une restriction de B vers A, par exemple le passage d'une occurrence minimum d'un élément de 1 à 2.

S'il est possible d'obtenir une définition qui a uniquement des liens de restriction avec les autres définitions possibles, cette définition est choisie comme base car c'est la définition la plus générique. Si aucune définition ne satisfait cette condition, il convient de chercher à générer une définition de base qui puisse avoir uniquement des relations de restriction avec les différentes définitions. Il est par exemple possible de partir de la définition ayant le plus de relations de restriction et de modifier cette définition pour intégrer chaque relation n'étant pas une relation de restriction. Pour une différence de type extension, il est possible d'ajouter à cette définition la sous- définition étendue. II convient de noter que de façon exceptionnelle la définition ainsi modifiée peut être différente de la définition initiale auquel cas il peut être décidé de conserver plusieurs définitions de base pour simplifier la phase de conversion du document XML vers l'objet programmatique. Par ailleurs, un utilisateur peut aussi définir certaines définitions comme étant à conserver, la raison pouvant être une contrainte de déploiement ou une instruction de guidage du système. (Lorsque plusieurs définitions de base existent, le processus est répété en groupant les définitions non sélectionnées à partir des définitions de base.

Durant le processus de sélection des définitions de base, les différences entre l'ensemble des définitions ont été mises à jour. Les règles de prétraitement et de post-traitement sont alors générées à partir de ces différences (étapes 340 et 350). Si plusieurs définitions de base ont été sélectionnées, les différences de type extension entre ces définitions sont utilisées. Pour chacune de ces différences, l'expression XPath correspondante est générée. Cette expression XPath, lorsqu'elle est vérifiée, permet de déterminer la définition de base exacte qui doit être utilisée pour la conversion du document XML vers l'objet programmatique.

La génération de l'expression XPath est effectuée en deux parties comme décrit à la figure 4 : la première partie consiste à générer la partie de navigation permettant d'accéder aux parties du document XML pouvant exhiber cette différence tandis que la deuxième partie consiste à tester l'existence de cette différence telle que la présence d'un attribut ou l'absence d'un élément. Le processus commence en déterminant et en sélectionnant une première différence de type extension (étapes 400 et 410). Chaque différence contient le chemin dans la définition schéma permettant de localiser l'endroit dans un document XML où se situe la différence. Le chemin est une pile de contextes. Chaque contexte devant être précisé est sélectionné (étapes 420 et 430) et une étape de localisation XPath est générée (étape 440). Pour des schémas simples, cette étape peut ne contenir qu'un nom d'élément. Cependant, il peut être nécessaire d'ajouter à ce nom d'élément un prédicat sur les attributs de cet élément ou sur les éléments voisins de cet élément. Ces contraintes supplémentaires permettent de retranscrire partiellement les structures schémas traversées durant cette étape cle localisation. En général, la génération est simple lorsqu'il n'y a pas de réutilisation excessive dans un élément clu même nom pour plusieurs de ses enfants directs. Lorsque le même nom est utilisé pour des éléments enfants directs dans différentes sous-définitions d'un élément, les tests d'occurrence peuvent s'avérer compliqués. Lorsque le chemin est généré, c'est-à-dire que le contexte est précisé, le type exact de la différence, par exemple un attribut optionnel ajouté ou un élément obligatoire enlevé, est déterminé (étape 450).

Une étape de test XPath est alors générée en fonction du type de différence déterminé (étape 460). L'expression XPath devient alors une règle de prétraitement qui, appliquée à un document XML, retourne une valeur booléenne. L'expression XPath est ensuite mémorisée dans l'ensemble des règles de prétraitement à appliquer pour un ensemble de documents XML particuliers (étape 470). Lorsque l'ensemble des différences est traité, les expressions XPath peuvent être utilisées (étape 480). II convient de noter ici que la génération des règles de prétraitement au moyen de XPath est un mode de mise en oeuvre préféré de l'invention car il s'agit d'une méthode directe et rapicle. Néanmoins, des alternatives existent pour l'homme du métier. La génération des règles de post-traitement illustrée sur la figure 5 est identique dans le principe à la génération des règles de prétraitement. Elle se passe en deux parties mais s'appuie sur le langage programmatique cible et sur la définition de l'objet programmatique. L'ensemble des différences existant entre chaque définition de base et ses définitions rattachées est déterminé. Chaque différence est alors convertie en une règle de post-traitement. Ces règles permettent ensuite de déterminer quelles sont les versions compatibles avec le document XML. La puissance d'expression des langages programmatiques actuels permettant une conversion fidèle d'un schéma XML en une définition d'objet ou de structure programmatique, la génération des règles de post-traitement est aisée car chaque partie de définition se trouve plus ou moins traduite dans la définition programmatique. La traduction d'une différence vers une règle de post-traitement est effectuée pour chaque différence (étapes 500 et 510). Pour chaque contexte à exprimer (étapes 520 et 530), des instructions programmatiques permettant de naviguer dans une instance programmatique correspondant au document XML sont générées (étape 540). Ces instructions permettent de sélectionner les données programmatiques exhibant la différence. Selon le type de la différence (étape 550), le test programmatique adapté est généré (étape 560). Le programme de test correspondant à la navigation et au test est ensuite mémorisé (étape 570). Lorsque l'ensemble des programmes de test est généré, ceux-ci peuvent alors être utilisés (étape 580). La figure 6 illustre la mise en oeuvre de l'invention pour traiter un document XML. Après avoir identifié le nom de l'élément racine du document XML à traiter (étape 600), les règles de prétraitement et de post-traitement sont accédées (étape 610). Les règles de prétraitement sont alors appliquées sur le document XML (étape 620) pour sélectionner la définition permettant la conversion du document XML en une structure programmatique (étape 630). Le document XML est ensuite traité selon la définition sélectionnée (étape 640) et les règles de post-traitement sont appliquées (étape 650) pour permettre l'obtention de la version finale du document XML et de l'objet programmatique. Cette information permet ainsi de sélectionner l'entité de traitement de l'objet programmatique. Le document XML peut être compatible avec plusieurs versions. En fonction de l'utilisation finale, une étape ultérieure de décision peut être faite. Dans le cadre d'un service web, le document XML correspond généralement à une requête. Cette requête est souvent liée à une réponse à générer en fonction de la requête. Cette relation requête/réponse est explicitée dans les documents WSDL. A partir d'un tel document, il est alors possible d'effectuer une analyse des différentes versions possibles de la réponse pour choisir l'entité de traitement qui produira cette réponse. La figure 7 illustre un exemple d'algorithme pour déterminer la version devant être utilisée si le document XML peut correspondre à plusieurs versions et si la description WSDL. est disponible. A partir des versions possibles de la requête (étape 700), les versions possibles de l'opération invoquée sont déterminées selon une description du service via, par exemple, un ou plusieurs documents WSDL (étape 710). Il est alors possible d'évaluer les versions possibles de la réponse (étape 720). Les différentes versions possibles des réponses sont ensuite analysées (étape 730). Cette analyse permet de détecter si l'une des versions est une restriction des autres. Si tel est le cas (étape 740), cette version cle la réponse, la plus minimaliste, est sélectionnée (étape 750). Ainsi, dans l'exemple donné précédemment concernant le cas où la première version de la définition correspond à un sous-ensemble de la seconde version de la définition, la première version de la définition est choisie et donc l'entité de traitement correspondante est sélectionnée.

Si la décision ne peut pas être prise en ce sens, il est possible d'effectuer une analyse statistique de l'utilisation des versions des opérations (étape 760). Pour chaque opération, le nombre de fois qu'est appelée chaque version de l'opération de façon non ambiguë est comptabilisé. Lorsqu'une ambiguïté apparaît, la version de l'opération la plus appelée est sélectionnée.

Cette dernière étape permet de maximiser les chances de sélectionner le type de réponse qui sera compréhensible par le client qui a envoyé la requête. Lorsque les versions de la sortie et de l'opération choisie sont déterminées, l'entité de traitement de l'opération est sélectionnée (étape 770). L'opération est alors exécutée (étape 780).

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications clans la description précédente.

Claims (21)

REVENDICATIONS

1. Procédé pour générer des règles de traitement pour au moins un document de type XML selon au moins deux versions de définition dudit au moins un document de type XML, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détermination (310) d'au moins une différence, appelée première différence, entre lesdites au moins deux versions de définition ; - classification (320) de ladite au moins une première différence déterminée ; - obtention (330) d'au moins une définition de base en fonction de ladite classification ; et, - génération (340, 350) d'au moins une règle de traitement selon au moins une différence, appelée seconde différence, entre ladite au moins une définition de base et l'une desdites au mains deux versions de définition, ladite au moins une règle de traitement étant une règle de prétraitement ou une règle de post-traitement.

2. Procédé selon la revendication 1 caractérisé en ce que ladite étape d'obtention d'au moins une définition de base est une étape de sélection de l'une desdites aux moins deux versions de définition.

3. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que si ladite au moins une première différence est une différence de type extension, ladite étape de génération d'au moins une règle de traitement comprend une étape de génération d'une étape de test (460, 560).

4. Procédé selon la revendication 3 caractérisé en ce qu'il comprend en outre une étape de génération d'une étape de localisation (440, 540).

5. Procédé selon la revendication 3 ou la revendication 4 caractérisé en ce que si ladite au moins une règle de traitement est une règlede prétraitement, ladite étape de génération d'une étape de test est une étape de génération d'une étape XPath et en ce que si ladite au moins une règle de traitement est une règle de post-traitement, ladite étape de génération d'une étape de test est une étape de génération d'une étape programmatique.

6. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que ladite au moins une première différence est du type restriction ou du type extension.

7. Procédé de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon au moins une règle de traitement déterminée selon le procédé selon l'une quelconque des revendications précédentes, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - identification d'un élément racine (600) ; - accès à ladite au moins une règle de traitement (610) ; - application de ladite au moins une règle de traitement (620, 650) ; sélection d'une version de définition parmi lesdites au moins deux versions de ladite définition selon le résultat de ladite application de ladite au moins un règle de traitement.

8. Procédé de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon au moins une règle de prétraitement et au moins une règle de post-traitement, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, -identification d'un élément racine (600) ; - accès à ladite au moins une règle de prétraitement et à ladite au 25 moins une règle de post-traitement (610) ; - application de ladite au moins une règle de prétraitement (620) ; - traitement dudit document de type XML (640) ; -application de ladite au moins une règle de post-traitement (650) ; sélection d'une version de définition parmi lesdites au moins deux 30 versions de ladite définition selon le résultat de ladite application de ladite au moins une règle de post-traitement.

9. Procédé selon la revendication 7 ou la revendication 8 caractérisé en ce que si lesdites au moins deux versions de ladite définition peuvent être utilisées, le procédé comprend en outre les étapes suivantes, -évaluation des définitions de résultats possibles pour chacune desdites au moins deux versions de ladite définition ; - analyse desdites définitions de résultats pour déterminer si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition ; et, - si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition, sélection de ladite une desdites au moins cieux versions de ladite définition.

10. Procédé selon la revendication 9 caractérisé en ce que si l'une desdites au moins deux versions de ladite définition n'est pas une restriction de l'autre desdites au moins deux versions de ladite définition, le procédé comprend en outre une étape de sélection de la version de ladite définition selon un critère de probabilité.

11. 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.

12. Moyen de stockage d'iinformations, 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 à 10.

13. Dispositif pour générer des règles de traitement pour au moins un document de type XML selon au moins deux versions de définition dudit au moins un document de type XML, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour déterminer au moins une différence, appelée première différence, entre lesdites au moins deux versions de définition ; - moyens pour classifier ladite au moins une première différence déterminée ;- moyens pour obtenir au moins une définition de base selon le résultat de ladite classification ; et, -moyens pour générer au moins une règle de traitement selon au rnoins une différence, appelée seconde différence, entre ladite au moins une définition de base et l'une desdites au moins deux versions de définition, ladite au moins une règle de traitement étant une règle de prétraitement ou une règle de post-traitement.

14. Dispositif selon la revendication 13 caractérisé en ce que lesdits moyens pour obtenir au moins une définition de base sont adaptés à sélectionner l'une desdites au moins deux versions de définition.

15. Dispositif selon la revendication 13 ou la revendication 14 caractérisé en ce qu'il comprend en outre des moyens pour générer une étape de test.

16. Dispositif selon la revendication 15 caractérisé en ce que lesdits 15 moyens pour générer une étape de test sont adaptés à générer une étape de test XPath ou une étape de test programmatique.

17. Dispositif selon la revendication 15 ou la revendication 16 caractérisé en ce qu'il comprend en outre des moyens pour générer une étape de localisation. 20

18. Dispositif selon la revendication 17 caractérisé en ce que lesdits moyens pour générer une étape de localisation sont adaptés à générer une étape de localisation XPath ou une étape de localisation programmatique.

19. Dispositif de sélection d'une version de définition pour un document de type XML parmi au moins deux versions de ladite définition selon 25 au moins une règle de prétraitement et au moins une règle de post-traitement, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens pour identifier un élérnent racine ; - moyens pour accéder à ladite au moins une règle de prétraitement et à ladite au moins une règle de post-traitement ; 30 - moyens pour appliquer ladite au moins une règle de prrétraitement ; - moyens pour traiter ledit document de type XML (640) ;moyens pour appliquer ladite au moins une règle de post-traitement ; -moyens pour sélectionner une version de définition parmi lesdites au moins deux versions de ladite définition selon le résultat de ladite application 5 de ladite au moins un règle de post-traitement.

20. Dispositif selon la revendication 19 caractérisé en ce qu'il comprend en outre les moyens suivants, - moyens pour évaluer des définitions de résultats possibles pour chacune desdites au moins deux versions de ladite définition ; et, 10 - moyens pour analyser lesdites définitions de résultats et pour déterminer si l'une desdites au moins deux versions de ladite définition est une restriction de l'autre desdites au moins deux versions de ladite définition.

21. Dispositif selon la revendication 20 caractérisé en ce qu'il comprend en outre des moyens pour sélection la version de ladite définition 15 selon un critère de probabilité.