FR 2924245 A1 20090529 FR 0759237 A 20071122 La présente invention concerne un procédé et un dispositif d'analyse 10 ainsi qu'un procédé et un dispositif d'évaluation d'une expression sur un document structuré. Elle s'applique, notamment, à l'évaluation, au fil de l'eau de requêtes XPath (acronyme de �XML Path Language � pour langage de chemin XML, XML étant l'acronyme de �eXtensible Markup Language � pour langage de balisage extensible). 15 XPath est une spécification du consortium W3C (acronyme de � World Wide Web Consortium � pour consortium de la toile mondiale). Le but de cette spécification est de définir une syntaxe pour adresser des parties d'un document XML. Cette syntaxe utilise une notation similaire aux expressions de chemins dans un système de fichiers, (par exemple � /bookstore/book �). 20 XPath définit quatre types de données : � chaîne �, � booléen �, � nombre � et � ensemble de noeuds � ainsi que des expressions permettant de manipuler ces données (opérateurs � = �, � != �, � �, ...). Un noeud XPath peut représenter différents types d'évènement XML : � racine � pour le début du document, � élément �, � attribut �, � texte �, 25 � commentaire �, � processing-instruction � et � namespace �. Cette syntaxe sert de base à la formation de requêtes sur des documents en vue de leur transformation (voir XSLT, acronyme de eXtensible Stylesheet Language Transformations, pour transformations basées sur le langage des feuilles de style de XML, selon la version française de la spécification : 30 http://xmlfr.org/w3c/TR/xslt/), d'accéder rapidement à des sous-parties (voir XPointer) ou d'effectuer des traitements sur des parties du document (voir XQuery). XPath a pour principal avantage de simplifier le développement d'applications appelées à naviguer dans des documents XML. L'entité 1 responsable de l'évaluation d'une expression XPath est appelée � Processeur XPath �. Le processeur XPath accepte, généralement, comme entrées, d'une part, une ou plusieurs expressions XPath et, d'autre part, une référence sur des données XML (lues dans un fichier ou reçues via une transmission réseau) sur lesquelles la ou les expressions doivent être évaluées. Comme mentionné dans l'introduction, XPath définit quatre types de données ainsi que sept types de noeuds. La syntaxe XPath définit également une grammaire décrivant les règles de construction des différentes expressions et sous-expressions. Les expressions XPath peuvent être regroupées en deux sous catégories que nous désignerons comme � Expressions de navigation � et � Expressions de calcul �. Les expressions de navigation sont les expressions qui retournent une liste ordonnée de noeuds XPath : essentiellement les � LocationPath � et les � Steps � qui correspondent à la spécification d'un chemin à résoudre dans un document XML. Les expressions de calcul comportent : - les expressions qui retournent un booléen � OrExpr �, � AndExpr �, � RelativeExpr �, � EqualityExpr � ; - les expressions qui retournent un nombre : � AdditiveExpr �, � MultiplicativeExpr � et - les expressions qui retournent n'importe quel type : � FilterExpr � et, en particulier, les � FunctionCall �. La présente invention vise, notamment, à traiter des expressions composées des deux types de sous-expressions, par exemple un appel de fonction dont au moins un des paramètres est exprimé par une LocationPath. En ce qui concerne l'organisation des �LocationPath� ou chemins de localisation, une LocationPath peut-être absolue ou relative selon qu'elle commence par � / � ou non. Dans le cas d'une LocationPath absolue, la recherche commence depuis la racine du document, alors que dans le cas de LocationPath relatives, la recherche est contextuelle (par exemple depuis le noeud courant). Toute LocationPath est composée de Steps, ou étapes de chemin de localisation. Ce niveau de décomposition est le niveau clé pour l'évaluation des LocationPaths car il peut être mis en correspondance avec un niveau de profondeur dans le document XML. Par exemple, l'expression /bookstore/book contient deux Steps qui sont : � bookstore � (recherché à la profondeur � 1 �) et � book � (recherché à la profondeur � 2 �). L'évaluation d'un Step se fait conditionnellement au Step parent, c'est-à-dire le Step qui le précède dans l'expression. Le résultat de l'évaluation d'un Step fournit donc le contexte d'évaluation pour le Step suivant. Ce contexte est composé d'un noeud contexte, d'une position et d'une taille : le noeud contexte est le noeud solution du Step précédent, la position indique le rang du noeud solution du Step courant parmi ses frères, la taille du contexte indique le nombre de noeuds solution du Step courant. Toute expression de type Step est composée de une à trois entités : - �AxisSpecifier � ou axes, optionnel, valant � child � (enfant) par défaut, qui décrit la relation de descendance ou d'ascendance entre le noeud contexte et les noeuds solution du Step. L'AxisSpecifier est un mot-clé parmi 13 mots clés prédéfinis par la syntaxe XPath, suivi de � :: �. Par exemple : � /a/child ::b � ou � /a/attribute ::b � signifient respectivement que l'on cherche un noeud � b � fils d'un noeud � a � se trouvant être fils du noeud racine du document et un noeud attribut � b � fils d'un noeud � a � également fils du noeud racine du document. Les 13 AxisSpecifier définis par la spécification sont les suivants : � self �, � child �, � attribute � (ou � @ �), � namespace �, � descendant �, � descendant-or-self �, �following � et � following-sibling �, qui sont considérés comme des axes � vers l'avant � (� forward axes � en anglais) et � parent �, � ancestor �, � ancestor-or-self �, � preceding � et � preceding-sibling �, qui sont considérés comme des axes � vers l'arrière � (� backward � ou � reverse � axes en anglais). - � NodeTest �, test de noeud, obligatoire, qui définit la contrainte de type � (node() �, � tex�) �, � comment() � ou � processing-instruction()) � ou de � nom (préfixe + nom) � que doivent respecter des noeuds pour être considérés comme solution du Step. Par exemple, � /child ::b � impose une contrainte de nom alors que � /descendant::comment() � permet de rechercher tous les noeuds de type commentaire et - � Predicate �, prédicat, optionnel, permet d'imposer des conditions supplémentaires pour la recherche de noeuds solution. Une expression � prédicat � est signalée par des crochets : � [...] � et suit les mêmes règles de construction que toute expression XPath. Par exemple � : /a/b[2] � permet de sélectionner tous les deuxièmes fils � b � de chaque élément � a � ; � /a/b[@id= � 3�] � permet de sélectionner les fils � b � de � a � possédant un attribut � id � ayant une valeur égale à 3. Comme décrit ci-dessus, XPath permet d'accéder à des parties d'un document XML. Une implémentation naïve d'un processeur XPath consisterait à construire une représentation intermédiaire du document XML sous une forme qui faciliterait la recherche, un arbre DOM (acronyme de � Document Object Model � en anglais, pour modèle d'objets de documents) par exemple, et à parcourir cet arbre autant de fois que nécessaire pour l'extraction des noeuds demandés en utilisant cette interface DOM. Une telle approche pose un double problème. Tout d'abord, elle peut s'avérer coûteuse en mémoire dans le cas de documents XML de grande taille. En effet, considérant un processeur XPath implanté dans un appareil embarqué (type appareil photo, photocopieur ou autre) les ressources sont limitées. Il faut donc veiller à évaluer les expressions XPath au fur et à mesure que les données XML sont disponibles en recourant le moins possible au stockage de ces données. Le second problème réside dans les multiples parcours faits sur l'arbre à la recherche des solutions. Dans un contexte de traitements des données XML à la volée (� streaming environment � en anglais), il n'est pas envisageable de parcourir plusieurs fois les données, surtout si ces données proviennent d'un échange de messages entre appareils communicant à travers un réseau (cas des services Web par exemple). Il convient donc de définir une représentation des expressions XPath de façon à préparer et à faciliter : - d'une part, leur évaluation dans un cadre de réception des données XML à la volée et, - d'autre part, l'émission des résultats à l'application aussitôt que ceux-ci sont disponibles. La majorité des articles ou brevets traitant de l'évaluation d'expressions XPath à la volée concerne davantage la représentation de telles expressions au détriment de la propagation des résultats. En effet, plus on compacte la représentation de la ou des expressions à évaluer et plus la propagation des résultats devient complexe. A l'inverse, une représentation visant à planifier la propagation des résultats peut s'avérer trop grande consommatrice de mémoire surtout lorsque l'on adresse l'évaluation de plusieurs expressions sur des appareils à ressources limitées. Le document US 7,171,407 propose une solution permettant d'évaluer à la volée des expressions XPath de type � expressions de navigation �. Il y est décrit une représentation des expressions de navigation sous forme de graphe orienté acyclique (voir sa figure 3). Dans cette représentation, chaque NodeTest des Step des LocationPath (30) correspond à un sommet (ou noeud) du graphe, les AxisSpecifiers étant représentés par les arcs du graphe. Cette représentation a pour principal avantage d'organiser la recherche d'informations XML selon l'ordre du document. En effet, si des AxisSpecifiers de type � parent � ou � ancêtre � sont présents dans les LocationPath à évaluer, les NodeTests correspondants sont organisés exclusivement selon une relation de descendance (c'est-à-dire respectant l'ordre du document). Toutefois, si cette représentation s'avère intéressante pour des expressions XPath purement de navigation, elle ne permet pas d'aborder les expressions de type calcul, ou de type hybride (mixant expressions de navigation et de calcul). De plus, cette représentation impose de maintenir des structures de stockage pour les noeuds XPath solution du dernier Step de chaque LocationPath afin de déterminer à posteriori si ce noeud est une solution pour la LocationPath dans son ensemble (le temps de résoudre des prédicats ou de vérifier les AxisSpecifiers, par exemple). Enfin, la phase de propagation de résultats se fait de façon optimiste d'un noeud vers son parent, pouvant parfois nécessiter une étape de nettoyage de certaines solutions ne vérifiant pas a posteriori certaines relations d'ascendance ou de descendance (AxisSpecifier). Le document US 2005/0228768 concerne des expressions XPath hybrides, c'est-à-dire contenant à la fois des expressions de navigation et des expressions de calcul. Il propose une représentation des expressions sous forme d'arbres dans lequel un noeud peut représenter soit un Step d'une LocationPath, soit un calcul à effectuer sur des résultats intermédiaires. Cependant dans cette proposition, l'évaluation ne se fait pas à la volée. Chaque résultat d'un noeud est toujours transmis à son noeud parent. Il n'est pas possible de simplifier l'arbre dans le cas où plusieurs expressions seraient à évaluer. La présente invention vise à remédier à ces inconvénients et, notamment, à fournir une représentation efficace des expressions XPath, en particulier en termes de propagation des résultats. A cet effet, selon un premier aspect, la présente invention vise un procédé d'analyse d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte : - une étape d'identification d'au moins une sous-expression de navigation d'au moins une expression à évaluer, au moins une dite sous- expression de navigation comportant au moins une étape de chemin de localisation, - une étape de représentation de chaque dite étape de chemin de localisation de chaque dite sous-expression de navigation, sous forme de cible de navigation compilée, structure représentant la recherche d'informations correspondant à ladite étape de chemin de localisation dans le document structuré, et, pour chaque étape de chemin de localisation : - une étape de détermination d'un destinataire du résultat d'une évaluation de ladite étape de chemin de localisation et - une étape d'ajout, dans la cible de navigation compilée de ladite étape de chemin de localisation, d'une information d'identification dudit destinataire. Identifier les sous expressions de navigation (typiquement les LocationPath ou chemin de localisation), permet de déterminer les composantes de l'expression qui dépendent des données XML. Extraire les étapes de chemin de localisation (� step �) de ces sous expressions de navigation permet de préparer les différents tests à effectuer lors de l'évaluation ultérieure. Identifier, pour chaque étape de chemin de localisation, un destinataire pour tout résultat issu de cette étape de chemin de localisation, permet d'accélérer la transmission des résultats d'évaluation et d'éviter de recourir à du stockage. Inclure ce destinataire dans la représentation de l'étape de chemin de localisation, à savoir la cible de navigation compilée, permet de préparer la transmission des résultats d'évaluation. La mise en oeuvre de la présente invention permet de prévoir tous les tests à réaliser lors du parcours unique du document structuré. Selon des caractéristiques particulières, au cours de l'étape de détermination d'un destinataire, on détermine une cible de navigation compilée destinataire du résultat d'une évaluation de ladite étape de chemin de localisation. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'organisation des cibles de navigation compilées en fonction de leur profondeur et une étape de liaison des dites cibles de navigation compilées entre elles. Ceci permet de planifier l'enchaînement des tests à effectuer au cours de l'évaluation. Selon des caractéristiques particulières, au cours de l'étape de liaison, on construit des branches d'un arbre de navigation par l'insertion de cibles de navigation compilées. On permet ainsi une évaluation à la volée. L'évaluation à la volée consiste, d'une part, à traiter les informations de chaque document à la volée et, d'autre part, à fournir à l'application utilisant le processeur XPath les résultats dès qu'ils sont calculés. Selon des caractéristiques particulières, au cours de l'étape d'insertion, on insère la cible de navigation compilée courante dans l'arbre de navigation qui représente le chemin de localisation courant, en fonction de la valeur de l'axe de la cible de navigation compilée courante. Selon des caractéristiques particulières, au cours de l'étape de représentation, on construit, à la fois, un arbre d'instructions et un arbre de navigation. Ceci permet de clairement séparer les parties des expressions dépendant des données structurées des parties des expressions purement calculatoires. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de détermination de cibles de navigation compilées intermédiaires redondantes et une étape de fusion des cibles de navigation compilées intermédiaires redondantes. On rend ainsi plus compacte la représentation de la ou des expressions à évaluer et on rend ainsi l'évaluation plus efficace. Selon des caractéristiques particulières, au cours de l'étape de représentation, on renseigne un champ de la cible de navigation compilée pour y indiquer à quel chemin de localisation ladite cible de navigation compilée appartient. Selon des caractéristiques particulières, chaque dite expression est 20 une expression XPath. Selon des caractéristiques particulières, l'étape de représentation comporte : - une étape de détermination d'une valeur d'axe correspondant à l'étape de chemin de localisation courante, 25 - une étape d'identification d'un test de noeud auquel doit satisfaire tout noeud candidat à la résolution de l'étape de chemin de localisation courante et - une étape d'identification d'au moins un prédicat associé à l'étape de localisation courante. 30 Selon des caractéristiques particulières, le procédé d'analyse objet de la présente invention, tel que succinctement exposé ci-dessus comporte une étape de regroupement de cibles de navigation compilées en fonction de tests de noeuds associés aux dites cibles de navigation compilées. On réduit ainsi le coût en mémoire de la représentation des expressions compilées. Selon des caractéristiques particulières, au cours de l'étape de regroupement, pour au moins deux cibles de navigation compilées correspondant au même niveau de profondeur, on détermine si les tests de noeud ont la même valeur et, si oui, l'une des cibles est mise à jour avec les valeurs de liens de cible de navigation compilée fille et d'éventuels prédicats, de l'autre cible de navigation compilée. Selon des caractéristiques particulières, si au moins un prédicat est identifié, on conserve au niveau de la cible de navigation compilée courante, un lien vers la première cible de navigation compilée de chaque prédicat. Selon des caractéristiques particulières, si au moins un prédicat est identifié, la cible de navigation compilée courante garde un lien vers chaque sous expression qui correspond au dit prédicat. Ceci permet de déterminer au cours de l'évaluation si ses prédicats sont résolus ou non. Selon des caractéristiques particulières, pour déterminer ledit destinataire, on détermine si une cible de navigation compilée parente existe et, si oui, on détermine si cette cible de navigation compilée parente contient au moins un prédicat et, si cette cible de navigation compilée parente ne contient aucun prédicat, le destinataire des résultats de la cible de navigation compilée parente devient le destinataire des résultats de la cible de navigation compilée courante. Ceci permet de lier la dernière cible de navigation compilée produisant un résultat à la cible de navigation compilée la plus proche possible de la racine de l'arbre de navigation afin d'accélérer la remontée des résultats. Selon des caractéristiques particulières, pour déterminer ledit destinataire, on détermine si une cible de navigation compilée parente existe et, si oui, on détermine si cette cible de navigation compilée parente contient au moins un prédicat et, si oui, la cible de navigation compilée parente devient le destinataire des résultats d'évaluation de la cible de navigation compilée courante. Ceci permet de ne pas considérer, lors de la remontée de résultats d'évaluation, des cibles de navigation compilées sur lesquelles aucun traitement de ce résultat n'est à effectuer. Selon un deuxième aspect, la présente invention vise un procédé d'évaluation d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte les étapes du procédé d'analyse tel que succinctement exposé ci-dessus et une étape d'évaluation de chaque dite expression en mettant en oeuvre au moins une dites cibles de navigation compilées incorporant une identification du destinataire de résultat d'évaluation d'une étape de chemin de localisation d'une sous-expression de navigation d'une dite expression. Selon des caractéristiques particulières, au cours de l'étape d'évaluation, on effectue une évaluation à la volée. Selon des caractéristiques particulières, le procédé d'évaluation tel que succinctement exposé ci-dessus comporte une étape de génération de cibles d'évaluation, à une cible de navigation compilée correspondant au moins une cible d'évaluation qui porte les informations relatives au statut de l'exécution. Cette distinction entre cibles de navigation compilées et cibles d'évaluation permet de conserver l'arbre de navigation intact en vue d'évaluations multiples ou en parallèle, éventuellement sur des documents différents. Selon des caractéristiques particulières, au cours de l'étape d'évaluation, on récupère, d'une part, un test de noeud en fonction du contenu d'une cible de navigation compilée associée à la cible d'évaluation courante et, d'autre part, un noeud et on détermine si ledit noeud respecte ledit test de noeud. Ceci permet de déterminer si une cible d'évaluation est atteinte ou non. Selon des caractéristiques particulières, au cours de l'étape d'évaluation, si une cible d'évaluation est résolue et si ladite cible d'évaluation est une feuille d'un arbre de navigation, le noeud courant est propagé vers le destinataire associé à la cible d'évaluation courante. Selon des caractéristiques particulières, au cours de l'étape d'évaluation, si une cible d'évaluation destinataire, autre que la racine d'un arbre de navigation, reçoit un noeud XML solution, celui-ci est utilisé pour la résolution de ladite cible d'évaluation et, si ce noeud XML permet d'obtenir un résultat pour cette cible d'évaluation, ce résultat est émis vers la cible destinataire associée à la cible d'évaluation courante. Selon un troisième aspect, la présente invention vise un dispositif d'analyse d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte : - un moyen d'identification d'au moins une sous-expression de navigation d'au moins une expression à évaluer, au moins une dite sous-expression de navigation comportant au moins une étape de chemin de localisation, - un moyen de représentation de chaque dite étape de chemin de localisation de chaque dite sous-expression de navigation, sous forme d'une cible de navigation compilée, - un moyen de détermination d'un destinataire du résultat d'une évaluation de chaque étape de chemin de localisation et - un moyen d'ajout, dans la cible de navigation compilée de ladite étape de chemin de localisation, d'une information d'identification dudit destinataire. Selon un quatrième aspect, la présente invention vise un dispositif d'évaluation d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte un dispositif d'analyse tel que succinctement exposé ci-dessus et un moyen d'évaluation de chaque dite expression en mettant en oeuvre au moins une des dites cibles de navigation compilées incorporant une identification du destinataire de résultat d'évaluation d'une étape de chemin de localisation d'une sous-expression de navigation d'une dite expression. Selon un cinquième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé objet de la présente invention tel que succinctement exposé ci-dessus. Selon un sixième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé objet de la présente invention tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques de ce procédé d'évaluation, de ce dispositif d'analyse, de ce dispositif d'évaluation, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés dans lesquels : - la figure 1 représente, sous forme d'un logigramme, les principales étapes d'un mode de réalisation particulier du procédé objet de la présente invention, - les figures 2 et 3 représentent, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention, - les figures 8 et 9 illustrent des relations entre des éléments d'une expression et - les figures 4 à 7 et 10 à 15 représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé objet de la présente invention. Les principales étapes du procédé objet de la présente invention sont représentées en figure 1 : au cours d'une étape 101, au moins une expression est fournie au processeur XPath 202 (voir figure 2). Au cours d'une étape 102, une analyse lexicale permet de représenter chaque expression par une suite de symboles correspondants à la grammaire définie par la spécification XPath. Au cours d'une étape 103, on détermine si tous les symboles sont connus. Si oui, au cours d'une étape 104, on effectue une analyse grammaticale qui permet de construire une représentation de chaque expression. Notamment, lors de cette étape 104, les sous expressions de navigation sont identifiées, étape 104a, et découpées en étapes (� step �), étape 104b et chaque étape se voit attribuer un destinataire de ses résultats d'évaluation, étape 104c. L'étape 104 est détaillée en regard de la figure 4. A la suite de l'étape 104, au cours d'une étape 105, on détermine si la représentation ainsi construite est valide. Si oui, on effectue une étape 106 de regroupement permettant de regrouper des étapes redondantes et non significatives. Si le résultat de l'une des étapes 103 ou 105 est négatif, on émet un signal d'expression invalide. L'étape 106 est détaillée en figure 7. Puis, on effectue une étape 107 de lancement de l'évaluation des expressions. Au cours d'une étape 108, on détermine si l'ensemble des résultats est disponible. Sinon, on réalise une étape 109 d'évaluation en fonction d'un document XML. A la suite de l'étape 109 ou si le résultat de l'étape 108 est positif, les étapes s'achèvent. La figure 2 décrit un contexte de mise en oeuvre de la présente invention. Le scénario typique d'utilisation de la présente invention implique une application 201 manipulant des données XML extraites par un ou plusieurs processeurs XPath 202 grâce à un ou plusieurs analyseurs (ou navigateur) XML 203 (� parser � en anglais) travaillant sur un flux de données XML 204. Le processeur XPath 202 comprend trois entités principales : - un compilateur 221 qui analyse les expressions et les traduit en une représentation interne, comme décrit en référence à la figure 4. Ce compilateur 221 est composé de deux analyseurs l'un lexical 261, l'autre sémantique 262 ; - une unité de contrôle d'exécution 222 qui gère la communication avec l'application 201, les interactions entre les différents modules et prend en charge l'évaluation des noeuds. Cette unité de contrôle d'exécution 222 est notamment composée d'un gestionnaire de cibles d'évaluation 271 responsable de la résolution des étapes de chemin de localisation composant les sous expressions de navigation et - un navigateur 223 qui permet au contrôleur d'exécution 222 de communiquer, de façon générique, avec n'importe quel navigateur XML 203, de représenter et de mémoriser les évènements XML sous forme de noeuds XPath dans un contexte de navigation 281. Ce navigateur 223 permet également de faire fonctionner le processeur XPath 202 en mode � pull � (il contrôle le parcours dans le document XML 204 et le navigateur XML 203) ou � push � (il est à l'écoute des données XML extraites par le navigateur XML 203 alors piloté par l'application 201). Les deux principales étapes de l'évaluation d'une ou plusieurs expression(s) XPath sont: - l'analyse en vue de la compilation (voir, ci-dessous, la construction de la représentation interne, et - l'évaluation proprement dite (voir, ci-dessous, l'évaluation d'une expression XPath, sur un document XML. L'invention est préférentiellement mise en oeuvre dans le ou les 20 processeurs XPath 202. La figure 3 représente un dispositif 301, tel un micro-ordinateur, dans lequel l'invention pourrait être mise en place et ses différents périphériques. Selon le mode de réalisation choisi et représenté en figure 2, un dispositif mettant en oeuvre l'invention est par exemple un micro-ordinateur 301 25 connecté à différents périphériques. Le dispositif 301 de la figure 3 comporte une interface de communication 318 reliée à un réseau 302 apte à transmettre et à recevoir des données numériques. Le dispositif 301 comporte également un moyen de stockage 314 tel que, par exemple, un disque dur. Il comporte aussi un lecteur 30 de disquette 315. La disquette 324 lue par ce lecteur 315 peut contenir des données XML selon l'invention ainsi que le code d'un programme 309 implémentant la présente invention, code qui, une fois lu par le dispositif 301, sera stocké dans le disque dur 314. Selon une variante, le programme 309 permettant au dispositif 301 de mettre en oeuvre l'invention, est stocké en mémoire morte 310 (appelée ROM, pour read only memory, sur le dessin). En seconde variante, le programme est reçu pour être stocké de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication. Le dispositif 301 possède un écran 312 permettant de visualiser les résultats des évaluations. A l'aide du clavier 313, l'utilisateur peut spécifier une expression XPath. L'unité centrale 311 (appelée � CPU � pour central processing unit, sur le dessin) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 310 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes relatifs à l'évaluation d'expressions XPath et d'extraction des évènements XML stockés dans une mémoire non volatile, par exemple la mémoire morte 310, sont transférés dans la mémoire vive 317 qui contient alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. Bien entendu, les disquettes 324 peuvent être remplacées par tout support d'information tel que CD-ROM, DVD ou carte mémoire. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé d'exécution. Le bus de communication 321 permet la communication entre les différents éléments inclus dans le micro-ordinateur 301 ou reliés à lui. La représentation du bus 321 n'est pas limitative et notamment l'unité centrale 311 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 301 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 301. La figure 4 illustre la construction de la représentation interne. Une ou plusieurs expressions XPath à évaluer sont spécifiées par un utilisateur ou préalablement stockées dans un fichier lu par l'application ou encore résultent de l'exécution, au niveau de l'application, d'un programme (par exemple un processeur XSLT ou XQuery) générant des requêtes XPath. Ces expressions sont reçues l'une après l'autre, au cours d'une étape 501. Le but des étapes qui suivent est de traduire les expressions XPath reçues par le processeur XPath 202 en une structure, par exemple un ou plusieurs arbre(s), sur laquelle le contrôleur d'exécution 222 va s'appuyer pour l'évaluation. Selon un mode de réalisation préféré, la représentation interne est composée à la fois d'un arbre d'instructions et d'un arbre de cibles de navigation compilées, une cible de navigation compilée représentant une étape � Step � d'un chemin de localisation � LocationPath �. Au cours d'une étape 502, on effectue une analyse lexicale. Cette étape consiste à analyser, un à un, les caractères qui représentent l'expression XPath courante et à les regrouper en symboles (� tokens � en anglais). Ces symboles peuvent représenter des symboles réservés, propres à la spécification, comme par exemple le caractère � / �, le symbole � :: �, ... ou bien des digits ou des caractères simples. L'étape 502 est réalisée par l'analyseur lexical 261 qui dispose d'une table de symboles prédéfinis en fonction de la grammaire XPath considérée (1.0 ou 2.0). A la suite de la décomposition en symboles effectuée au cours de l'étape 502, au cours d'une étape 503, on détermine si les symboles générés sont valides. Si au cours de cette étape 503, un des symboles est analysé comme non permis ou inconnu par l'analyseur lexical 261, le compilateur 221 s'arrête et informe le contrôleur d'exécution XPath 222 de la non-conformité de l'expression, lors d'une étape 509. Cette expression ne peut alors pas être évaluée. Une variante consiste à ignorer le symbole non reconnu et à continuer la compilation. Dans le cas de plusieurs expressions à évaluer simultanément, toute expression invalide est rejetée de l'évaluation. Si l'étape de test 503 conduit à un ensemble de symboles considérés comme valides par l'analyseur lexical 261, au cours d'une étape 504, l'analyseur sémantique 262 récupère le premier symbole généré lors de l'étape 502. A partir de ce symbole, l'analyseur sémantique 262 tente, au cours d'une étape 505, d'identifier une sous expression élémentaire, par exemple un appel de fonction (� FunctionCall �), une expression d'égalité (� EqualityExpr �), un chemin de localisation (� LocationPath �)... Si le symbole courant ne permet pas une telle identification, alors l'analyseur sémantique 262 lit un nouveau symbole en vérifiant au préalable qu'il en existe un, au cours d'une étape 506. Au contraire, si une sous expression élémentaire est reconnue par l'analyseur sémantique 262, au cours d'une étape 505, alors l'analyseur sémantique 262 détermine s'il s'agit d'une sous expression de type navigation, au cours d'une étape 507. Sinon, la sous expression identifiée est insérée dans l'arbre d'instruction lors d'une étape 508 et l'analyseur sémantique 262 retourne à l'étape 506. S'il s'agit d'une sous expression de navigation, alors l'analyseur sémantique 262 lit un ou plusieurs symboles qui suivent les symboles mis en oeuvre au cours de l'étape 504, au cours d'une étape 510, afin de construire une représentation de l'étape de chemin de localisation (� Step �) courante lors d'une étape 512, représentation que l'on nomme � cible de navigation compilée �. La représentation de l'étape de chemin de localisation (� step �) ainsi construite est stockée dans l'analyseur sémantique 262 comme cible de navigation compilée parente des prochaines éventuelles étapes de chemin de localisation (� step �) à construire, au cours d'une étape 513. Puis, on retourne à l'étape 510 pour poursuivre le traitement des symboles de la liste des symboles tant que ceux-ci correspondent à des composantes de l'étape de chemin de localisation (� Step �), correspondant à un résultat positif de l'étape 511. Pour chaque étape de chemin de localisation (� Step �) ainsi identifiée, l'analyseur sémantique 262 construit, lors de l'étape 512, une cible de navigation compilée associée. Si le symbole lu ne correspond pas à une composante d'un Step, c'est-à-dire si le résultat de l'étape 511 est négatif, l'analyseur sémantique 262 essaie d'utiliser ce symbole pour identifier une nouvelle sous expression au cours d'une nouvelle étape 505. L'analyseur sémantique 262 réitère les étapes 510, 511, 512 et 513 jusqu'à ce que plus aucun symbole ne soit disponible, le résultat de l'étape 510 étant alors négatif, ou bien lorsque le symbole lu ne correspond pas à une composante d'un Step, le résultat de l'étape 511 étant alors négatif. Lorsque plus aucun symbole ne reste à lire, le résultat de l'étape 506 ou de l'étape 510 étant alors négatif, le compilateur XPath 221 considère l'expression suivante, en déterminant d'abord s'il en existe au moins une, au cours d'une étape 514, et, si oui, en la récupérant au cours d'une nouvelle itération de l'étape 501, avant de retourner à l'étape 502. S'il ne reste plus d'expression, au cours d'une étape 515, on termine l'étape de construction de la représentation interne par le regroupement des cibles de navigation compilées redondantes. Cette étape 515 de regroupement est décrite en référence à la figure 7. La figure 5 donne le détail de l'étape 512 relative à la construction de la représentation d'une étape de chemin de localisation (� Step � dans la spécification XPath). Cette représentation est appelée � cible de navigation compilée � car elle porte des informations de structure et de valeur sur les noeuds XML que l'on cherche dans le document XML 204 et car les informations de structure impliquent donc une navigation. En effet, un axe (� AxisSpecifier �) spécifie le type de relation arborescente (c'est à dire le sens de recherche) entre un noeud contextuel (solution de l'étape précédente) et les noeuds à localiser. L'axe peut également fournir une information sur le type de noeud (par exemple, � attribute :: �) et donne également une indication sur la profondeur dans le document XML 204 à laquelle se trouveront les solutions potentielles. Le test de noeud (� NodeTest �) fournit une information soit sur le type de noeud recherché soit sur son nom. Enfin, un ou plusieurs prédicats (� Predicate �) permettent, éventuellement, de filtrer les solutions d'une étape de chemin de localisation (� Step �). L'étape 512 de construction de la représentation de l'étape de chemin de localisation courante consiste, pour l'analyseur sémantique 262, à créer, au cours d'une étape 600, une cible de navigation compilée. Lors de cette création, l'analyseur sémantique 262 renseigne un champ de la cible de navigation compilée qui permet de savoir à quel chemin de localisation (� LocationPath �) la cible de navigation compilée appartient. Puis, une étape 601 consiste à déterminer à quelle valeur d'axe parmi les treize valeurs possibles définies par la syntaxe XPath correspond le symbole courant. A la suite de l'étape 601, au cours d'une étape 602, on effectue la lecture d'un nouveau symbole. Au cours d'une étape 603, on identifie le test de noeud. A cet effet, l'analyseur sémantique 262 identifie, à partir du symbole courant ou du nouveau symbole lu, soit un type de noeud soit un nom, qualifié ou non, que doit vérifier tout noeud candidat à la résolution de l'étape de chemin de localisation (� step �) courante. A la suite de l'identification du test de noeud, l'analyseur sémantique 262 détermine s'il peut identifier les éventuels prédicats, au cours d'une étape 604, associés à l'étape de chemin de localisation (� step �) courante. Pour cela, un prédicat étant, par définition, une expression XPath entre les caractères `[' et la construction d'un prédicat se fait selon les étapes de construction 504 à 513 de la figure 4. Si au moins un prédicat est identifié, au cours d'une étape 605, au niveau de l'étape de chemin de localisation (� step �) courante, est conservé un lien vers la première cible de navigation compilée de chaque prédicat. Puis, lors d'une étape 606, la cible de navigation compilée courante garde un lien vers la (ou les) sous expressions qui correspondent au(x) prédicat(s), ceci afin de déterminer au cours de l'évaluation si ses prédicats sont résolus ou non. Ensuite, au cours d'une étape 607, l'analyseur sémantique 262 détermine si la cible de navigation compilée courante possède une cible de navigation compilée parente sauvegardée en mémoire du compilateur au cours de l'étape 513. Si oui, l'analyseur sémantique 262 met à jour le lien parent- enfant entre la cible de navigation compilée parente et la cible de navigation compilée courante, lors d'une étape 608. Puis, au cours d'une étape 609, on insère la cible de navigation compilée courante dans l'arbre de navigation qui va représenter le chemin de localisation courant. Pour cela, l'analyseur sémantique 262 se base sur la valeur de l'axe de la cible de navigation compilée courante : s'il s'agit d'un axe de type � enfant � (child), � descendant � ou � descendant ou réflexif � (� descendant-or-self �), la cible de navigation compilée courante est insérée dans l'arbre de navigation comme fille de la cible de navigation compilée parente, c'est-à-dire à un niveau correspondant à un niveau de profondeur incrémenté de un, par rapport à celui de la cible de navigation compilée parente. Si l'axe vaut � attribut �, � espace des noms � (� namespace �) ou � réflexif � (� self �), alors la cible de navigation compilée courante est insérée comme soeur de la cible de navigation compilée parente, c'est-à-dire à la même profondeur dans l'arbre de navigation. Si l'axe vaut � parent �, la cible de navigation compilée est insérée au niveau de profondeur décrémenté de un, par rapport à la cible de navigation compilée parente. Si l'axe vaut � ancêtre � (� ancestor �) ou bien � ancêtre ou réflexif � (� ancestor- or-self �), la cible de navigation compilée courante est insérée au niveau � 1 � de l'arbre de navigation comme fille de la cible de navigation compilée racine. Suite à cette insertion, l'analyseur sémantique 262 calcule le destinataire pour les résultats d'évaluation de la cible de navigation compilée courante lors d'une étape 610. Pour cela, il procède selon les étapes de la figure 6. Comme on l'observe en figure 6, au cours d'une étape 700, on détermine si une cible de navigation compilée parente existe. Si oui, l'analyseur sémantique 262 détermine si cette cible de navigation compilée parente contient au moins un prédicat, lors d'une étape 701. Si ce n'est pas le cas, le compilateur XPath 221 ajoute en 702 l'information de destinataire des résultats à la cible de navigation compilée courante avec pour valeur le destinataire des résultats de la cible de navigation compilée parente. Puis la cible de navigation compilée parente est marquée comme non pertinente en ce qui concerne la propagation des résultats, au cours d'une étape 703. Si, au contraire, la cible de navigation compilée parente contient au moins un prédicat, le compilateur XPath 221 ajoute en 704 l'information de destinataire des résultats à la cible de navigation compilée courante avec pour valeur la cible de navigation compilée parente. La cible de navigation compilée courante est ensuite marquée comme pertinente lors d'une étape 705. L'étape 706 de la figure 6 correspond au cas où la cible de navigation compilée courante est la première d'un chemin de localisation, c'est-à-dire au cas où le résultat de l'étape 607 est négatif. Dans ce cas, la cible de navigation compilée courante est marquée comme pertinente lors de cette étape 706 et l'information de destinataire des résultats est ajouté à cette cible de navigation compilée courante avec pour valeur le chemin de localisation parent en 707. On observe que les étapes 706 et 707 correspondent au cas de l'étape 615 suivie d'un résultat négatif au cours de l'étape 700. De retour à l'étape 610 de la figure 5, une fois le destinataire identifié, on détermine le type de la cible de navigation compilée courante, ce type étant utilisé par le contrôleur d'exécution 222 lors de l'évaluation. Pour cela, au cours d'une étape 611, on détermine si la cible de navigation compilée courante possède des prédicats. Si oui, son type prend la valeur �intermédiaire de prédicat � au cours d'une étape 613. Sinon, son type prend la valeur � intermédiaire� au cours d'une étape 612. Si le résultat de l'étape 607 est négatif, c'est-à-dire si l'analyseur sémantique 262 n'a pas encore sauvegardé de cible de navigation compilée parente en 513, la cible de navigation compilée courante crée une nouvelle branche dans l'arbre de navigation, au cours d'une étape 614. Puis, son destinataire et son niveau de pertinence sont initialisés au cours d'une étape 615, en réalisant les étapes 700 et 706. Puis, au cours d'une étape 616, on détermine si au moins un prédicat est présent. Si la cible de navigation compilée courante ne contient aucun prédicat, son type est initialisé à �racine �, au cours d'une étape 617. Sinon, son type prend la valeur �racine de prédicat � au cours d'une étape 618. Comme on l'observe en regard de la figure 7, qui concerne la factorisation ou le regroupement des cibles de navigation compilées, afin de réduire le coût en mémoire de la représentation des expressions XPath compilées, la mesure de pertinence associée aux cibles de navigation compilées peut-être utilisée. Cela consiste à factoriser les cibles de navigation compilées intermédiaires identifiées comme non pertinentes au cours de l'étape 703, dans le traitement et la propagation des résultats. Pour plus de lisibilité, on décrit cette factorisation en regard de l'étape 515, comme consécutive à la construction de la représentation interne. De même, on considérera la notion de � regroupement de cibles de navigation compilées � identique à la notion de � factorisation de cibles de navigation compilées �. Cependant, cette factorisation pourrait s'intégrer dans les étapes de construction de cette représentation, notamment lors des étapes de calcul du destinataire des résultats, notamment l'étape 610. L'étape de factorisation 515 commence par une étape 800 au cours de laquelle on met à � 0 � un indice de profondeur courant dans l'arbre de navigation. Ensuite, le compilateur 221 récupère, au cours d'une étape 801, la liste de cibles de navigation compilées pour le niveau de profondeur courant. Puis, au cours d'une étape 802, on détermine si la liste contient au plus une cible de navigation compilée. Si oui, la factorisation se termine. Sinon, le compilateur 221 sélectionne la première cible de navigation compilée de la liste, au cours d'une étape 803. Au cours d'une étape 804, on détermine si la première cible de navigation compilée de la liste est pertinente. Si oui, le compilateur 221 détermine s'il existe une cible de navigation compilée suivante, au cours d'une étape 805 et, si oui, la cible de navigation compilée suivante devient la cible de navigation compilée courante en 806 et on retourne à l'étape 804. Si la cible de navigation compilée courante testée en 804 s'avère non pertinente, la cible de navigation compilée courante devient la cible de navigation compilée de référence, au cours d'une étape 807. Ensuite, le test de noeud de la cible de navigation compilée de référence est sauvegardé comme test de noeud de référence, lors d'une étape 808. Puis, au cours d'une étape 809, on détermine s'il existe une cible de navigation compilée suivante. Sinon, on retourne à l'étape 805. Si plus aucune cible de navigation compilée de référence n'est disponible, le parcours de la liste reprend à partir de la cible de référence en 805 (avec itérations sur 806. On observe que l'itération passant par l'étape 809 consiste à faire varier la cible de navigation compilée référence depuis la cible de navigation compilée courante jusqu'à la dernière cible de navigation compilée de la liste.. Si le résultat de l'étape 809 est positif, on passe à la cible de navigation compilée suivante et, au cours d'une étape 810, on détermine si la cible de navigation compilée suivante, récupérée depuis la liste courante de cibles de navigation compilées, est pertinente. Sinon, le compilateur 221 compare son test de noeud au test de noeud de référence, au cours d'une étape 811. Si le test de noeud courant a la même valeur que le test de noeud de référence, au cours d'une étape 812, la cible de navigation compilée de référence est mise à jour avec les liens de la cible de navigation compilée courante. Enfin, au cours d'une étape 813, la cible de navigation compilée courante (obtenue en 809) est détruite puisque regroupée dans la cible de navigation compilée de référence et on retourne à l'étape 809. Si le résultat de l'étape 810 est positif, la cible de navigation compilée étant détectée comme pertinente, le compilateur 221 retourne à l'étape 809. De même, si la comparaison entre les tests de noeuds de l'étape 811 est négatif, on retourne à l'étape 809, et ce jusqu'à atteindre la fin de la liste courante. Dans ce cas, le résultat de l'étape 809 est négatif et on retourne à l'étape 805 où l'on vérifie si la cible de navigation compilée courante a une cible de navigation compilée suivante. Si tel est le cas, on retourne à l'étape 806. Sinon, le traitement est terminé pour la liste de cibles de navigation compilées courante récupérée au cours de l'étape 801). Lorsque le résultat de l'étape 805 est négatif, au cours d'une étape 814, on passe à la profondeur suivante et on retourne à l'étape 801 jusqu'à atteindre une profondeur pour laquelle il n'existe aucune cible de navigation compilée, le résultat de l'étape 802 étant alors négatif. La mise à jour des liens, au cours de l'étape 812, consiste pour une cible de navigation compilée courante Ci et une cible de navigation compilée de référence Cref données, à ajouter la ou les prochaines cibles de navigation compilées de Ci à la liste des cibles de navigation compilées filles de Cref. La suppression des cibles de navigation compilées redondantes ainsi que les liens vers les destinataires des résultats sont illustrés par des exemples en figures 8 et 9. En figure 8, dans l'expression de gauche 950, on voit qu'en cas d'appel de fonction contenant plusieurs chemins de localisation, la majorité des cibles de navigation compilées associées à ces chemins peuvent se regrouper. Sur l'exemple de droite 951, où les chemins de localisation contiennent parfois des prédicats, on constate que les cibles de navigation compilées nommées � author � ne sont pas factorisées. Ceci est dû au fait que l'une se trouve être à la feuille de l'arbre de navigation, donc pertinente, alors que la seconde se trouve être une cible de navigation compilée intermédiaire non pertinente. La cible nommée � book � sur l'exemple de droite se trouve factorisée car uniquement une de ses filles possède un prédicat, l'autre ayant comme destinataire son chemin de localisation parent. Le fait de ne pas factoriser des cibles de navigation compilées ayant le même test de noeud mais des prédicats différents permet d'éviter un filtrage des solutions arrivant sur cette cible de navigation compilée. Si de telles cibles de navigation compilée étaient factorisées, cela impliquerait de devoir identifier sur lequel des résultats l'un des prédicats a été évalué à � vrai � ou à � faux �. Cela empêcherait toute remontée directe de résultat et ralentirait l'évaluation des expressions XPath. Une fois l'ensemble des cibles de navigation compilées construites pour l'ensemble des expressions XPath, leur évaluation peut débuter. La figure 9 représente un exemple de représentation interne, avant la factorisation de l'étape 515, sur laquelle se base l'évaluation. Sur cet exemple, deux expressions 900 sont considérées et décomposées en un arbre d'instructions 901 et un arbre de navigation 902. La racine 903 de l'arbre d'instructions regroupe les expressions 900. L'arbre de navigation 902 contient l'ensemble des cibles de navigation compilées créées lors de l'étape 512. Ces cibles de navigation compilées représentent les étapes de chemin de localisation (� Step �) des expressions 900. La cible de navigation compilée 910 correspond à la racine de l'arbre de navigation. Les cibles de navigation compilées 915 et 916 correspondent à des cibles de navigation compilées ayant été factorisées comme décrit en regard de la figure 7. Les cibles de navigation compilées, 911, 913 et 914, sont celles qui permettent de résoudre une expression de type chemin de localisation : - la cible de navigation compilée 911 correspond aux résultats pour le chemin de localisation 907, - la cible de navigation compilée 913 aux résultats pour le chemin de localisation 908 et - la cible de navigation compilée 914 aux résultats pour le chemin de localisation 909. Ces cibles de navigation compilée 911, 913 et 914 ont, chacune, un lien, respectivement 904, 905 et 906 vers un destinataire de résultats. Les figures 10 et 11 concernent une évaluation d'une expression XPath, qui se déroule en deux étapes. La première étape consiste à lancer l'exécution de toutes les sous expressions associées aux noeuds de l'arbre d'instructions construit au cours de l'étape 508. Tout d'abord, le noeud racine de l'arbre d'instructions, 903 sur l'exemple de la figure 9, est récupéré au cours d'une étape 1000. A partir de ce noeud racine, on détermine, au cours d'une étape 1001, si le noeud suivant est une feuille de l'arbre d'instructions, par exemple 907 ou 908 sur l'exemple de la figure 9, et, sinon, au cours d'une étape 1010, la sous expression associée au noeud voit son statut d'évaluation mis à � en cours de traitement � et on passe au noeud suivant. Puis, on réitère l'étape 1001. Lorsque le résultat de l'étape 1001 est positif, une feuille de l'arbre d'instructions étant atteinte, au cours d'une étape 1002, l'exécution de la sous expression associée est activée. Puis, au cours d'une étape 1003, on détermine si un résultat est disponible sans avoir besoin d'informations XML. Si oui, ce résultat est propagé à la sous expression parente, c'est-à-dire au noeud précédent dans l'arbre, lors d'une étape 1006. Puis, au cours d'une étape 1007, on effectue une propagation, ou remontée, du résultat. Pour un noeud parent possédant plusieurs fils, le résultat est mis en attente de résultat de tous les fils afin d'agréger les résultats des noeuds fils pour calculer le résultat du noeud parent, au cours d'une étape 1008. La propagation du résultat du noeud reprend quand tous les noeuds fils ont un résultat qui permet l'agrégation au cours de l'étape 1008. Suite à cette agrégation, la remontée de résultat se poursuit lors de nouvelles itérations des étapes 1006 à 1008 jusqu'à atteindre le noeud racine 903 de l'arbre d'instructions 901, ce qui correspond à un résultat du test 1006 négatif. Lorsque ce noeud est atteint, le résultat courant correspond à un résultat pour une des expressions XPath et est donc émis vers l'application au cours d'une étape 1009. Si le résultat de l'étape 1003 est négatif, ce qui indique que la sous expression associée à une feuille de l'arbre d'instructions 901 n'a pas de résultat disponible (typiquement une sous expression de navigation), lors d'une étape 1004, la sous expression est mise en attente de données XML. A titre d'exemple, en figure 9, les feuilles de l'arbre d'instructions sont les LocationPath 907 et 908 correspondant, pour la première, à l'argument de l'appel de fonction à � string � et, pour la seconde, à l'expression du chemin principal de la deuxième expression. Typiquement, le résultat de l'étape 1003 est négatif et ces deux sous expressions sont alors mises en attente de données XML à l'étape 1004. La LocationPath 909 est un cas particulier car elle représente une expression de type prédicat. Son évaluation est déclenchée par la cible d'évaluation (voir description de la seconde étape ci-dessous) correspondant à la cible de navigation compilée sur laquelle porte ce prédicat, de référence 913 sur l'exemple de la figure 9. L'étape 1004 consiste à insérer, au niveau du gestionnaire de cibles d'évaluation 271, la ou les cibles d'évaluation correspondant à la ou aux cibles de navigation compilées racines 910 de l'arbre de navigation 902. Puis, au cours d'une étape 1005, on détermine si un noeud parent existe. Si oui, on retourne à l'étape 1001. Sinon, le traitement s'achève. L'étape 1005 permet ainsi de poursuivre le parcours des autres branches de l'arbre d'instructions 901 jusqu'à ce que l'arbre d'instructions ait été intégralement parcouru. La seconde étape principale du traitement consiste en la récupération des informations XML 104 en vue de la résolution des sous expressions mises en attente de données XML à l'étape 1004, typiquement les sous expressions de navigation identifiées au cours de l'étape 507. C'est le contrôleur d'exécution 222 qui prend en charge cette partie, aidé par le gestionnaire de cibles d'évaluation 271. La suite du traitement se déroule selon les étapes illustrées en figure 11. On note ici qu'à une cible de navigation compilée correspond au moins une cible d'évaluation. Comme leurs noms l'indiquent, les cibles de navigation compilées sont construites par le compilateur 221 et servent de support à l'évaluation des expressions par le contrôleur 222 qui, via son gestionnaire de cibles d'évaluation 271, crée, au moment d'évaluer une étape de chemin de localisation, une cible d'évaluation qui porte les informations relatives au statut de l'exécution. Cette distinction entre cibles de navigation compilées et cibles d'évaluation permet de conserver l'arbre de navigation regroupant l'ensemble des cibles de navigation compilées intact en vue d'évaluations multiples ou en parallèle. De plus, l'information de destinataire calculée en 610 ou 615 est également présente dans la cible d'évaluation car la propagation de résultats s'effectue sur l'ensemble des cibles d'évaluation et non sur les cibles de navigation compilées. Comme on l'observe en figure 11, lors d'une étape 1100, le navigateur XML 203 est initialisé avec le document XML 204 sur lequel l'application 201 évalue une ou plusieurs expressions XPath. Puis, au cours d'une étape 1101, on détermine si le navigateur XML 203 est prêt à envoyer des évènements XML. Sinon, l'évaluation est impossible. Si oui, le gestionnaire de cibles d'évaluations 271 crée une ou plusieurs cibles d'évaluation initiales associées à la ou aux cible(s) de navigation compilée(s) racine(s) de l'arbre d'évaluation, référencée 910 de l'exemple de la figure 9. Au cours d'une étape 1102, ces cibles d'évaluation racines sont validées, ont leur statut d'évaluation mis à la valeur � solution intermédiaire �. Le gestionnaire de cibles d'évaluation 271 positionne son indice de profondeur à � 0 �, correspondant au maintien de la profondeur, dans le document XML ou par rapport au contexte d'évaluation initial, puis prépare les prochaines cibles d'évaluation devant être vérifiées, lors d'une étape 1103. Cette étape 1103 est décrite en référence à la Figure 15. A la suite de l'étape 1103, au cours d'une étape 1104, le processeur XPath 202 reçoit, dans le cas mettant en oeuvre le � push �, ou demande, dans le cas mettant en oeuvre le � pull � un évènement XML 204 via le navigateur XML 203. Cet évènement 204 est sauvegardé en mémoire du navigateur XPath 223 sous forme d'un noeud XPath. Les étapes suivantes 1105, 1107 et 1108, consistent à comparer le type d'évènement XML reçu par rapport aux différents types possibles : - l'étape 1105 détermine s'il s'agit d'un début d'élément XML et, si oui, on passe à une étape 1106 ; -sinon, l'étape 1107 détermine s'il s'agit d'une fin de document et, si oui, l'étape d'évaluation s'achève, - sinon, l'étape 1108 détermine s'il s'agit d'une fin d'élément XML et, si oui, on passe à une étape 1109 et -sinon, on passe à une étape (non représentée) réalisant l'équivalent des étapes 1106 et 1109 ; En effet, c'est alors un événement signalant un noeud XML de type texte ou commentaire, et les noeuds texte et commentaire sont décomposés en deux évènements, l'un de début du noeud et l'autre de fin du noeud. Dans le cas d'un début de noeud XPath, lors de l'étape 1106, le gestionnaire de cibles d'évaluation 271 incrémente son indice de profondeur de � 1 � lors d'une étape 1200 (voir figure 12). Puis le gestionnaire de cibles d'évaluation 271 récupère, au cours d'une étape 1201, la première cible d'évaluation dans la liste de cibles d'évaluation correspondant à la profondeur courante. Cette liste de cibles d'évaluation est préparée au cours de l'étape 1103, la première fois, puis au cours de l'étape 1211, les fois suivantes. Puis, au cours d'une étape 1202, on détermine si au moins une cible d'évaluation est présente dans cette liste de cibles d'évaluation. Si oui, le test de noeud (NodeTest) correspondant est sélectionné lors d'une étape 1203. Ce test de noeud est récupéré via la cible de navigation compilée associée à la cible d'évaluation courante. Sinon, l'étape 1106 se termine et on passe à l'évènement XML suivant au cours de l'étape 1104. En référence à l'exemple de la figure 9, à la profondeur � 1 �, trois cibles de navigation compilées sont sélectionnées, qui font appel à deux tests différents sur le noeud : � book � et � bookstore �. Le test de noeud correspondant à la cible d'évaluation sélectionnée au cours de l'étape 1201 est sélectionné lors de l'étape 1203 puis, au cours d'une étape 1204, on détermine si ce test de noeud a déjà été résolu pour la profondeur courante. Si c'est le cas, au cours d'une étape 1206, la cible d'évaluation courante a son statut d'évaluation mis à jour en fonction du résultat du test de noeud. Si le test de noeud n'a pas déjà été résolu, il l'est lors d'une étape 1205 qui consiste à réellement effectuer les tests sur le noeud XPath courant. Selon la spécification XPath, il peut s'agir de tester soit le nom, soit le type du noeud XPath courant. Après résolution du test sur le noeud, le statut d'évaluation de la cible d'évaluation courante est mis à jour au cours de l'étape 1206. Au cours de cette étape 1206, le statut d'évaluation de la cible d'évaluation peut prendre différentes valeurs : - � Solution potentielle �, Si la cible d'évaluation contient des prédicats et que sa cible de navigation compilée associée correspond à une feuille de l'arbre de navigation 902. Dans ce cas, chaque prédicat associé est activé (voir l'expression 912 dans l'exemple de la figure 9) ; - � Solution potentielle intermédiaire �, Si la cible d'évaluation contient des prédicats et que sa cible de navigation compilée associée ne correspond pas à une feuille de l'arbre de navigation 902. Dans ce cas aussi, chaque prédicat associé est activé, - � Solution intermédiaire �, Si la cible d'évaluation est entièrement atteinte et si sa cible de navigation compilée associée n'est pas une feuille de l'arbre de navigation, - � Solution �, Si la cible d'évaluation est entièrement atteinte et que sa cible de navigation compilée associée est une feuille de l'arbre de navigation et - � Sans Solution �, Si la cible d'évaluation n'est pas atteinte. Puis, au cours d'une étape 1207, on détermine si, au cours de l'étape 1206, au moins une cible d'évaluation a atteint le stade � Solution �. Si oui, le noeud courant est propagé vers le destinataire de la cible d'évaluation courante, lors d'une étape 1208. Sinon, au cours d'une étape 1209, on détermine si le statut de la cible d'évaluation est la valeur � Sans Solution�. Si oui, on passe à la cible d'évaluation suivante dans la liste au cours d'une étape 1210 et on retourne à l'étape 1202. Sinon, au cours d'une étape 1211, on prépare la ou les prochaines cibles d'évaluation filles de la cible d'évaluation courante puis on passe à l'étape 1210. On note que les deux tests combinés 1207 et 1209 permettent, respectivement, de faire remonter un résultat pour une branche de l'arbre de navigation ou d'arrêter la recherche le long d'une branche de l'arbre. Les autres valeurs de statuts d'évaluation (� solution intermédiaire �, � solution intermédiaire potentielle � et � solution potentielle �) conduisent à l'étape 1211, décrite en référence à la Figure 15. Lorsqu'il n'y a plus de cible d'évaluations à tester pour la profondeur courante, le résultat de l'étape 1202 étant négatif, l'étape 1106 se termine et on retourne à l'étape 1104 jusqu'à ce que la fin du document soit atteinte. La propagation des résultats de l'étape 1208 consiste, pour une cible d'évaluation dont le statut vaut � Solution �, à propager le noeud résultat vers une cible d'évaluation parente pertinente ou bien directement jusqu'au chemin de localisation parent. Typiquement, sur l'exemple de la figure 9, la cible de navigation 911 aurait son statut mis à � Solution � sur un début d'élément XML nommé � title �. La propagation du résultat 1208 consiste à faire remonter le noeud XPath représentant cet évènement jusqu'au chemin de localisation parent 907. Ensuite, ce résultat est transmis à l'instruction correspondant au chemin de localisation 907 mise en attente de données XML au cours de l'étape 1004. Pour cela, comme exposé en regard de la figure 13, qui donne le détail de l'étape 1208, on cherche le destinataire des résultats de la cible d'évaluation courante. Au cours d'une étape 1300, on détermine si le destinataire des résultats de la cible d'évaluation courante est son chemin de localisation parent. Si oui, le résultat est fourni au chemin de localisation parent (LocationPath) au cours d'une étape 1301 et on retourne à l'étape 1208. Ensuite, on détermine, au cours d'une étape 1212, si ce résultat permet d'éliminer l'ensemble des sous expressions de navigation en attente de données XML à l'étape 1004. Si oui, l'évaluation est terminée. Sinon, le traitement se poursuit au cours de l'étape 1210. Si le test 1300 sur le destinataire des résultats indique que celui-ci ne correspond pas à un chemin de localisation, il correspond à une de ses cibles d'évaluation parentes. Le résultat est alors transmis à ladite cible d'évaluation parente, lors d'une étape 1302. Puis, au cours d'une étape 1303, on détermine si le statut d'évaluation de cette cible d'évaluation parente est � solution intermédiaire �. Si oui, on retourne à l'étape 1300, jusqu'à atteindre soit le chemin de localisation parent, soit une cible d'évaluation parente dont le statut d'évaluation est différent de � solution intermédiaire �. Si le résultat du test 1303 est négatif, au cours d'une étape 1304, on détermine si le statut vaut � solution potentielle intermédiaire �. Si oui, le résultat est mis en attente au niveau de cette cible d'évaluation, lors d'une étape 1305, jusqu'à sa résolution complète. Si le résultat de l'étape 1304 est négatif ou à la suite de l'étape 1305, on retourne à l'étape 1208. Le passage de � solution potentielle � à � solution � (intermédiaire ou non) se fait lors de l'étape 1007 où, par exemple, une sous expression représentant un prédicat, par exemple 912 en figure 9, possède un résultat et le transmet à sa cible d'évaluation parente, 913 en figure 9. Si le résultat de l'étape 1108 est positif, c'est-à-dire dans le cas d'une fin de noeud XPath, au cours de l'étape 1109, on désactive les cibles d'évaluation appartenant à la liste de cibles d'évaluation correspondant à la profondeur courante du gestionnaire de cibles d'évaluation 271, au cours d'une étape 1400 illustrée en figure 14. La désactivation peut consister soit à enlever ces cibles d'évaluation de la pile de cibles d'évaluation, soit à leur associer un statut � active � / � inactive � qui est, dans ce cas, initialisé à � inactive �. Puis, au cours d'une étape 1401, on détermine si, parmi les cibles d'évaluation à désactiver, au moins une correspond à une cible d'évaluation racine (information portée par le type de la cible de navigation compilée associée). Si oui, au cours d'une étape 1402, un signal est envoyé au chemin de localisation (LocationPath) parent indiquant qu'aucune solution n'a été trouvée pour le contexte d'évaluation courant. Cela permet de débloquer des sous expressions en attente de données XML au cours de l'étape 1004 et de remonter un résultat vide au cours des étapes 1006 à 1008 et, éventuellement, d'émettre un résultat d'évaluation au cours de l'étape 1009. Puis, au cours d'une étape 1403, on détermine si cette propagation a conduit à une fin d'évaluation. Si oui, l'évaluation s'achève. Sinon, au cours d'une étape 1404, la profondeur courante est décrémentée de � 1 �. Au cours d'une étape 1405, on détermine si la profondeur courante vaut � 0 �. Si oui, l'évaluation s'achève car cela signifie que l'on a atteint la fin des données XML 204. Sinon, au cours d'une étape 1406, les cibles d'évaluation se trouvant à la nouvelle profondeur courante sont réinitialisées par le biais des statuts d'évaluation et des statuts des tests de noeud (NodeTest) associés, en vue d'une évaluation sur de nouvelles données XML au cours de l'étape 1004 si toutefois l'étape 1110 n'a pas déterminé que la fin d'évaluation est atteinte. Les étapes de la Figure 15 décrivent la préparation de la liste de cibles d'évaluation à vérifier pour le prochain niveau de profondeur, ce qui détaille, en particulier, les étapes 1103 et 1211. Pour cela, le gestionnaire de cibles 271 récupère, au cours d'une étape 1500, la liste de cibles d'évaluation correspondant au niveau de profondeur courant. La première cible d'évaluation de cette liste de cibles d'évaluation est alors considérée comme la cible d'évaluation courante, au cours d'une étape 1501. Puis le gestionnaire de cibles d'évaluation récupère, au cours d'une étape 1502, la cible de navigation compilée associée à la cible d'évaluation courante. Il récupère ensuite, au cours d'une étape 1503, la liste des cibles de navigation compilées filles de la cible de navigation compilée trouvée au cours de l'étape 1502. Pour chacune de ces cibles de navigation compilées filles, il crée une cible d'évaluation associée, au cours de l'étape 1504. Chaque cible d'évaluation ainsi créée est ensuite insérée dans la pile de cibles du gestionnaire de cibles 271, au cours d'une étape 1505. A cette occasion, chaque cible d'évaluation créée a une relation fille-parente qui est initialisée avec la cible d'évaluation courante. L'étape d'insertion d'une nouvelle cible d'évaluation, au cours d'une étape 1505, est dépendante de la nature de sa cible de navigation compilée et notamment de la valeur de l'axe (AxisSpecifier). Si la valeur de l'axe � descendant �, � ancêtre � ou � descendant ou réflexif � ou encore � ancêtre ou réflexif �, la cible de navigation compilée est à propager pour tous les niveaux de profondeur rencontrés au cours de l'évaluation. Si la valeur de l'axe est � réflexif �, � attribut � ou � espace de nom �, la cible d'évaluation courante est à insérer au même niveau que la cible courante lors de l'étape 1505 et non au prochain niveau de profondeur. Ensuite, au cours d'une étape 1506, un éventuel destinataire est associé à chaque cible d'évaluation. En effet, si, pour une cible d'évaluation créée lors de l'étape 1504, la cible de navigation compilée associée a un destinataire qui correspond à une cible parente, alors il est nécessaire d'insérer dans la cible d'évaluation associée un destinataire. Sinon, dans le cas d'un destinataire correspondant à un chemin de localisation, la cible d'évaluation y accède via sa cible de navigation compilée et n'a donc pas besoin de son propre destinataire. Dans le cas d'un destinataire propre à la cible d'évaluation, ce destinataire correspond à la première cible d'évaluation parente dont la cible de navigation compilée associée est pertinente. Une fois les éventuels calculs de destinataires effectués, le gestionnaire de cibles d'évaluation 271 passe à la cible d'évaluation suivante dans la liste de cibles d'évaluation courante au cours d'une étape 1507. S'il en existe une, elle devient la cible d'évaluation courante au cours d'une étape 1508 puis le gestionnaire de cibles d'évaluation répète les étapes 1502 à 1507 jusqu'à ce que la fin de la liste de cible d'évaluation courante soit atteinte au cours de l'étape 1507. Une fois la fin de la liste de cibles d'évaluation atteinte au cours de l'étape 1507, le gestionnaire de cibles d'évaluation 271 passe à l'étape 1509, au cours de laquelle il détermine si, dans l'arbre d'évaluation, pour la profondeur courante, il reste des cibles de navigations compilées qui n'ont pas été traitées. Ceci permet de traiter le cas des axes correspondant à des relations d'ascendance (� parent �, � ancêtre � ou � ancêtre-ou-réflexif �). Si le résultat de l'étape 1509 est positif, les cibles d'évaluation associées sont créées au cours d'une étape 1510 et insérées dans la liste de cibles d'évaluation courante du gestionnaire de cibles d'évaluation 271, au cours d'une étape 1511. Les destinataires de ces cibles d'évaluation construites en avance par rapport à leur cible d'évaluation parente auront leur destinataire mis à jour lorsque la cible de navigation compilée associée parente de leur propre cible de navigation compilée associée sera traitée au cours de l'étape 1502. A la suite de l'étape 1511 ou si le résultat de l'étape 1509 est négatif, l'étape de préparation des prochaines cibles d'évaluation se termine. Comme on le comprend à la lecture de la description qui précède, la mise en oeuvre de la présente invention fournit un moyen d'évaluer des expressions XPath à la volée. Ceci est permis par une analyse de ces expressions afin de préparer et de faciliter la gestion des résultats dès que le processeur doit traiter simultanément au moins deux chemins de localisation (LocationPath), qu'il s'agisse d'une seule expression contenant elle-même plusieurs chemins de localisation ou bien de plusieurs expressions à évaluer sur un même document. De plus, l'invention permet, par l'analyse des expressions, de réduire la taille de la représentation interne sur laquelle s'appuie l'évaluation, tout en préservant la simplicité de propagation des résultats. Les avantages en découlant sont rappelés ici : - l'efficacité car le parcours du document XML est unique, - l'émission des résultats dès qu'ils sont calculés, - le traitement simple des noeuds XML résultats avec un stockage minimum, - l'évaluation efficace du fait de la factorisation de calculs et de la résolution a priori des AxisSpecifiers, - l'analyse réutilisable, la représentation interne calculée une fois peut être évaluée plusieurs fois sur le même document ou sur des documents différents et - le support d'expression mixant des appels de fonction ou des opérations avec des expressions purement de navigation. REVENDICATIONS 1 - Procédé d'analyse d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte : - une étape d'identification (104a, 505) d'au moins une sous-expression de navigation d'au moins une expression à évaluer, au moins une dite sous-expression de navigation comportant au moins une étape de chemin de localisation, - une étape de représentation (512) de chaque dite étape de chemin de localisation de chaque dite sous-expression de navigation, sous forme de cible de navigation compilée, structure représentant la recherche d'informations correspondant à ladite étape de chemin de localisation dans le document structuré, et, pour chaque étape de chemin de localisation : - une étape de détermination (104c, 610, 615) d'un destinataire du résultat d'une évaluation de ladite étape de chemin de localisation et - une étape d'ajout (702, 704, 707), dans la cible de navigation compilée de ladite étape de chemin de localisation, d'une information d'identification dudit destinataire. 2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination d'un destinataire, on détermine une cible de navigation compilée destinataire du résultat d'une évaluation de ladite étape de chemin de localisation. 3 û Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce qu'il comporte une étape d'organisation des cibles de navigation compilées en fonction de leur profondeur et une étape de liaison des dites cibles de navigation compilées entre elles (609). 4 û Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape de liaison, on construit des branches d'un arbre de navigation par l'insertion de cibles de navigation compilées (609).5 û Procédé selon la revendication 4, caractérisé en ce que, au cours de l'étape d'insertion, on insère la cible de navigation compilée courante dans l'arbre de navigation (609) qui représente le chemin de localisation courant, en fonction de la valeur de l'axe de la cible de navigation compilée courante. 6 û Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte une étape de détermination de cibles de navigation compilées intermédiaires redondantes et une étape de fusion des cibles de navigation compilées intermédiaires redondantes (812 et 813). 7 û Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, au cours de l'étape de représentation, on renseigne un champ de la cible de navigation compilée pour y indiquer à quel chemin de localisation ladite cible de navigation compilée appartient (512). 8 û Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que chaque dite expression est une expression XPath. 9 - Procédé selon la revendication 8, caractérisé en ce que l'étape de représentation comporte : - une étape de détermination d'une valeur d'axe correspondant à l'étape de chemin de localisation courante, - une étape d'identification d'un test de noeud auquel doit satisfaire tout noeud candidat à la résolution de l'étape de chemin de localisation courante et - une étape d'identification d'au moins un prédicat associé à l'étape de localisation courante. 10 û Procédé selon la revendication 9, caractérisé en ce qu'il comporte une étape de regroupement (515) de cibles de navigation compilées en fonction de tests de noeuds associés aux dites cibles de navigation compilées. 11 û Procédé selon la revendication 10, caractérisé en ce que, au cours de l'étape de regroupement, pour au moins deux cibles de navigation compilées correspondant au même niveau de profondeur, on détermine si les tests de noeud ont la même valeur (811) et, si oui, l'une des cibles est mise à jour avec les valeurs de liens de cible de navigation compilée fille et d'éventuels prédicats, de l'autre cible de navigation compilée.12 û Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que, si au moins un prédicat est identifié, on conserve au niveau de la cible de navigation compilée courante, un lien vers la première cible de navigation compilée de chaque prédicat (605). 13 û Procédé selon la revendication 12, caractérisé en ce que, si au moins un prédicat est identifié, la cible de navigation compilée courante garde un lien vers chaque sous expression qui correspond au dit prédicat (606). 14 û Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que, pour déterminer ledit destinataire, on détermine si une cible de navigation compilée parente existe et, si oui, on détermine si cette cible de navigation compilée parente contient au moins un prédicat (701) et, si cette cible de navigation compilée parente ne contient aucun prédicat, le destinataire des résultats de la cible de navigation compilée parente devient le destinataire des résultats de la cible de navigation compilée courante (702). 15 û Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que, pour déterminer ledit destinataire, on détermine si une cible de navigation compilée parente existe et, si oui, on détermine si cette cible de navigation compilée parente contient au moins un prédicat (701) et, si oui, la cible de navigation compilée parente devient le destinataire des résultats d'évaluation de la cible de navigation compilée courante (704). 16 - Procédé d'évaluation d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte les étapes du procédé d'analyse selon l'une quelconque des revendications 1 à 15 et une étape d'évaluation de chaque dite expression en mettant en oeuvre au moins une dites cibles de navigation compilées incorporant une identification du destinataire de résultat d'évaluation d'une étape de chemin de localisation d'une sous-expression de navigation d'une dite expression (107, 108, 109). 17 û Procédé selon la revendication 16, caractérisé en ce que, au cours de l'étape d'évaluation, on effectue une évaluation à la volée. 18 û Procédé selon l'une quelconque des revendications 16 ou 17, caractérisé en ce qu'il comporte une étape de génération de cibles d'évaluation, à une ciblede navigation compilée correspondant au moins une cible d'évaluation qui porte les informations relatives au statut de l'évaluation. 19 û Procédé selon la revendication 18, caractérisé en ce que, au cours de l'étape d'évaluation, on récupère, d'une part, un test de noeud en fonction du contenu d'une cible de navigation compilée associée à la cible d'évaluation courante et, d'autre part, un noeud et on détermine si ledit noeud respecte ledit test de noeud. 20 û Procédé selon la revendication 19, caractérisé en ce que, au cours de l'étape d'évaluation, si une cible d'évaluation est résolue et si ladite cible d'évaluation est une feuille d'un arbre de navigation, le noeud courant est propagé vers le destinataire associé à la cible d'évaluation courante (1208). 21 û Procédé selon l'une quelconque des revendications 16 à 20, caractérisé en ce que, au cours de l'étape d'évaluation, si une cible d'évaluation destinataire, autre que la racine d'un arbre de navigation, reçoit un noeud XML solution, celui-ci est utilisé pour la résolution de ladite cible d'évaluation et, si ce noeud XML permet d'obtenir un résultat pour cette cible d'évaluation, ce résultat est émis vers la cible destinataire associée à la cible d'évaluation courante. 22 - Dispositif d'analyse d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte : - un moyen d'identification d'au moins une sous-expression de navigation d'au moins une expression à évaluer, au moins une dite sous-expression de navigation comportant au moins une étape de chemin de localisation, - un moyen de représentation de chaque dite étape de chemin de localisation de chaque dite sous-expression de navigation, sous forme d'une cible de navigation compilée, - un moyen de détermination d'un destinataire du résultat d'une évaluation de chaque étape de chemin de localisation et - un moyen d'ajout, dans la cible de navigation compilée de ladite étape de chemin de localisation, d'une information d'identification dudit destinataire.23 -Dispositif d'évaluation d'au moins une expression composée de sous-expressions à évaluer sur un document structuré, caractérisé en ce qu'il comporte un dispositif selon la revendication 22 et un moyen d'évaluation de chaque dite expression en mettant en oeuvre au moins une des dites cibles de navigation compilées incorporant une identification du destinataire de résultat d'évaluation d'une étape de chemin de localisation d'une sous-expression de navigation d'une dite expression. 24 - Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'analyse selon l'une quelconque des revendications 1 à 15 et/ou du procédé d'évaluation selon l'une quelconque des revendications 16 à 21. 25 - Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé d'analyse selon l'une quelconque des revendications 1 à 15 et/ou du procédé d'évaluation selon l'une quelconque des revendications 16 à 21.