FR2914758A1 - Procede et dispositif de modification d'une expression et procede et dispositif d'evaluation d'une expression - Google Patents

Abstract

L'invention est relative à un procédé de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce qu'au moins une sous-expression comprenant au moins une expression élémentaire ayant au moins un paramètre, le procédé comprend les étapes suivantes : détermination d'un premier type, le premier type étant le type d'un paramètre de ladite au moins une expression élémentaire ; détermination d'un second type, le second type étant associé au résultat de l'évaluation dudit paramètre de ladite au moins une expression élémentaire; détermination de la cohérence du premier type avec le second type en fonction de ladite au moins une expression élémentaire ; et modification de la sous-expression si incohérence du premier type avec le second type.

Description

La présente invention se rapporte à un procédé et un dispositif de 10

modification d'une expression, notamment d'une expression de type XPath et un procédé et un dispositif d'évaluation d'une telle expression. Elle trouve une application générale dans le traitement de flux de données en langage de balisage et plus précisément sur des fichiers au format XML. 15 Un document, selon l'invention, comprend une pluralité d'éléments structurant les données du document, ces éléments étant appelés noeuds selon la terminologie XML. Le langage XPath (acronyme de XML Path Language ) est issu d'une spécification du consortium W3C appelée Spécification XPath 1.0 , 20 présente à l'adresse www.w3.org/TR/xpath. Ce langage a pour objectif de définir une syntaxe adaptée à adresser des parties d'un document structuré de type XML. La syntaxe de ce langage utilise une syntaxe similaire à celle utilisée dans les expressions relatives à des chemins de localisation dans un système 25 de fichiers, par exemple l'expression de type chemin de localisation /librairie/livre . Le langage XPath définit quatre types de données qui sont chaîne , booléen , nombre et ensemble de noeuds , sept types de noeuds, aussi appelés éléments, et des expressions permettant de manipuler 30 les données, notamment les opérateurs définis égalité , différence , infériorité , supériorité , addition , soustraction , multiplication , division , modulo , ou binaire et et binaire . Quand aux noeuds, ils 1 peuvent représenter différents types d'évènement XML, par exemple le début du document (aussi appelé le noeud racine), un élément XML, un attribut, un texte, un commentaire, une instruction de traitement ( processing-instruction en terminologie anglo-saxonne) et un espace de nommage ( namespace en terminologie anglo-saxonne). Cette syntaxe permet l'expression de requêtes sur des documents structurés en vue, par exemple de leur transformation (par exemple la transformation XSLT selon la recommandation du W3C définie à l'adresse www.w3.org/TR/xslt), de l'accès rapide à des sous-parties (par exemple selon la recommandation du W3C: XPointer : www.w3.org/TR/WD- xptr) ou de la réalisation de traitements sur des parties du document (par exemple selon le langage XQuery 1.0, défini à l'adresse www.w3.org/TR/xquery). Le langage XPath permet de simplifier le développement d'applications aptes à parcourir des données dans des documents structurés de 15 type XML. L'entité apte à réaliser l'évaluation d'une expression XPath est appelée processeur XPath ( XPath Processor en terminologie anglo-saxonne). A partir d'une expression XPath et d'une référence à des données XML mémorisées dans un document ou reçues via une transmission réseau, le 20 processeur XPath évalue l'expression. La syntaxe XPath définit également une grammaire décrivant les règles de construction des différentes expressions et sous-expressions. Ces expressions sont notamment les expressions retournant un booléen (par exemple, les expressions OrExpr, AndExpr, RelativeExpr, EqualityExpr), les 25 expressions retournant un nombre (par exemple AdditiveExpr, MultiplicativeExpr), les expressions retournant n'importe quel type de données (par exemple, les expressions FilterExpr et FunctionCall), et les expressions retournant une liste ordonnée de noeuds (par exemple, les expressions LocationPath correspondant à la spécification d'un chemin à résoudre dans un 30 document XML). L'invention est particulièrement adaptée aux expressions de type chemin de localisation ( LocationPath selon la syntaxe du langage XPath).

Une expression de type chemin de localisation peut-être absolue ou relative selon qu'elle commence par / ou non. Dans le cas d'une expression de type chemin absolu, la recherche commence depuis le début du document, aussi appelé racine, alors que dans le cas d'une expression de type chemin relatif, la recherche est contextuelle, par exemple depuis le noeud courant. Toute expression de type chemin de localisation est composée d'un ensemble d'expressions indiquant les étapes de localisation dans ce chemin ( Steps en terminologie anglo-saxonne), et chaque étape de localisation correspondant à un niveau de décomposition pour l'évaluation de l'expression de type chemin de localisation. En effet, chaque étape de localisation peut être mise en correspondance avec un niveau de profondeur dans le document XML. Par exemple, l'expression relative au chemin /librairie/livre comprend deux étapes de localisation qui sont d'une part librairie , recherché à la profondeur 1 et d'autre part livre , recherché à la profondeur 2.

L'évaluation d'une étape de localisation se fait notamment en fonction de l'expression de l'étape parente de localisation, i.e. l'étape de localisation précédente dans l'expression. Le résultat de l'évaluation d'une étape de localisation fournit le contexte d'évaluation pour l'étape de localisation suivante. Ce contexte est composé de trois éléments : un noeud appelé noeud contexte , une position et une taille. Le noeud contexte est le noeud dans le document qui vérifie l'étape de localisation précédente, la position indique le rang du noeud solution de l'étape de localisation courante parmi ses frères, la taille du contexte indique le nombre de noeuds solution de l'étape de localisation courante.

Toute étape de localisation comprend une à trois entités parmi les entités suivantes. Tout d'abord, l'entité exprimant une filiation, aussi appelée axe, ( AxisSpecifier selon la syntaxe XPath) décrit la relation entre un noeud contexte et les noeuds solution d'une étape de localisation. Cette entité est optionnelle. Par défaut, cette entité prend la valeur enfant ( child selon la syntaxe XPath). Par exemple, les expressions /a/child ::b et /a/attribute ::b signifient que l'on recherche, respectivement, un noeud b fils d'un noeud a , le noeud a se trouvant à la racine du document et un noeud représentant un attribut b fils d'un noeud a , le noeud a étant également à la racine du document. La spécification définit 13 types d'entité exprimant une relation de filiation ( AxisSpecifier ) qui sont : self, child, attribute (ou @), namespace, descendant, descendant-or-self, following, following-sibling qui sont considérés comme des expressions de filiation descendante (forward axes en anglais) et parent, ancestor, ancestor-or-self, preceding et preceding-sibling qui sont considérés comme des expressions de filiation ascendante (backward ou reverse axes en anglais).

Ensuite, l'entité exprimant un test d'éligibilité d'un noeud candidat ( NodeTest selon la syntaxe XPath) définit soit une contrainte de type soit une contrainte de nom que les noeuds candidats doivent respecter pour être considérés comme solution d'une étape de localisation. Cette entité est obligatoire.

La syntaxe définit différents tests sur le type de noeuds, notamment, la contrainte de type noeud ( node() )) selon la syntaxe XPath), la contrainte de type texte ( tex ) selon la syntaxe XPath), la contrainte de type commentaire ( comment() )) selon la syntaxe XPath) et la contrainte de type instruction de traitement ( processing-instruction() )) selon la syntaxe XPath). Par exemple, l'expression /child::b impose une contrainte de nom alors que l'expression /descendant::comment() permet de rechercher tous les noeuds de type commentaire. Enfin, l'entité exprimant un prédicat ( Predicate selon la syntaxe XPath) permet d'imposer une ou plusieurs conditions supplémentaires pour la recherche de noeuds solution d'une étape de localisation. Cette entité est optionnelle. Une expression appelée prédicat , indiquée entre crochets, suit les mêmes règles de construction que toute expression XPath. Par exemple, l'expression /a/b[2] permet de sélectionner tous les deuxièmes éléments XML fils de nom b de chaque noeud de type élément XML de nom a , et l'expression /a/b[@id= 3 ] permet de sélectionner les fils de nom b du noeud de type élément XML de nom a possédant un attribut id ayant une valeur égale à 3. La spécification XPath définit en outre des règles de conversion de types lorsque ceux-ci sont impliqués en tant qu'opérande d'une expression de comparaison. II s'agit notamment des expressions d'égalité ( EqualityExpr selon la syntaxe XPath), des expressions de relation ( RelationalExpr selon la syntaxe XPath) ou des expressions d'addition ( AdditiveExpr selon la syntaxe XPath). Ces règles sont les suivantes. Tout d'abord, concernant la comparaison de deux noeuds issus de deux ensembles de noeuds, celle-ci doit être ramenée en une comparaison entre types simples. Ainsi l'opérateur d'égalité implique de convertir chaque noeud en chaîne de caractères, la comparaison s'effectuant sur la représentation en chaîne de chacun des noeuds. En revanche, un opérateur d'addition ou de comparaison à savoir, les expressions inférieur, supérieur, inférieur ou égal et supérieur ou égal, impose une conversion en nombre de chacun des noeuds. Selon le type de noeud, différents modes de conversion sont définis par la spécification XPath. Ensuite, concernant la comparaison d'un ensemble de noeuds avec un type simple, tel que vu précédemment, le noeud doit être converti soit en booléen si le type simple est de type booléen, soit en chaîne si le type simple est de type chaîne, soit en chaîne puis en nombre si le type simple est de type nombre. Enfin, concernant la comparaison entre types simples, celle-ci dépend de l'opérateur. Par exemple, les opérateurs de comparaison et 25 arithmétiques requièrent des conversions vers des nombres. La spécification XPath définit en outre des règles de conversion d'un noeud en chaîne. La conversion de type la plus complexe est sans nul doute le passage d'un noeud en sa représentation sous la forme de chaîne. Cette 30 conversion dépend du type de noeud. En effet, pour les noeuds de type attribut, texte et commentaire, il suffit de prendre la valeur du noeud. En revanche, pour les noeuds de type élément, la représentation en chaîne consiste en la concaténation de tous les noeuds texte se trouvant entre la balise ouvrante de l'élément concerné et sa balise fermante. La Figure 1 illustre quelques conversions de noeuds en chaîne. Ainsi, l'implémentation actuelle du langage XPath permet d'accéder à des parties d'un document XML après avoir construit une représentation intermédiaire du document XML apte à faciliter la recherche, notamment sous la forme d'un arbre représentant un modèle d'objets du document ( document Object Model ou DOM en terminologie anglo-saxonne défini à l'adresse www.w3.org/DOM). Ainsi la recherche consiste à parcourir cet arbre autant de fois que nécessaire pour l'extraction des noeuds demandés. Une telle approche pose un double problème. Cette solution s'avère coûteuse en espace mémoire notamment dans le cas de documents XML de grande taille. En effet, si un processeur XPath est implanté dans un appareil de type appareil photo, photocopieur ou autre, ayant des ressources limitées, la représentation intermédiaire peut être trop volumineuse pour être mémorisée. De plus, cette solution s'avère coûteuse en temps d'exécution du fait des parcours multiples sur l'arbre DOM lors de la recherche de noeuds solutions de l'expression XPath. Toutefois, si l'on considère la conversion d'un noeud élément en chaîne, celle-ci impose de disposer du contenu de l'élément dans sa globalité. Pour ce faire, il est nécessaire de réaliser du stockage en mémoire ou des parcours multiples. Par exemple si l'on cherche à évaluer l'expression suivante : //livre/titre = Les Miserables , cette expression doit rechercher un élément titre. Puis lorsqu'un tel élément est trouvé, il est nécessaire de déterminer sa représentation en chaîne afin d'effectuer la comparaison par rapport à la chaîne Les Miserables . Pour ce faire, l'ensemble des noeuds texte se trouvant sous l'élément titre est récupéré. II est connu de réaliser une réécriture des expressions XPath 30 notamment afin de traduire des axes vers l'arrière ( backward axes selon la syntaxe XPath) en axes vers l'avant ( forward axes selon la syntaxe XPath). 7

