Brevet FR2915295A1 — publié le 20081024

La présente invention concerne un procédé et un dispositif d'évaluation de requêtes sur un document hiérarchisé. Elle s'applique, en particulier au traitement, à la volée, de documents en langage XPath. XPath (acronyme de eXtensible Markup Language Path Language pour langage de chemin de langage de balisage extensible ) est une spécification du consortium W3C (acronyme de worldwide web consortium pour consortium de la toile d'étendue 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 ). 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, commentaire, processing-instruction et namespace . Cette syntaxe sert de base à la formation de requêtes sur des documents XML en vue de leur transformation ( XSLT ), d'accéder rapidement à des sous-parties ( XPointer ) ou d'effectuer des traitements sur des parties du document ( XQuery ). XPath a pour principal avantage de simplifier le développement d'applications appelées à naviguer dans des documents XML. L'entité responsable de l'évaluation d'une requête sur un document hiérarchisé XPath est appelée Processeur XPath . Le processeur XPath accepte généralement comme entrées d'une part une ou plusieurs requêtes sur un document hiérarchisé 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 requête doit être évaluée. L'évaluation d'une requête consiste à appliquer cette requête sur un document XML donné. Dans l'exemple /bookstore/book, l'évaluation sur un document XML consiste à extraire de ce document tous les éléments nommés book se trouvant à la profondeur de deux et ayant comme parent l'élément nommé bookstore . XPath définit les quatre types de données mentionnés ci-dessus ainsi que sept types de noeuds. La syntaxe XPath définit également une grammaire décrivant les règles de construction des différentes requêtes et sous-requêtes. Ces requêtes peuvent être regroupées selon les sous catégories suivantes : - requêtes retournant un booléen : OrExpr , AndExpr , 10 RelativeExpr , EqualityExpr ; - requêtes retournant un nombre AdditiveExpr , MultiplicativeExpr ; - requêtes retournant n'importe quel type : FilterExpr et, en particulier, les FunctionCall et 15 - requêtes retournant une liste ordonnée de noeuds essentiellement les LocationPath qui correspondent à la spécification d'un chemin de localisation à résoudre dans un document XML. Ce sont ces dernières requêtes qui sont particulièrement concernées par la présente invention. 20 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). 25 Toute LocationPath est composée d'étapes de localisation ( Steps en terminologie XPath) . Ce niveau de décomposition est le niveau clé pour l'évaluation des LocationPath car il peut être mis en correspondance avec un niveau de profondeur dans le document XML. Par exemple, la requête /bookstore/book contient deux Steps qui sont : 30 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 la requête. 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 requête de type Step est composée de une à trois entités. L'entité NodeTest est obligatoire et définit la contrainte de type (node(), text(), 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 . L'entité AxisSpecifier , optionnelle ( child , par défaut), décrit la relation entre le noeud contexte et les noeuds solution du Step . L' AxisSpecifier est un mot-clé parmi treize prédéfinis par la syntaxe XPathl.0, 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 à la racine du document et un noeud attribut b fils d'un noeud a se trouvant à la racine du document. Les treize AxisSpecifier définis par la spécification sont les suivants : - self , attribute (ou @ ), namespace , child , descendant , descendant-or-self , following , following-sibling qui sont considérés comme des axes vers l'avant 25 ( 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 axes ou reverse axes en anglais). L'entité Predicate , optionnelle, permet d'imposer des conditions 30 supplémentaires pour la recherche de noeuds solutions. Une requête prédicat est signalée par des crochets : [...] et suit les mêmes règles de construction que toute requête XPath . Par exemple, /a/b[2] permet de sélectionner tous les deuxièmes fils b de chaque élément a et /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 par exemple, et à parcourir cet arbre autant de fois que nécessaire pour l'extraction des noeuds demandés. Une telle approche pose un double problème. Tout d'abord, une telle approche peut s'avérer coûteuse en mémoire dans le cas de documents XML de grande taille. Or, dans le cas d'un processeur XPath implanté dans un appareil embarqué, par exemple un appareil photo ou un photocopieur, les ressources en mémoire sont limité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, ou web services , par exemple). Si l'on regarde les quatre premières requêtes 11 dans l'exemple de la figure 2, on s'aperçoit qu'un élément book 10 est potentiellement solution de chaque requête sous réserve que l'on ait vérifié une ou plusieurs conditions sur son prix, son titre, etc... En d'autres termes, il existe deux possibilités pour n'importe quel processeur XPath : - soit on évite les parcours multiples, ce qui impose au processeur de conserver en mémoire l'élément book et son contenu jusqu'à ce que le processeur ait assez d'informations XML afin de décider si l'élément book est solution ou non, - soit on évite de stocker : pour cela, soit le processeur dispose d'une représentation du document XML qu'il peut parcourir à volonté, au détriment du temps de réponse, soit il conserve un marqueur sur la position correspondant au début de l'élément book . Dans ce dernier cas, il explore plus avant le document XML, à la recherche d'informations lui permettant de prendre une décision concernant l'élément book . Une fois la décision prise, le processeur retourne à la position du début de l'élément book pour éventuellement émettre le résultat et explorer le document à la recherche d'autres solutions. Il apparaît clairement que la deuxième solution n'est pas envisageable dans un contexte d'application embarquée et communicante où les ressources mémoire sont limitées et où les données doivent être consommées au fur et à mesure de leur réception. La première solution où l'on stocke le nombre minimum d'information permettant de décider impose cependant de contrôler la somme d'information qui est sauvegardée en mémoire afin de garantir un fonctionnement correct de l'application et d'éviter tout débordement de mémoire tampon et toute consommation excessive de mémoire. Le problème de contrôle de mémoire tampon dans des systèmes d'information manipulant des données structurées est essentiellement présent en entrée des analyseurs ( parser en anglais) XML. Par exemple, la demande de brevet US 2004/026844 intitulée Scalable storage and processing of hierarchical documents propose une solution proche de la deuxième solution exposée ci-dessus, sous la forme d'un système de mémoire tampon avec un point de repère à partir duquel on peut rejouer les informations contenues en mémoire. Cependant, aucune stratégie de contrôle de débordement n'y est mise en oeuvre. La présente invention vise à remédier à ces inconvénients. En particulier, un des buts de la présente invention est de fournir un contrôle de consommation mémoire dans le cadre d'évaluations XPath à la volée. A cet effet, selon un premier aspect, la présente invention vise un procédé de contrôle de consommation mémoire lors de l'évaluation d'au moins une requête sur au moins un document hiérarchisé comportant : - une étape d'analyse d'au moins une requête pour détecter si elle est susceptible d'entraîner un débordement de mémoire tampon lors de l'évaluation de ladite requête et - lorsque ladite requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape d'évaluation de ladite requête mettant en oeuvre un premier mode d'évaluation et lorsque ladite requête n'est pas susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape d'évaluation de ladite requête mettant en oeuvre un deuxième mode d'évaluation en fonction du résultat de ladite analyse, ledit premier mode d'évaluation utilisant moins de mémoire tampon que le deuxième mode d'évaluation. Parmi les avantages découlant de la mise en oeuvre de la présente invention, on peut citer : - l'efficacité, car il est effectué un parcours unique du document, ce qui garantit le traitement à la volée du flux de données ; - cette analyse s'avère peu coûteuse car elle peut être réalisée une 15 seule fois pour de multiples évaluations ; - le mécanisme s'avère dynamiquement adaptable de par l'analyse dynamique lorsque des risques multiples existent et différentes stratégies ou combinaison de stratégies peuvent être appliquées au cours de l'évaluation. - les cas simples ne sont pas pénalisés car la gestion de mémoire 20 n'est pas nécessaire. Par rapport à l'état de l'art, on va ainsi au-delà d'une approche en tout ou rien lorsque le risque de débordement existe. Selon des caractéristiques particulières, le premier mode d'évaluation est avec pertes et le deuxième mode d'évaluation est sans perte. 25 L'évaluation en mode avec pertes correspond à une évaluation où tous les résultats (emboîtés ou non) sont considérés mais leur contenu peut être tronqué. Selon des caractéristiques particulières, dans le premier mode d'évaluation avec pertes, on tronque le contenu d'au moins une partie des 30 résultats de la requête. Selon des caractéristiques particulières, pour tronquer le contenu d'au moins une partie des résultats de la requête, on supprime : - des noeuds selon au moins un des critères suivants : le noeud est de type commentaire , le noeud est de type texte et ne contient que des informations de mise en page, et le noeud est de type texte et correspond à une taille supérieure à une valeur prédéterminée ; - le contenu des résultats en ne conservant que l'évènement de début ; et/ou - le contenu des résultats en ne conservant qu'un numéro 10 d'évènement. On note que, la suppression de ces noeuds présente les avantages suivants : en ce qui concerne les noeuds de type commentaire , ces informations étant destinés à un lecteur mais pas à un traitement automatique, leur suppression permet de gagner de l'espace mémoire sans nuire à l'application, - en ce qui concerne les noeuds de type texte qui ne contiennent que des informations de mise en page, les données réelles étant plus importantes que les informations de mise en page, leur suppression de ces données n'influe que sur le rendu du résultat mais pas sur sa valeur et en ce qui concerne les noeuds de type texte qui correspondent à une taille supérieure à une valeur prédéterminée, en éliminant les noeuds texte les plus coûteux, on concentre la perte d'information sur un minimum de noeuds et on libère un espace mémoire conséquent. On note aussi que la suppression du contenu des résultats en ne conservant que l'évènement de début ; et/ou du contenu des résultats en ne conservant qu'un numéro d'évènement, permettent à l'application d'être 30 informée d'un résultat tout en minimisant le coût de stockage. L'application dispose de la localisation de l'événement dans le document. L'application a donc la possibilité de récupérer et de reconstruire ultérieurement ce résultat. 15 20 25 Selon des caractéristiques particulières, le premier mode d'évaluation comporte une évaluation complète de l'expression au cours de laquelle on écarte les résultats emboîtés. Ainsi, les résultats emboîtés ne sont pas considérés et il n'est pas nécessaire de stocker ces résultats particuliers. On réduit donc l'encombrement de la mémoire tampon. Selon des caractéristiques particulières, après l'étape de compression, le premier mode d'évaluation comporte une étape de vérification de la taille de la mémoire tampon occupée et, si cette taille est supérieure à une valeur seuil prédéterminée, on met en oeuvre une évaluation en mode dégradé ou avec pertes. Selon des caractéristiques particulières, le premier mode d'évaluation comporte une étape de compression de données mémorisées relatives à ladite requête et une étape de décompression des données compressées. Selon des caractéristiques particulières, le premier mode d'évaluation comporte une étape de stockage externe, en dehors de la mémoire tampon, de données mémorisées relatives à ladite requête. Selon des caractéristiques particulières, le premier mode d'évaluation comporte une évaluation incomplète de l'expression au cours de laquelle, lorsque l'on traite des évènements correspondants au contenu d'un résultat, on désactive la recherche de nouveaux résultats, tant que la fin du résultat en cours n'est pas atteinte. Selon des caractéristiques particulières, au cours de l'étape d'analyse, on détermine si, au cours de l'analyse sémantique on a rencontré des axes dits récursifs. Les axes récursifs sont, par exemple : descendant , descendant-or-self , ancestor ou ancestor-or-self . Si tel est le cas, alors il existe un risque de résultats emboîtés (des résultats contenus à l'intérieur d'un résultat). Selon des caractéristiques particulières, au cours de l'étape d'analyse, on détermine si des prédicats sont présents dans la requête à évaluer. Si tel est le cas, cela signifie qu'il existe un risque de décision différée (un noeud ne peut être déclaré solution que si les prédicats associés peuvent être résolus). Grâce à chacune de ces dispositions, on peut recourir à du stockage, par exemple jusqu'à ce que toutes les composantes de la requête soient résolues. Selon des caractéristiques particulières, au cours de l'étape d'analyse , on détermine un type de risque de débordement et le procédé tel que succinctement exposé ci-dessus comporte, lorsque la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape de sélection d'un premier mode d'évaluation en fonction du type de risque déterminé au cours de l'étape d'analyse. Selon des caractéristiques particulières, les types de risque comportent au moins l'un des types suivants : un type décision différée - un type résultats emboîtés . Selon des caractéristiques particulières, au cours de l'étape de sélection du premier mode d'évaluation, si le type de risque est résultats emboîtés , on détermine s'il est possible de traiter en mode d'évaluation dégradé et, si oui, le premier mode d'évaluation sélectionné est le mode d'évaluation dégradé. Selon des caractéristiques particulières, s'il n'est pas possible de traiter la requête en mode d'évaluation dégradé, on détermine si un mode d'évaluation avec stockage externe est possible et, si oui, le premier mode d'évaluation sélectionné est un mode d'évaluation avec stockage externe. Selon des caractéristiques particulières, si un mode d'évaluation avec stockage externe n'est pas possible, on détermine si un mode d'évaluation avec pertes est possible et, si oui, le premier mode d'évaluation sélectionné est un mode d'évaluation avec pertes. Selon des caractéristiques particulières, si mode d'évaluation avec pertes n'est pas possible, le premier mode d'évaluation sélectionné est un mode d'évaluation avec compression de données relatives à ladite requête. Selon des caractéristiques particulières, au cours de l'étape de sélection du premier mode d'évaluation, si le type de risque est décision différée , on détermine si le type de risque est aussi un type résultats emboîtés et, si non, le premier mode d'évaluation est sélectionné parmi le mode d'évaluation avec pertes et le mode d'évaluation avec compression des données relatives au document sur lequel on évalue la dite requête. Selon des caractéristiques particulières, au cours de l'étape de sélection du premier mode d'évaluation, si le type de risque est décision différée , on détermine si le type de risque est aussi un type résultats emboîtés et, si oui, on parcourt la liste des noeuds présents en mémoire tampon et on détermine quel type de noeud est majoritairement présent en mémoire tampon, parmi les types de noeuds suivants : type en attente de décision et type appartient à un résultat emboîté et on sélectionne le premier mode d'évaluation en fonction du type de noeud majoritaire dans la mémoire tampon. L'intérêt d'une telle mise en oeuvre est de considérer tous les types de risques et, de plus, d'adapter dynamiquement la gestion du risque de débordement en fonction du type de noeuds présents en mémoire. Selon des caractéristiques particulières, lorsque la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, on effectue une étape d'affichage, sur une interface utilisateur, d'un message indiquant que la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation et une étape de sélection, par l'utilisateur d'un mode d'évaluation de la requête. Grâce à ces dispositions, l'utilisateur peut lui-même décider quel type d'évaluation il souhaite voir utiliser. Selon un deuxième aspect, la présente invention vise un dispositif de contrôle de consommation mémoire lors de l'évaluation d'au moins une requête 30 sur au moins un document hiérarchisé comportant : - un moyen d'analyse d'au moins une requête pour détecter si elle est susceptible d'entraîner un débordement de mémoire tampon lors de l'évaluation de ladite requête et -un moyen d'évaluation adapté : - lorsque ladite requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, à évaluer ladite requête mettant en oeuvre un premier mode d'évaluation et -lorsque ladite requête n'est pas susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, à évaluer ladite requête mettant en oeuvre un deuxième mode d'évaluation en fonction du résultat de ladite analyse, ledit premier mode d'évaluation utilisant moins de mémoire tampon que le deuxième mode d'évaluation. Selon un troisiè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é de contrôle tel que succinctement exposé ci-dessus. Selon un quatriè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é de contrôle tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques de ce dispositif, de ce programme et de ce support d'information étant similaires à ceux du procédé de contrôle 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, schématiquement, un contexte applicatif de l'invention, - la figure 2 représente, schématiquement, un document XML et une recherche XPath, - la figure 3 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention, - la figure 4 représente, sous forme d'un logigramme, des étapes d'un mode de réalisation particulier du procédé objet de la présente invention et - les figures 5 à 7 représentent des détails des étapes illustrées en figure 4. Comme illustré en figure 1, la mise en oeuvre du mode particulier de réalisation du procédé objet de la présente invention décrit en figures 3 à 7 concerne une application manipulant des données XML 101 extraites par un ou plusieurs processeurs XPath 102 grâce à un ou plusieurs analyseurs XML 103 ( parser en anglais) travaillant sur un flux de données XML 104. Le processeur XPath comprend cinq entités principales : - un compilateur 121 qui analyse les requêtes et les traduit en une représentation interne, décrit en regard de la figure 4. Celui ci est composé de deux analyseurs, l'un lexical 161, l'autre sémantique 162 ; - une unité de contrôle d'exécution 122 qui gère la communication avec l'application, les interactions entre les différents modules et prend en charge l'évaluation de noeuds XPath ; - un ou plusieurs navigateurs XPath 123 qui permettent au contrôleur d'exécution de communiquer de façon générique avec n'importe quel analyseur XML 103 et de représenter et de mémoriser les évènements XML sous forme de noeuds XPath. La mémorisation des noeuds se fait dans une mémoire tampon 173 ; -un gestionnaire de mémoire 124 qui surveille la mémoire tampon 173 au cours de l'évaluation afin de parer à tout débordement. Il est à noter que ce gestionnaire de mémoire 124 peut être, selon une variante, déporté au niveau de l'application qui, lors de la récupération de résultats, peut demander au processeur 102 l'état de l'occupation de la mémoire tampon 173 et, en fonction de cette occupation de la mémoire tampon 173, éventuellement changer de mode d'évaluation et - une unité de compression/décompression 125 permettant de compacter et de décompacter les informations décrivant les noeuds XPath. Les principales étapes de l'évaluation d'une requête XPath sont : - son analyse en vue de sa compilation, - puis son évaluation sur un flux de données XML. La présente invention est préférentiellement mise en oeuvre dans le 5 ou les processeurs XPath 102, notamment : - dans le compilateur 121, pour la partie analyse du risque de débordement de mémoire et - dans le contrôleur 122, le gestionnaire de mémoire 124, l'unité de compression/décompression 125, pour la partie activation et exécution des 10 stratégies d'évitement de débordement. Selon un mode de réalisation préféré, le processeur XPath 102 est à l'écoute d'évènements XML émis par le navigateur XML 103. Il agit ainsi comme un filtre sur ces évènements en ne transmettant à l'application 101 utilisant le processeur XPath 102, ou n'utilisant respectivement que ceux 15 répondant à la requête ou à une sous requête XPath. Selon l'invention, le processeur XPath 102 est, en plus du mode d'évaluation normal, apte à mettre en oeuvre plusieurs modes d'évaluation : dégradé , avec pertes , avec stockage externe et avec compression qui correspondent respectivement à une évaluation sans tous les éventuels 20 résultats emboîtés, à une évaluation avec tous les résultats mais dont le contenu peut être tronqué, à une évaluation complète mais nécessitant un stockage externe et à une représentation interne des noeuds XPath en mémoire tampon 173 sous une forme compressée (XML binaire par exemple). Ces modes d'évaluation peuvent être activés et/ou désactivés en cours d'évaluation 25 et le processeur XPath 102 sait indiquer à l'application lequel ou lesquels de ces modes d'évaluation il implémente. En ce qui concerne l'évaluation en mode avec pertes , elle correspond à une évaluation où tous les résultats (emboîtés ou non) sont considérés mais leur contenu peut être tronqué. Par exemple, dans le cas 30 d'éléments à l'intérieur desquels se trouvent des noeuds de type commentaire , ces commentaires peuvent être supprimés de la mémoire tampon. De plus, dans ce mode avec pertes, si la suppression des éventuels noeuds commentaires ne permet pas de dégager d'espace mémoire suffisant, on peut supprimer les noeuds de type texte qui contiennent uniquement des informations de mise en page, par exemple des espaces, des tabulations et/ou des retours à la ligne, ou supprimer, en premier lieu, les noeuds ayant la taille la plus importante. Une autre alternative consiste à ne conserver que l'évènement XML correspondant au début de résultat, par exemple, dans le cas d'un élément, seuls la balise ouvrante avec le nom de l'élément et ses attributs seraient transmis, le contenu ne serait alors pas gardé en mémoire. Une alternative supplémentaire consiste à ne conserver que le numéro de l'évènement qui a déclenché un résultat afin que l'application puisse en re-parcourant le document obtenir les données XML correspondant au résultat. Cette alternative s'avère pertinente dans le cas de résultats emboîtés : l'application recevant un résultat, se voit informée au cours de la réception de ce résultat qu'un noeud XML contenu dans ce résultat a déclenché un nouveau résultat. L'application peut donc commencer à construire le deuxième résultat en parallèle et à partir du premier (donc sans re-parcourir le document). De son côté le processeur XPath n'a plus besoin de sauvegarder les résultats emboîtés. La figure 3 représente un dispositif 201 auquel s'applique la présente invention, tel un micro-ordinateur et ses différents périphériques. Selon le mode de réalisation choisi et représenté à la figure 3, un dispositifmettant en oeuvre l'invention est, par exemple, un micro-ordinateur 201 connecté à différents périphériques. Le dispositif 201 comporte une interface de communication 218 reliée à un réseau 202 apte à transmettre et à recevoir des données numériques. Le dispositif 201 comporte également un moyen de stockage 214 tel que par exemple un disque dur. II comporte aussi un lecteur de disquette 215. La disquette 224 peut contenir des données XML ainsi que le code exécutable d'un programme implémentant le procédé objet de la présente l'invention qui, une fois lu par le dispositif 1, est stocké dans le disque dur 214. Selon une variante, le programme permettant au dispositif de mettre en oeuvre l'invention, peut être stocké en mémoire morte ROM 210. En seconde variante, le programme pourra être 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 201 possède un écran 212 permettant de visualiser les résultats des évaluations. A l'aide du clavier 213, l'utilisateur peut spécifier une requête XPath. L'unité centrale CPU 211 exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 210 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes relatifs à l'évaluation de requêtes XPath et d'extraction des évènements XML stockés dans une mémoire non volatile, par exemple la ROM 210, sont transférés dans la mémoire vive RAM 217 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 224 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 221 permet la communication entre les différents éléments inclus dans le micro-ordinateur 201 ou reliés à lui. La représentation du bus 221 n'est pas limitative et notamment l'unité centrale 211 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 201 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 201. La figure 4 représente des étapes mises en oeuvre dans un mode de réalisation du procédé objet de la présente invention, pour évaluer une requête XPath. Dans ce mode de réalisation, la requête XPath à évaluer peut, sans que ce soit limitatif, être spécifiée par un utilisateur ou bien être pré-stockée dans un fichier lu par l'application implémentant le procédé objet de la présente invention ou encore résulter de l'exécution, au niveau de cette application, d'un programme générant des requêtes XPath. Cette requête est reçue par le processeur XPath 102 lors d'une étape 301. Au cours d'une étape 302, on débute une analyse lexicale en analysant, un à un, les caractères qui représentent la requête XPath et en les regroupant 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 302 est effectuée par l'analyseur lexical 161, qui dispose d'une table de symboles prédéfinis en fonction de la grammaire XPath 1.0. A la suite de la décomposition en symboles de l'étape 302, au cours d'une étape 303, on teste les symboles générés. Si au cours de cette étape 303, un des symboles est analysé comme non permis ou inconnu , par l'analyseur lexical 161, le compilateur 121 s'arrête et informe le contrôleur d'exécution 122 de la non-conformité de la requête, lors d'une étape 306. Cette requête ne peut donc pas être évaluée. Si l'étape 303 conduit à ce que l'analyseur lexical 161 considère l'ensemble de symboles comme valides, on passe à une étape 304. Cette étape 304 consiste, pour l'analyseur sémantique 162, à parcourir la liste de symboles issus de l'étape 302 et à identifier les types de requêtes définis par la syntaxe XPath 1.0 et contenus dans la requête à compiler. Par exemple, si le premier symbole trouvé correspond à / , il s'agit d'une AbsoluteLocationPath au sens de la grammaire XPath. Dans ce cas, le compilateur 121 poursuit l'analyse des symboles pour identifier les composantes de cette AbsoluteLocationPath , typiquement les Steps , eux-mêmes composés d ( AxisSpecifier , de NodeTest et, éventuellement, de Prédicats . Puis, au cours d'une étape 305, on détermine si la suite de symboles permet de construire une requête valide au sens de la grammaire XPath. Si oui, la requête a été compilée avec succès et l'analyse du risque peut débuter. A cet effet, le compilateur 121 détermine, au cours d'une étape 307 si, au cours de l'analyse sémantique de l'étape 304, il a rencontré des axes dits récursifs : descendant , descendant-or-self , ancestor ou ancestor-or-self . Si tel est le cas, alors il existe un risque de résultats emboîtés (des résultats contenus à l'intérieur d'un résultat). Cette information est sauvegardée au niveau du compilateur 121, au cours d'une étape 309. Parallèlement à la vérification sur les valeurs d'axes, le compilateur 121 détermine, au cours d'une étape 308 si des prédicats sont présents dans la requête à évaluer. Si tel est le cas, cela signifie qu'il existe un risque de décision différée (un noeud ne peut être déclaré solution que si les prédicats associés peuvent être résolus). Cette information est alors sauvegardée au niveau du compilateur 121 au cours d'une étape 310. Puis, au cours d'une étape 311, on détermine si le compilateur 121 a noté qu'un risque de débordement de mémoire existait, c'est-à-dire si au moins une des étapes 307 et 308 a donné un résultat positif, ou non...DTD: S'il y a un risque de débordement de mémoire, le gestionnaire de mémoire est activé au cours d'une étape 312, puis la requête est évaluée au cours d'une étape 313. Si le résultat de l'étape 311 indique qu'il n'existe pas de risque de débordement, par exemple pour une requête du type /bookstore/book/title , on passe directement à l'évaluation de la requête, au cours d'une étape 313, sans activer le gestionnaire de mémoire. Dans un mode particulier de mise en oeuvre de l'invention, où le processeur XPath est utilisé depuis une interface graphique utilisateur (en anglais GUI ou graphical user interface ), l'étape 311 est suivie de l'émission d'un message d'avertissement, au cours d'une étape 311b destinée à informer l'utilisateur de l'existence du risque de débordement. Suite à cet avertissement, l'utilisateur peut : - ignorer le message et continuer l'évaluation, - reformuler son expression en la simplifiant si cela est possible, - choisir d'évaluer la requête en l'état dans un mode dégradé, par 25 exemple en ne considérant pas les résultats emboîtés ou -choisir d'évaluer la requête en l'état sans écarter le moindre résultat mais en imposant une stratégie de prévention de débordement parmi une liste qui lui est proposée, par exemple, compression des données mémorisées, relecture locale du flux de données XML si cela est possible, et/ou 30 recours à un stockage externe. En fonction du choix de l'utilisateur lors de l'étape 311b, le traitement de la requête s'arrête ou se poursuit au cours d'étapes 312 et 313 en mettant en oeuvre le mode d'évaluation de requête sélectionné par l'utilisateur. La figure 5 illustre des étapes d'évaluation d'une requête XPath qui commence au cours de l'étape 313. L'évaluation débute par une étape 400 où le contrôleur d'exécution 122 récupère la requête XPath compilée par le compilateur 121 à l'étape 304. L'évaluation d'une requête XPath se base sur la structure générée par le compilateur, à savoir, principalement, la décomposition de la requête en sous-requêtes filles. Puis, on suit la relation parente-fille de la requête compilée afin de savoir s'il existe une sous requête, au cours d'une étape 401. Si c'est le cas, pour cette sous requête, on suit la relation parente-fille associée et on boucle sur le test de l'étape 401 jusqu'à ce qu'aucune sous requête ne soit plus disponible. Une fois que plus aucune sous requête n'est disponible, au cours d'une étape 402, on démarre l'évaluation de la sous requête courante. Cela consiste en une initialisation des statuts d'évaluation de la sous requête. Vient ensuite une étape 403 au cours de laquelle le contrôleur 122 détermine si le compilateur 121 a pré-calculé un résultat pour la sous requête courante. Si c'est le cas, le contrôleur récupère la requête parente, si elle existe, lors d'une étape 406. S'il n'en existe pas, le résultat est le résultat final de l'évaluation et il est retourné à l'application qui utilise le processeur XPath, lors d'une étape 409. Si une requête parente existe, au cours d'une étape 407, on propage le résultat de la sous requête fille vers sa requête parente. Puis, au cours d'une étape 408, ce résultat est éventuellement (en fonction de la présence ou non de d'au moins une requête soeur du type de la requête parente) agrégé avec d'autres résultats de sous requêtes soeurs, par exemple un résultat pour un opérande d'une requête d'addition. Cette étape d'agrégation peut être, par exemple, une simple conversion de type. On boucle ensuite sur l'étape 406 jusqu'à atteindre la requête principale sans requête parent au cours de l'étape de test 406, puis on effectue l'émission du résultat final au cours d'une étape 409. Si l'étape 403 indique que le compilateur n'a pas trouvé de résultat pour la sous requête courante, cela signifie que la sous requête a besoin d'informations XML pour être complètement évaluée. Dans ce cas, au cours d'une étape 404, la sous requête est mise en attente de ces informations XML et de leur interprétation par le contrôleur 122. Le contrôleur 122 maintient une liste de LocationPath en cours d'évaluation ainsi que le Step courant pour chacune de ces LocationPath . Puis l'on passe à une étape 405 de recherche de la requête parente puis, pour cette requête parente, on continue la descente le long de ses requêtes filles, au cours de l'étape 401. Le déblocage de chaque sous requête mise en attente lors de l'étape 405 est décrit ci-dessous en référence à la figure 6 qui détaille les traitements consécutifs à l'émission d'un évènement XML par le navigateur XML 103. Ce traitement débute par la réception de l'évènement XML, lors d'une étape 500, au niveau du navigateur XPath 123. Suite à cette réception, le navigateur XPath 123 retire de la mémoire tampon 173 les éventuels noeuds marqués comme obsolètes lors d'une étape 501. Puis, le contrôleur d'exécution 122 détermine, au cours d'une étape 502, si un risque de débordement de mémoire tampon est associé à la requête à évaluer. L'étape 502 consiste à déterminer si le gestionnaire de mémoire 124 a été activé par le compilateur 121 lors de l'étape 312. Dans le cas où aucun risque n'a été détecté, on sélectionne un deuxième mode d'évaluation et le noeud représentant l'évènement XML courant est sauvegardé dans la mémoire tampon 173 par le navigateur XPath 123 au cours d'une étape 503. Puis, au cours d'une étape 504, on évalue ce noeud. Pour cette évaluation, le contrôleur d'exécution 122 détermine, de manière connue, si ce noeud vérifie la ou les relations de filiation ( AxisSpecifier ) et le ou les tests de noeud ( NodeTest ) imposés par le ou les Step courants des différentes LocationPath indexées par le contrôleur 122 lors de l'étape 404. Au cours de cette étape évaluation 504 mettant en oeuvre le deuxième mode d'évaluation, le noeud est marqué comme solution , solution potentielle ou non solution , selon respectivement qu'il satisfait une des LocationPath indexées, qu'il reste à vérifier des prédicats sur ce noeud ou qu'il ne satisfait aucune des LocationPath indexées. Puis, au cours d'une étape 505 le contrôleur détermine si le noeud courant est une solution ou pas. Si c'est le cas, lors d'une étape 506, le contrôleur récupère, dans sa liste de LocationPath indexées, celles dont le dernier Step est satisfait par le noeud courant. Pour chacune des LocationPath , le contrôleur émet un signal de résultat qui consiste à leur envoyer le noeud résultat. Cela permet de sortir les LocationPaths de leur attente, au cours de l'étape 404b de la figure 5, et de les faire passer aux étapes 406 à 409 de propagation de résultat. Dans le cas où l'étape 505 indique que le noeud courant n'est pas solution ou est une solution potentielle , le processeur se met en attente du prochain évènement XML reçu, en retournant à l'étape 500. Si l'étape 502 indique que le gestionnaire de mémoire 124 est activé, celui-ci détermine, au cours d'une étape 507, si la mémoire est quasiment remplie. A cet effet, lors de la création du processeur XPath, on peut lui spécifier une taille maximale pour sa mémoire tampon. Cette taille mémoire peut être exprimée, sans que ce soit limitatif, comme un nombre de noeuds XPath ou comme un nombre d'octets maximal pouvant être stockés. La détermination de l'étape 507 peut consister à vérifier que, par exemple, 90% de la mémoire est occupée. Si ce n'est pas le cas, le noeud est sauvegardé puis traité comme décrit précédemment aux étapes 503 à 506, en mettant en oeuvre le deuxième mode d'évaluation. En revanche, si un seuil d'occupation de mémoire (ici 90 %) est franchi, on sélectionne un premier mode d'évaluation parmi une pluralité de premiers modes d'évaluation utilisant, chacun, moins d'espace de mémoire tampon que le deuxième mode d'évaluation. A cet effet, on sélectionne une stratégie de gestion du risque ou d'évitement du débordement puis on applique cette stratégie. Ces étapes sont réalisées lors d'étapes 508 et 509 et détaillées en référence à la figure 7. La sélection de la stratégie anti-débordement de la mémoire tampon, c'est-à-dire du premier mode d'évaluation parmi une pluralité de modes d'évaluation, se base sur l'analyse faite par le compilateur 121 lors des étapes 307 à 310 et éventuellement sur une analyse des noeuds présents en mémoire tampon 173. Pour cela, le contrôleur d'exécution récupère, au cours d'une étape 600, le type de risque identifié par le compilateur 121. Il est à noter que l'arrivée à l'étape 600 fait suite à une étape de test 507 qui a indiqué qu'un risque de débordement existait pour le noeud XPath représentant l'évènement XML reçu au cours de l'étape 500. Le contrôleur détermine donc si le risque est de type décision différée lors d'une étape 601. Si ce n'est pas le cas, il détermine, au cours d'une étape 602, s'il s'agit d'un risque de type résultats emboîtés . S'il s'agit d'un risque de type résultats emboîtés , au cours d'une étape 603, on détermine si le processeur XPath supporte un mode d'évaluation dégradé. Si tel est le cas, la stratégie retenue est alors l'évaluation en mode dégradé, au cours d'une étape 604. Si le processeur XPath 102 ne supporte pas le mode dégradé ou si celui-ci n'est pas activé, le contrôleur d'exécution détermine si le recours à un stockage externe est possible, lors d'une étape 605. Si le recours à un stockage externe est possible, le contrôleur sélectionne comme stratégie le mode stockage externe , lors d'une étape 606. Dans le cas où le résultat de l'étape 605 est négatif, le contrôleur d'exécution détermine si un mode d'évaluation avec pertes est permis, au cours d'une étape 607. Si un mode d'évaluation avec pertes est permis, au cours d'une étape 608, on retient la stratégie mode avec pertes . Sinon, la stratégie retenue est alors le mode compression , au cours d'une 609. Si le résultat de l'étape 601 est positif, il y a un risque de décision différée. Dans ce cas, au cours d'une étape 610, on détermine si un risque de résultats emboîtés est également présent. Si ce n'est pas le cas, la mémoire tampon 173 est remplie de noeuds en attente de décision. Dans ce cas, le contrôleur détermine si un mode d'évaluation avec pertes est envisageable lors d'une étape 611. Si c'est le cas, la stratégie sélectionnée est mode avec pertes lors de l'étape 608. Dans le cas contraire, la stratégie retenue est mode compression , lors de l'étape 609. Si le résultat de l'étape 610 indique qu'en plus du risque de décision différée, il existe également un risque de résultats emboîtés, alors une étape supplémentaire d'analyse de la mémoire tampon est effectuée au cours d'une étape 612. Lors de cette étape 612, le gestionnaire de mémoire 124 parcourt la liste des noeuds présents en mémoire tampon 173. Chacun de ces noeuds possède un statut d'évaluation qui indique, entre autres, s'il est en attente de décision ou s'il appartient à un résultat emboîté. L'étape 612 consiste donc à analyser quel type de noeud est majoritairement présent en mémoire tampon 173 du navigateur XPath 123. Puis, une étape 613 détermine s'il s'agit de noeuds de type résultats emboîtés ou pas. Si c'est le cas, le traitement se poursuit comme décrit précédemment à partir de l'étape 603. Sinon, au cours d'une étape 614, on détermine si la majorité des noeuds correspond à des noeuds en attente de décision. Si oui, la sélection de la stratégie anti-débordement se poursuit à l'étape 611, comme décrit précédemment. Si le test 614 est négatif, le contenu de la mémoire est détruit au cours d'une étape 615. En effet, dans ce cas, le remplissage de la mémoire est sans doute dû à une erreur et son contenu est donc détruit à l'étape 615. L'évaluation se poursuit ensuite normalement à l'étape 503. L'intérêt d'une telle mise en oeuvre est de considérer tous les types de risques et, de plus, d'adapter dynamiquement la stratégie en fonction du type de noeuds présents en mémoire. De plus, l'ensemble des tests sur les modes supportés par le processeur permet de prendre en compte un mode d'évaluation éventuellement choisi par un utilisateur ou défini par l'application. Selon une variante, la stratégie retenue, quel que soit le risque, est le mode compression afin de fournir une évaluation complète et sans perte. L'application de ce mode compression peut alors être suivi d'une étape de vérification de la taille de la mémoire occupée qui, si elle demeure importante, peut conduire à considérer la sélection d'une stratégie supplémentaire de type évaluation en mode dégradé ou évaluation avec pertes. Cette approche a l'avantage de garantir une évaluation complète de la requête mais peut ralentir le processus d'évaluation du fait des compressions et décompressions pouvant intervenir. De plus, elle ne prend pas en compte les possibilités du processeur comme, par exemple, l'utilisation d'un stockage externe. Les paragraphes ci-dessous détaillent l'étape 509 d'application de la ou des stratégies retenues lors de l'étape 508. Si, au cours d'une étape 510, on détermine que la stratégie s'avère efficace, l'évaluation continue. Dans le cas contraire, un signal d'erreur est émis vers l'application et l'évaluation s'arrête. L'évaluation en mode dégradé correspond à une évaluation où les résultats emboîtés ne sont pas considérés. II n'est donc pas nécessaire de les stocker. Par exemple /bookstore/descendant ::* appliqué sur le document XML 10 de la figure 2 ne retournerait que les éléments book et leur contenu et non les noeuds descendants que sont tous les title et author . Ce mode dégradé ne résout pas le problème des noeuds stockés en attente de décision. En revanche, ce mode dégradé a l'avantage de simplifier la gestion de la mémoire par le navigateur 123 puisque aucun noeud n'a besoin d'être conservé en vue de son émission ultérieure. Dans l'exemple mentionné auparavant, le début d'élément title , lorsque analysé au cours de l'étape 504 par le processeur 102 est émis vers l'application à l'étape 409 (via sa propagation au cours de l'étape 506) et supprimé, au cours de l'étape 501, de la mémoire tampon 173 au moment où le noeud texte fils de l'élément title est reçu par le navigateur 123 au cours de l'étape 500. L'évaluation en mode avec pertes correspond à une évaluation où tous les résultats (emboîtés ou non) sont considérés mais leur contenu peut être tronqué. Par exemple, dans le cas d'éléments à l'intérieur desquels se trouvent des noeuds de type commentaire , ces commentaires peuvent être supprimés de la mémoire tampon par le gestionnaire de mémoire 124. Si la suppression des éventuels noeuds commentaires ne permet pas de dégager d'espace mémoire suffisant, le gestionnaire de mémoire 124 peut supprimer les noeuds de type texte en commençant par ceux qui ne contiennent que des informations de mises en page, par exemple en étant composés d'espaces, de tabulations et/ou de retour à la ligne puis si cela ne suffit pas par les noeuds de type texte ayant la valeur la plus importante en terme de taille, c'est-à-dire qui correspondent à une taille supérieure à une valeur prédéterminée. En complément, on effectue la suppression du contenu des résultats en ne conservant que l'évènement de début et/ou du contenu des résultats en ne conservant qu'un numéro d'évènement. Cette suppression permet à l'application d'être informée d'un résultat tout en minimisant le coût de stockage. L'application dispose de la localisation de l'événement dans le document. L'application a donc la possibilité de récupérer et de reconstruire ultérieurement ce résultat. Cette approche peut s'appliquer pour les deux types de risque : résultats emboîtés et noeuds en attente de décision. Lorsque la solution anti-débordement retenue est la compression du contenu de la mémoire tampon, le module de compression/décompression 125 est activé. Ce module, une fois activé, commence par compresser les noeuds présents en mémoire tampon 173. Par exemple, un noeud XPath de type élément peut être représenté par un type, un nom, un préfixe et un espace de nommage. Certains noeuds tels que les attributs , texte et commentaires ont également un champ représentant leur valeur. La plupart de ces champs (hormis le type) sont représentés par des chaînes de caractères. Il est donc envisageable de compresser ces chaînes de caractères afin de gagner de la place en mémoire. Tout processus de conversion de chaîne de caractères vers une représentation plus compacte peut être considéré. Pour la suite de l'évaluation, tant que le module de compression 125 est actif, les évènements XML reçus par le navigateur 123, au cours de l'étape 500, sont représentés à l'étape 503 par la version compressée du noeud XPath. C'est lors du test de l'étape 507 que le mode compression/décompression est éventuellement désactivé si le gestionnaire de mémoire 124 détecte que la mémoire tampon 173 est quasiment vide. Lorsqu'un résultat est trouvé pour une requête XPath à évaluer et que le mode compression est activé, l'étape 409 d'émission d'un résultat, qui consiste à envoyer le contenu de la mémoire tampon 173 à l'application 101, requiert une étape préalable de décompression effectuée par le module 125. Si le processeur est informé, au début de l'évaluation, que l'application 101 dispose d'un espace de stockage 111, celui-ci peut être utilisé par le processeur 102 lorsque sa propre mémoire approche de la saturation. Ainsi, lors d'un test 507 positif, si à l'étape 508 suivante, c'est la solution du stockage externe qui est retenue, son application lors de l'étape 509 consiste à copier le contenu de la mémoire tampon 173 dans cet espace de stockage externe 111. Dans le cas où il s'agit de résultats emboîtés, le signal correspondant à la fin de l'élément courant, lors de l'émission du résultat 409, permet de signaler à l'application que ces résultats peuvent être consommés et considérés comme résultats. Si ce stockage externe est utilisé pour les noeuds en attente de décision, lorsque le noeud XPath reçu à l'étape 503 et évalué au cours de l'étape 504 permet de décider, sur les noeuds en attente, un signal de non résultat est émis à partir de l'étape 506 pour effectuer les étapes 404b et suivantes. Comme précédemment, l'étape 409 permet de signaler à l'application que les noeuds stockés sont devenus obsolètes et qu'ils peuvent donc être effacés de la mémoire. Au contraire, si l'évaluation 504 conduit à un noeud résultat, sa propagation au cours de l'étape 506 et son émission au cours de l'étape 409 permettent de signaler à l'application que les noeuds stockés sont finalement des résultats à considérer, donc à consommer et retirer de l'information stockée dans l'espace de stockage 111. Comme on le comprend à la lecture de ce qui précède, la mise en oeuvre de la présente invention fournit un moyen d'évaluer des requêtes XPath à la volée tout en maîtrisant la consommation de mémoire. Ceci est permis par une analyse approfondie des requêtes afin d'anticiper tout risque de débordement de mémoire tampon allouée au processeur XPath et, le cas échéant, par la mise en oeuvre de la ou des stratégies la ou les mieux adaptées pour réduire la mémoire consommée à un instant donné.25 REVENDICATIONS 1 - Procédé de contrôle de consommation mémoire lors de l'évaluation d'au moins une requête sur au moins un document hiérarchisé comportant : - une étape (304-311, 502-503, 507-510, 600-603, 605, 607, 610-615) d'analyse d'au moins une requête pour détecter si elle est susceptible d'entraîner un débordement de mémoire tampon lors de l'évaluation de ladite requête et - lorsque ladite requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape (312, 504, 604, 606, 608, 609) d'évaluation de ladite requête mettant en oeuvre un premier mode d'évaluation et - lorsque ladite requête n'est pas susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape (313, 504) d'évaluation de ladite requête mettant en oeuvre un deuxième mode d'évaluation en fonction du résultat de ladite analyse, ledit premier mode d'évaluation utilisant moins de mémoire tampon que le deuxième mode d'évaluation. 2 ù Procédé selon la revendication 1, dans lequel le premier mode d'évaluation est avec pertes et le deuxième mode d'évaluation est sans perte. 3 ù Procédé selon la revendication 2, caractérisé en ce que, dans le premier mode d'évaluation avec pertes, on tronque le contenu d'au moins une partie des résultats de la requête. 4 ù Procédé selon la revendication 3, caractérisé en ce que, pour tronquer le contenu d'au moins une partie des résultats de la requête, on supprime : - des noeuds selon au moins un des critères suivants : le noeud est de type commentaire , le noeud est de type texte et ne contient que des 30 informations de mise en page et le noeud est de type texte et correspond à une taille supérieure à une valeur prédéterminée ;- le contenu des résultats en ne conservant que l'évènement de début ; et/ou -le contenu des résultats en ne conservant qu'un numéro d'évènement. 5 û Procédé selon l'une quelconque des revendications 1 ou 4, dans lequel le premier mode d'évaluation comporte une étape (609) de compression de données mémorisées relatives à ladite requête et une étape de décompression des données compressées. 6 û Procédé selon la revendication 5, dans lequel, après l'étape (609) de compression, le premier mode d'évaluation comporte une étape de vérification de la taille de la mémoire tampon occupée et, si cette taille est supérieure à une valeur seuil prédéterminée, on met en oeuvre une évaluation en mode dégradé ou avec pertes. 7 û Procédé selon l'une quelconque des revendications 1 à 6, dans lequel le 15 premier mode d'évaluation comporte une évaluation (604) complète de l'expression au cours de laquelle on écarte les résultats emboîtés. 8 û Procédé selon l'une quelconque des revendications 1 à 7, dans lequel le premier mode d'évaluation comporte une étape (606) de stockage externe, en dehors de la mémoire tampon, de données mémorisées relatives à ladite 20 requête. 9 û Procédé selon l'une quelconque des revendications 1 à 8, dans lequel le premier mode d'évaluation comporte une évaluation incomplète de l'expression au cours de laquelle, lorsque l'on traite des évènements correspondants au contenu d'un résultat, on désactive la recherche de nouveaux résultats, tant 25 que la fin du résultat en cours n'est pas atteinte. 10 û Procédé selon l'une quelconque des revendications 1 à 9, dans lequel, au cours de l'étape (307) d'analyse, on détermine, au cours d'une analyse sémantique si on a rencontré des axes dits récursifs. 11 û Procédé selon l'une quelconque des revendications 1 à 10, dans lequel, 30 au cours de l'étape (308) d'analyse, on détermine si des prédicats sont présents dans la requête à évaluer.12 û Procédé selon l'une quelconque des revendications 1 à 11, dans lequel, au cours de l'étape d'analyse, on détermine un type de risque de débordement, le procédé comportant, lorsque la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, une étape de sélection d'un premier mode d'évaluation en fonction du type de risque déterminé au cours de l'étape d'analyse. 13 û Procédé selon la revendication 12, dans lequel les types de risque comportent au moins l'un des types suivants : un type décision différée et - un type résultats emboîtés . 14 û Procédé selon la revendication 13, dans lequel, au cours de l'étape (603, 604) de sélection du premier mode d'évaluation, si le type de risque est résultats emboîtés , on détermine s'il est possible de traiter la requête en mode d'évaluation dégradé et, si oui, le premier mode d'évaluation sélectionné est le mode d'évaluation dégradé. 15 û Procédé selon la revendication 14, caractérisé en ce que, s'il n'est pas possible de traiter la requête en mode d'évaluation dégradé, on détermine si un mode d'évaluation avec stockage externe est possible et, si oui, le premier mode d'évaluation sélectionné est un mode d'évaluation avec stockage externe. 16 û Procédé selon la revendication 15, caractérisé en ce que, si un mode d'évaluation avec stockage externe n'est pas possible, on détermine si un mode d'évaluation avec pertes est possible et, si oui, le premier mode d'évaluation sélectionné est un mode d'évaluation avec pertes. 17 û Procédé selon la revendication 16, caractérisé en ce que, si un mode d'évaluation avec pertes n'est pas possible, le premier mode d'évaluation sélectionné est un mode d'évaluation avec compression de données relatives à ladite requête. 18 û Procédé selon la revendication 12, dans lequel, au cours de l'étape de sélection du premier mode d'évaluation, si le type de risque est décision différée , on détermine si le type de risque est aussi un type résultats emboîtés et, si non, le premier mode d'évaluation est sélectionné parmi lemode d'évaluation avec pertes et le mode d'évaluation avec compression des données relatives au document sur lequel on évalue ladite requête. 19 û Procédé selon la revendication 12, dans lequel, au cours de l'étape (603, 604, 610, 612, 613) de sélection du premier mode d'évaluation, si le type de risque est décision différée , on détermine si le type de risque est aussi un type résultats emboîtés et, si oui, on parcourt la liste des noeuds présents en mémoire tampon et on détermine quel type de noeud est majoritairement présent en mémoire tampon, parmi les types de noeuds suivants : type en attente de décision et - type appartient à un résultat emboîté et on sélectionne le premier mode d'évaluation en fonction du type de noeud majoritaire dans la mémoire tampon. 20 û Procédé selon l'une quelconque des revendications 1 à 19, caractérisé en ce que, lorsque la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, on effectue une étape (311b) d'affichage, sur une interface utilisateur, d'un message indiquant que la requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation et une étape de sélection, par l'utilisateur d'un mode d'évaluation de la requête. 21 - Dispositif de contrôle de consommation mémoire lors de l'évaluation d'au moins une requête sur au moins un document hiérarchisé comportant : - un moyen (210, 211, 217) d'analyse d'au moins une requête pour détecter si elle est susceptible d'entraîner un débordement de mémoire tampon lors de l'évaluation de ladite requête et - un moyen (210, 211, 217) d'évaluation adapté : - lorsque ladite requête est susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, à évaluer ladite requête mettant en oeuvre un premier mode d'évaluation et -lorsque ladite requête n'est pas susceptible d'entraîner un débordement de mémoire tampon lors de son évaluation, à évaluer ladite requête mettant en oeuvre un deuxième mode d'évaluation en fonctiondu résultat de ladite analyse, ledit premier mode d'évaluation utilisant moins de mémoire tampon que le deuxième mode d'évaluation. 22 - Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé de contrôle selon l'une quelconque des revendications 1 à 20. 23 - Support d'informations (214, 224) 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é de contrôle selon l'une quelconque des revendications 1 à 20.