Brevet FR2908539A1 — publié le 20080516

La présente invention se rapporte à un procédé et un dispositif d'évaluation d'une expression, notamment d'une expression de type XPath sur les données contenues dans un document structuré. Elle trouve une application générale dans le traitement de flux de données XML et plus précisément sur des fichiers au format XML. 15 Le langage XPath (acronyme de XML Path Language ) est issu d'une spécification du consortium W3C appelée Spécification XPath 1.0 , 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. 20 La syntaxe de ce langage utilise une syntaxe similaire à celle utilisée dans les expressions relatives à des chemins de localisation dans un système de fichiers, par exemple l'expression relative à un chemin de localisation /librairie/livre . Le langage XPath définit quatre types de données qui sont 25 chaîne , booléen , nombre et ensemble de noeuds , sept types de noeuds et des expressions permettant de manipuler 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 peuvent représenter différents 30 types d'évènement XML, par exemple le début du document (aussi appelé le noeud racine), un élément, un attribut, un texte, un commentaire, une instruction de traitement ( processing-instruction en terminologie anglo-saxonne) et un 1 2908539 2 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 5 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 10 d'applications aptes à parcourir des données dans des documents structurés de 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 15 XML mémorisées dans un document ou reçues via une transmission réseau, le 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 20 exemple, les expressions OrExpr, AndExpr, RelativeExpr, EqualityExpr), les 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 25 LocationPath correspondant à la spécification d'un chemin à résoudre dans un document XML). L'invention est particulièrement adaptée aux expressions relatives à un chemin de localisation ( LocationPath selon la syntaxe du langage XPath). 30 Une expression relative à un chemin de localisation peut-être absolue ou relative selon qu'elle commence par / ou non. Dans le cas d'une expression relative à un chemin absolue, la recherche commence depuis le 2908539 3 début du document, aussi appelé racine, alors que dans le cas d'une expression relative à un chemin relative, la recherche est contextuelle, par exemple depuis le noeud courant. Toute expression relative à un chemin de localisation est composée 5 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 relative à un 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 25 entités suivantes. Tout d'abord, l'entité exprimant une filiation, aussi appelé axes, ( 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 exemple, les expressions /a/child ::b et /a/attribute ::b 30 signifient que l'on recherche, respectivement, un noeud b fils d'un noeud a et un noeud représentant un attribut b fils d'un noeud a . La spécification définit 13 types d'entité exprimant une relation de filiation 2908539 4 ( 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 5 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 10 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 ( textO selon la syntaxe XPath), la contrainte de 15 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::commentO permet de rechercher 20 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 fils de nom b de chaque noeud de type élément 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 de nom a possédant un attribut id ayant une valeur égale à 3. L'implémentation actuelle du langage XPath permet d'accéder à des parties d'un document XML après avoir construit une représentation 2908539 5 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 5 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 10 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 couteuse 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. L'évaluation à la volée d'une expression XPath consiste dans le cas 15 idéal à traiter les évènements XML au fur et à mesure de leur réception par le processeur XPath. Ainsi à chaque évènement reçu, le processeur XPath décide si le noeud satisfait ou non les contraintes de l'étape de localisation courante et ce jusqu'à la dernière étape de localisation exprimée dans l'expression relative à un chemin de localisation. Toutefois, la détermination du respect des 20 contraintes d'un évènement XML n'est pas toujours possible au moment où le processeur XPath reçoit et traite cet évènement. Ceci est particulièrement le cas lorsque l'expression relative à un chemin de localisation contient des prédicats. L'exemple illustré en Figure 1 comprend un exemple d'un document XML (0.1) où chaque ligne lue représente 25 un événement à traiter (0.2). Il est illustré par l'évaluation de l'expression /a/b[b] . Cette évaluation va produire comme résultat lorsque l'évènement b0 sera reçu (0.3). En outre, un problème additionnel est le problème des solutions emboitées. Celui-ci correspond à l'application des entités exprimant une filiation 30 de type descendant ( descendant selon la syntaxe XPath) et de type descendant ou noeud contexte ( descendant-or-self selon la syntaxe XPath) sur des documents XML récursifs. 2908539 6 Selon l'exemple illustré en Figure 1, une expression du type //b/c (i.e. /descendant-or-self.-:node0/b/c) qui consiste à rechercher tous les noeuds de type élément de nom c fils de noeud de type élément de nom b se trouvant à n'importe quelle profondeur du document XML pose les problèmes 5 suivants. Tout d'abord, lors de l'évaluation, la correspondance entre une étape de localisation et la profondeur dans le document XML est perdue. En effet, dans les expressions ci-dessus, la recherche n'est nullement limitée à la recherche des éléments b ayant une profondeur de deux et des éléments 10 c ayant une profondeur de trois. Ensuite, lors de la recherche d'éléments c résolvant l'étape de localisation de niveau trois, le processeur doit auparavant détecter les éventuels éléments b rencontrés comme solution de l'étape de localisation de niveau deux et sur lesquels des noeuds fils c sont recherchés. Ainsi, la 15 résolution de l'expression ci-dessus peut donc être vue comme la recherche du motif b/c à n'importe quel niveau de profondeur. L'évaluation à la volée, pour être complète, doit également permettre l'émission des résultats au fur et à mesure qu'ils sont déterminés. II est connu du document US2004068487 intitulé Method for 20 streaming XPath processing with forward and backward axes une méthode apte à évaluer des expressions à la volée dans laquelle les expressions XPath contenant des relations de filiation ascendante ( reverse axes selon la syntaxe XPath) sont ré-écrites. Cette méthode d'évaluation est réalisée à partir d'une représentation de l'expression sous la forme d'un arbre (XTree) du 25 document XML. Cet arbre permet d'obtenir des relations de filiation vers l'avant et donc de garantir un seul parcours du flux XML. Cependant, selon cette méthode, le processeur XPath doit analyser tous les noeuds fournis par un analyseur XML, ce qui peut conduire dans le cas des expressions les plus simples à un surcoût en temps d'évaluation. Pour chaque noeud ainsi reçu, le 30 processeur retourne un statut : solution , non solution ou solution potentielle . 2908539 7 Selon le document US20040172599 intitulé Systems and methods for streaming XPath queries , il est décrit un processeur XPath compatible avec un traitement à la volée. Selon cette méthode, le processeur reçoit des évènements d'un analyseur, décide du caractère de correspondance sur ces 5 évènements par rapport à une expression et informe une application utilisant les noeuds résultats. Cette solution possède les mêmes inconvénients que la précédente à savoir l'analyse exhaustive de tous les noeuds du flux XML. Compte tenu de ce qui précède, il serait par conséquent intéressant de pouvoir évaluer des expressions, notamment des expressions XPath à la 10 volée en limitant les parcours multiples et la mémorisation des données structurées 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é d'évaluation d'une expression pour accéder à au moins une partie d'un 15 document structuré au moyen d'au moins un navigateur apte à extraire les données structurées du document, l'expression étant composée d'au moins deux sous expressions relatives chacune à un chemin de localisation, caractérisé en ce qu'il comprend une étape d'évaluation de chacune des sous-expressions sur la base des données du document au moyen d'au moins un 20 navigateur distinct pour chaque sous-expression. Le procédé d'évaluation d'une expression, notamment une expression de type XPath, pour accéder à au moins une partie d'un document structuré au moyen d'au moins un navigateur apte à extraire les données structurées du document selon l'invention permet de déterminer les données du 25 document satisfaisant l'expression. L'expression est composée d'au moins deux sous expressions relatives chacune à un chemin de localisation. Selon l'invention, chacune des sous-expressions relatives à un chemin de localisation est évaluée sur les données du document à partir d'au moins un navigateur distinct. 30 Ainsi, il est permis d'évaluer des expressions à la volée en limitant, d'une part, le stockage de données du document structuré et d'autre part, les 2908539 8 parcours multiples du document structuré dans un mode optimisé. Le procédé permet, en outre, de fournir les résultats dès qu'ils sont calculés. Pour ce faire, le procédé conforme à l'invention utilise plusieurs navigateurs aptes à traiter les sous-expressions de l'expression. 5 Selon une caractéristique particulière, le procédé comprend une étape préalable de détermination du nombre de navigateurs. Ainsi, le nombre de navigateurs est choisi de manière à optimiser le traitement d'une expression donnée. Selon une autre caractéristique particulière, chaque sous-expression 10 relative à un chemin comprend un ensemble d'étapes de localisation. Selon une caractéristique particulière, chaque étape de localisation comprend au moins une entité exprimant une filiation entre les données structurées. Selon une autre caractéristique particulière, la filiation est une filiation 15 indirecte. Selon une caractéristique particulière, le procédé comprend une étape de détermination des sous-expressions ayant au moins une entité exprimant une filiation indirecte. Selon une caractéristique particulière, le procédé comprend une 20 étape de test approfondi sur ladite au moins une entité exprimant une filiation indirecte, le test approfondi étant fonction de conditions sur les données et sur les évaluations précédentes desdites données. Selon une caractéristique particulière, le procédé comprend : - une étape d'extraction des données sur la base desquelles les 25 sous-expressions sont évaluées ; et - une étape de mémorisation des données extraites. Le test approfondi, permet d'extraire des résultats et notamment d'éventuels résultats imbriqués (ou emboîtés) quelle que soit leur profondeur en ne stockant qu'une partie de leur historique et sans parcours multiple. 30 Selon une caractéristique particulière, lors de l'évaluation d'une seconde sous-expression faisant suite à une première sous-expression, ledit au 2908539 9 moins un navigateur de la seconde sous-expression est initialisé avec le contexte du navigateur de la première sous-expression. Ainsi, le navigateur utilisé pour analyser la seconde sous-expression est apte à reprendre le traitement au même niveau que le navigateur utilisé 5 pour la première sous-expression. Selon une caractéristique particulière, chacun desdits navigateurs pilote au moins un analyseur du document structuré. Selon une caractéristique particulière, si des navigateurs utilisent un même analyseur, les données extraites par un navigateur sont réutilisées par 10 un autre navigateur utilisant ce même analyseur. Selon une caractéristique particulière, le procédé comprend une étape de détermination des données extraites du document vérifiant l'ensemble des sous-expressions. Selon une caractéristique particulière, dès que des données sont 15 déterminées, lesdites données sont fournies à une application apte à traiter ces données. Selon l'invention, il est permis à une application d'obtenir les résultats de l'évaluation au fur et à mesure de la détermination des données satisfaisant à l'expression. 20 L'invention permet l'émission des données au fur et à mesure, ce qui permet de traiter les données plus rapidement au niveau de l'application, sans avoir à attendre le traitement complet et donc sans forcément recourir au stockage de ces résultats. Selon une caractéristique particulière, les données déterminées sont 25 mémorisées. Selon une caractéristique particulière, si des données déterminées ont une relation de filiation directe ou indirecte avec des données préalablement déterminées, alors ces données sont émises après les données préalablement déterminées. 30 En outre, selon cette caractéristique, les données satisfaisant l'expression sont émises dans l'ordre du document. 2908539 10 Ceci permet d'être compatible, notamment, avec la spécification XPath 1.0. Selon une caractéristique particulière, l'émission des données déterminées est précédée d'un signal de début et est suivi d'un signal de fin. 5 Ceci permet à l'application d'être informée du début et de la fin d'un résultat, ce qui lui permet de traiter immédiatement ce résultat. Ainsi, selon cette caractéristique, l'application qui reçoit les données satisfaisant l'expression n'a pas de séparation des résultats à effectuer. Corrélativement, l'invention vise également un dispositif d'évaluation 10 d'une expression pour accéder à au moins une partie d'un document structuré au moyen d'au moins un navigateur apte à extraire les données structurées du document, l'expression étant composée d'au moins deux sous expressions relatives chacune à un chemin de localisation, caractérisé en ce qu'il comprend des moyens d'évaluation de chacune des sous-expressions sur la base des 15 données du document au moyen d'au moins un navigateur distinct pour chaque sous-expression. Ce dispositif présente les mêmes avantages que le procédé d'évaluation d'une expression brièvement décrit ci-dessus et ils ne seront donc pas rappelés ici. 20 Selon d'autres aspects, l'invention concerne aussi des programmes d'ordinateur pour une mise en oeuvre du procédé de l'invention décrit brièvement ci-dessus. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui va suivre, cette description 25 étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, dans lesquels : -la figure 1 représente un exemple d'un document XML sur lequel une expression est évaluée; - la figure 2 illustre le contexte applicatif de l'invention ; 30 - la figure 3 représente de manière schématique un appareil dans lequel est mise en oeuvre l'invention ; 2908539 11 - la figure 4 illustre un algorithme de compilation d'une expression XPath conforme à l'invention ; - la figure 5 illustre un algorithme d'analyse des expressions de filiation conforme à l'invention ; 5 - la figure 6 représente un algorithme d'évaluation d'une expression XPath selon l'invention ; - la figure 7 illustre un algorithme d'évaluation des expressions de filiation selon l'invention ; - la figure 8 illustre un algorithme de recherche d'un noeud candidat 10 conformément à l'invention ; - la figure 9 illustre un algorithme de test selon le mode normal conformément à l'invention ; - la figure 10 illustre un algorithme de test selon le mode approfondi conformément à l'invention ; 15 - la figure 11 illustre l'évaluation d'une expression XPath sur un document XML selon l'invention ; - la figure 12 illustre un traitement du signal début de résultat par un navigateur conformément à l'invention ; - la figure 13 illustre un traitement de tout évènement XML extrait par 20 le navigateur ; et - la figure 14 illustre un algorithme traitant les résultats emboités. L'invention consiste à évaluer des expressions, notamment des expressions XPath, à la volée en limitant à la fois les parcours multiples et la 25 mémorisation de données, notamment de données XML pour accéder à au moins une partie d'un document structuré. Plus particulièrement, la description va porter sur l'évaluation des expressions relatives à un chemin de localisation ( LocationPath selon la syntaxe XPath) contenant des entités de type expression de filiation 30 ( AxisSpecifier selon la syntaxe XPath) descendant ( forward AxisSpecifier en terminologie anglo-saxonne), c'est-à-dire les entités qui 2908539 12 spécifient des relations de filiation ou de descendance de noeud par rapport à un noeud contexte donné. En outre, la description de l'invention comprend la fourniture à une application des résultats de l'évaluation au fur et à mesure de leur 5 détermination. Pour cela, le processeur XPath utilise plusieurs analyseurs XML aussi appelés navigateurs XML ( XML Parser en anglais). Tel que décrit ci-après, le nombre de navigateurs peut être déterminé par avance. Ces derniers peuvent être activés ou désactivés et ils peuvent être synchronisés dès que 10 nécessaire. De plus, l'invention permet de détecter et traiter les solutions emboitées, notamment en activant dès que nécessaire la mémorisation d'un historique des noeuds traités par l'analyseur et en réalisant un test approfondi sur ces noeuds. Toutefois, une étape préalable d'analyse des étapes de 15 localisation issues de la compilation est nécessaire. La Figure 2 illustre le contexte applicatif de l'invention dans lequel une application 1 traite 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. 20 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. 25 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. En outre, il prend en charge l'évaluation des noeuds. En outre, le processeur XPath comprend un ou plusieurs navigateurs 30 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 2908539 13 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. 5 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 de compilation mise en oeuvre par exemple par le compilateur 21 et une phase d'évaluation mise en oeuvre par exemple par l'unité de contrôle d'exécution 22. En référence à la figure 3, un dispositif apte à fonctionner en tant que 10 dispositif d'évaluation d'une expression, notamment d'une expression XPath pour accéder à au moins une partie d'un document structuré 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é d'évaluation d'une expression, 15 notamment d'une expression XPath pour accéder à au moins une partie d'un document structuré selon l'invention. Selon le mode de réalisation choisi, ce dispositif peut être par exemple un micro-ordinateur 300 connecté à différentes périphériques, par exemple, une caméra numérique 301 (ou un scanner, ou tout autre moyen 20 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. 25 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. 30 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é. 2908539 14 Le micro-ordinateur 300 peut également être relié à un microphone 308 par l'intermédiaire d'une carte d'entrée/sortie (non représentée). Le micro-ordinateur 300 comprend également un écran 309 pour visualiser les résultats des évaluations à l'utilisateur. A l'aide du clavier 310 ou de tout autre moyen 5 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 307 ou dans les autres éléments de stockage décrits. Lors de la mise sous tension, les programmes et procédés d'évaluation 10 d'expression, notamment d'expression XPath, et d'extraction des événements XML stockés dans une des mémoires non-volatiles, par exemple la ROM 307, sont transférés dans la mémoire vive RAM 312 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. 15 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, intégré ou non au dispositif, éventuellement amovible, mémorise un programme dont l'exécution met en oeuvre le procédé d'évaluation d'expressions. Il est 20 aussi possible de faire évoluer le mode de réalisation de l'invention, par exemple, en ajoutant des méthodes d'évaluation 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 plusieursdisquettes 306. Bien entendu, les disquettes 306 peuvent être remplacées par tout support d'information tel que CD-ROM ou carte 25 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 30 à tout élément du micro-ordinateur 300, directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 300. 2908539 15 La Figure 4 illustre un algorithme de compilation d'une expression XPath mise en oeuvre dans le compilateur d'un processeur XPath conforme à l'invention. L'expression XPath à évaluer peut être spécifiée par un utilisateur ou 5 bien mémorisée par exemple dans un fichier et lu par l'application 1. Selon un autre mode de réalisation, l'expression XPath résulte de l'exécution par l'application d'un programme générant des expressions XPath. L'expression est reçue par le processeur XPath 2 lors de l'étape E41. L'étape E42, qui suit l'étape E41 consiste à débuter l'analyse lexicale 10 de l'expression. Pour ce faire et selon un mode de réalisation, il est analysé un à un les caractères de l'expression XPath pour ensuite regrouper les caractères et former des symboles, aussi connus sous le terme anglo-saxon tokens . Le regroupement des caractères permet de déterminer notamment les symboles réservés définis dans la spécification XPath, par exemple le 15 caractère / , ou des classes de caractères représentant par exemple des chiffres ou des caractères simples. L'étape E42 est suivie de l'étape E43 au cours de laquelle on vérifie la validité des symboles déterminés. Si lors de l'étape E43, il est détecté un symbole invalide, non permis 20 ou inconnu, alors l'étape E43 est suivie de l'étape E44 au cours de laquelle le compilateur termine son exécution et informe le processeur XPath 2 de la non-conformité de l'expression. Si lors de l'étape E43, il n'est pas détecté un symbole invalide, non permis ou inconnu, alors l'étape E43 est suivie de l'étape E45 au cours de 25 laquelle l'étape d'analyse grammaticale est exécutée. Cette étape consiste pour le compilateur 21 à parcourir la liste de symboles déterminés lors de l'étape E42 et à identifier les types d'expression définis par la syntaxe XPath 1.0 dans l'expression à compiler. Par exemple, si le premier symbole trouvé correspond à / , alors 30 l'expression est relative à un chemin de localisation absolu ( AbsoluteLocationPath selon la syntaxe XPath) au sens de la grammaire XPath. Dans ce cas, le compilateur 21 poursuit l'analyse des symboles pour 2908539 16 identifier les composantes du chemin ( LocationPath selon la syntaxe XPath), c'est-à-dire les étapes de localisation, qui peuvent être composées d'entités exprimant une relation de filiation ( AxisSpecifier selon la syntaxe XPath), un test d'éligibilité ( NodeTest selon la syntaxe XPath) et 5 éventuellement un ou plusieurs prédicats. Lors de cette même étape E45, dès que le compilateur identifie une expression de localisation, il initialise un navigateur XPath 23 qui prendra en charge la recherche de noeuds candidats à la résolution de cette expression. Ce traitement est décrit ci-après en référence aux figures 6 et 7. 10 L'étape E45 est suivie de l'étape E46 au cours de laquelle on vérifie que l'expression, c'est-à-dire la suite de symboles, est valide au sens de la grammaire XPath. Dans la négative, l'étape E46 se poursuit à l'étape E44 précédemment décrite. 15 Au contraire, si l'expression est valide, alors l'algorithme se poursuit à l'étape E47 au cours de laquelle le compilateur 21 alloue en mémoire une structure de représentation de chaque composante de l'expression. Cette étape est suivie de l'étape E48 qui consiste à analyser les étapes de localisation extraites par le compilateur 21 lors de l'étape E45. Cette 20 étape est décrite plus en détail ci-après en référence à la Figure 5. Lors de cette étape, on détermine, pour chaque étape de localisation de chaque expression relative à un chemin de localisation, le mode de test qui doit être effectué par l'unité de contrôle d'exécution 22 lors de l'évaluation de cette étape de localisation. 25 Selon un mode de réalisation conforme à l'invention, deux types de test peuvent être réalisés : soit le simple test d'éligibilité ( NodeTest en terminologie anglo-saxonne) soit un test du noeud approfondi, ce dernier est décrit ci-après en référence à la Figure 10. A l'issue de cette analyse, le compilateur 21 informe l'unité de 30 contrôle d'exécution 22 de la fin de l'analyse, ce dernier va alors démarrer l'évaluation de l'expression (étape E49). 2908539 17 L'étape E48 de la Figure 4 détermine pour chaque étape de localisation de chaque expression relative à un chemin de localisation d'une expression XPath le mode de test à appliquer lors de son évaluation. Différents modes de test peuvent être envisagés. 5 Tout d'abord, le mode de test normal correspond à la simple application du test d'éligibilité correspondant à l'étape de localisation. Selon un mode de réalisation particulier, il s'agit du mode par défaut, notamment lorsque la représentation de l'étape de localisation est construite par le compilateur. 10 Ensuite, un mode de test peut consister au mode approfondi. Celui-ci nécessite un test sur l'historique du noeud candidat. Enfin, un mode de test peut consister à ne réaliser aucun test. Ce mode de test correspond à certaines combinaisons d'entité exprimant une relation de filiation ( AxisSpecifier ) et de test d'éligibilité. Dans ce cas, tout 15 noeud candidat est un résultat pour l'étape de localisation. On parlera alors d'étape virtuelle de localisation ( VirtualStep en terminologie anglo-saxonne). Selon un mode de réalisation particulier, l'étape E48 est réalisée en même temps que l'étape E47 consistant à construire des structures de représentation. 20 Il est maintenant décrit l'analyse des étapes de localisation en référence à la Figure 5. L'analyse des étapes de localisation issues de la compilation débute par l'étape E500 consistant à l'obtention de la structure construire par le compilateur lors de l'étape E47 de la Figure 4 représentant l'expression relative 25 à un chemin de localisation dont les étapes de localisation vont être analysées. Cette structure comprend une liste des étapes de localisation qui composent l'expression relative à un chemin de localisation. La première étape de localisation est récupérée lors de l'étape E501. La représentation de l'étape de localisation mémorise des références sur les 30 structures qui la composent, par exemple la représentation de l'entité exprimant une relation de filiation et du test d'éligibilité ainsi qu'une représentation du type de noeud attendu comme solution. 2908539 18 Par exemple, cette représentation comprend le type, un préfixe, un nom, un incrément de profondeur par rapport au noeud contexte. La valeur de l'entité exprimant une relation de filiation de l'expression relative à un chemin de localisation est ainsi obtenue lors de l'étape E502, au 5 moyen notamment de la référence contenue dans la structure de représentation de l'étape de localisation. L'étape E502 est suivie de l'étape E503 consistant à tester la valeur de l'entité afin de déterminer s'il s'agit d'une relation de filiation de type descendant ( descendant selon la syntaxe XPath). 10 Si le test est positif, alors l'étape E503 est suivie de l'étape E504 au cours de laquelle l'incrément de profondeur du noeud attendu est mis à une valeur de manière à représenter l' infini . Cette étape est ensuite suivie de l'étape E505 consistant à déterminer si la structure de représentation de l'étape de localisation comprend 15 une étape de localisation suivante. S'il n'y a pas d'étape de localisation suivante, alors l'algorithme se poursuit à l'étape E506 consistant à déterminer s'il existe une expression relative à un chemin de localisation suivante à traiter. Dans le cas positif, l'algorithme se poursuit à l'étape E501 20 précédemment décrite. Si le test de l'étape E506 est négatif, alors il est mis fin à l'algorithme de la Figure 5. De retour à l'étape E505, s'il existe une étape de localisation suivante à traiter, alors l'algorithme se poursuit à l'étape E507. 25 L'étape E507 consiste à marquer l'étape de localisation suivante comme devant subir un test approfondi. Ensuite, cette étape est suivie de l'étape E502 précédemment décrite au cours de laquelle l'étape de localisation suivante est analysée. De retour à l'étape E503, si la valeur de l'entité détermine une 30 relation de filiation différente du type descendant, alors l'algorithme se poursuit à l'étape E508 au cours de laquelle on teste cette entité afin de déterminer si la valeur reflète une relation de type descendant ou lui-même ( descendant-or- 2908539 19 self selon la syntaxe XPath) c'est-à-dire de profondeur quelconque, y compris la profondeur courante. Si le test est négatif, alors l'algorithme se poursuit à l'étape E509 consistant à affecter la valeur 1 à l'incrément de profondeur. 5 A l'issue de cette étape, l'algorithme se poursuit à l'étape E510 consistant à déterminer s'il existe une étape de localisation suivante à traiter. Si tel est le cas, l'étape E510 est suivie de l'étape E502 précédemment décrite au cours de laquelle l'étape de localisation suivante est analysée. 10 S'il n'y a pas d'étape de localisation suivante, alors l'algorithme se poursuit à l'étape E506, précédemment décrite, consistant à déterminer s'il existe une expression relative à un chemin de localisation suivant à traiter. De retour à l'étape E508, si le test est positif, c'est-à-dire si l'entité reflète une relation de type descendant ou noeud contexte, alors l'algorithme se 15 poursuit à l'étape E511 au cours de laquelle on teste la valeur du test d'éligibilité de l'étape de localisation courante. Si cette valeur correspond à un test sur le type noeud ( node() selon la syntaxe XPath), alors l'algorithme se poursuit à l'étape E512. En effet, dans ce cas, l'étape de localisation est considérée comme étant une étape de 20 localisation virtuelle ( Step Virtuel selon la syntaxe XPath). Pour cette raison, l'étape E512 consiste à marquer cette étape de localisation comme étant virtuelle. L'algorithme se poursuit à l'étape E510 précédemment décrite. De retour à l'étape E511, si le test est négatif, alors l'algorithme se 25 poursuit à l'étape E513 consistant à marquer l'étape de localisation comme devant subir un test normal. Lors de cette même étape, l'incrément de profondeur du noeud attendu est mis à une valeur indiquant l' infini . Toutefois, l'étape de localisation suivante obtenue lors de l'étape 30 E505 sera marquée à l'étape E506 comme devant subir un test approfondi. A l'issue de cet algorithme, l'unité de contrôle d'exécution 22 dispose d'une représentation de l'expression XPath sous forme de structures de 2908539 20 données. Ensuite, l'évaluation de l'expression peut débuter tel que décrit à l'étape E48 de la figure 4, sur les données d'un flux XML soit reçu par le réseau soit provenant d'un document. Il est maintenant décrit l'évaluation d'une expression XPath 5 conformément à l'invention en référence à la Figure 6. L'évaluation d'une expression XPath est réalisée à partir de la structure générée par le compilateur notamment tel que décrit en référence à la Figure 5. A chaque type d'expression de la syntaxe XPath, est associée une 10 structure de représentation avec des références sur la (ou les) sousexpression(s) qui la compose(nt). En outre, à chaque structure est associée une liste d'instructions à exécuter pour son évaluation. Cette liste comprend notamment un appel à l'exécution de la (ou des) sous expression(s) et des instructions pour gérer les 15 erreurs et/ou les résultats. Par exemple pour une expression de type addition ( AdditiveExpr selon la syntaxe XPath), la liste d'instructions serait : évaluer l'opérande de gauche, évaluer l'opérande de droite puis appliquer l'opérateur + sur ces 2 opérandes. L'algorithme d'évaluation d'une expression XPath débute par l'étape 20 E600, consistant à exécuter la liste des instructions associée à l'expression de plus haut niveau. Selon la syntaxe du langage XPath, l'expression de plus haut niveau est identifié par l'entité Expr . Cette exécution déclenche en cascade l'exécution des sous-expressions qui composent l'expression XPath jusqu'au niveau de la (ou des) expression(s) relative(s) à un chemin de localisation. 25 L'algorithme se poursuit à l'étape E601 par le lancement de l'exécution de l'expression relative à un chemin de localisation. Cette étape est suivie de l'étape E602 au cours de laquelle l'unité de contrôle d'exécution 22 vérifie si cette expression représente l'expression principale ou si cette expression est issue par exemple d'un prédicat. 30 Si tel est le cas, alors l'algorithme se poursuit à l'étape E603 au cours de laquelle l'unité de contrôle d'exécution 22 fait appel à son navigateur 2908539 21 XPath 23 principal. Si ce dernier n'a pas été initialisé, alors un analyseur 3 d'un flux de données XML 4 est créé et relié au navigateur XPath 23 principal. L'unité de contrôle d'exécution 22 est ensuite apte à lancer l'évaluation des étapes de localisation de l'expression relative à un chemin de 5 localisation selon l'étape E606 qui est détaillée ci-après en référence à la Figure 7. De retour à l'étape E602, si la vérification est négative, alors l'unité de contrôle d'exécution 22 initialise un navigateur XPath 23. Toutefois, lors de l'étape E604 qui suit l'étape E602, les valeurs des variables d'état du navigateur 10 en cours d'utilisation, désigné par navigateur de référence, sont mémorisées. Cette étape est suivie de l'étape E605 au cours de laquelle le navigateur initialisé par l'unité de contrôle d'exécution 22 va être synchronisé avec le navigateur de référence. Cette étape de synchronisation est réalisée notamment en 4 étapes. 15 Tout d'abord, la synchronisation débute à l'étape E650 au cours de laquelle le nouveau navigateur XPath 23 voit son historique remis à zéro. Cet historique peut contenir notamment des informations sur un ou plusieurs noeuds traités, des statistiques sur les types de noeud déjà analysés. Ensuite l'algorithme se poursuit à l'étape E651 consistant à 20 récupérer l'analyseur XML 3 associé au nouveau navigateur XPath 23. Si ce dernier n'a pas été préalablement créé, alors on procède à la création d'un nouveau navigateur. L'étape E651 est suivie de l'étape E652 consistant à recopier les valeurs des variables d'état de l'analyseur XML de référence dans les variables 25 d'état de l'analyseur XML du nouveau navigateur XPath 23. L'étape suivante (étape E653) consiste à affecter les données de l'analyseur XML de référence à la mémoire tampon de l'analyseur XML associé au nouveau navigateur XPath. Cette mémoire stocke les données provenant du flux XML 4. 30 L'algorithme se poursuit à l'étape E606. En effet, après avoir sélectionné le navigateur XPath 23 à utiliser, l'unité de contrôle d'exécution 22 réalise l'évaluation des étapes de localisation de l'expression relative à un 2908539 22 chemin de localisation courante. Cette étape est décrite ci-après en référence à la Figure 7. L'étape E607 suit l'étape E606 au cours de laquelle l'unité de contrôle d'exécution 22 restaure l'état du navigateur XPath 23 mémorisé lors de 5 l'étape E604 lorsque l'évaluation des étapes de localisation conduit à l'envoi d'un résultat ou se termine sans résultat. L'expression relative à un chemin de localisation restaurée lors de l'étape E607 utilise le résultat éventuel déterminé lors de l'étape E606 et le processeur continue son évaluation. Pour ce faire, celui-ci teste lors de l'étape 10 E608 si l'expression relative à un chemin de localisation a été totalement évaluée ou non. Dans le cas négatif, l'étape E608 est suivie de l'étape E606 précédemment décrite dans laquelle l'étape de localisation suivante est évaluée. 15 Si l'expression relative à un chemin de localisation a été entièrement évaluée, alors il est mis fin à l'algorithme d'évaluation. II est maintenant décrit l'évaluation des étapes de localisation en référence à la Figure 7. L'évaluation des étapes de localisation composant une expression 20 relative à un chemin de localisation consiste à traiter consécutivement chaque étape de localisation qui la compose. L'algorithme débute à l'étape E710 consistant à sélectionner la première étape de localisation. Ensuite, lors de l'étape E711, on détermine si l'étape de localisation 25 courante nécessite un test approfondi. Si tel est le cas, alors l'algorithme se poursuit à l'étape E712 consistant à activer la sauvegarde de l'historique du navigateur XPath 23 pour cette étape de localisation et les suivantes. La désactivation de la sauvegarde (réalisée à l'étape E713) interviendra lorsque l'unité de contrôle d'exécution 22 30 sera de nouveau positionnée sur l'étape de localisation parente de celle qui a déclenché l'activation de la sauvegarde. 2908539 23 Les étapes E712 et E713 sont suivies de l'étape E714 consistant à chercher un noeud candidat à partir des données XML. Un algorithme conforme à l'invention détaillant cette étape est illustré en Figure 8 et est décrit ci-après. 5 Si le test de l'étape E714 est négatif, c'est-à-dire si aucun noeud candidat n'a été trouvé, alors l'algorithme se poursuit à l'étape E720. L'étape E720 détermine s'il existe une étape de localisation précédente à l'étape de localisation courante. Si tel est le cas, alors l'étape de localisation précédente devient 10 l'étape de localisation courante et l'algorithme se poursuit à l'étape E711 précédemment décrite. Dans le cas contraire, l'expression relative à un chemin de localisation a été entièrement évaluée et il est mis fin à l'algorithme. Lorsqu'un noeud candidat a été trouvé à l'étape E714, l'algorithme se 15 poursuit à l'étape E715 au cours de laquelle on teste le noeud candidat en lui appliquant le test d'éligibilité afin de déterminer s'il est une solution potentielle de l'étape de localisation courante. Dans la négative, l'étape E715 est suivie de l'étape E714 précédemment décrite au cours de laquelle: on cherche un nouveau candidat, 20 le candidat courant n'étant pas éligible pour la résolution de l'étape de localisation courante. Dans le cas positif, l'algorithme se poursuit à l'étape E716 consistant à la vérification d'éventuels prédicats associés à l'étape de localisation courante. 25 Les prédicats sont représentés par des expressions, notamment des expressions XPath composées de sous-expressions. L'évaluation des prédicats est réalisée conformément à l'évaluation d'une expression telle qu'illustrée en Figure 6 à la différence que les noeuds résultats d'une expression représentant un prédicat ne sont pas transmis à l'application mais traduits en un résultat 30 booléen selon le test à effectuer dans le prédicat. II peut s'agir d'un test de valeur, de position, de nom ou de simple existence. 2908539 24 Si le test est négatif, l'étape E716 est suivie de l'étape E714 précédemment décrite. Si, au contraire le test est positif, l'algorithme se poursuit à l'étape E717 consistant à déterminer si l'étape de localisation traitée est la dernière 5 étape de l'expression relative à un chemin de localisation. Dans la négative, l'étape E717 est suivie de l'étape E719 consistant à déterminer l'étape de localisation suivante. Cette étape est ensuite suivie de l'étape E711 précédemment décrite. Si l'étape de localisation est la dernière de l'expression relative à un 10 chemin de localisation alors l'algorithme se poursuit à l'étape E718. Durant cette étape, on procède à l'émission du résultat de l'évaluation de l'expression relative à un chemin de localisation. Le principe général de cet algorithme est de considérer l'étape de localisation suivante (étape E719) lorsqu'un résultat pour une étape de 15 localisation intermédiaire a été trouvé (test positif lors de l'étape E716 suivi d'un test négatif lors de l'étape E717). II est maintenant décrit la recherche d'un noeud candidat correspondant à l'étape E714 de la Figure 7. Un algorithme conforme à l'invention est illustré en Figure 8. 20 L'unité de contrôle d'exécution 22 obtient la valeur de l'entité exprimant une relation de filiation de l'étape de localisation courante à l'étape E800. Cette étape est suivie de l'étape E801 au cours de laquelle on vérifie si la relation de filiation contient la relation self , i.e. si cette valeur est 25 noeud contexte ( self selon la spécification XPath) ou bien descendant ou noeud contexte ( descendant-or-self selon la spécification XPath). Si la valeur contient une relation de type noeud contexte alors l'algorithme se poursuit à l'étape E802 au cours de laquelle l'unité de contrôle d'exécution demande au navigateur XPath 23 de lui fournir le noeud courant. Le 30 résultat de l'étape de localisation précédente est donc le noeud contexte de l'étape de localisation courante. 2908539 25 L'étape E803 suit l'étape E802 au cours de laquelle ce noeud courant est émis comme un noeud candidat. Si lors de l'étape E801, les valeurs sont différentes, alors l'algorithme se poursuit à l'étape E804 au cours de laquelle l'unité de contrôle d'exécution 5 22 compare la valeur de l'entité à la valeur attribut ( attribute selon la syntaxe XPath). Si la valeur est attribut alors l'algorithme se poursuit à l'étape E805 au cours de laquelle l'unité de contrôle d'exécution 22 demande au navigateur XPath 23 de lui fournir le noeud de type attribut courant. 10 Cette étape est suivie de l'étape E806 au cours de laquelle on détermine si ce noeud a fait l'objet d'une recherche par l'analyseur XML 3. Si tel est le cas, ce noeud est mémorisé dans la mémoire du navigateur XPath 23. L'étape suivante (étape E803) consiste à émettre ce noeud comme noeud candidat. Le stockage des noeuds et leur émission vers l'application sont 15 décrits plus bas en référence aux figures 12 et 13. Si, lors de l'étape E805, aucun attribut n'est trouvé, la sauvegarde réalisée à l'étape E806 n'est pas réalisée. En outre, lors de l'étape E803, l'événement émis est l'événement fin. De retour à l'étape E804, si la valeur de l'entité est différente de la 20 valeur attribut , alors l'algorithme se poursuit à l'étape E807 au cours de laquelle l'unité de contrôle d'exécution 22 compare la valeur de l'entité à la valeur enfant ( child selon la syntaxe XPath). Si la valeur est enfant alors l'algorithme se poursuit à l'étape E808 au cours de laquelle l'unité de contrôle d'exécution 22 indique au 25 navigateur XPath 23 la profondeur à laquelle celui-ci doit chercher un noeud candidat. Le calcul de la profondeur est la valeur profondeur du noeud contexte incrémenté de la valeur 1 si l'étape de localisation n'a pas été identifiée comme devant subir un mode approfondi. Dans le cas contraire, la profondeur cible 30 prend la valeur infinie. 2908539 26 L'étape E808 est suivie de l'étape E810 au cours de laquelle le navigateur XPath 23 recherche le candidat en faisant appel à l'analyseur XML 3. Pour ce faire, l'analyseur XML 3 parcourt la partie du flux XML 4 5 correspondant au sous-arbre se trouvant sous le noeud contexte jusqu'à ce qu'un noeud fils du noeud contexte de type texte, commentaire ou élément soit trouvé. Il apparaît ainsi, qu'à l'inverse des solutions mentionnées dans l'état de la technique, le navigateur XPath 23 ne fournit au contrôleur d'exécution 22 que les noeuds pertinents. 10 Ce noeud est ensuite sauvegardé en mémoire du navigateur XPath 23 lors de l'étape suivante (étape E811). Ensuite, l'étape E811 est suivie de l'étape E803 au cours de laquelle on émet le noeud trouvé comme noeud candidat. Toutefois, si aucun noeud n'a été trouvé entre le début du noeud 15 contexte et sa fin, identifié par une balise XML fermante alors, lors de l'étape E803, l'événement fin est émis. De retour à l'étape E807, si la valeur de l'entité est différente de la valeur enfant , alors l'algorithme se poursuit à l'étape E812 au cours de laquelle l'unité de contrôle d'exécution 22 vérifie si l'entité contient une relation 20 de type descendant ( descendant ou descendant-or-self selon la syntaxe XPath). Si la valeur est descendant ou descendant ou noeud contexte alors l'algorithme se poursuit à l'étape E813 au cours de laquelle l'unité de contrôle d'exécution 22 indique au navigateur XPath 23 que la recherche d'un 25 fils ou descendant est à réaliser sans limite de profondeur à partir de la profondeur courante. L'étape E813 est suivie de l'étape E810 précédemment décrite. Si, lors de l'étape E812, la valeur de l'entité ne contient pas de valeur de type descendant alors l'algorithme se poursuit à l'étape E814 au cours 30 de laquelle on émet une information indiquant qu'aucun candidat n'a été trouvé. Dans le cas particulier dans lequel la valeur de l'entité est la valeur descendant ou noeud contexte ( descendant-or-self selon la syntaxe 2908539 27 XPath), l'unité de contrôle d'exécution 22 réalise une recherche en fonction de la valeur noeud contexte tel que décrit à l'étape E801 si cette dernière n'a pas déjà été faite pour l'étape de localisation courante. Toutefois, si aucun candidat n'a été trouvé, alors la recherche est réalisée en fonction de la valeur 5 descendant tel que décrit à partir de l'étape E812. Il est maintenant décrit le test du candidat mentionné à l'étape E715 de la Figure 7. Si l'étape E714 n'a pas émis un évènement de fin ou d'erreur, alors l'étape de test E715 est activée. Si l'étape de localisation courante a été identifiée lors de la 10 compilation (décrite à l'étape E506 de la Figure 5) comme nécessitant un test approfondi , l'étape E715 de la Figure 7 est réalisée tel que décrit ci-après en référence à la Figure 10. Si l'étape de localisation courante a été identifiée comme étant une étape de localisation virtuelle ( Step virtuel selon la syntaxe XPath) (décrite à 15 l'étape E502 de la Figure 5) alors le test de l'étape E715 retourne la valeur vrai. Si l'étape de localisation courante a été identifiée comme nécessitant un mode de test normal , alors l'étape E715 est réalisée tel que décrit ci-après en référence à la Figure 9. Cet algorithme de test selon le mode normal est maintenant décrit en 20 référence à la Figure 9. L'algorithme débute à l'étape E901 au cours de laquelle l'unité de contrôle d'exécution 22 obtient la valeur du test d'éligibilité ( Node Test selon la syntaxe XPath) associée à la représentation de l'étape de localisation courante. Cette entité peut prendre la valeur test du nom ( NameTest 25 selon la syntaxe XPath), ou test du type ( NodeType selon la syntaxe XPath) pouvant être : noeud ( node() )) selon la syntaxe XPath), texte ( textO selon la syntaxe XPath), commentaire ( comment() )) selon la syntaxe XPath) ou instruction de traitement ( processing-instruction() )) selon la syntaxe XPath) selon la spécification XPath. Le test sur le nom peut 30 porter à la fois sur la valeur de l'espace de nommage du noeud (représentée par un préfixe) et sur son nom local , nom unique à l'intérieur de cet espace de nommage. 2908539 28 L'étape E901 est suivie de l'étape E902 au cours de laquelle on compare la valeur du test d'éligibilité du noeud obtenue à la valeur test du nom .Si le test d'éligibilité a la valeur test du nom alors l'algorithme se 5 poursuit à l'étape E903 au cours de laquelle l'unité de contrôle d'exécution 22 résout le préfixe, autrement dit la valeur de l'espace de nommage, associé au noeud candidat. Celle information est mémorisée dans la mémoire du navigateur XPath 23. L'étape E903 est suivie de l'étape E904 consistant à comparer la 10 valeur du préfixe ainsi obtenue avec la valeur de l'espace de nommage correspondant au préfixe contenu dans le test du nom . Si ces valeurs sont équivalentes alors l'algorithme se poursuit à l'étape E905 dans laquelle l'unité de contrôle d'exécution 22 obtient le nom local du noeud candidat, c'est-à-dire par exemple, le nom unique à l'intérieur de 15 l'espace de nommage. L'étape E905 est suivie de l'étape E906 au cours de laquelle le nom local du noeud candidat est comparé au nom local porté précisé dans le test du nom . Si les noms sont équivalents alors le noeud candidat satisfait le test 20 associé à l'étape de localisation courante et peut être considéré comme une solution potentielle de l'étape de localisation. Ensuite il sera procédé à la vérification des prédicats, notamment au cours de l'étape E716 de la Figure 7. Dans le cas contraire, le noeud candidat ne satisfait pas le test associé à l'étape de localisation courante et il est considéré comme n'étant pas 25 une solution de l'étape de localisation. De retour à l'étape E902 dans le cas où le test d'éligibilité n'a pas la valeur test du nom alors l'algorithme se poursuit à l'étape E907 consistant à comparer la valeur du test d'éligibilité avec la valeur type du noeud . Si le test d'éligibilité n'a pas la valeur type du noeud alors il est 30 mis fin à l'algorithme en retournant un message d'erreur. Sinon, si le test d'éligibilité a la valeur type du noeud alors l'algorithme se poursuit à l'étape E908 au cours de laquelle l'unité de contrôle 2908539 29 d'exécution 22 obtient le type du noeud candidat. Cette information est mémorisée dans la mémoire du navigateur XPath 23. L'algorithme se poursuit à l'étape E909 au cours de laquelle on compare le type du candidat avec la valeur du type contenu dans la valeur 5 type du noeud . Si les valeurs sont similaires alors le noeud candidat est une solution potentielle de l'étape de localisation. Dans le cas contraire, le noeud candidat n'est pas une solution. II est maintenant décrit, en référence à la Figure 10, un algorithme 10 réalisant le test approfondi conforme à l'invention. La décision de mise en oeuvre ultérieure du test approfondi est prise lors de la compilation d'une étape de localisation conditionnellement à la valeur de l'entité exprimant une relation de filiation tel que décrit en Figure 5. Ce mode de test peut-être activé, notamment lors du test d'un 15 candidat tel que décrit en référence à l'étape E715 de la Figure 7. Tel que précédemment décrit en référence à la Figure 7, si l'étape de localisation courante nécessite un test approfondi (étape E711), l'unité de contrôle d'exécution 22 obtient le profil du noeud attendu déterminé lors de l'analyse de l'étape de localisation afin de le comparer au noeud candidat 20 déterminé lors de l'étape E714. L'algorithme du test approfondi débute à l'étape E1000 par l'obtention du noeud candidat. Cette étape est suivie de l'étape E1001 consistant à obtenir le noeud attendu. Ce dernier est disponible dans la structure de représentation de 25 l'étape de localisation courante. L'étape suivante (étape E1002) consiste pour l'unité de contrôle d'exécution 22, à comparer le type du noeud candidat avec le type du noeud attendu. Si les types des noeuds sont comparables, alors l'algorithme se 30 poursuit à l'étape E1003 au cours de laquelle l'unité de contrôle de l'exécution applique le test du nom de l'étape de localisation courante. 2908539 30 Si le test d'éligibilité de l'étape de localisation a la valeur type de noeud et non la valeur test du nom , cette étape n'est pas exécutée par l'unité de contrôle d'exécution. Sinon, ce test consiste en l'enchaînement des étapes E903 à E906 en référence à la Figure 9. 5 Si le test réalisé à l'étape E1003 est vrai, l'algorithme se poursuit à l'étape E1003a durant laquelle l'unité de contrôle d'exécution obtient la profondeur. Ensuite l'étape E1003a est suivie de l'étape E1004 au cours de laquelle on compare la profondeur obtenue et la profondeur attendue pour les résultats de l'étape de localisation courante. 10 Si la profondeur obtenue est différente de la profondeur attendue alors il est mis fin à l'algorithme et le test d'éligibilité retourne la valeur faux. La profondeur attendue est la profondeur entre le noeud contexte et un noeud qui serait solution de l'étape courante du chemin. Cet incrément est calculé lors de l'étape E504 ou de l'étape E509 de la Figure 5. 15 Si, au contraire, la profondeur obtenue est similaire à la profondeur attendue alors l'étape E1004 est suivie de l'étape E1005 consistant à obtenir l'incrément de profondeur attendu entre le noeud résultat et son noeud contexte. L'étape suivante (étape E1006) consiste à obtenir le noeud contexte du noeud candidat qui a été mémorisé dans l'historique du navigateur XPath 23. 20 Si le noeud contexte n'existe pas, alors il n'y a aucune contrainte à vérifier sur son historique et le noeud candidat est déclaré solution potentielle mettant ainsi fin à l'algorithme. Dans le cas contraire, c'est-à-dire si un noeud parent existe dans l'historique, alors l'algorithme se poursuit à l'étape E1007 au cours de laquelle 25 sa profondeur est utilisée pour calculer l'incrément de profondeur entre le noeud parent et le noeud candidat. L'étape suivante (étape E1008) consiste à comparer cet incrément à l'incrément attendu. Si l'incrément est différent de l'incrément attendu, alors il est mis fin à 30 l'algorithme en retournant la valeur faux. Si, au contraire, l'incrément est similaire à l'incrément attendu, alors le noeud contexte devient le noeud à tester de façon approfondie. 2908539 31 Pour ce faire, l'algorithme se poursuit à l'étape E1009 au cours de laquelle l'unité de contrôle d'exécution 22 obtient le profil du noeud attendu pour l'étape de localisation précédent l'étape de localisation en cours de traitement. S'il n'y a plus de noeud attendu, alors il est mis fin à l'algorithme de 5 test approfondi en déclarant le noeud candidat comme solution potentielle. Dans le cas contraire, c'est-à-dire si un noeud de référence existe, alors l'algorithme se poursuit à l'étape E1002 précédemment décrite. Les étapes E1002 à E1008 sont réitérées jusqu'à atteindre soit la fin de l'historique (test négatif réalisé lors de l'étape E1006), soit l'initialisation du test approfondi 10 de l'étape de localisation (étape E1009). Il est maintenant présenté un exemple d'évaluation illustré en Figure 11 selon le mode test approfondi . Deux expressions XPath relative à un chemin de localisation équivalentes (1111), mais écrites différemment, comprennent quatre étapes de 15 localisation : S0, SI et S2, et une étape de localisation virtuelle SV1 (1113). A chaque expression devant subir un test approfondi (SI et S2), les profils des noeuds attendus (1112), en termes de type, préfixe, nom, et incrément de profondeur, sont illustrés à titre d'exemple. En figure 11, il est également illustré un document contenant des 20 données XML (1114) sur lesquelles sont évaluées les expressions XPath. Il est illustré les différents noeuds contextes (1115) qui sont rencontrés au cours de l'évaluation des expressions. Ces noeuds contextes correspondent aux solutions de l'étape de localisation virtuelle SV1. Selon la solution décrite dans les paragraphes précédents, 25 lorsqu'une solution est trouvée pour l'étape de localisation virtuelle SV1, l'évaluation se poursuit par l'évaluation de l'étape de localisation S1, notamment par l'exécution des étapes E714 à E716 de la Figure 7, puis par l'évaluation de l'étape de localisation S2 lorsqu'un élément b avec un incrément de profondeur égal à 1 par rapport au noeud contexte est trouvé. 30 Les solutions de l'expression (1116) seront alors les éléments, ayant n'importe quel nom, situés à un niveau de profondeur +1 par rapport aux solutions de l'étape de localisation S1. 2908539 32 Il est maintenant décrit une variante de réalisation de la mise en oeuvre des navigateurs multiples ayant pour objectif de limiter le nombre d'accès au flux XML, basée sur une synchronisation des navigateurs XPath. Les navigateurs XPath 23 du processeur XPath 2 peuvent posséder 5 une référence sur une zone mémoire du processeur XPath. Dans cette zone mémoire, le navigateur XPath 23 courant écrit les données XML extraites par l'analyseur XML 3 et lues depuis le flux 4 sous la forme d'une suite d'évènements. Cette mémoire peut être mise en oeuvre sous la forme d'une liste 10 ordonnée gérée de telle manière que le premier évènement mémorisé est le premier événement consommé. Seul le navigateur XPath principal 23 est habilité à retirer les éléments de cette liste et à les traiter. Cette mise en oeuvre nécessite, toutefois, une étape d'initialisation 15 dans laquelle, lors de la sauvegarde de l'état des variables du navigateur de référence (réalisée lors de l'étape E604 de la figure 6), le navigateur garde une référence sur le dernier élément de la liste. Cette référence est le point de départ pour les navigations qui sont créées consécutives à l'étape de restauration E607 de la Figure 6. 20 Lorsque le navigateur principal est restauré à l'étape E607, celui-ci reprend la navigation à partir des différents éléments de la liste d'évènements. Lorsque le dernier événement de la liste est atteint, le navigateur reprend la navigation en utilisant son analyseur XML 3. Ainsi, selon cette mise en oeuvre, un seul analyseur XML 3 est utilisé. 25 En outre, ce mode de réalisation particulier présente l'avantage de diminuer la consommation de bande passante dans les cas où le flux XML 4 provient d'une connexion réseau. Selon l'invention, la décomposition de l'évaluation d'une expression XPath en plusieurs tâches est facilitée. En effet, dans le mode de mise en 30 oeuvre basé sur une pluralité de navigateurs XPath (c'est-à-dire en fonctionnement multi-tâches), le navigateur XPath principal 23 effectue les évaluations selon les étapes de localisation de l'expression relative à un chemin 2908539 33 de localisation principale, tandis qu'en parallèle, les autres navigateurs XPath 23 effectuent les évaluations des sous-expressions correspondant par exemple aux prédicats ou aux expressions de localisation se trouvant dans des appels de fonction. 5 Dans le mode de réalisation particulier de mise en oeuvre des navigateurs multiples, le navigateur XPath principal 23 remplit la mémoire du processeur XPath 2 via son analyseur XML 3 associé. La synchronisation d'un nouveau navigateur intervient lorsque le navigateur principal détecte un noeud comme une solution potentielle (test 10 réalisé à l'étape E715 de la Figure 7). Une nouvelle tâche et le nouveau navigateur XPath 23 sont créés. Dans cette tâche, le nouveau navigateur obtient les évènements XML depuis la mémoire du processeur XPath 2 et évalue la sous-expression courante tandis que dans la tâche principale, le navigateur XPath 23 poursuit le parcours du flux 15 XML 4 via son analyseur XML 3 à la recherche de solutions potentielles. Les tâches attachées à la résolution des sous expressions se terminent lorsqu'une solution a été trouvée ou lorsque la séquence d'évènements représentant le sous arbre de recherche a été entièrement parcourue. 20 Selon un autre mode de réalisation, ce mécanisme peut être étendu à une approche multi-tâches basée sur les étapes de localisation. Dans ce mode de réalisation, un navigateur XPath principal s'attache à résoudre la première étape de localisation et dès qu'une solution potentielle est trouvée, une ou deux tâches peuvent être créées afin respectivement de 25 résoudre un éventuel prédicat sur l'étape de localisation courante et de prendre en charge la résolution de l'étape de localisation suivante. Cette mise en oeuvre est particulièrement avantageuse dans le cas de documents XML indexés par profondeur. En effet, elle permet, d'une part, un accès rapide aux éléments se trouvant à une même profondeur et, d'autre part, 30 de ne pas considérer les sous arbres correspondant aux étapes de localisation consécutifs à une étape de localisation sans solution. 2908539 34 Il est maintenant décrit en référence à la Figure 12, l'émission des résultats. Afin de réaliser une évaluation des données intégralement à la volée, les résultats extraits du flux XML 4 par le processeur XPath 2 via son 5 navigateur XPath 23 sont retournés à l'application 1 au fur et à mesure de leur détection. Pour ce faire, le navigateur principal XPath 23 du processeur XPath comprend deux champs appelés émission et stockage indiquant respectivement le statut en termes d'émission d'évènements vers l'application, 10 notamment lorsqu'un résultat a été trouvé lors de l'étape E718 de la Figure 7 et le statut en termes de stockage d'évènements représentant un résultat compris dans le résultat en cours d'émission. En effet, le problème principal réside dans la gestion des résultats emboîtés. Par exemple, si l'on considère le flux XML suivant : 15 , sur lequel on évalue l'expression //b, on obtiendra les deux résultats suivants : et . On constate sur cet exemple que le deuxième élément b et son contenu sont inclus dans le premier résultat et doivent donc être émis deux fois. L'algorithme décrit ci-dessous en référence aux Figures 12 et 13 permet de 20 traiter ce genre de situation sans recourir à un stockage multiple des résultats emboîtés ( dans notre exemple). Le tableau ci-dessous résume les actions à réaliser en fonction du type d'évènement reçu ou extrait par le navigateur XPath 23 au cours du parcours du flux XML 4. Ce parcours est réalisé lors de l'étape E714 de 25 recherche de noeuds candidats. L'évènement début de résultat est émis par le contrôleur d'exécution 22 à l'étape E718. Le traitement de cet évènement est décrit en référence à la figure 12. 2908539 Evènement : Début de Evènement XML fin de résultat résultat Statuts Non-émission Activer Ne pas Impossible l'émission, considérer émettre le noeud courant Emission, non-Activer le Emettre Emettre, dépiler les stockage stockage, l'évènement queues stocker et d'évènements puis émettre le noeud désactiver l'émission courant Emission, Activer un Stocker Stocker l'évènement stockage nouveau l'évènement puis désactiver le stockage, dernier stockage stocker et émettre le noeud courant Tel qu'illustré dans le tableau ci-dessus, les évènements peuvent être de trois sortes. 1. Tout d'abord, l'événement début de résultat est un 5 évènement émis par l'unité de contrôle de l'exécution 22 lors de l'étape E718 de la Figure 7 afin de signaler au navigateur que le noeud courant correspond au début d'un nouveau résultat. 2. Ensuite, l'événement évènement XML décrit tous les évènements XML extraits par l'analyseur 3 lors du parcours du flux XML 4. 10 3. Enfin, l'événement fin de résultat est un évènement généré lors de la recherche de noeuds candidats de l'étape E810 de la Figure 8. Cet événement est généré lorsque le navigateur XPath 23 récupère depuis le flux XML 4 la balise fermante qui correspond à la fin de l'élément résultat. Dans l'exemple présenté précédemment décrit, des évènements de fin sont détectés 15 pour les éléments . La Figure 12 illustre le traitement du signal début de résultat par le navigateur XPath 23. Le traitement du signal début de résultat débute à l'étape E1200 par la réception de ce signal par le navigateur XPath 23. Ce signal provient de l'unité de contrôle d'exécution 22. 2908539 36 Cette étape est suivie d'une étape de test (étape E1201) afin de déterminer si le navigateur est déjà en mode émission , en particulier, si le résultat nouvellement détecté se trouve à l'intérieur du résultat précédent. Dans le cas négatif, l'algorithme se poursuit à l'étape E1202 au cours 5 de laquelle le mode émission est activé. Pour ce faire, la valeur du champ émission du navigateur est positionné à la valeur vrai. Ensuite, lors de l'étape suivante (étape E1203), le signal de début de résultat est émis vers l'application. Ce signal étant pris en charge par l'un des gestionnaires d'évènements de l'application. 10 En effet, l'application peut mettre en oeuvre des gestionnaires d'évènements, par exemple similaires à ceux des analyseurs XML, ayant une interface de type SAX (tel que décrit notamment à l'adresse suivante : sax.sourceforge.net/) et des gestionnaires spécifiques à l'utilisation du processeur XPath comme un gestionnaire de début et fin de résultat. 15 Si le test de l'étape E1201 s'avère positif, le mode stockage du navigateur XPath 23 est alors activé à l'étape E1204. Ensuite l'étape E1205 permet au navigateur XPath d'indexer ce noeud correspondant à un début de résultat emboîté dans une liste de début de résultats. Cette liste sera utilisée pour détecter la fin d'un résultat emboîté et pour émettre les noeuds 20 correspondant au moment opportun. La figure 13 décrit le traitement de tout évènement XML extrait par le navigateur XPath 23. Ce traitement débute (étape E1300) avec la lecture d'un nouvel évènement dans le flux XML 4 au moyen d'un analyseur XML 3. 25 L'étape E1300 est suivie de l'étape E1301 au cours de laquelle cet évènement est traduit en noeud XPath et conservé en mémoire du navigateur XPath 23 en vue de son évaluation (étape E715) par l'unité de contrôle d'exécution 22. L'étape suivante E1302 consiste à vérifier si le mode d'émission du 30 navigateur XPath 23 est actif ou non. 2908539 37 Si ce n'est pas le cas, le noeud est effacé de la mémoire du navigateur XPath 23 et le navigateur attend que l'unité de contrôle d'exécution 22 lui demande d'effectuer une recherche d'un nouveau candidat (étape E714). Si le test de l'étape E1302 est positif, le navigateur XPath doit 5 émettre le noeud courant. Préalablement à cette émission, au cours de l'étape E1304, on vérifie si le mode stockage est actif. Si tel est le cas, l'étape E1304 est suivie de l'étape E1305 au cours de laquelle le noeud courant est marqué comme devant être conservé après 10 son émission. Ce marquage associe également le cas échéant l'information début ou fin de résultat sur les noeuds correspondant respectivement à des débuts et à des fins d'éléments. L'étape suivante E1306 consiste à vérifier si le noeud courant 15 représente la fin du dernier résultat détecté. Selon un mode de réalisation, ce test vérifie que le noeud courant est une balise fermante de la même profondeur que la balise ouvrante ayant donné lieu à cette détection de résultat. Si tel est le cas, l'algorithme se poursuit à l'étape E1307 de désactivation du mode stockage . Puis le noeud est émis lors de l'étape 20 E1308. Si le test de l'étape E1306 est négatif, le noeud est émis à l'étape E1308. Cette étape E1308 émet le noeud vers l'application sans toutefois l'effacer de la mémoire du navigateur XPath 23. Dans le cas d'un test de l'étape E1304 négatif, l'étape suivante 25 (étape E1309) consiste à vérifier si le noeud courant correspond à la fin du résultat courant. Autrement dit, cela consiste à s'assurer, si le résultat courant correspond à un élément, que le noeud courant correspond à une balise fermante de ce noeud élément résultat. 30 Pour tout autre type de noeud, le noeud lui-même est à la fois début et fin de résultat. 2908539 38 Si le test de l'étape E1309 est positif, la fin du résultat courant est atteinte et le mode émission est donc désactivé lors de l'étape E1310. Puis à l'étape E1311, le noeud est émis et effacé de la mémoire du navigateur XPath. 5 L'étape E1311 est suivie de l'étape E1312 au cours de laquelle le signal de fin de résultat est émis. L'étape suivante (étape E1313) consiste à émettre d'éventuels résultats emboîtés. Cette étape est détaillée ci-après en référence à la Figure 14. 10 Si le test de l'étape E1309 est négatif alors l'algorithme se termine à l'étape E1314 au cours de laquelle le noeud courant est émis. En référence à la figure 14, l'algorithme débute à l'étape E1400 au cours de laquelle le navigateur XPath vérifie si la liste de débuts de résultats emboîtés est vide. 15 Si la liste n'est pas vide, il récupère le premier début de résultat lors de l'étape E1401. Cette étape est ensuite suivie de l'envoi d'un signal de début de résultat à l'étape E1402. Le noeud courant est ensuite émis et retiré de la mémoire du navigateur XPath lors de l'étape E1403. 20 Cette étape est suivie de l'étape E1404 consistant à récupérer le noeud suivant. L'étape E1404 est suivie de l'étape E1405 au cours de laquelle on teste si ce noeud est marqué comme appartenant à un autre résultat emboîté. Si tel est le cas, alors l'algorithme se poursuit à l'étape E1406 au 25 cours de laquelle on vérifie s'il s'agit de la fin du résultat courant. Dans le cas positif, l'étape E1406 est suivie de l'étape E1407 au cours de laquelle le noeud correspondant est émis. Le noeud est également effacé de la mémoire du navigateur XPath. Puis le signal de fin de résultat est émis à l'étape suivante E1408, 30 puis on itère sur la liste d'index de débuts de résultats (étape E1400), jusqu'à ce que cette liste soit vide. 2908539 39 De retour au test lors de l'étape E1406, si le noeud courant ne correspond pas à la fin du résultat courant, il s'agit alors d'un noeud appartenant au résultat et celui-ci est émis lors de l'étape suivante (étape E1410). Cette étape est suivie de l'étape E1404 au cours de laquelle le parcours de la liste de 5 noeuds est poursuivi. De retour au test de l'étape E1405, si le noeud n'est pas marqué alors celui-ci est émis puis retiré de la liste de noeuds du navigateur XPath 23 lors de l'étape E1409. Ensuite, cette étape est suivie de l'étape E1404 précédemment 10 décrite afin de parcourir les prochains noeuds. Ainsi, l'invention fournit un moyen d'évaluer des expressions XPath à la volée. Pour cela, le processeur XPath utilise au moins un navigateur XPath, un navigateur principal restant positionné sur un noeud potentiellement résultat, et éventuellement un ou plusieurs autres navigateurs explorant localement les 15 données XML. De plus, afin de détecter d'éventuelles solutions emboitées, le processeur analyse les étapes de localisation des expressions relatives à un chemin de localisation pour leur assigner un mode de test spécifique si besoin et ne stocker l'historique des noeuds que lorsque nécessaire. REVENDICATIONS 1. Procédé d'évaluation d'une expression pour accéder à au moins une partie d'un document structuré au moyen d'au moins un navigateur apte à extraire les données structurées du document, l'expression étant composée d'au moins deux sous expressions relatives chacune à un chemin de localisation, caractérisé en ce qu'il comprend une étape d'évaluation de chacune des sous-expressions sur la base des données du document au moyen d'au moins un navigateur distinct pour chaque sous-expression. 2. Procédé d'évaluation selon la revendication 1, caractérisé en ce qu'il comprend une étape préalable de détermination du nombre de navigateurs. 3. Procédé d'évaluation selon la revendication 1 ou la revendication 2, caractérisé en ce que chaque sous-expression relative à un chemin comprend un ensemble d'étapes de localisation. 4. Procédé d'évaluation selon la revendication 3, caractérisé en ce 20 que chaque étape de localisation comprend au moins une entité exprimant une filiation entre les données structurées. 5. Procédé d'évaluation selon la revendication 4, caractérisé en ce que la filiation est une filiation indirecte. 6. Procédé d'évaluation selon la revendication 5, caractérisé en ce que le procédé comprend une étape de détermination des sous- expressions ayant au moins une entité exprimant une filiation indirecte. 30 7. Procédé d'évaluation selon la revendication 6, caractérisé en ce qu'il comprend une étape de test approfondi sur ladite au moins une entité 25 2908539 41 exprimant une filiation indirecte, le test approfondi étant fonction de conditions sur les données et sur les évaluations précédentes desdites données. 8. Procédé d'évaluation selon la revendication 7, caractérisé en ce 5 que le procédé comprend : - une étape d'extraction des données sur la base desquelles les sous-expressions sont évaluées ; et - une étape de mémorisation des données extraites. 10 9. Procédé d'évaluation selon l'une quelconque des revendications précédentes, caractérisé en ce que lors de l'évaluation d'une seconde sous-expression faisant suite à une première sous-expression, ledit au moins un navigateur de la seconde sous-expression est initialisé avec le contexte du navigateur de la première sous-expression. 15 10. Procédé d'évaluation selon l'une quelconque des revendications précédentes, caractérisé en ce que chacun desdits navigateurs pilote au moins un analyseur du document structuré. 11. Procédé d'évaluation selon la revendication 10, caractérisé en ce que si des navigateurs utilisent un même analyseur (3), les données extraites par un navigateur sont réutilisées par un autre navigateur utilisant ce même analyseur. 12. Procédé d'évaluation selon l'une quelconque des revendications précédentes, caractérisé en ce que le procédé comprend une étape de détermination des données extraites du document vérifiant l'ensemble des sous-expressions. 13. Procédé d'évaluation selon la revendication 12, caractérisé en ce que dès que des données sont déterminées, lesdites données sont fournies à une application apte à traiter ces données. 2908539 42 14. Procédé d'évaluation selon la revendication 12, caractérisé en ce que les données déterminées sont mémorisées. 5 15. Procédé d'évaluation selon la revendication 12, caractérisé en ce que si des données déterminées ont une relation de filiation directe ou indirecte avec des données préalablement déterminées, alors ces données sont émises après les données préalablement déterminées. 10 16. Procédé d'évaluation selon la revendication 15, caractérisé en ce que l'émission des données déterminées est précédé d'un signal de début et est suivi d'un signal de fin. 17. Procédé d'évaluation selon l'une quelconque des revendications 15 précédentes, caractérisé en ce que l'expression est une expression de type XPath. 18. Dispositif d'évaluation d'une expression pour accéder à au moins une partie d'un document structuré au moyen d'au moins un navigateur apte à 20 extraire les données structurées du document, l'expression étant composée d'au moins deux sous expressions relatives chacune à un chemin de localisation, caractérisé en ce qu'il comprend des moyens d'évaluation de chacune des sous-expressions sur la base des données du document au moyen d'au moins un navigateur distinct pour chaque sous-expression. 25 19. Dispositif d'évaluation selon la revendication 18, caractérisé en ce qu'il comprend des moyens de détermination du nombre de navigateurs. 20. Dispositif d'évaluation selon la revendication 18 ou la 30 revendication 19, caractérisé en ce que chaque sous-expression relative à un chemin comprend un ensemble d'étapes de localisation. 2908539 43 21. Dispositif d'évaluation selon la revendication 20, caractérisé en ce que chaque étape de localisation comprend au moins une entité exprimant une filiation entre les données structurées. 5 22. Dispositif d'évaluation selon la revendication 21, caractérisé en ce que la filiation est une filiation indirecte. 23. Dispositif d'évaluation selon la revendication 22, caractérisé en ce que le dispositif comprend des moyens de détermination des sous-10 expressions ayant au moins une entité exprimant une filiation indirecte. 24. Dispositif d'évaluation selon la revendication 23, caractérisé en ce qu'il comprend des moyens de test approfondi sur ladite au moins une entité exprimant une filiation indirecte, le test approfondi étant fonction de conditions 15 sur les données et sur les évaluations précédentes desdites données. 25. Dispositif d'évaluation selon la revendication 24, caractérisé en ce que le dispositif comprend : - des moyens d'extraction des données sur la base desquelles les 20 sous-expressions sont évaluées ; et - des moyens de mémorisation des données extraites. 28. Dispositif d'évaluation selon l'une quelconque des revendications 18 à 25, caractérisé en ce qu'il comprend des moyens d'initialisation aptes à 25 initialiser ledit au moins un navigateur de la seconde sous-expression avec le contexte du navigateur de la première sous-expression lors de l'évaluation d'une seconde sous-expression faisant suite à une première sous-expression. 29. Dispositif d'évaluation selon l'une quelconque des revendications 30 18 à 26, caractérisé en ce que chacun desdits navigateurs pilote au moins un analyseur du document structuré. 2908539 44 28. 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 l'une quelconque des revendications 1 à 17, lorsque ce programme est chargé et exécuté par un 5 système informatique. 29. 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 10 l'exécution des étapes du procédé d'évaluation d'une expression selon l'une quelconque des revendications 1 à 17.