Par exemple, il est connu du document US 20040068487 intitulé Method for streaming XPath processing with forward and backward axes'; la réécriture des expressions de manière à éviter la vérification de relations entre un noeud courant et ses ascendants.

Cependant, cette méthode ne permet pas d'effectuer une conversion de noeuds vers un type chaîne car elle adresse uniquement des expressions de type chemin de localisation ( LocationPath en terminologie anglo-saxonne). En outre, il est connu du document US20050257201 intitulé Optimisation of XPath expressions for evaluation upon streaming XML data , de reformuler les expressions XPath en expressions équivalentes dans un langage XPath réduit et ce en vue de leur évaluation à la volée. Ce langage XPath réduit est composé d'un sous ensemble de spécifications telles que XQuery ou encore XPath 2.0. Toutefois, selon cette méthode, les expressions produites ne sont plus conformes à la spécification XPath 1.0. De plus, cette méthode n'adresse pas le problème de conversion de types. Compte tenu de ce qui précède, il serait par conséquent intéressant de pouvoir fournir un moyen de rendre l'expression XPath explicite afin que le processeur, notamment le processeur XPath, obtienne les informations nécessaires pour calculer le résultat au plus tôt, de manière à garantir l'évaluation à la volée de l'expression XPath et en s'affranchissant d'au moins certains des inconvénients mentionnés ci-dessus. La présente invention vise en premier lieu à fournir un procédé de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce qu'au moins une sous-expression comprenant au moins une expression élémentaire ayant au moins un paramètre, le procédé comprend les étapes suivantes : - détermination d'un premier type, le premier type étant le type d'un paramètre de ladite au moins une expression élémentaire ; 8

détermination d'un second type, le second type étant associé au résultat de l'évaluation dudit paramètre de ladite au moins une expression élémentaire ; détermination de la cohérence du premier type avec le second type en fonction de ladite au moins une expression élémentaire ; et -modification de la sous-expression si incohérence du premier type avec le second type. L'invention fournit un moyen de modifier des expressions, notamment des expressions XPath en vue d'évaluer ces expressions à la volée, 10 notamment par un parcours unique du document structuré. Pour ce faire, une analyse des expressions élémentaires et des opérandes de ces expressions élémentaires est réalisée afin d'expliciter le cas échéant l'expression. Cette analyse est basée sur la détermination pour un opérande d'une expression élémentaire de son type, notamment au moyen de 15 la grammaire de ces expressions et sur la détermination du type associé au résultat de l'évaluation. De plus, la modification de l'expression est réalisée préalablement à l'évaluation et est réutilisable lors de multiples évaluations, éventuellement par des processeurs différents. 20 En outre, du point de vue de l'utilisateur, aucun changement d'habitude n'est à opérer puisque le procédé de modification prend en charge d'expliciter les expressions et de réaliser la conversion des types des opérandes si nécessaire. Selon une caractéristique particulière, ledit au moins un paramètre 25 comprend au moins un paramètre implicite. Selon une autre caractéristique particulière, la sous-expression comprenant un ensemble d'étapes de localisation, le procédé comprend une étape de détermination d'au moins une étape de localisation implicite dans l'ensemble des étapes de localisation, et l'étape de modification de la sous- 30 expression comprend une étape d'ajout d'au moins une nouvelle étape de localisation à l'ensemble des étapes de localisation représentant ladite au moins une étape de localisation déterminée.

Selon cette caractéristique, une analyse des expressions et des opérandes de ces expressions est réalisée afin d'expliciter le cas échéant toutes les étapes de localisation nécessaires à la résolution de ces expressions. Selon un mode de réalisation, ladite au moins une nouvelle étape de localisation comprend une relation de filiation directe déterminée à partir d'information structurelle du document structuré. Selon un autre mode de réalisation, l'étape de modification comprend une étape d'insertion d'au moins une sous-expression intermédiaire. Selon encore un autre mode de réalisation, ladite au moins une sous-expression intermédiaire comprend au moins une fonction de conversion. Selon une caractéristique particulière, ladite au moins une expression élémentaire est au moins une expression élémentaire prédéterminée. L'expression élémentaire prédéterminée est notamment une expression de type relation, une expression de type appel de fonction, une expression de type égalité, une expression de type addition, une expression de type multiplication, une expression de type unaire. II s'agit par exemple des différents types d'expressions telles que les expressions égalité , relation , addition , multiplication et division définies par la grammaire XPath. La présente invention a également pour but de fournir un procédé d'évaluation d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce que le procédé comprend les étapes suivantes : - une étape de modification d'une expression selon le procédé de modification conforme à l'invention, et - une étape d'évaluation de la dite expression modifiée. L'invention fournit un moyen d'évaluer des expressions, notamment des expressions XPath, à la volée.

Pour ce faire, une étape de modification de l'expression conformément à l'invention est réalisée afin de rendre l'évaluation efficace, notamment par un parcours unique du document structuré. 10

Corrélativement, l'invention vise également un dispositif de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce qu'au moins une sous-expression comprenant au moins une expression élémentaire ayant au moins un paramètre, le dispositif comprend les moyens suivants : des moyens de détermination d'un premier type, le premier type étant le type d'un paramètre de ladite au moins une expression élémentaire ; des moyens de détermination d'un second type, le second type étant associé au résultat de l'évaluation dudit paramètre de ladite au moins une expression élémentaire ; des moyens de détermination de la cohérence du premier type avec le second type en fonction de ladite au moins une expression élémentaire ; et - des moyens de modification de la sous-expression si incohérence du premier type avec le second type. Ce dispositif présente les mêmes avantages que le procédé de modification brièvement décrit ci-dessus. La présente invention a également pour but de fournir un dispositif d'évaluation d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce que le dispositif comprend les moyens suivants : - des moyens de modification d'une expression selon le dispositif de modification conforme à l'invention, et - des moyens d'évaluation de la dite expression modifiée. Ce dispositif présente les mêmes avantages que le procédé d'évaluation brièvement décrit ci-dessus. La présente invention vise aussi un moyen de stockage, éventuellement amovible partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme d'ordinateur, permettant la mise en oeuvre des procédés tels qu'exposés ci-dessus. 11

La présente invention vise enfin un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, comportant des séquences d'instructions pour mettre en oeuvre les procédés tels qu'exposés ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil 5 programmable. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, dans lesquels : 10 - la figure 1 représente un exemple d'un document XML sur lequel des exemples de conversion sont illustrés ; - la figure 2 illustre le contexte applicatif de l'invention ; - la figure 3 représente de manière schématique un appareil dans lequel est mise en oeuvre l'invention ; 15 - la figure 4 illustre un algorithme de d'évaluation d'une expression XPath conforme à l'invention ; - la figure 5 illustre un algorithme d'analyse grammaticale de l'expression XPath conformément à l'invention détaillant l'étape E44 de la figure 4 ; 20 - la figure 6 illustre un exemple de décomposition d'une expression XPath en un ensemble de sous-expressions ; - la figure 7 illustre un algorithme de vérification des types selon la conformation détaillant l'étape E56 de la figure 5 ; - la figure 8 représente un algorithme de réécriture d'une sous-25 expression selon l'invention ; - la figure 9 illustre un exemple de représentation interne d'expression réécrite conformément à l'invention ; et - la figure 10 illustre un algorithme d'évaluation d'une expression XPath selon l'invention. 30 L'invention permet, au moyen d'une analyse de l'expression, notamment d'une expression XPath, de détecter de potentielles conversions de 12

type nécessaires à l'évaluation de cette expression. Dans le cas où des conversions de type sont nécessaires, celles-ci sont identifiées afin de rendre explicite l'expression pour qu'un processeur XPath supportant l'évaluation à la volée puisse également évaluer à la volée tout type d'expressions y compris, les expressions de type égalité ( EqualityExpr selon la syntaxe XPath), des expressions de type relation ( RelationalExpr selon la syntaxe XPath), des expressions de type fonction ( FunctionCal! selon la syntaxe XPath) des expressions de type addition ( AdditiveExpr selon la syntaxe XPath), des expressions de type multiplication ( MultiplicativeExpr selon la syntaxe XPath) ou des expressions de type unaire ( UnaryExpr selon la syntaxe XPath). Il est à noter que la conversion modifie l'expression, toutefois, l'expression reste compatible, notamment avec la syntaxe XPath 1.0. De la sorte, l'expression modifiée est toujours utilisable quel que soit le processeur XPath 1.0. Aussi, le procédé de l'invention peut-être considéré comme un préprocesseur d'expressions en vue de leur simplification. En outre, le traitement conforme à l'invention peut-être réalisé une fois et utilisé pour plusieurs évaluations sur différents documents.

La Figure 2 illustre le contexte applicatif de l'invention dans lequel une application 1 traite des données, notamment des données XML, extraites par un processeur XPath 2 au moyen d'un ou plusieurs analyseurs XML 3 à partir d'un flux de données XML 4, un analyseur XML pouvant être un navigateur XML.

Selon un mode de réalisation, le processeur XPath 2 comprend trois entités. Tout d'abord, il comprend un compilateur 21 ayant pour rôle d'analyser les expressions et de les traduire en une représentation interne. Le fonctionnement de ce compilateur est décrit ci-après en référence à la Figure 4.

Le compilateur 21 est composé, notamment de deux analyseurs : un analyseur lexical 211 et un analyseur sémantique 212.

Ensuite, le processeur XPath comprend une unité de contrôle d'exécution 22 apte à gérer, d'une part, les interactions entre les différents modules du processeur XPath et, d'autre part, la communication du processeur XPath avec l'application 1. De plus, il prend en charge l'évaluation des noeuds.

En outre, le processeur XPath comprend un ou plusieurs navigateurs XPath 23 qui permettent à l'unité de contrôle d'exécution 22 de piloter de façon générique un ou plusieurs analyseurs XML 3. Les navigateurs XPath 23 sont également aptes à représenter les évènements XML reçus des analyseurs XML 3 sous la forme de noeuds XPath. Les navigateurs XPath 23 possèdent une mémoire tampon destinée si-besoin à stocker des noeuds XPath. Les analyseurs XML sont responsables de l'extraction d'informations XML à partir du flux ou d'un document 4 et de leur émission vers le processeur XPath 2. L'évaluation d'une expression XPath est notamment décrite ci-après en référence aux Figures 4 et 5, et comprend une phase d'analyse en vue de la compilation mise en oeuvre par exemple par le compilateur 21 et une phase d'évaluation en vue de l'extraction des noeuds selon le mode d'évaluation choisi mise en oeuvre par exemple par l'unité de contrôle d'exécution 22. Ainsi, l'invention est mise en oeuvre notamment dans le ou les processeurs XPath.

En référence à la figure 3, un dispositif apte à fonctionner en tant que dispositif de modification d'une expression apte à être évaluée et / ou dispositif d'évaluation d'une telle expression sur des éléments d'un document structuré, notamment d'une expression XPath, est maintenant décrit dans sa configuration matérielle.

Le dispositif de la figure 3 possède l'ensemble des moyens nécessaires à la mise en oeuvre du procédé de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, notamment d'une expression XPath selon l'invention. Selon le mode de réalisation choisi, ce dispositif peut être par exemple un micro-ordinateur 300 connecté à différents périphériques, par exemple, une caméra numérique 301 (ou un scanner, ou tout autre moyen d'acquisition ou de stockage d'image) reliée à une carte graphique.

Le micro-ordinateur 300 comporte de préférence une interface de communication 302 reliée à un réseau 303 apte à transmettre des informations numériques. Le micro-ordinateur 300 comporte également un moyen de stockage 304, tel que par exemple un disque dur, ainsi qu'un lecteur de disquette 305.

La disquette 306 comme le disque 304 peuvent contenir des données XML selon l'invention ainsi que le code de l'invention qui, une fois lu par le micro-ordinateur 300, sera stocké dans le disque dur 304. Selon une variante, le ou les programmes permettant au dispositif 300 de mettre en oeuvre l'invention sont stockés dans une mémoire morte ROM 307.

Selon une autre variante, le ou les programmes sont reçus totalement ou partiellement à travers le réseau de communication 303 pour être stockés comme indiqué. Le micro-ordinateur 300 peut également être relié à un microphone 308 par l'intermédiaire d'une carte d'entrée/sortie 314. Le micro-ordinateur 300 comprend également un écran 309 notamment pour permettre à l'utilisateur de visualiser les résultats des évaluations. A l'aide du clavier 310 ou de tout autre moyen approprié, l'utilisateur peut spécifier une expression XPath. L'unité centrale CPU 311 exécute les instructions relatives à la mise en oeuvre de l'invention, ces instructions étant stockées dans la mémoire morte ROM 20 307 ou dans les autres éléments de stockage décrits. Lors de la mise sous tension, les programmes et procédés modification d'une expression et d'évaluation d'une telle expression, notamment d'une expression XPath, stockés dans une desmémoires non-volatiles, par exemple la ROM 307, sont transférés dans la mémoire vive RAM 312 qui 25 contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. En variante, les procédés peuvent être stockés dans différents emplacements de stockage du dispositif 300. De manière générale, un moyen de stockage d'information lisible par un ordinateur ou par un microprocesseur, 30 intégré ou non au dispositif, éventuellement amovible, mémorise un programme dont l'exécution met en oeuvre les procédés de modification d'une expression et d'évaluation d'une telle expression. II est aussi possible de faire évoluer le mode de réalisation de l'invention, par exemple, en ajoutant des méthodes de modification actualisées ou améliorées qui sont transmises par le réseau de communication 303 ou chargées par l'intermédiaire d'une ou de plusieurs disquettes 306. Bien entendu, les disquettes 306 peuvent être remplacées par tout support d'information tel que CD-ROM ou carte mémoire. Un bus de communication 313 permet la communication entre les différents éléments du micro-ordinateur 300 et les éléments reliés à celui-ci. On notera que la représentation du bus 313 n'est pas limitative. En effet, l'unité centrale CPU 311 est, par exemple, susceptible de communiquer des instructions à tout élément du micro-ordinateur 300, directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 300. Il est maintenant décrit en référence à la Figure 4, des étapes de l'évaluation d'une expression XPath, conformément à l'invention. L'expression XPath à évaluer est, par exemple spécifiée par un utilisateur ou pré-stockée dans un fichier lu par l'application ou encore elle résulte de l'exécution au niveau de l'application d'un programme générant des requêtes XPath. Cette expression est reçue, à l'étape E41, par le processeur XPath 2. Ensuite, l'étape suivante (étape E42) consiste à démarrer l'analyse lexicale. Pour ce faire, les caractères de l'expression XPath sont analysés les uns après les autres et sont regroupés en symboles ( tokens en terminologie anglo-saxonne). Ces symboles peuvent représenter des symboles réservés, par exemple des symboles propres à la spécification, notamment comme le caractère / , le symbole :: , ... ou bien des digits ou des caractères simples. Cette étape est réalisée notamment par l'analyseur lexical 211. Celui-ci dispose d'une table de symboles prédéfinis en fonction de la grammaire XPath 1.0 pour réaliser cette analyse.

Suite à la décomposition de l'expression en un ensemble de symboles à l'étape E42, l'étape suivante (étape E43) consiste à tester les symboles générés. 16

Si au cours de cette étape, on détecte qu'un des symboles est analysé comme non permis ou inconnu par l'analyseur lexical, alors l'étape E43 est suivie de l'étape E47 au cours de laquelle le compilateur 21 arrête l'évaluation de l'expression et informe le processeur XPath 22 de la non-conformité de l'expression. Cette expression ne peut donc pas être évaluée. Selon une variante de réalisation, le symbole non reconnu est ignoré et l'analyse de l'expression se poursuit. Dans le cas inverse, c'est-à-dire si lors de l'étape de test (étape E43), le résultat du test indique que l'ensemble des symboles est considéré comme valide par l'analyseur lexical, alors l'algorithme se poursuit à l'étape E44 par l'analyse grammaticale. L'étape E44 consiste pour l'analyseur sémantique 212 à parcourir la liste de symboles générés lors de l'étape E42 et à identifier les types d'expression définis par la syntaxe XPath 1.0 qui sont contenus dans l'expression à compiler. La syntaxe XPath 1.0 est décrite en Annexe A. L'annexe A illustre quelques exemples, en gras, de sous-expressions nécessitant l'étape d'analyse E56 de la figure 5. Au cours de cette étape E44, l'expression est également analysée afin de détecter si une réécriture est nécessaire. Cette étape est décrite plus en 20 détail ci-après en référence à la figure 8. Par exemple, si le premier symbole trouvé dans l'expression correspond au symbole / , alors cette expression correspond à un chemin absolu ( AbsoluteLocationPath selon la syntaxe XPath). Dans ce cas, le compilateur 21 poursuit l'analyse des symboles pour 25 identifier les composantes de ce chemin absolu, c'est-à-dire les chemins de localisation ( Steps selon la syntaxe XPath), eux-mêmes composés d'axes ( AxisSpecifier selon la syntaxe XPath), de tests d'éligibilité d'un noeud candidat ( NodeTest selon la syntaxe XPath) et éventuellement de prédicats ( Predicate selon la syntaxe XPath). 30 En outre, tel que mentionné en Annexe A, lorsque le type de résultat est marqué comme indéterminé , le contexte permet de lever l'ambiguïté. 17

Par exemple, si un argument d'une expression de type appel de fonction est de type chemin de localisation, alors le type de retour est un ensemble de noeuds. De même, le type de retour d'une expression de type appel de 5 fonction dépend de la fonction appelée. Toutefois, à l'étape E44, lors du calcul du type du résultat d'une sous expression de type appel de fonction, le compilateur 21 a connaissance du nom de la fonction et donc de son type de retour. L'étape E44 est suivie de l'étape E45 consistant à tester si 10 l'expression construite à partir de la suite de symboles est valide, notamment au sens de la grammaire XPath. Si le test est positif, alors l'expression a été compilée avec succès et l'algorithme se poursuit à l'étape E46 consistant à évaluer cette expression. Dans le cas contraire, l'étape E45 est suivie de l'étape E47 au cours 15 de laquelle un signal d'erreur est émis par le compilateur 21 afin d'informer le processeur XPath que l'expression ne peut être évaluée. Il est maintenant décrit, en référence à la Figure 5, un algorithme d'analyse d'une expression XPath conformément à l'invention et détaillant l'étape E44 de la figure 4. 20 Selon cet algorithme d'analyse, l'expression XPath à évaluer est décomposée en un ensemble de sous-expressions élémentaires conformément à la grammaire XPath illustrée en Annexe A. Un exemple d'une telle décomposition est illustré en figure 6. La décomposition de l'expression consiste à parcourir l'expression 25 principale et à relier les différentes sous-expressions entre elles selon une relation parent-enfants. Ainsi, l'algorithme débute à l'étape E50 au cours de laquelle le compilateur 21 identifie la première sous-expression de l'expression XPath à évaluer. 30 L'étape E50 est suivie de l'étape E51 au cours de laquelle on vérifie si une sous-expression correspondante à la grammaire du langage a été identifiée dans l'expression courante.

Par exemple, si la première sous-expression correspond à l'opérateur = , cette sous-expression est une expression d'égalité ( EqualityExpr selon la syntaxe XPath) du langage XPath tel qu'illustré par la grammaire de XPath en Annexe A.

Si tel n'est pas le cas, alors l'étape E51 est suivie de l'étape E54 décrite ci-après. Au contraire, si la sous-expression est une expression du langage alors l'étape E51 est suivie de l'étape E52 au cours de laquelle on sauvegarde cette sous-expression.

Ensuite, lors de l'étape suivante (étape E53) la sous-expression identifiée devient l'expression courante. L'étape E53 est suivie de l'étape E50 afin que l'expression courante soit à nouveau analysée. En effet, la sous-expression, devenue l'expression courante, peut elle-même être composée de sous-expressions qu'il convient d'analyser. De retour à l'étape E51, si le test est négatif, cela signifie qu'aucune sous expression n'a pu être extraite de l'expression courante, alors la sous-expression est une expression élémentaire. Dans ce cas, l'étape E51 est suivie de l'étape E54 au cours de laquelle le compilateur 21 construit une structure de représentation. Lors de cette même étape, il est également calculé le type de résultat attendu pour cette expression élémentaire. En outre, ce type de résultat est mémorisé dans la structure de représentation. Le type du résultat se déduit de la grammaire de l'expression et notamment de la grammaire XPath donnée en Annexe A. L'étape E54 est suivie de l'étape E55 au cours de laquelle le compilateur vérifie, notamment, si l'expression élémentaire est une expression de comparaison ou un appel de fonction. Si tel est le cas, l'étape E55 est suivie de l'étape E56 consistant à 30 vérifier la concordance de types soit entre les opérandes de la comparaison, soit entre les paramètres de la fonction. 19

Cette vérification des types des opérandes ou des paramètres est décrite ci-après en référence à la figure 7. L'étape E56 est suivie de l'étape E57. Si, à l'étape E55, la vérification est négative, alors l'algorithme se poursuit à l'étape E57 au cours de laquelle le compilateur récupère la sous-expression parente de l'expression courante. L'étape E57 est suivie de l'étape E58 au cours de laquelle il est vérifié si une sous-expression parente existe. Si tel n'est pas le cas, alors il est mis fin à l'algorithme.

Au contraire, si l'expression parente existe, l'étape E58 est suivie de l'étape E59 au cours de laquelle l'expression parente devient l'expression courante. L'étape E59 est suivie de l'étape E50. En effet, les étapes E50 à E59 sont de nouveau appliquées sur l'expression parente. L'algorithme est itéré jusqu'à ce que le test de l'étape E58 indique que l'expression principale a été atteinte, c'est-à-dire qu'il n'y a pas d'expression parente. Il est maintenant décrit en référence à la Figure 7 un algorithme de vérification des types soit entre les opérandes de la comparaison, soit entre les paramètres de la fonction conformément à l'invention, détaillant l'étape E56 de la Figure 5. Cet algorithme de vérification des types de résultats effectue la vérification de la cohérence entre un type de résultat attendu au niveau d'un opérande ou au niveau d'un paramètre et un type de résultat issu de l'évaluation d'une sous-expression. Pour ce faire, il comprend principalement deux phases. En effet, dans un premier temps, il est calculé le type de résultat produit par la ou les sous-expressions. Et dans un second temps, en fonction de l'opérateur ou de la fonction appelée, le compilateur identifie le type dans lequel éventuellement convertir les opérandes ou le paramètre. Cette conversion peut parfois entraîner une réécriture de l'expression. Pour cette raison, il est détecté, par le compilateur, les cas dans lesquels une réécriture de 20

l'expression est nécessaire et la réécriture est activée (tel que décrit ci-après en en référence à la figure 8). Un algorithme de vérification des opérandes ou des paramètres, illustré en Figure 7 conformément à l'invention, commence par l'obtention de la 5 sous-expression courante (étape E701). L'étape suivante (étape E702) consiste à tester si cette sous-expression est une expression de comparaison. Cette étape est réalisée notamment par le compilateur. Dans la négative, l'algorithme de poursuit à l'étape E713 décrite ci-10 après. Si cette sous-expression est une expression de comparaison, alors l'étape E702 est suivie de l'étape E703 au cours de laquelle l'opérateur de comparaison est obtenu, notamment par le compilateur. L'opérateur de comparaison est obtenu à partir de la liste de 15 symboles générés lors de l'étape E42 de la Figure 4 par l'analyseur lexical. L'étape E703 est suivie de l'étape E704 consistant à tester si cet opérateur est un opérateur de comparaison de type booléen. Par exemple, il est testé si cet opérateur est l'opérateur ou ( or selon la syntaxe XPath), ou et ( and selon la syntaxe XPath). 20 Si le test est positif, alors il est mis fin à l'algorithme. Dans ce cas, la sous expression, expression de comparaison, n'a pas besoin d'être modifiée. En effet, la conversion de n'importe quel type vers un booléen est évidente. Et, si le test est négatif, alors l'étape E704 est suivie de l'étape E705 au cours de laquelle le type de résultat pour l'opérande gauche, calculé lors de 25 l'étape E54 de la figure 5, est obtenu. Cette obtention est notamment réalisée par le compilateur. L'étape E705 est suivie de l'étape E706 consistant à tester si le type de résultat pour l'opérande gauche est un booléen. Si le test est positif, alors il est mis fin à l'algorithme. En effet, dans 30 ce cas, la conversion des résultats des opérandes en types booléens est évidente.

Et, si le test est négatif, alors l'étape E706 est suivie de l'étape E707 au cours de laquelle le type de résultat pour l'opérande droite est obtenu. L'étape E707 est suivie de l'étape E708 consistant à tester si le type de résultat pour l'opérande droite est un booléen.

Si le test est positif, alors il est mis fin à l'algorithme. En effet, le résultat de l'opérande de droite doit être converti en booléen, ce qui ne présente aucune difficulté. Et, si le test de l'étape E708 est négatif, alors l'étape E708 est suivie de l'étape E709 au cours de laquelle on teste si le type de résultat pour l'opérande de gauche est de type ensemble de noeuds . Ce test est réalisé notamment par le compilateur. Si le test est négatif, l'algorithme se poursuit à l'étape E711 décrite ci-après. Toutefois, si le test est positif, c'est-à-dire si le type de résultat pour 15 l'opérande de gauche est de type ensemble de noeuds , alors l'étape E709 est suivie de l'étape E710, étape au cours de laquelle l'opérande de gauche peut nécessiter une réécriture. L'étape E710 sera détaillée ci-après en référence à la Figure 8. L'étape E710 est suivie de l'étape E711 au cours de laquelle on teste 20 si le type de résultat pour l'opérande de droite est de type ensemble de noeuds . Si le test est négatif, alors il est mis fin à l'algorithme Toutefois, si le test est positif, c'est-à-dire si le type de l'opérande de droite est de type ensemble de noeuds , alors l'étape E709 est suivie de 25 l'étape E712, étape au cours de laquelle l'opérande de droite peut nécessiter une réécriture. Cette étape sera détaillée ci-après en référence à la Figure 8. A l'issue de l'étape E712, il est mis fin à l'algorithme. De retour à l'étape E702, dans le cas négatif, c'est-à-dire lorsque la 30 sous-expression n'est pas un opérateur de comparaison, l'algorithme se poursuit à l'étape E713. 22

Dans ce cas, la sous-expression correspond alors à un paramètre d'un appel de fonction. Au cours de l'étape E713, le nom de la fonction appelée est obtenu, notamment par le compilateur 21. Le nom est obtenu à partir de la liste des 5 symboles générés lors de l'étape E54 de la Figure 5. Selon un mode de réalisation, il s'agit du dernier symbole correspondant à un nom de fonction. L'étape E713 est suivie de l'étape E714 au cours de laquelle on identifie l'indice du paramètre correspondant à la sous-expression parmi la liste 10 de paramètres demandés par la fonction. Pour ce faire et selon un mode de réalisation, l'analyseur sémantique 212 maintient un indice initialisé à zéro dès qu'il rencontre un appel de fonction. Cet indice est incrémenté dès qu'une sous- expression fille de l'appel de fonction est détectée, notamment à l'étape E50 de la figure 5. 15 L'étape E714 est suivie de l'étape E715 au cours de laquelle, à partir du nom de la fonction et de l'indice du paramètre, l'analyseur sémantique 212 est en mesure de déterminer le type attendu pour ce paramètre. Ensuite, lors de l'étape suivante (étape E716), le type de résultat attendu pour l'évaluation de cette sous-expression est déterminé en fonction, 20 par exemple, de la construction de la sous-expression. Ainsi, par exemple, si la sous-expression représentant le paramètre est de type chemin de localisation ( LocationPath selon la syntaxe du langage XPath), le type attendu pour le résultat d'évaluation est un ensemble de noeuds . 25 Cette étape est réalisée notamment par l'analyseur sémantique 212. L'étape E716 est suivie de l'étape E717 consistant à tester si le type de résultat attendu pour l'évaluation de cette sous-expression est de type ensemble de noeuds . Si le test est négatif, il est mis fin à l'algorithme. 30 Sinon, c'est-à-dire si le type de résultat attendu pour l'évaluation de cette sous-expression est de type ensemble de noeuds , alors l'étape E717 23

est suivie de l'étape E718 au cours de laquelle on teste si le type attendu pour le paramètre de la fonction est un booléen. Si le test est positif, il est mis fin à l'algorithme. Aucune réécriture n'est nécessaire puisque la conversion du résultat de la sous-expression vers le type booléen ne nécessitera aucune information XML supplémentaire. Sinon, l'étape E718 est suivie de l'étape E719, au cours de laquelle la sous-expression est réécrite. Cette étape sera détaillée ci-après en référence à la Figure 8. A l'issue de l'étape E719, il est mis fin à l'algorithme.

Il est maintenant décrit, en référence à la Figure 8, un algorithme conforme à l'invention pour la réécriture d'une sous expression. La réécriture d'une sous expression intervient lorsque l'analyseur sémantique a détecté par exemple que la sous-expression retourne un ensemble de noeuds alors que le type attendu est chaîne ou nombre . Selon un mode de réalisation particulier, une analyse plus fine est réalisée afin de déterminer si la réécriture doit réellement être effectuée. En effet, dans tous les cas, une conversion doit être activée lors de l'évaluation mais dans certains cas, celle-ci ne nécessite pas d'information XML autre que celle apparaissant dans la sous-expression. C'est par exemple le cas lorsque la sous-expression retourne un ensemble de noeuds de type texte , attribut , espace de nommage ( namespace en terminologie anglo-saxonne), instruction de traitement ( processing-instruction en terminologie anglo-saxonne) ou commentaire .

Il en est autrement lorsque la sous-expression est susceptible de retourner soit des noeuds de type élément , racine ou indéterminé (NodeTest=node()). Ce processus d'analyse ainsi que la réécriture éventuelle qui s'ensuit sont maintenant décrits en référence à la figure 8.

Un algorithme de réécriture d'une sous-expression conforme à l'invention, illustré en Figure 8, débute à l'étape E800 consistant à obtenir la sous-expression de type chemin ( PathExpr selon la syntaxe XPath) composant la sous-expression à analyser. Cette étape est notamment réalisée par l'analyseur sémantique 212. Si la sous-expression obtenue à l'étape E800 a comme type de résultat attendu un ensemble de noeuds, elle comprend soit une sous- expression de type chemin de localisation ( LocationPath selon la syntaxe XPath), soit une sous expression primaire retournant un ensemble de noeuds ( PrimaryExpr selon la syntaxe XPath) tel que, par exemple, un appel à la fonction nommée id() , ou variable qui fait référence à un ensemble de noeuds ( VariableReference selon la syntaxe XPath) ou d'une combinaison de ces différents types, notamment dans l'expression d'un chemin de localisation relatif ( RelativeLocationPath selon la syntaxe XPath). L'étape E800 est suivie de l'étape E801 consistant à obtenir la sous-expression de type chemin de localisation ( LocationPath selon la syntaxe XPath) éventuellement présente dans la sous-expression de type chemin ( PathExpr selon la syntaxe XPath). Dans le cas d'une expression primaire ( PrimaryExpr selon la syntaxe XPath), et plus particulièrement d'un appel à la fonction id() , l'étape E801 consiste à obtenir l'éventuel chemin de localisation passé en paramètre de cette fonction. Si un tel chemin est obtenu, il est utilisé comme base d'une réécriture préalable de la sous-expression primaire en sous expression de type chemin de localisation. Sinon, la sous-expression de type chemin de localisation sera //*[@id= argument ] où argument , est le paramètre passé à la fonction id(). Le test de l'étape E802 consiste à vérifier si un type chemin de localisation a pu être extrait lors de l'étape E801. Dans le cas d'un type variable qui fait référence à un ensemble de noeuds, ce test retourne faux et l'on passe à l'étape E812. Dans le cas contraire, c'est-à-dire si le test est positif, alors l'analyseur sémantique est positionné au début du chemin de la sous expression courante. Ainsi l'étape E802 est suivie de l'étape E803 consistant à obtenir la première étape du chemin de localisation ( Step selon la syntaxe XPath). 25

L'étape E803 est suivie de l'étape E804 consistant à obtenir l'étape suivante dans le chemin de localisation. Ensuite, l'étape E805 teste si l'étape suivante existe. Si le test est positif, alors l'étape E805 est suivie de l'étape E804.

Toutefois, si le test est négatif, alors l'étape E805 est suivie de l'étape E806. Ainsi, les étapes E804 et E805 consistent à parcourir une à une les étapes du chemin de localisation jusqu'à atteindre la dernière étape. Lorsque la dernière étape est atteinte (le test de l'étape E805 est négatif), alors, lors de l'étape E806, la valeur de l'axe liée à l'étape est obtenue. Cette étape est réalisée notamment par l'analyseur sémantique. L'étape E806 est suivie de l'étape E807 au cours de laquelle on teste la valeur obtenue de l'axe. S'il s'agit d'un axe de type attribut ou de type espace de nommage , alors la réécriture est inutile car la transformation de noeuds de type attribut ou espace de nommage est immédiate. Ainsi il est mis fin à l'algorithme. Si, au contraire, la valeur de l'axe n'est pas de type attribut ou de type espace de nommage , alors l'étape E807 est suivie de l'étape E808 consistant à obtenir le test du noeud de l'étape. Cette étape est notamment réalisée par l'analyseur sémantique. Ensuite, l'étape E808 est suivie de l'étape E809 au cours de laquelle on effectue un test de noeud. Ce test consiste à comparer la valeur du test du noeud de l'étape avec la valeur test de type .

Selon un mode de réalisation particulier, la valeur du test du noeud de l'étape est comparée avec la valeur noeud ( node() selon la syntaxe XPath). Si ce test est positif, c'est-à-dire que la valeur du test du noeud de l'étape a la valeur test de type et qu'il ne s'agit pas de la valeur noeud alors il est mis fin à l'algorithme. En effet, la réécriture de la sous-expression n'est pas nécessaire car les noeuds solution de la sous-expression courante sont d'un type aisé à convertir en chaîne de caractères.

Au contraire, si le test est négatif c'est-à-dire que la valeur du test du noeud de l'étape a la valeur test de type ou que sa valeur est égale à noeud alors l'algorithme se poursuit à l'étape E810 consistant à tester la valeur de l'axe courant avec la valeur self .

Cette étape permet de déterminer le type de noeud retourné par la sous-expression. Si le test est positif, alors l'algorithme se poursuit à l'étape E811 au cours de laquelle l'étape parente du chemin est obtenue. Puis cette étape est suivie de l'étape E806 précédemment décrite.

En effet, il est appliqué, sur cette étape, les deux tests des étapes E809 et E810 afin de déterminer le type de noeuds attendus pour le chemin de localisation dont sont issues les étapes de localisation. Dès lors qu'une des étapes parentes du chemin de localisation permet de lever l'ambiguïté sur le type de noeud attendu, alors les étapes E807 à E810 sont suivies de l'étape E812. Lorsque l'algorithme passe par l'étape E812, les noeuds retournés par la sous-expression sont de type élément . Et au cours de cette étape E812, il est rendu explicite la sous-expression courante en termes d'informations XML à extraire du document.

Pour ce faire, il est créé, notamment par le compilateur 21, une nouvelle étape avec une valeur d'axe égale à descendant et un test de noeud de type texte . Si le compilateur 21 dispose d'informations, notamment d'informations de type XML Schema, sur l'élément courant, alors la valeur de l'axe peut-être la valeur enfant ( child selon la syntaxe XPath) de sorte à simplifier l'évaluation de l'expression. Toutefois, pour pouvoir effectuer le remplacement de la valeur descendant par la valeur enfant , il faut que le schéma du document indique que l'élément courant n'est composé que d'un seul noeud texte, non pas de noeuds éléments fils. 27

Cette nouvelle étape du chemin de localisation permet d'indiquer l'ensemble des noeuds texte à extraire à partir d'un élément courant, ces noeuds étant des noeuds solution de la sous-expression d'origine. L'étape suivante (étape E813) consiste, notamment pour le 5 compilateur 21, à créer une nouvelle sous-expression de type appel de fonction ( FunctionCall selon la syntaxe XPath). En effet, afin de rendre explicite la conversion de l'ensemble de noeuds vers une chaîne ou un nombre, l'appel explicite à la fonction de conversion est généré via cette nouvelle sous-expression. 10 De plus, cette étape permet de distinguer l'appel à la fonction chaîne de caractère ( string selon la syntaxe XPath) de la spécification de l'appel à une fonction valeur de la chaîne de caractère ( string-value ) non définie par la spécification et qui prend en charge le calcul de la représentation en chaîne d'un noeud. 15 Par exemple, au cours de l'étape E813, les expressions présentes dans la première colonne du Tableau 1, sont respectivement réécrites tel qu'illustré dans la seconde colonne de ce tableau. En outre, un exemple de représentation interne d'expression réécrite est présenté en Figure 9. /librairie/libre/titre = string(/librairie/livre/titre/descendant::text()) = "Les Les Miserables Miserables" contains(//livre, "XML") contains(string(//livre/descendant::text()), "XML") string(//livre) string(//livre/descendant::text()) $var string($var/descendant::text()) sum(//livre/prix) sum(number(string(//Iivre/prix/descendant::text()))) 20 Tableau 1

La sous-expression créée lors de l'étape E813 consiste donc, soit en un appel à la fonction nombre ( number() selon la syntaxe XPath) et à la fonction chaîne de caractère ( string() selon la syntaxe XPath), soit en un 25 appel direct à la fonction chaîne de caractère selon que le type dans lequel doit être converti le résultat est respectivement un nombre ou une chaîne. 28

Suite aux étapes de réécriture (étapes E812 et E813), l'étape suivante (étape E814) consiste en la mise à jour de l'expression parente de la sous-expression courante. Lors de cette étape, la relation parent-fille de l'expression parente est également mise à jour. En effet, la sous-expression fille de l'expression parente devient l'expression créée lors de l'étape E813 de manière à remplacer la sous-expression d'origine, cette dernière devient un paramètre de la nouvelle sous-expression, c'est-à-dire un appel de fonction. A l'issue de l'étape E814, il est mis fin à l'algorithme de réécriture 10 d'une sous-expression, correspondant à l'étape d'analyse sémantique, étape 44 de la Figure 4. II est maintenant décrit en référence à la Figure 10, un algorithme d'évaluation d'une expression XPath conformément à l'invention. Dans l'algorithme de la Figure 4 concernant des étapes de 15 l'évaluation d'une expression XPath précédemment présentées, l'étape E44 consiste à analyser l'expression XPath afin de détecter si une réécriture est nécessaire. Cette étape, comme on l'a vu, est suivie de l'étape E45 consistant à vérifier si l'expression construite à partir de la suite de symboles est valide. Cette étape permet, notamment au compilateur 21 d'indiquer au contrôleur 22 20 si la compilation s'est bien passée. Si tel est le cas, alors l'étape E45est suivie de l'étape E46 consistant à évaluer l'expression XPath. L'évaluation d'une expression XPath se base sur la structure générée par le compilateur, à savoir, notamment la décomposition de 25 l'expression en sous-expressions filles. Ainsi, l'évaluation d'une expression débute à l'étape E1000 par l'obtention de l'expression XPath compilée par le compilateur 21. L'étape suivante (étape E1001) consiste à suivre la relation parent-fille qui est associée à l'expression afin de savoir s'il existe une sous-30 expression. 29

Si une sous-expression existe, alors l'étape E1001 boucle sur elle-même. En effet, on suit la relation parent-fille de l'expression jusqu'à ce qu'il n'y ait plus de sous-expression. Ainsi, en l'absence de sous-expression, l'étape E1001 est suivie de l'étape E1002 consistant au démarrage de l'évaluation de la sous-expression courante. Ce démarrage consiste en une initialisation des statuts de l'évaluation de la sous expression. L'étape E1002 est suivie de l'étape E1003 au cours de laquelle il est vérifié, notamment par le contrôleur 22, si un résultat pour la sous-expression est pré calculé, ce pré calcul étant réalisé par exemple par le compilateur 21. Si un résultat est disponible, l'algorithme se poursuit à l'étape E1006 décrite ci-après. Si aucun résultat n'est disponible pour la sous-expression courante, alors l'étape E1003 est suivie de l'étape E1004 au cours de laquelle de nouvelles données XML sont attendues pour être interprétées, notamment par le contrôleur 22. En effet, la sous-expression a besoin d'informations XML pour être complètement évaluée. L'étape E1004 est suivie de l'étape E1005 consistant à rechercher 20 une expression parente. Cette étape est suivie de l'étape E1001 précédemment décrite, au cours de laquelle on parcourt les sous-expressions de l'expression parente déterminée lors de l'étape E1005. De retour à l'étape E1003, si le test est positif, c'est-à-dire s'il existe 25 un résultat disponible pour la sous-expression, alors l'expression parente est recherchée. L'étape E1003 est suivie de l'étape E1006 consistant à vérifier si l'expression parente existe. Si aucune expression parente n'existe, alors le résultat disponible est 30 le résultat final de l'évaluation, et l'algorithme se poursuit à l'étape E1009 au cours de laquelle ce résultat est retourné à l'application qui utilise le processeur XPath.

Dans le cas contraire, c'est-à-dire s'il existe une expression parente, alors l'expression parente est obtenue, notamment par le contrôleur, et l'algorithme se poursuit à l'étape E1007 consistant à propager le résultat de la sous-expression fille vers l'expression parente.

L'étape E1007 est suivie de l'étape E1008 au cours de laquelle le résultat est éventuellement agrégé avec d'autres résultats de sous-expressions soeurs, par exemple le résultat est agrégé à un résultat pour un autre opérande d'une expression d'addition. Selon le type de sous expression, l'étape d'agrégation peut consister 10 en une simple conversion de type. Ensuite, l'étape E1008 est suivie de l'étape E1006 précédemment décrite. L'étape E1006 à E1008 sont réitérées jusqu'à atteindre l'expression principale, c'est-à-dire jusqu'à ce qu'il n'y ait plus d'expression parent et donc 15 jusqu'à l'envoi du résultat final lors de l'étape El 009.

Annexe A Type de Type d'expression ou sous Règle de construction résultat expression indéterminé Expr ::= OrExpr booléen OrExpr = AndExpr I OrExpr 'or' AndExpr booléen AndExpr = EqualityExpr AndExpr and, EqualityExpr booléen EqualityExpr ::= RelationalExpr I EqualityExpr '=' RelationalExpr I EqualityExpr '!=' RelationalExpr booléen RelationalExpr ::= AdditiveExpr I RelationalExpr '<' AdditiveExpr I RelationalExpr ' AdditiveExpr 1 RelationalExpr =' AdditiveExpr 1 RelationalExpr '>=' AdditiveExpr nombre AdditiveExpr ::= MultiplicativeExpr 1 AdditiveExpr '+ ' MultiplicativeExpr 1 AdditiveExpr'-' MultiplicativeExpr nombre MultiplicativeExpr ::= UnaryExpr 1 MultiplicativeExpr MultiplyOperator UnaryExpr 1 MultiplicativeExpr'div' UnaryExpr 1 MultiplicativeExpr 'mod' UnaryExpr indéterminé UnaryExpr ::= UnionExpr I '-' UnaryExpr indéterminé UnionExpr = PathExpr I UnionExpr '1' PathExpr indéterminé PathExpr = LocationPath 1 FilterExpr FilterExpr RelativeLocationPath 1 FilterExpr '//' RelativeLocationPath indéterminé FilterExpr ::= PrimaryExpr 1 FilterExpr Predicate indéterminé PrimaryExpr ::= VariableReference 1 indéterminé ' Expr')' 1 chaîne Literai I nombre Number 1 cf. spec. FunctionCall noeuds LocationPath = RelativeLocationPath 1 AbsoluteLocationPath 1 noeuds AbsoluteLocationPath .._ RelativeLocationPath? 1 AbbreviatedAbsoluteLocationPath noeuds RelativeLocationPath ::= Step 1 RelativeLocationPath Step 1 Abbreviated Relative Location Path noeuds AbbreviatedAbsoluteLocati = '//'RelativeLocationPath onPath noeuds AbbreviatedRelativeLocati = RelativeLocationPath Step onPath noeuds Step = AxisSpecifier NodeTest Predicate* AbbreviatedStep noeuds AbbreviatedStep ::= ,' noeuds AxisSpecifier = AxisName '::' 1 AbbreviatedAxisSpecifier noeuds AbbreviatedAxisSpecifier ::= '@'? noeuds NodeTest ::= NameTest J NodeType ' 'y 1 'processing-instruction''(' Literai ' noeuds NameTest ::= '*' 1 NCName ':' '*' 1 QName noeuds NodeTest = 'comment' 1 'text' 1 'processing-instruction' 1 'node' booléen Predicate ::= '[' PredicateExpr']' booléen PredicateExpr ::= Expr cf. spec. FunctionCall = FunctionName Argument (',' Argument)* )? ' indéterminé Argument ::= Expr

Claims (33)

REVENDICATIONS

1. Procédé de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce qu'au moins une sous-expression comprenant au moins une expression élémentaire ayant au moins un paramètre, le procédé comprend les étapes suivantes : détermination d'un premier type, le premier type étant le type d'un paramètre de ladite au moins une expression élémentaire ; détermination d'un second type, le second type étant associé au résultat de l'évaluation dudit paramètre de ladite au moins une expression élémentaire ; détermination de la cohérence du premier type avec le second type en fonction de ladite au moins une expression élémentaire ; et modification de la sous-expression si incohérence du premier type avec le second type.

2. Procédé de modification selon la revendication 1, caractérisé en ce que ledit au moins un paramètre comprend au moins un paramètre implicite. 20

3. Procédé de modification selon la revendication 1 ou la revendication 2, caractérisé en ce que, la sous-expression comprenant un ensemble d'étapes de localisation, le procédé comprend une étape de détermination d'au moins une étape de localisation implicite dans l'ensemble 25 des étapes de localisation, et l'étape de modification de la sous-expression comprend une étape d'ajout d'au moins une nouvelle étape de localisation à l'ensemble des étapes de localisation représentant ladite au moins une étape de localisation déterminée. 30

4. Procédé de modification selon la revendication 3, caractérisé en ce que ladite au moins une nouvelle étape de localisation comprend une relation de filiation directe déterminée à partir d'information structurelle du document structuré.

5. Procédé de modification selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de modification comprend une étape d'insertion d'au moins une sous-expression intermédiaire.

6. Procédé de modification selon la revendication 5, caractérisé en ce que ladite au moins une sous-expression intermédiaire comprend au moins une fonction de conversion.

7. Procédé de modification selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une expression élémentaire est au moins une expression élémentaire prédéterminée.

8. Procédé de modification selon la revendication 7, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type relation.

9. Procédé de modification selon la revendication 7, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type appel de fonction. 25

10. Procédé de modification selon l'une la revendication 7, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type égalité.

11. Procédé de modification selon l'une la revendication 7, 30 caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type addition.20 35

12. Procédé de modification selon l'une la revendication 7, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type multiplication.

13. Procédé de modification selon l'une la revendication 7, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type unaire.

14. Procédé de modification selon l'une quelconque des revendications précédentes, caractérisé en ce que l'expression est une expression de type XPath.

15. Procédé d'évaluation d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce que le procédé comprend les étapes suivantes : - une étape de modification d'une expression selon le procédé de modification conforme à l'une quelconque des revendications 1 à 13, et - une étape d'évaluation de ladite expression modifiée.

16. Dispositif de modification d'une expression apte à être évaluée sur des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce qu'au moins une sous-expression comprenant au moins une expression élémentaire ayant au moins un paramètre, le dispositif comprend les moyens suivants : des moyens de détermination d'un premier type, le premier type étant le type d'un paramètre de ladite au moins une expression élémentaire ; des moyens de détermination d'un second type, le second type étant associé au résultat de l'évaluation dudit paramètre de ladite au moins une expression élémentaire ; des moyens de détermination de la cohérence du premier type avec le second type en fonction de ladite au moins une expression élémentaire ; et des moyens de modification de la sous-expression si incohérence du premier type avec le second type.

17. Dispositif de modification selon la revendication 16, caractérisé en ce que ledit au moins un paramètre comprend au moins un paramètre implicite.

18. Dispositif de modification selon la revendication 16 ou la revendication 17, caractérisé en ce que, la sous-expression comprenant un ensemble d'étapes de localisation, le dispositif comprend des moyens de détermination d'au moins une étape de localisation implicite dans l'ensemble des étapes de localisation, et les moyens de modification de la sous-expression comprennent des moyens d'ajout d'au moins une nouvelle étape de localisation à l'ensemble des étapes de localisation représentant ladite au moins une étape de localisation déterminée.

19. Dispositif de modification selon 18, caractérisé en ce que ladite au moins une nouvelle étape de localisation comprend une relation de filiation directe déterminée à partir d'information structurelle du document structuré.

20. Dispositif de modification selon l'une quelconque des revendications 16 à 19, caractérisé en ce que les moyens de modification comprennent des moyens d'insertion d'au moins une sous-expression intermédiaire.

21. Dispositif de modification selon la revendication 20, caractérisé 30 en ce que ladite au moins une sous-expression intermédiaire comprend au moins une fonction de conversion.

22. Dispositif de modification selon l'une quelconque des revendications 16 à 21, caractérisé en ce que ladite au moins une expression élémentaire est au moins une expression élémentaire prédéterminée.

23. Dispositif de modification selon la revendication 22, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type relation.

24. Dispositif de modification selon la revendication 22, caractérisé 10 en ce que l'expression élémentaire prédéterminée est une expression de type appel de fonction.

25. Dispositif de modification selon l'une la revendication 22, caractérisé en ce que l'expression élémentaire prédéterminée est une 15 expression de type égalité.

26. Dispositif de modification selon l'une la revendication 22, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type addition.

27. Dispositif de modification selon l'une la revendication 22, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type multiplication. 25

28. Dispositif de modification selon l'une la revendication 22, caractérisé en ce que l'expression élémentaire prédéterminée est une expression de type unaire.

29. Dispositif d'évaluation d'une expression apte à être évaluée sur 30 des éléments d'un document structuré, ladite expression comprenant au moins une sous-expression, caractérisé en ce que le dispositif comprend les moyens suivants : 20 38 - des moyens de modification d'une expression selon le dispositif de modification conforme à l'une quelconque des revendications 16 à 28 et - des moyens d'évaluation de la dite expression modifiée.

30. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé de modification d'une expression selon l'une quelconque des revendications 1 à 14, lorsque ce programme est chargé et exécuté par un système informatique.

31. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'évaluation d'une expression selon la revendication 15, lorsque ce programme est chargé et exécuté par un système informatique.

32. 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 des étapes du procédé de modification d'une expression selon l'une quelconque des revendications 1 à 14.

33. 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 des étapes du procédé d'évaluation d'une expression selon la revendication 15.