FR2926378A1 - Procede et dispositif de traitement pour l'encodage d'un document de donnees hierarchisees - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif de codage de document et plus particulièrement un procédé de traitement d'un document (10a, 10b, 10c) comprenant des données hiérarchisées organisées en une pluralité d'items, ledit procédé comportant :- une étape préalable (512) de génération d'au moins une table dite "d'encodage" (34) comprenant des informations d'encodage organisées en une pluralité de structures d'encodage (34) associées chacune à un item, ladite étape préalable de génération étant basée sur le codage préalable d'autres documents de données hiérarchisées,- une étape de codage dudit document de données hiérarchisées, comprenant :a. une étape d'extraction (541, 600, 710, 805) d'un item à coder;b. une étape de détermination, dans ladite table d'encodage, d'une structure d'encodage associée audit item à coder;c. une étape d'encodage (625, 655, 730, 820, 850, 935) dudit item extrait à partir de ladite structure d'encodage déterminée.

Description

La présente invention concerne un procédé et un dispositif de traitement pour l'encodage de document. Elle s'applique, en particulier, au langage XML (acronyme de Extensible Markup Language pour langage de balisage extensible). Ce langage est une syntaxe pour définir des langages informatiques. XML permet ainsi de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et se terminant par une balise fermante comportant, elle aussi, le nom de l'élément (par exemple : </balise>). Chaque élément peut contenir d'autres éléments, appelés éléments enfants (une terminologie de filiation, parent , enfant , étant utilisée pour décrire les relations entre les éléments imbriqués) ou des données textuelles. D'autre part, un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple: <balise attribut="valeur">). La syntaxe XML permet aussi de définir des commentaires (par exemple: <!-- Commentaire-->) et des instructions de traitement, qui peuvent préciser à une application informatique les traitements à appliquer au document XML (par exemple : <?montraitement?> ), ainsi que des sections d'échappement qui permettent d'éviter qu'une section de texte soit interprétée comme une balise lorsqu'elle en a la forme (par exemple: <![CDATA[<texte>Echappement</texte>]]> où <texte> est reconnu comme une chaîne de caractère et non pas une balise). Dans la terminologie XML, l'ensemble des termes élément , attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement sont regroupés sous le nom générique de item . Dans un cadre plus général, l'ensemble de ces termes (formant l'élément défini entre une balise ouvrante et une balise fermante) peut être regroupé sous le nom générique de noeud .

Plusieurs langages différents basés sur le XML peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace selon la terminologie anglo-saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier , pour Identifiant uniforme de ressource), par exemple http://canon.crf.fr/xml/monlangage . L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple : xmins:ml="http://canon.crf.fr/xml/monlangage" associe le préfixe ml à l'URI http://canon.crf.fr/xml/monlangage ). Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de : (par exemple: <ml:balise ml:attribut="valeur"> indique que l'élément balise découle de l'espace de nommage ml et qu'il en est de même pour l'attribut attribut). Le standard XML Schema ou schéma XML définit un langage permettant de décrire la structure d'un ensemble de documents XML. Un document XML Schema est un document XML, et décrit l'ensemble des éléments et des attributs pouvant être présents dans un document XML conforme à ce document XML Schema, ainsi que les relations entre ces éléments et ces attributs. D'autres systèmes permettent de décrire la structure d'un ensemble de documents XML, comme les DTD (acronyme de Document Type Definition , pour Définition de Type de Document) ou comme le langage Relax NG. XML présente de nombreux avantages et est devenu un langage de référence pour stocker des données dans un fichier ou pour échanger des données. XML permet en particulier de disposer de nombreux outils pour traiter les fichiers générés. D'autre part, un document XML peut être édité manuellement avec un simple éditeur de texte. En outre, comme un document XML contient sa structure intégrée aux données, ce document est très lisible même sans en connaître la spécification. Le principal inconvénient de la syntaxe XML est d'être très prolixe. Ainsi la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi un temps de traitement important lors de la génération et de la lecture de documents XML. Elle induit aussi un temps de transmission important. Pour remédier à ces inconvénients, d'autres méthodes pour encoder un document XML ont été recherchées. Le but de ces méthodes est de coder le contenu du document XML sous une forme plus efficace, tout en permettant de reconstruire facilement le document XML. Cependant, la plupart de ces méthodes ne conservent pas l'ensemble des avantages du format XML. Parmi ces méthodes, la plus simple consiste à coder les données de structure dans un format binaire au lieu d'utiliser un format textuel. En outre, la redondance des informations structurelles dans le format XML peut être supprimée ou au moins diminuée (par exemple, il n'est pas forcément utile de préciser le nom de l'élément dans la balise ouvrante et la balise fermante). Une autre méthode est d'utiliser une table d'index, en particulier pour les noms d'éléments et d'attributs qui sont généralement répétés dans un document XML. Ainsi, lors de la première occurrence d'un nom d'élément, celui-ci est codé normalement dans le fichier et un index lui est associé. Puis, pour les occurrences suivantes de ce nom d'élément, l'index est utilisé à la place de la chaîne complète, réduisant la taille du document généré, mais facilitant aussi la lecture (il n'y a plus besoin de lire la chaîne complète dans le fichier, et en outre, la détermination de l'élément lu peut être réalisée par une comparaison d'entiers au lieu d'une comparaison de chaînes de caractères). Enfin, au-delà de ces méthodes élémentaires, il existe des méthodes plus évoluées consistant notamment à prendre en compte un nombre plus important d'informations structurelles du document afin de compresser davantage les données. On peut citer, entre autres, le cas d' Efficient XML , format utilisé comme base pour la standardisation d'un format XML binaire par le groupe de travail EXI (acronyme de "Efficient XML Interchange") du W3C (acronyme de World Wide Web Consortium , organisation produisant des standards pour le Web), qui prend en compte l'ordre d'apparition des différents items au sein d'un document pour construire une grammaire qui permet d'encoder les items les plus fréquents sur un faible nombre de bits. On peut également citer le format XML binaire "Fast Infoset", spécifié par la norme ITU-T Rec. X.891 1 ISO/IEC 24824-1, qui offre une représentation plus compacte d'un document XML en utilisant des codes binaires d'items et des tables d'index. Dans ce format, les types d'items sont décrits en tant que listes qui utilisent des codes binaires de longueur variable. Fast Infoset utilise de manière intensive les techniques d'indexation en créant des tables pour des ensembles précis d'informations XML. Ces tables permettent d'encoder une information donnée (un item par exemple) de manière littérale (par exemple selon l'un des format de codage de caractères UTF8 ou UTF16 où UTF est l'acronyme de "UCS transformation format" 8 bits) la première fois que cette information est rencontrée durant l'encodage du document. Cette information est ensuite ajoutée dans la table d'indexation et associée à un index. Ultérieurement, lorsque cette information est détectée à nouveau dans le document XML, l'index correspondant est récupéré dans la table d'indexation et on encode alors la valeur de cet index à la place de l'information. On peut ainsi obtenir une compression notable des données. On note un certain nombre de tables d'indexation, parmi lesquelles : - deux tables indexant respectivement les préfixes et les URI afin de définir les espaces de nommage ; - deux tables spécifiques indexant respectivement les valeurs d'attributs et les valeurs de noeuds textes ; - une table indexant les noms locaux d'attributs et d'éléments ; - deux tables spécifiques indexant respectivement, d'une part les noms qualifiés (qui regroupent par exemple un préfixe, une URI et un nom local) d'éléments, et d'autre part les noms qualifiés d'attributs. On peut noter que la norme Fast Infoset permet à l'encodeur de décider si telle ou telle valeur d'attribut ou de noeud texte est à indexer, par exemple en fonction de la longueur de la valeur ou de la chaîne de caractère. Ceci permet notamment de limiter la taille de la mémoire utilisée par l'encodeur. La décision d'indexer ou non une valeur d'attribut ou un noeud texte est alors encodée dans le flux Fast Infoset pour permettre au décodeur associé d'indexer ou non les valeurs à décoder. De retour à Efficient XML , on note que cette norme utilise un ensemble de grammaires pour coder un document XML. Pour pouvoir coder les items compris dans un document XML, la spécification Efficient XML divise chacun des "noeuds" en parties élémentaires appelées événements, par exemple une balise ouvrante. Ces événements sont similaires à ceux générés par des analyseurs syntaxiques (ou parseurs selon un anglicisme largement utilisé) XML travaillant en mode "streaming", c'est-à-dire représentant un document XML comme un flux de données, tels que les parseurs SAX (acronyme de Simple API for XML , pour Interface de programmation simple pour XML). Ainsi, par exemple, dans la spécification Efficient XML, un noeud XML est représenté par un événement de début d'élément (balise ouvrante), un ensemble d'événements représentant son contenu et un événement de fin d'élément. Lorsqu'un événement est composé d'un unique item, on note qu'une 20 assimilation de l'événement à l'item peut être réalisée. Ainsi pour la suite de la description, on assimilera événement et item. Une grammaire est composée d'un ensemble de productions, chaque production comprenant une description d'événement (ou item) XML, une valeur de codage associée et l'indication de la grammaire suivante à 25 utiliser. Pour coder un événement XML à l'aide d'une grammaire, la production contenant la description la plus précise de l'événement XML est utilisée. La valeur de codage contenue dans cette production est utilisée pour représenter l'événement, et les informations contenues dans l'événement et non décrites dans la production sont codées. 30 Grammaires et productions sont ainsi vues comme des structures d'encodage des événements ou items qu'elles proposent d'encoder.

Une grammaire selon Efficient XML est évolutive. Dans un certain nombre de cas, après l'occurrence d'un événement XML déjà décrit par une production de la grammaire (s'il n'est pas décrit par une production, il ne peut être encodé par la grammaire), la grammaire est modifiée pour inclure une nouvelle production plus efficace correspondant à cet événement XML. Cette production peut soit contenir une description plus précise de l'événement, diminuant le nombre d'informations à coder pour représenter l'événement, soit avoir une valeur de codage plus compacte. Les valeurs de codage, ou codes , sont exprimées sous forme de priorités ayant, généralement, entre 1 et 3 niveaux. Coder une valeur de codage revient à coder les valeurs de sa priorité. Chaque niveau est codé sur le nombre de bits minimum pour pouvoir coder la plus grande valeur de ce niveau associée à une production de la grammaire. Par exemple, pour un niveau prenant des valeurs de 0 à 6, on utilise 3 bits de codage.

Pour coder un document XML, un ensemble de grammaires est utilisé. Quelques grammaires servent à coder la structure propre au document XML. En outre, pour chaque type d'élément XML présent dans le document (un type d'élément XML étant un ensemble d'éléments ayant le même nom), un ensemble de grammaires est utilisé pour coder les éléments XML de ce type.

Les règles de grammaires utilisées peuvent soit être des règles génériques, communes à tous les documents XML et construites à partir de la syntaxe XML, soit être des règles spécifiques à un type de document, construites à partir d'un Schéma XML décrivant la structure de ce type de document.

Lors du décodage, le processus inverse est utilisé : la valeur de codage est extraite et permet d'identifier l'événement XML codé, ainsi que les informations complémentaires à décoder. En outre, lors du décodage, les mêmes règles d'évolution des grammaires sont utilisées, permettant d'avoir à tout moment un ensemble de règles de grammaires identique à celui qui était utilisé lors du codage. A titre d'exemple, le fragment XML suivant est utilisé pour décrire le codage d'un document XML à l'aide de la spécification Efficient XML : <person> <firstname>John</firstname> <lastname>Smith</lastname> </person> L'encodeur n'ayant pas encore rencontré d'élément ou événement person , une grammaire par défaut est créée pour cet élément. Il s'agit d'une grammaire ne contenant que des productions génériques. Durant l'encodage de l'élément person , de nouvelles productions sont créées et insérées pour rendre la grammaire liée à l'élément person plus efficace. La grammaire par défaut utilisée pour coder le contenu de l'élément person est la suivante (de manière simplifiée par rapport à la spécification Efficient XML) : ElementContent : EE 0 SE (*) ElementContent 1.0 CH ElementContent 1.1 EE correspond à l'événement de fin d'élément, SE (*) correspond un événement de début d'élément quelconque (générique, le nom n'est donc pas précisé), et CH correspond à un événement de contenu textuel. 20 La grammaire ainsi créée est stockée dans une table, par exemple en mémoire volatile de l'encodeur. Lors de l'encodage, après avoir reçu l'événement correspondant au début d'élément person , SE (person) , et l'avoir codé par exemple de façon littérale, l'encodeur sélectionne la grammaire de codage du contenu de 25 l'élément person , décrite ci-dessus. Ensuite, l'encodeur reçoit l'événement correspondant au début d'élément firstname , SE (firstname) . La production qui correspond à cet événement dans la grammaire ci-dessus est la deuxième : SE (*) ElementContent 1.0 30 L'encodeur va donc coder la priorité 1.0 . Comme le premier niveau de priorité comprend deux valeurs distinctes ( 0 et 1 ) parmi les productions de la grammaire, ce niveau peut être codé sur un bit, avec la valeur15 1 . De même, le deuxième niveau de priorité comprend deux valeurs distinctes et peut être codé sur un bit, avec la valeur 0 . La priorité 1.0 est donc codée ici avec les deux bits 10 . Ensuite, comme la production ne précise pas le nom de l'élément, firstname est codé, par exemple de façon littérale, en utilisant la production CH ElementContent 1.1 On poursuit ensuite l'encodage du contenu de firstname . Dans ce dessein, on recherche la règle associée à cet élément. Comme aucun élément firstname n'a été rencontré, on crée une grammaire firstname à partir de la grammaire par défaut. L'élément firstname contient un noeud texte pour unique enfant. Une fois ce noeud texte encodé, on met à jour la grammaire de firstname en insérant une production texte CH. Grammaire firstname ElementContent : Characters 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 Une fois le contenu de firstname codé, l'encodeur modifie la 20 grammaire associée à l'élément person pour adapter la grammaire aux données XML rencontrées. Pour cela, une nouvelle production est ajoutée à la grammaire, cette production correspondant au début d'élément firstname . A cette production est associée la priorité 0 , et les autres priorités sont décalées pour conserver l'unicité des priorités. On rappelle ici que le décodeur 25 agissant de façon symétrique sera en mesure de réaliser des décalages de priorités (ou index) similaires au fur et à mesure du décodage des données reçues. Ainsi la grammaire devient :

30 Grammaire person ElementContent : SE (firstname) ElementContent 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 L'événement suivant du fragment XML à coder est le début de l'élément lastname . Comme pour firstname , cet élément est codé à l'aide de la production : SE (*) ElementContent 2.0 puisque aucune production correspondant à l'élément lastname n'est trouvée. Le premier niveau de priorité ayant maintenant trois valeurs possibles, il est codé sur 2 bits, avec la valeur 2 . Le deuxième niveau de priorité est toujours codé sur un seul bit. La priorité 2.0 est donc codée ici avec les trois bits 100 . Le nom de l'élément, lastname , est ensuite codé par exemple littéralement en binaire. Puis le contenu de lastname est codé à l'aide de la grammaire associée à l'élément lastname , à créer si nécessaire lors de la première itération, de façon similaire à celle décrite ci-dessus pour "firstname". Ensuite, la grammaire person est modifiée pour y ajouter une production correspondant au début de l'élément lastname et elle devient alors : Grammaire person ElementContent : SE (lastname) ElementContent 0 SE (firstname) ElementContent 1 EE 2 SE (*) ElementContent 3.0 CH ElementContent 3.1 Ensuite, l'événement de fin d'élément, correspondant à la fin de l'élément person est codé, en utilisant la production : EE 2 Il est à noter que toutes les productions de la grammaire à 30 l'exception de cette dernière production comprennent la description d'un événement, le code associé et la grammaire suivante à utiliser. Cette 25 grammaire suivante est celle utilisée pour continuer le codage après le codage de l'événement compris dans la production. Cependant, dans le cas d'un événement décrivant un début d'élément, les grammaires spécifiques à cet élément sont utilisées pour coder le contenu de l'élément. La grammaire suivante indiquée dans la production comprenant l'événement de début d'élément est utilisée pour le codage après la fin de cet élément. Aussi, la production comprenant l'événement de fin d'élément ne contient pas de grammaire suivante : la grammaire à utiliser pour coder la suite du document est celle qui avait été indiquée par la grammaire de l'élément parent dans la production utilisée pour coder l'événement de début de cet élément. Si, par la suite, dans le document XML, le codeur rencontre un autre élément person similaire, cet élément va être codé à partir de cette grammaire. Ainsi le premier événement correspondant au contenu de l'élément person est l'événement de début de l'élément firstname . Cet élément est codé avec la production:

correspond aussi à cet événement, mais est moins précise (elle ne précise pas le nom "firstname" de l'élément. C'est donc la première production qui est utilisée pour une efficacité de codage accrue. L'encodeur code donc la priorité de cette production, à savoir la valeur "1", qui est codée sur deux bits (car prenant des valeurs de 0 à 3), soit "01". Il n'y a pas besoin de coder le nom de l'élément, puisque celui-ci est précisé par la production et ressort du codage littéral initial lorsque l'élément "firstname" a été rencontré pour la première fois. L'encodeur code ensuite le contenu de l'élément "firstname".

Comme une production spécifique à l'événement de début de l'élément firstname existe déjà dans la grammaire, il n'est pas nécessaire d'ajouter une nouvelle production à la grammaire. SE (firstname) ElementContent 1 On note que la production 3.0 SE (*) ElementContent L'encodeur code ensuite, de manière similaire, l'événement de début de l'élément lastname , en codant uniquement la priorité 0 avec les deux bits 00 . Ainsi, pour le codage du deuxième élément person similaire au premier, le code généré est plus compact, puisqu'il n'est plus nécessaire de coder le nom des éléments contenus dans person , ni littéralement (en codant l'intégralité de la chaîne de caractères), ni même à l'aide d'un index. Un point commun aux méthodes Fast Infoset et Efficient XML est l'utilisation de tables d'encodage, respectivement tables d'indexation et tables de grammaires/productions, qui sont évolutives et maintenues à jour par l'encodeur pour décrire chacun des éléments des données à encoder. Pour la suite du présent document, l'on évoquera indifféremment ces tables sous le terme de tables d'encodage. Les tables d'encodage sont constituées de structures d'encodage associant à un élément au moins une valeur de codage.

Que ce soit pour l'une ou l'autre de ces deux méthodes d'encodage, l'encodage d'un document XML requiert plusieurs traitements coûteux en temps et en ressources machines, comme par exemple : - l'encodage littéral des chaînes de caractères XML, par exemple préfixes, noms locaux ou valeurs, au format UTF8 ou UTF16 ; - la recherche, dans les tables d'encodage, des index correspondant à une information (ou item ou événement) XML traitée ; - la construction et la mise à jour des tables d'encodage, par exemple à partir d'une unique grammaire par défaut. On note également que ces coûts de traitement se multiplient alors 25 que le nombre de documents à encoder est multiplié. On cherche donc à diminuer les coûts de traitement liés notamment à ces différents pôles, lors de l'encodage de documents, afin d'offrir un encodage plus rapide. A cet effet, l'invention vise notamment un procédé de traitement d'un 30 document comprenant des données hiérarchisées organisées en une pluralité d'items, ledit procédé comportant : - une étape préalable de génération d'au moins une table dite "d'encodage" comprenant des informations d'encodage organisées en une pluralité de structures d'encodage associées chacune à un item, ladite étape préalable de génération étant basée sur le codage préalable d'autres documents de données hiérarchisées, - une étape de codage dudit document de données hiérarchisées, comprenant : a. une étape d'extraction d'un item à coder ; b. une étape de détermination, dans ladite table d'encodage, d'une 10 structure d'encodage associée audit item à coder ; c. une étape d'encodage dudit item extrait à partir de ladite structure d'encodage déterminée. On fera aisément le rapprochement entre la structure d'encodage évoquée ici et les grammaires/productions évoquées précédemment. Aussi, la 15 structure d'encodage renseigne de façon générale des informations d'encodage, par exemple, la composition d'un item, des valeurs qu'il peut prendre et éventuellement des valeurs pré-encodées associées, comme on le verra pas la suite. Egalement, on note que par l'utilisation d'une table d'encodage pré- 20 remplie, le codage de nouvelles données hiérarchisées n'a plus nécessairement comme point de départ la grammaire par défaut évoquée ci-dessus. L'utilisation du résultat de documents déjà encodés fournit notamment des tables d'encodage cohérentes apportant des informations a priori à l'encodeur. 25 L'étape d'extraction est entendue, au sens de la présente invention, comme une étape consistant à récupérer un nouvel item à partir d'un fichier de données ou d'un flux (streaming) de données, par exemple des données récupérées à la volée dans une application client-serveur. Le terme "document" utilisé ci-dessus vise à englober à la fois tout 30 fichier de données et toutes données produites sous forme de flux par une application, pour autant que le document composé de ces données ait un début et une fin, par exemple une balise de début de document et une balise correspondante de fin de document (à titre illustratif, les balises <html> et </html> délimite un document HTML ou encore le prologue <?xml version=...> initie un document XML). On note que ces documents sont de type électronique.

En pratique, cette extraction est effectuée dans l'ordre progressif d'énumération des données à l'intérieur du fichier de données ou du flux, par exemple à l'aide d'un parseur. L'invention part du constat selon lequel une application XML peut encoder un grand nombre de documents XML. Ces documents ont généralement une redondance forte entre eux. Ainsi, alors qu'une application XML connaît généralement un nombre limité de langages basés sur XML, une grande partie des traitements effectués par une application d'encodage pour un document est effectuée pour l'encodage, par cette même application, d'un autre document. En effet, en pratique, entre deux documents à encoder, l'encodeur efface les "apprentissages", c'est-à-dire par exemple les tables d'encodage, liés au premier document encodé avant d'encoder le document suivant en "réapprenant" possiblement les mêmes structures ou mêmes éléments. L'invention propose ainsi une solution permettant de réduire, en partie, les traitements effectués pour chaque encodage. Cette réduction se base notamment sur la connaissance par l'encodeur d'une description probable du document XML à encoder illustrée par la table d'encodage pré-remplie. L'étape de codage de l'item utilise donc des informations (structure d'encodage) de la table d'encodage pré-générée, c'est-à-dire les connaissances a priori d'informations d'encodage découlant d'une description probable. On obtient ainsi une recherche guidée, simplifiée et généralement plus rapide de la valeur de codage correspondante à l'item à encoder. L'utilisation de telles structures d'encodage pré-définies permet de ne pas reconstruire à chaque encodage de nouvelles données, en particulier issues d'une même application, des structures d'encodage propres en partant d'une structure par défaut. Grâce à l'invention, on peut, par exemple, réutiliser les tables d'encodage qui ont été élaborées lors d'encodages précédents, ou bien configurer l'encodeur, et plus précisément les tables d'encodage, à l'aide de données d'importation. Une fois cette importation effectuée, l'encodeur utilise ces données pour l'encodage de un ou plus documents XML. Dans un mode de réalisation, les étapes a, b et c sont réitérées pour une pluralité (notamment l'ensemble) d'items du document de données hiérarchisées, notamment du fichier de données. On peut ainsi réaliser l'encodage complet du fichier. Afin d'obtenir une recherche d'indexation plus rapide dans les tables d'encodage, on prévoit que l'étape de détermination comprend une étape b') de prédiction dudit item à coder. Par exemple, ladite prédiction peut indiquer une structure de ladite table d'encodage afin de réaliser l'étape d'encodage b) de l'item à partir de cette structure. L'indication peut, par exemple, prendre la forme d'un index prédit correspondant à l'index de la structure dans la table d'encodage. On note ainsi que la prédiction b') a lieu avant l'étape c) d'encodage. Afin de déterminer l'exactitude de la prédiction, on prévoit, lors de ladite détermination b), une étape b') de comparaison entre ledit item extrait et ledit item prédit. La comparaison peut notamment être effectuée sur les événements items dans leurs intégralités ou sur les items composant ces événements, notamment lorsque l'événement est un début d'élément. Selon une caractéristique particulière, la prédiction b') est fonction de l'item encodé lors l'itération précédente, c'est-à-dire, en pratique, en fonction de l'item précédant, dans l'énumération du document de données hiérarchisées.

La prédiction est ainsi basée sur un contexte courant composé, au moins en partie, de l'item qui vient d'être encodé. Lorsque l'on souhaite prédire un élément, il est en effet plus efficace de respecter un ordre logique de parcours des données, ici l'ordre du fichier de données, et de s'appuyer sur un ordre prévu de ces données (une structure de description a priori comme introduite ci- après). Notamment, la prédiction b') est effectuée à l'aide d'un ensemble de structures de description (26) d'items reliées entre elles de sorte à former une description globale a priori (assimilable à une liste éventuellement ordonnée d'items), ladite prédiction consistant à déterminer un item dont la structure de description associée est reliée à la structure de description de l'item encodé lors de l'itération précédente, c'est-à-dire un item qui suit l'item précédemment encodé. En particulier, lesdites structures de description et les structures d'encodage sont reliées, par exemple à l'aide d'un pointeur d'une structure vers l'autre, de sorte qu'un item donné soit représenté par une structure de description et une structure d'encodage. Ainsi, il est aisé à parti d'une structure de description prédite de récupérer les informations d'encodage présentes dans la structure d'encodage correspondante. Dans un mode de réalisation, pour réaliser le lien entre une structure d'encodage et une structure de description, cette dernière comprend l'indication d'un index pour l'item correspondant (par exemple l'index que l'on souhaite encoder), l'index référant la structure d'encodage des tables d'encodage et plus précisément une production de l'au moins une grammaire. Cette référence index-production est notamment effective dans les deux sens et permet d'accélérer la détermination de la valeur d'encodage de l'item extrait en cas de détermination positive, puisqu'à l'aide de cet index, déterminé dans la structure de description, on obtient directement les informations d'encodage dans les tables d'encodage. L'index peut notamment être pré-encodé afin d'accélérer encore le processus d'encodage. On note ici que ces index peuvent être déterminés et insérés dans les structures de description lors de la formation des tables d'encodage ci-dessus à partir du fichier de description.

Notamment, lesdites structures de description sont générées lors de l'étape préalable, c'est-à-dire avant d'entamer l'encodage à proprement parler du document. Dans un mode de réalisation de l'invention, lesdites structures de description forment une chaîne de structures d'attributs principaux, c'est-à-dire une liste d'attributs principaux sous forme d'objets (de description) liés les uns aux autres.

Notamment, ladite liste d'attributs principaux peut être ordonnée. L'ordonnancement permet de faciliter la prédiction de l'item suivant en fonction du dernier item extrait et encodé. Egalement, au moins une structure d'attributs principaux peut comprendre un pointeur vers une structure d'attribut suivant. On peut prévoir plusieurs pointeurs éventuellement ordonnés. Cette configuration permet de fournir des moyens de prédiction efficaces pour l'ensemble des attributs susceptibles d'être mis en oeuvre dans le document de données. Dans un mode de réalisation de l'invention, lesdites structures de description forment une chaîne de structures d'éléments principaux. Notamment, lesdites structures d'éléments principaux sont ordonnées dans ladite chaîne afin de simplifier la procédure de prédiction. En pratique, on peut ordonner la chaîne en choisissant au moins un élément principal dit "racine", à partir duquel l'encodage ou la prédiction de nouvelles données hiérarchisées peut commencer. En particulier, au moins une structure d'éléments principaux comprend un pointeur vers une structure d'élément hiérarchiquement inférieur, dit élément enfant. Eventuellement plusieurs pointeurs peuvent être prévus, par exemple des pointeurs formant une liste ordonnée. Cela contribue également à une prédiction efficace de l'item suivant du fichier de données. En pratique, la liste renseigne généralement un seul élément enfant afin de limiter les procédures de recherche et parcours dans les structures de description. Egalement, au moins une structure d'éléments principaux comprend un pointeur vers une structure d'élément de même niveau hiérarchique, dit élément suivant. Eventuellement plusieurs pointeurs peuvent être prévus, par exemple des pointeurs formant une liste ordonnée. Cette liste contribue également à prédire efficacement les items suivants. En pratique, la liste renseigne généralement un seul élément suivant afin de limiter les procédures de recherche et parcours dans le fichier de description.

Egalement, au moins une structure d'éléments principaux comprend un pointeur vers une structure d'attribut. Eventuellement plusieurs pointeurs peuvent être prévus, par exemple des pointeurs formant une liste ordonnée.

Les attributs sont notamment décrits selon les listes d'attributs présentées ci-dessus. Egalement, au moins une structure d'éléments principaux comprend un pointeur vers une structure de déclarations d'espace de nommage.

Eventuellement plusieurs pointeurs peuvent être prévus, par exemple des pointeurs formant une liste ordonnée. On comprend ici que pour obtenir une grande profondeur hiérarchique que permet la description XML, les éléments enfants rattachés à un élément principal sont également des éléments principaux auxquels on associe des éléments enfants, des attributs et des éléments suivants. Dans un mode de réalisation, ladite étape de prédiction est effectuée sur au moins un item parmi l'ensemble comprenant une balise ouverte, un attribut de balise ouverte, une déclaration d'espace de nommage, une information de valeurs d'attributs et/ou de noeuds texte.

Dans un mode de réalisation, lors de ladite génération préalable, on initialise ladite table d'encodage à l'aide d'un fichier de description, aussi bien pour les structures d'encodage que pour celles de description. Ainsi, les structures de description et d'encodage reprennent la description structurelle a priori des données hiérarchisées fournie par le fichier de description. En pratique, les structures de description et d'encodage comprennent au moins une grammaire comportant des productions agencées pour décrire un item par un ensemble d'événements. En particulier, le fichier de configuration peut notamment être associé à l'application ayant généré le document de données hiérarchisées à encoder.

Ainsi, l'encodeur utilisera des informations a priori susceptibles de correspondre à l'organisation du document de données à encoder qui aura été généré par ladite application. Selon un caractéristique particulière, le document de données hiérarchisées et les autres documents de données hiérarchisés ont été générés par une même application. Puisque tous ces documents de données ont été générés par une même application, ils suivent un même format décrivant les documents de façon plus précise que les schémas XML, tel qu'indiqué plus loin dans la description. Les structures de description et d'encodage qui découle des premiers documents de données sont ainsi susceptibles de fournir une description et des informations d'encodage a priori cohérentes avec l'organisation de l'ensemble des documents de données à encoder. On obtient alors un encodage efficace et une diminution des coûts de traitement associés. On peut également prévoir que ladite génération préalable comprend un pré-encodage littéral (binaire) d'au moins une valeur associée à au moins un item et le stockage de ladite valeur pré-encodée dans la structure d'encodage associée audit item. A titre d'exemple, une telle valeur peut être des index, des chaînes de caractères, des valeurs numériques. On effectue ainsi un seul encodage préliminaire des index lors du pré-encodage et jamais pendant l'encodage, ce qui permet de diminuer les opérations à effectuer lors de l'encodage des items du fichier de données. La phase d'encodage c) consiste alors, en partie, à récupérer ces valeurs pré-encodées des structures d'encodage. L'invention propose ainsi un procédé d'encodage plus rapide. En variante au pré-encodage, on prévoit que ladite étape d'encodage c) comprend une sous-étape d'encodage binaire d'une valeur associée audit item extrait et prédit, et renseignée dans les structures de description. Ainsi, une fois récupérée la valeur associée à l'item extrait effectivement prédit, on effectue l'encodage de cette valeur, par exemple un index. Dans un mode de réalisation, on peut également prévoir une étape de mise à jour de l'au moins une table d'encodage en cas de prédiction inexacte, ladite mise à jour étant fonction d'un codage générique dudit item extrait. On entend par "codage générique" un codage de l'état de la technique, par exemple le codage Efficient XML tel que déjà connu. Grâce à ce mode de réalisation, on enrichit les structures d'encodage et de description au fur et à mesure de l'encodage afin d'en faire profiter la suite de l'encodage du document de données voire l'encodage de documents de données suivants. Grâce à ce mode de réalisation, il est également possible de paralléliser la constitution des structures de description et d'encodage avec l'encodage, à proprement parler, des items composant un premier document ou un document ultérieur de données. Notamment, en cas de prédiction inexacte, on prévoit une étape de recherche générique dudit item extrait dans lesdites tables d'encodage. Cette recherche correspond à ce qui est pratiqué par l'état de la technique et ledit item extrait est alors encodé en fonction du résultat de la recherche. Le résultat de la recherche peut notamment être un index déjà encodé. On obtient ainsi un encodage garanti sans surcoût par rapport aux mécanismes de l'art antérieur connus. Dans un mode de réalisation, au moins une table d'encodage comprend, dans les structures d'encodage associées chacune à un item, un indicateur agencé pour indiquer si ledit item a déjà été codé lors d'une étape d'encodage c) du codage dudit document de données.

En particulier, les indicateurs comprennent chacun un compteur qui est incrémenté à chaque nouvel encodage littéral b) dudit item. Egalement, on prévoit que lesdits indicateurs sont réinitialisés lors du codage d'un nouveau document de données hiérarchisées. En particulier, cette réinitialisation comprend l'incrémentation d'un compteur du nombre d'encodages associé à l'item pour les données hiérarchisées à encoder, de sorte à le mettre au même niveau qu'un deuxième compteur du nombre d'encodages associé à l'item indépendamment des données hiérarchisées à encoder. En variante, cette réinitialisation comprend la réinitialisation de chaque indicateur à une valeur dite nulle indiquant qu'aucun item n'a été codé. En pratique, ces deux variantes peuvent être mises en oeuvre comme suit : - chaque valeur de la table d'encodage 34 a un champ "déjà-encodé" qui passe de 'faux' à 'vrai' lors du premier encodage de l'item pour les données à coder. A la fin de l'encodage de ces données, on prévoit de remettre tous ces champs à 'faux' pour pouvoir correctement effectuer un second encodage; - chaque valeur dans le fichier 10c a un champ Cv officiant comme compteur du nombre d'encodages (incrémenté à chaque occurrence). Chaque table 34 a un champ Ct officiant comme compteur du nombre d'encodages pour une valeur spécifique. Ainsi, lorsqu'une valeur est rencontrée dans les items extraits, si Cv<Ct, alors on encode en littéral la valeur à l'aide d'une valeur pré-encodée déjà présente dans les tables 34 (car cette valeur a déjà été encodée durant un encodage précédent des fichier 10a,b). On met l'index de la valeur à jour et on met Cv égal à Ct. Si Cv>=Ct, la valeur a déjà été encodée en littéral pour l'encodage du fichier 10c courant et on encode l'index de la valeur. Cette variante permet aussi l'intégration de valeurs connues de l'encodeur et du décodeur et donc l'encodage sous la forme d'index et jamais sous une forme littérale. L'invention permet ainsi de générer des fichiers encodés similaires à ceux encodés par les techniques de l'art antérieur connues de sorte que le décodage de ces fichiers peut être effectué par les mêmes décodeurs sans coût supplémentaire. L'invention a également trait à un dispositif de traitement d'un document comprenant des données hiérarchisées organisées en une pluralité d'items, ledit dispositif comportant : - un moyen de génération, préalable à un encodage dudit document, d'au moins une table dite "d'encodage" comprenant des informations d'encodage organisées en une pluralité de structures d'encodage associées chacune à un item, ladite génération étant basée sur le codage préalable d'autres documents de données hiérarchisées (10a, 10b), - un moyen de codage dudit document de données hiérarchisées, comprenant : a. un moyen d'extraction apte à extraire un item à coder dudit document ; b. un moyen de détermination, dans ladite table d'encodage, d'une structure d'encodage associée audit item à coder ; c. un moyen d'encodage apte à coder ledit item extrait à partir de ladite structure d'encodage déterminée.

Les avantages de ce dispositif sont similaires à ceux du procédé de traitement objet de la présente invention, tel que succinctement exposé ci-dessus. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de traitement exposé précédemment. Notamment, on prévoit que le moyen de détermination comprend un moyen de prédiction de l'item à coder, par exemple sous forme d'indication (un pointeur) d'une structure d'encodage de ladite table d'encodage afin de fournir cette indication au moyen d'encodage c). Egalement, le moyen de détermination peut comprendre un moyen de comparaison apte à comparer ledit item extrait avec ledit item prédit et à transmettre, audit moyen d'encodage, une indication fonction de ladite comparaison.

Selon un mode de réalisation, le dispositif de codage comprend un moyen de mémorisation d'état courant agencé pour mémoriser des informations relatives aux items extraits par ledit moyen d'extraction, ledit moyen de prédiction étant agencé pour prédire ledit item à coder en fonction desdites informations mémorisées dans le moyen de mémorisation d'état courant, notamment en fonction de l'item extrait lors du codage précédent. Eventuellement, ledit moyen d'encodage étant apte à coder, en cas de prédiction inexacte, ledit item à coder à partir desdites tables d'encodage. Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de traitement conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. Un programme d'ordinateur lisible par un microprocesseur, comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de traitement conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur.

Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente un schéma de principe de la présente invention ; - la figure 2 montre une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre du procédé selon l'invention ; - la figure 3 représente, sous forme d'un logigramme, un exemple de construction d'un fichier et/ou de structures de description ; - la figure 4 représente, sous forme d'un logigramme, des étapes d'analyse d'items d'information à encoder lors de la construction du fichier et/ou des structures de description de la figure 3 ; - la figure 5 représente, sous forme d'un logigramme, des étapes d'analyse de valeurs XML à encoder lors de la construction du fichier et/ou des structures de description de la figure 3 ; - la figure 6 représente, sous forme d'un logigramme, des étapes de finalisation de la description lors de la construction du fichier et/ou des structures correspondant de la figure 3 ; - les figures 7a et 7b représentent, sous forme de logigrammes, des exemples d'encodage respectivement sans et avec des structures de description initiales ; - la figure 8 illustre, sous forme d'un logigramme, des étapes pour l'encodage spécifique d'une balise ouvrante dans le processus de la figure 7 ; - la figure 9 illustre, sous forme d'un logigramme, des étapes pour l'encodage spécifique des déclarations d'espace de nommage dans le processus de la figure 7 ; - la figure 10 illustre, sous forme d'un logigramme, des étapes pour l'encodage spécifique des attributs dans le processus de la figure 7 ; et - la figure 11 illustre, sous forme d'un logigramme, des étapes pour l'encodage spécifique d'un noeud texte dans le processus de la figure 7. En référence à la figure 1, on décrit tout d'abord le fonctionnement général de l'invention pour le codage de documents XML 10a, 10b et 10c.

Ces documents sont générés par une même application XML 11 et présentent ainsi des ressemblances dues aux mécanismes répétitifs de génération de l'application 11. Cette génération est illustrée par les flèches 12a, 12b et 12c. Dans l'exemple de la figure 1, on se concentre sur l'encodage du document XML 10c alors que les deux documents 10a et 10b ont déjà été encodés par l'encodeur 20. Le document 10c peut être vu indifféremment comme un document déjà généré ou comme un document en cours de génération par l'application (mode flux ou streaming). Dans ce dernier cas, on applique à la volée l'invention sur les données générées en continu.

L'encodeur 20 comprend un premier module d'extraction 21 apte à récupérer (flèche 22) le document 10c ou chacun des items (via les événements) de ce document et à fournir un item extrait 23 à encoder. Ce module d'extraction 21 peut notamment comprendre un parseur XML qui facilite la récupération des événements et données XML élémentaires (items, par exemple attributs, éléments, textes). Le module d'extraction 21 met à jour une information d'état courant 24, par exemple en indiquant l'item nouvellement extrait et qui va faire l'objet de l'encodage qui suit. L'information d'état courant 24 comprend également, par exemple sous forme de liste de deux items ou plus, une indication de l'item qui vient d'être encodé lors de l'itération d'encodage précédente. Cette indication de l'item précédent servira notamment à la prédiction de l'item 23 à encoder. L'indication peut notamment être un pointeur sur une structure de description comme introduite ci-après. L'encodeur 20 comprend également un module de prédiction 25 qui, à partir de l'état courant 24, en particulier de l'item précédemment encodé, et de structures ou objets 26 de description détermine un item prédit 27. Comme on le verra par la suite, ces structures de description renseignent d'une description a priori des documents XML 10a,b,c et peuvent être stockées à même les tables d'encodage, Ces structures 26 sont notamment des objets informatiques permettant de mémoriser une structure organisationnelle de données. Elles sont établies sur la base d'un fichier de description/configuration 26' ou sur la base d'encodages précédents (des documents antérieurs 10a,b). Pour assurer une description globale a priori des documents, on remarquera que les structures de description 26 sont liées les unes aux autres, par exemple par l'intermédiaire de références ou pointeurs. La prédiction du prochain item d'information XML à encoder permet notamment de ne pas recourir, lorsque la prédiction est correcte, à une stratégie d'encodage conventionnelle, par exemple par recherche d'indexation générique (basée sur des tables d'indexation pour Fast Infoset ou sur des grammaires pour Efficient XML). Cette prédiction peut notamment être déportée lors de l'encodage de l'item précédent. Ayant la connaissance de l'item en cours, le module de prédiction 25 peut alors déterminer le prochain item à encoder à partir des structures de description 26, par exemple en récupérant l'item suivant dans une liste ordonnée. On note donc que prédiction et extraction peuvent être réalisées indifféremment l'une avant l'autre ou en parallèle.

Le fichier de description 26' est un fichier listant une description d'organisation et de valeurs des données à l'intérieur de fichiers XML. Les objets de description 26 offrent donc une structure adaptée pour stocker ces informations d'organisation et de valeurs. Pour obtenir une prédiction efficace qui se base sur les structures de description 26, ces dernières (et également le fichier 26') doivent correspondre au mieux aux documents 10a,b,c à encoder. En effet, si les structures 26 fournissent l'exacte organisation des données dans les documents 10a,b,c, alors les items 27 prédits seront exactement ceux attendus par l'extraction 21. On remarque ainsi que les structures de description 26 et l'éventuel fichier 26' ne diffèrent que par la forme dans laquelle les informations de description sont stockées (objets informatiques vs. fichiers XML, par exemple). Ainsi pour la suite du document, les caractéristiques (constitution, formation, par exemple) de l'une de ces descriptions 26, 26' s'appliquent indifféremment à l'autre (lorsque le fichier de description 26' existe) On fournit, en lien avec les figures 3 à 6, différents mécanismes permettant d'obtenir un fichier de description 26' efficace au regard des 5 documents XML 10 à encoder. Le fichier de description 26' peut être issu d'un fichier de configuration prédéfini, notamment ce fichier de configuration peut être associé à l'application XML 11 génératrice des documents 10 et être généré au moment du développement de l'application. Cette association est illustrée sur la figure 1 10 par la flèche 28. Dans ce cas, on s'attend à obtenir un fichier de description 26', et par voie de conséquence des structures de description 26, listant les mécanismes habituels de génération de l'application 11 (par exemple l'ordre des éléments et balises XML suivi par l'application 11 pour la génération des fichiers XML). Il en résulte alors une meilleure prévision (par le module 25 et sur 15 la base des structures de description 26) des documents 10a,b,c générés par cette application 11. En alternative ou en combinaison, le fichier de description 26' peut être créé ou complété par le codage antérieur des documents XML 10a et 10b (illustration par les flèches 29'). 20 Egalement les structures de description 26 peuvent être créées/complétées par le codage antérieur des documents 10a,b, comme illustré par les flèches 29. Le système réalise ainsi un auto-apprentissage de la description "type" des documents XML 10 à encoder. Cet apprentissage est d'autant plus 25 efficace que les documents XML 10 suivent des règles d'élaboration similaires, par exemple lorsque ceux-ci ont été générés par la même application 11. Cet auto-apprentissage peut être effectué en continu (le fichier de description 26' et/ou les structures de description 26 sont mis à jour à chaque itération d'encodage des documents 10a et 10b) ou après l'encodage fini de chacun des 30 documents 10a et 10b. La présente invention ne se limite cependant pas à l'encodage de documents générés par une seule et même application. Le fichier de description 26', les structures de description 26' et les différents documents 10 à encoder peuvent être établis sur la base d'applications différentes. Combiné avec le fichier de description 26', cet apprentissage permet de faire converger les structures de description 26 de façon plus rapide vers un ensemble cohérent de documents XML 10 à encoder. On entend ici par "cohérent" le fait que les différents documents XML de l'ensemble reprennent les mêmes règles ou mécanismes d'élaboration de données XML et présentent donc des formats XML similaires ou proches. Une troisième voie pour enrichir ou former le fichier/les structures de description 26'/26 consiste à compléter ces derniers à partir de l'encodage en cours du document XML courant (illustration par la flèche 30). Cet apprentissage est similaire à celui évoqué en lien avec les flèches 29, mais porte sur le document XML en cours de codage. On comprend ainsi que pour optimiser l'encodage de plusieurs documents XML, éventuellement cohérents entre eux, on veillera à conserver les mêmes structures de description 26 pour l'encodage de l'ensemble de ces documents. La description d'un document XML comprend des informations que l'on peut dériver d'un schéma XML. Les structures de description 26 et le fichier 20 de description 26' contiennent ainsi : -une liste d'attributs et d'éléments, de préférence une liste associée aux attributs et une liste associée aux éléments ; - pour chaque élément de la liste, une liste des premiers enfants possibles, une liste des éléments suivants possibles et une liste des attributs 25 possibles. Les "enfants" sont à entendre au sens hiérarchique des données du fichier XML et renvoient généralement à des éléments de la liste qui ont, eux-mêmes, des enfants propres. En pratique, on indique, dans la liste, un seul élément suivant et un seul enfant ; - pour chaque attribut de la liste, une liste des attributs suivants 30 possibles. Chaque élément peut présenter une structure de description a priori correspondante, de telle sorte que la structure de description d'un élément "père" comprend des pointeurs vers un premier élément fils et un premier élément suivant. On note que, contrairement à un schéma XML qui décrit un langage XML de façon générale, ces structures de description 26 s'appuient sur les habitudes et règles d'utilisation de ce langage spécifiques à l'application 11 générant les documents XML 10. De ce fait, les structures 26 et le fichier de description 26' sont plus précis qu'un simple schéma XML. On peut ainsi récupérer les informations suivantes : - on prévoit que les attributs forment une liste ordonnée. En effet, l'ordre des attributs XML n'a pas de signification selon la norme XML ; les langages de schéma ne définissent donc pas de contrainte sur l'ordre. Une application 11, par contre, génère souvent les attributs d'un élément dans le même ordre, ordre fixé au moment de la mise en oeuvre de la génération du document XML 10 par cette application 11 ; - on prévoit que les primitives de type <xs:all>, c'est-à-dire des déclarations de structures de données complexes, sont décrites dans les structures 26 sous forme d'un ensemble ordonné d'éléments, l'ordre étant spécifique à l'application 11, alors que les déclarations conventionnelles de telles primitives sont, de façon conventionnelle, non ordonnées vis-à-vis des éléments les composant ; -l'application 11 n'utilise généralement pas l'ensemble des possibilités offertes par un schéma XML possible. De ce fait, les informations extraites sont souvent plus restrictives que l'éventuel schéma associé. Ainsi, on prévoit que les primitives <xs:wildcard> et <xs:choice> sont remplacées respectivement par un sous-ensemble des éléments et des valeurs possibles de ces primitives. Les descriptions 26 et 26' contiennent, par conséquent, des informations qui ne sont pas dans un schéma XML sur lequel l'application 11 peut se baser pour générer les documents. On liste ici des exemples de telles informations : - l'ordre des attributs, comme mentionnés plus haut grâce à l'ordonnancement dans les listes ; 28 û la présence de déclaration de nommage; û la définition des préfixes associés aux déclarations de nommage; û la stratégie d'insertion d'espaces (au sens des caractères typographiques) entre les noeuds XML; û le fait qu'un attribut ou un élément ait toujours la même valeur ou prenne un nombre restreint de valeurs; û le fait que les valeurs d'un attribut ou d'un élément ont un intérêt à être indexées, ce qui est par exemple le cas lorsque celles-ci se répètent à l'intérieur d'un même document XML 10.

Grâce à ces informations, les items sont identifiés de façon précise (présence des déclarations de nommage par exemple) et la prédiction 25 n'en est que meilleure. En annexe 1 ci-après, on a présenté un exemple de fichier de description 26', et implicitement des structures de description 26 qui en découlent: Cet exemple montre une façon de mettre au format XML les données de description, par exemple sous forme déclarative à l'intérieur des éléments bp:attributes et bp:elements, ou sous forme d'exemples annotés (bp:examples). Les structures de description 26 peuvent reprendre cette représentation des éléments XML De retour au module de prédiction 25 de la figure 1, on peut limiter la prédiction à des items précis d'informations XML. Dans le cadre du présent exemple, on se limite aux items suivants, les plus répandus et dont le gain d'encodage sera le plus important en mettant en oeuvre l'invention: û balise ouvrante; attribut de balise ouvrante; déclaration d'espace de nommage dans une balise ouvrante; informations (type, indexation...) des valeurs d'attribut et de noeuds texte.

Le module de prédiction 25 connaît, grâce à l'information 24 (un pointeur vers les structures de description), l'item qui vient d'être codé (ou en cours de codage si on réalise la prédiction pour l'item à venir), recherche cet 29 item dans les structures de description 26 (cette recherche aura normalement été déjà faite pour l'encodage de l'item précédent). Grâce aux informations contenues dans la structure de description récupérée, par exemple un pointeur vers une autre structure, on détermine le prochain item à venir (par exemple élément enfant ou élément suivant de l'item précédent). Cet item prochain est l'item prédit 27. La prédiction 25 peut également s'appuyer, en complément, sur le fichier de description 26' lorsque celui-ci existe. C'est notamment le cas, lorsque pour des raisons d'optimisation du système d'exécution (par exemple taille de mémoire limitée, dans un module de microcircuit), on ne crée, à partir du fichier 26', qu'une partie des structures de description 26. Certaines structures 26 comprennent ainsi un renvoi vers le fichier de description 26' en lieu et place d'un pointeur vers une autre structure de description 26. Par conséquent, lors d'un processus de prédiction, on peut être amené à accéder au fichier 26' et à créer, sur demande, une nouvelle structure 26. Le module de prédiction 25 peut également extraire, lors de cette étape, des informations d'encodage liées à cet item prédit afin de faciliter l'encodage ultérieur de l'item en cas de prédiction exacte. On aura donc prévu des données pré-encodées (valeurs littérales, index, par exemple) liées aux structures de description 26. En pratique, on lie les structures de description 26 à des tables d'encodage 34 qui comprennent ces données pré-encodées. Cette liaison peut être réalisée au moyen de pointeurs établissant un lien bidirectionnel entre une structure de description 26 d'un item et une entrée (une structure d'encodage) de table d'encodage 34 de l'item en question.

On remarquera donc que structures de description 26 et tables d'encodage 34 ont été, au moins partiellement, remplies avant l'encodage du document 10c. Comme indiqué précédemment, l'encodeur 20 est préconfiguré avant l'encodage du document 10c, soit par l'encodage préalable des documents 10a,b soit à partir du fichier 26'. Cette préconfiguration concerne principalement la formation des tables d'encodage 34 et des structures de description 26.

Lors de cette génération préalable des tables 34, on pré-encode de façon littérale toutes les valeurs à encoder et on stocke ces valeurs pré-encodées dans les entrées de tables d'encodage 34 correspondant aux structures de description 26 respectives, afin de permettre leur détermination lors de la prédiction. On prévoit également affecter à ce stade des index à chacune de ces valeurs pré-encodées (index utilisés pour le codage). Le processus illustré par la figure 1 se poursuit lorsque les items extrait 23 et prédit 27 sont fournis à un comparateur 31 afin de déterminer si la prédiction est correcte. Eu égard au nom d'élément, d'attribut ou de déclaration d'espace de nommage de l'item considéré 27, on vérifie que la prédiction est correcte en comparant les chaînes de caractères associées avec l'item extrait 23. Concernant les valeurs d'attributs et de noeuds texte, la vérification de la prédiction peut concerner la valeur exacte, auquel cas on effectue une comparaison des chaînes de caractères. Accessoirement, on peut prendre en compte le type d'encodage des valeurs à comparer. Le type d'encodage est généralement mis en oeuvre pour distinguer l'algorithme d'encodage littéral des valeurs, afin de tenir compte du typage des données (chaîne de caractères, entier, float, etc.). Egalement, on peut tenir compte de l'indexation ou non de la valeur, même si en pratique, on ne vérifie pas cette prédiction mais on l'utilise plutôt pour ne pas indexer les valeurs qui, selon la description, ne se retrouvent pas dans le document ou pour lesquelles l'encodage n'apparaît pas utile.

Lorsque la prédiction est correcte, on effectue un encodage de l'item par un module d'encodage 32 de l'encodeur 20, en fonction des informations d'encodage obtenues depuis les tables d'encodage 34 via la structure de description correspondante 26 (flèche 33), éventuellement dès la phase de prédiction 25. On décrit par la suite plus en détail l'encodage d'items prédits correctement. Lorsque la prédiction est erronée, l'encodage est également réalisé par le module d'encodage 32. Ce dernier effectue alors une recherche 31 générique conventionnelle, dans les tables d'encodage 34, pour récupérer les informations nécessaires à l'encodage. De ce fait, une mauvaise prédiction pour un évènement ne provoque pas automatiquement une mauvaise prédiction pour l'évènement suivant. En effet, dans le cas où la prédiction est mauvaise, la prédiction de l'item suivant se base sur les informations récupérées par la recherche générique. De façon conventionnelle, une recherche générique consiste à effectuer une recherche directement dans les tables d'encodage 34 de l'encodeur 20 sans connaissance a priori de l'item qui vient d'être encodé. On note ici que ces tables reposent sur un couple clé-valeur, ce qui amène généralement à calculer une ou plusieurs fois un index à partir de la clef puis à comparer la clé recherchée à la clé donnée par l'index. II apparaît ainsi que la recherche générique est beaucoup plus coûteuse que le coût associé à la prédiction (nécessitant uniquement de lire dans la structure de description de l'item précédemment encodé). Ainsi grâce à l'invention, on récupère l'ensemble des informations utiles au traitement efficace de l'item à encoder et notamment un index d'encodage. Si la prédiction a été bonne, la récupération est très rapide grâce aux informations contenues dans les structures de description prédites: on utilise les pointeurs à l'intérieur des structures de description 26' pour prédire l'item suivant et pour récupérer les valeurs ou index pré-encodés dans les tables d'encodage 34. Sinon, en l'absence de prédiction exacte, la récupération a le coût normal de détection d'indexation d'un encodeur XML binaire standard à l'aide des tables d'encodage 34. Néanmoins, grâce au pointeur prévu dans les entrées des tables d'encodage, il est possible de reprendre le fil de la prédiction à partir de la structure de description 26 associée (via le pointeur) à l'entrée des tables d'encodage 34 déterminée par la voie conventionnelle. Ainsi, dans les documents encodés, les valeurs pré-encodées sont utilisées une unique fois et les occurrences ultérieures des valeurs littérales correspondantes sont remplacées par les index associés (ces index peuvent 32 être réévalués si des codages génériques sont utilisés, ce qui décale l'indexation des valeurs), éventuellement déterminés par voie de prédiction. Grâce à ces dispositions, lors de l'encodage successif des documents 10a,b,c, l'encodeur 20 n'a pas à effectuer à plusieurs reprises la construction progressive des tables 34, qui est coûteuse en temps de traitement. On illustre cet avantage à l'aide de l'exemple suivant. Considérons plusieurs petits documents XML selon le format fourni en annexe 2, documents que l'on souhaite encoder.

Dans cet exemple, aucune redondance des noms d'élément n'est trouvée, c'est-à-dire qu'un encodage par redondance (utilisation d'index) n'est pas efficace. Les tables d'encodage 34 formées au fur et à mesure de l'encodage d'un tel document servent alors uniquement à déterminer qu'il n'y a pas de redondance et qu'il faut donc encoder les noms d'éléments de manière littérale. De façon conventionnelle, on construit de manière identique et détruit ces tables pour l'encodage de chacun des documents XML. Grâce à l'invention, on prévoit la formation de tables d'encodage 34 et de structures d'encodage 26 efficaces en une seule fois préalablement à l'encodage des documents. Dans l'exemple de l'annexe 2, ces tables n'auront d'ailleurs jamais à être modifiées puisque l'enchaînement des items est régulier et donc prédictible de façon efficace par le module de prédiction 25. De par la constitution préalable des tables d'encodage 34, l'indication permettant de savoir si une information (nom d'élément, préfixe, etc) a déjà été encodée ou pas durant l'encodage du document XML 10 en cours n'est alors plus donnée par la présence ou pas de cette information (nom d'élément, préfixe, etc) dans une table d'encodage 34 comme c'est le cas dans les solutions de l'art antérieur. Afin de pallier ce manque, on prévoit que cette indication est mentionnée au niveau de l'information prédite ou au niveau de l'information se trouvant dans les tables d'encodage 34.

En pratique, deux variantes sont envisagées comme suit: 33 - chaque entrée d'item de la table d'encodage 34 a un champ "déjà-encodé" qui passe de 'faux' à 'vrai' lors du premier encodage de l'item pour les données à coder; - chaque valeur du document 10c a un champ Cv officiant comme compteur du nombre d'encodages (incrémenté à chaque occurrence de cette valeur). Chaque table 34 a un champ Ct officiant comme compteur du nombre d'encodages pour une valeur spécifique. En comparant Cv et Ct, on sait ainsi si un encodage a déjà eu lieu pour le document 10c courant. L'encodeur ainsi configuré peut encoder de manière efficace un document 10c respectant la description 26 fournie à l'encodeur 20. Il est à noter qu'à chaque nouvel encodage, il est nécessaire de réinitialiser l'indication de non-encodage pour chaque entrée de table d'encodage 34. Ceci peut être fait de manière décentralisée au niveau de chaque entrée de table ou de manière centralisée en incrémentant un compteur du nombre d'encodage. Cette dernière façon permet notamment d'obtenir un traitement de réinitialisation pour un coût (quasi) nul. En pratique, pour les deux variantes ci-dessus,: à la fin de l'encodage des données, on prévoit de remettre tous les champs "déjà-encodé" à 'faux' pour pouvoir correctement effectuer un second 20 encodage; - lorsqu'une valeur est rencontrée dans les items extraits, si Cv<Ct, alors on encode en littéral la valeur à l'aide d'une valeur pré-encodée déjà présente dans les tables 34 (car cette valeur a déjà été encodée durant un encodage précédent des documents 10a,b). On met l'index de la valeur à jour (car l'index 25 trouvé dans la table 34 correspond à celui des encodages précédents des documents 10a,b) et on met Cv égal à Ct (réinitialisation par incrémentation). Si Cv>=Ct, la valeur a déjà été encodée en littéral pour l'encodage du document 10c courant et on encode l'index de la valeur. Lorsque la prédiction du module 25 est correcte, on effectue un 30 encodage efficace de l'item par le module d'encodage 32. On distingue ici le cas d'un item d'information XML correctement prédit, par exemple une balise, 34 un attribut, et le cas d'une valeur XML, par exemple les valeurs d'attributs ou de noeuds texte. Un exemple d'encodage détaillé sera décrit par la suite en référence aux figures 7 à 11, parmi lesquelles les figures 8, 9 et 10 en partie illustrent l'encodage d'un item d'information XML correctement prédit ou non. Dans le cas d'un item correctement prédit, on connaît automatiquement l'état de cet item, notamment s'il a déjà été encodé ou pas lors de l'encodage courant du document 10 grâce, par exemple, à la valeur de l'indicateur de non-encodage dans les tables d'encodage 34.

Si l'item n'a pas encore été indexé pour l'encodage du document courant 10c (champ "déjà-encodé" à 'faux' ou Cv<Ct, pour les deux variantes ci-dessus), on encode la chaîne de caractères correspondant à l'item (le nom de l'élément, le préfixe ou l'URI de la déclaration d'espace de nommage, la valeur d'un attribut...). Cet encodage correspond généralement à la traduction conventionnelle de la chaîne de caractère au format UTF8. Le résultat de la prédiction contient généralement la forme traduite et directement transmissible au module d'encodage 32. Selon une particularité de l'invention, cette traduction aura été effectuée au préalable, par exemple lors de la génération des tables d'encodage 34 à partir du fichier de description 26'. Ainsi, on n'effectue cette traduction qu'une unique fois pour l'ensemble des documents qui sont encodés. Si l'item a déjà été indexé, on encode alors l'index de cet item. On note ici que l'index aura, dans ce cas, possiblement été obtenu directement depuis les structures de description 26 lors de la phase de prédiction.

L'encodage de l'index peut aussi être factorisé : û au moment de la génération des tables 34 et des structures de description 26: dans ce cas, l'item aura toujours le même index et la conversation index vers octets est faite une unique fois pour l'ensemble des documents. On gagne ainsi en efficacité et rapidité lors de l'encodage de plusieurs documents; û pour chaque encodage courant du document 10c : dans ce cas, la conversion est faite une seule fois par encodage si nécessaire, c'est-à-dire 35 lorsque l'index de l'item n'est pas le même que lors de l'encodage précédent des documents 10a,b. L'item encodé 35 correspond alors à l'index encodé et/ou à la chaîne de caractères encodée.

Le cas de l'encodage d'une valeur XML sera décrit plus en détail en référence à la figure 10 en partie et à la figure 11. Les valeurs XML sont par exemple les valeurs d'attributs et de noeuds texte mais également les valeurs textuelles contenues par différents évènements XML (CDATA, commentaires, instructions de traitements...).

On note qu'un encodage selon l'art antérieur nécessite tout d'abord de déterminer quel est l'algorithme d'encodage à utiliser. Différents algorithmes peuvent en effet être utilisés pour encoder de manière plus efficace (en termes de rapidité et/ou de compression) ces valeurs XML en fonction de leur typage. Ces algorithmes sont généralement déterminés par l'application qui utilise l'encodeur pour envoyer/stocker le document XML 10c. Dans le cadre d'une utilisation d'une interface de programmation XML standard (SAX, PULL, DOM), ces algorithmes se retrouvent dans une table dans laquelle il faut aller chercher l'algorithme spécifique. Par défaut, deux approches d'encodage des valeurs XML sont possibles : ù soit on effectue un tri entre les valeurs à indexer et les valeurs à ne pas indexer; ù soit on effectue une indexation sur l'ensemble des valeurs à indexer. La première stratégie a l'avantage de permettre de limiter la taille de la mémoire utilisée par l'encodeur puisque seules les valeurs à indexer seront traitées. Elle permet aussi de n'indexer que les valeurs qui sont potentiellement redondantes. Dans le cas où l'on souhaite indexer la valeur, un encodeur tel que défini par l'état de l'art vérifie si cette valeur a été indexée durant l'encodage courant et met à jour la table d'encodage correspondante si nécessaire. L'invention telle que décrite en lien avec les figures 10 et 11 permet au contraire: 36 ù d'effectuer la recherche du type d'algorithme une seule fois pour l'ensemble des encodages au lieu de le faire pour chaque valeur; ù d'effectuer une décision d'indexation des valeurs basée sur les encodages précédents. Cette décision prend en paramètre le nom de l'élément/attribut parent de la valeur à encoder. Dans le cas où la prédiction de la valeur est exacte, ce qui arrive fréquemment pour, par exemple, les noeuds espace ("whitespace" selon la terminologie anglo-saxonne), l'invention permet notamment: ù de ne pas effectuer la recherche d'indexation dans les tables 10 d'encodage 34 et structures 26; ù de n'effectuer la conversion chaîne de caractères vers octet qu'une seule fois pour l'ensemble des encodages. Ces différents avantages offrent un gain en termes de rapidité d'encodage. On note également que ce gain n'est pas contrebalancé par des 15 traitements additionnels nécessaires à l'invention. Notamment le coût de récupération de ces informations d'encodage correspond au coût de prédiction ou de recherche générique nécessaire à l'encodage de l'item d'information XML parent. En référence à la figure 2, il est maintenant décrit à titre d'exemple 20 une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 40, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon 25 encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau. Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 60, ou un scanner ou tout 30 autre moyen d'acquisition ou de stockage d'images, reliée à une carte d'entrée/sortie (non représentée) et fournissant au dispositif de traitement d'information des données multimédia. 37 Le dispositif 40 comporte un bus de communication 41 auquel sont reliés : - Une unité centrale de traitement CPU 42 se présentant par exemple sous la forme d'un microprocesseur ; - Une mémoire morte 43 dans laquelle peuvent être contenus les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention ; -Une mémoire vive 44 qui, après la mise sous tension du dispositif 40, contient le code exécutable des programmes de l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en oeuvre de l'invention ; - Un écran 45 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 46 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 47 ou un crayon optique ; - Un disque dur 48 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - Un lecteur de disquette 49 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 70 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - Une interface de communication 50 reliée au réseau de 25 télécommunications 80, l'interface 50 étant apte à transmettre et à recevoir des données. Dans le cas de données audio, le dispositif 40 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 90. 30 Le bus de communication 41 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 40 ou reliés à celui-ci. La représentation du bus 41 n'est pas limitative et, notamment, l'unité 38 centrale 42 est susceptible de communiquer des instructions à tout élément du dispositif 40 directement ou par l'intermédiaire d'un autre élément du dispositif 40. Les disquettes 42 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de traitement d'information, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Le code exécutable permettant au dispositif de traitement d'information la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 43, sur le disque dur 48 ou sur un support numérique amovible tel que par exemple une disquette 70 comme décrite précédemment.

Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 800, via l'interface 50, pour être stocké dans un des moyens de stockage du dispositif 40 (tel que le disque dur 48 par exemple) avant d'être exécuté. L'unité centrale 42 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 40, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 48 ou la mémoire morte 43, sont transférés dans la mémoire vive 44 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC). 39 Le dispositif décrit ici et, particulièrement, l'unité centrale 42, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 1, 3 à 11, pour mettre en oeuvre chaque procédé objet de la présente invention et constituer chaque dispositif objet de la présente invention.

En référence aux figures 3 à 11, on décrit maintenant plus en détail la génération du fichier de description 26' et par voie de conséquence les structures de description 26, par exemple en l'absence de fichier 26' (figures 3 à 6) et l'encodage des items mettant en oeuvre une prédiction conformément à l'invention (figures 7 à 11).

Pour simplifier les explications, on fait référence pour la suite au fichier de description 26'. Ces explications sont également applicables aux structures de description 26 pour lesquelles il conviendra alors de respecter les nomenclatures des objets informatiques utilisés. Comme évoqué en lien avec la figure 1, le fichier de description peut être généré avant ou pendant la phase d'encodage à proprement parler. La description fournie ci-après montre ces deux étapes de génération et de codage de façon indépendante. En réalité les deux étapes peuvent être effectuées en parallèle : la génération de la description peut être progressive, notamment sur la prédiction des items suivants et être utilisée par l'étape d'encodage proprement dite. Pour des raisons de clarté, on sépare néanmoins ces étapes dans le reste de la description. La construction du fichier de description 26' à partir d'un ensemble de documents 10 s'effectue en deux étapes. Dans un premier temps, une analyse statistique des documents est effectuée comme décrite ci-après en lien avec les figures 3 à 5. Ensuite, ces informations statistiques étant disponibles, une étape de génération de la description 26 est effectuée (figure 6). II est à noter que l'analyse statistique effectue de nombreux traitements identiques à ceux effectués lors d'un encodage d'un document XML. De fait, l'étape d'analyse statistique peut être effectuée en parallèle d'un encodage pour un surcoût modéré. L'étape de génération de la description 26, 26' peut, par ailleurs, être effectuée à tout moment, par exemple: 40 û de manière incrémentale lors de l'encodage de premiers documents XML; û à un instant où les données statistiques récoltées sont jugées suffisantes, par exemple dès lors que l'on dispose de dix éléments à encoder.

Si la description 26, 26' est générée lors de l'encodage des premiers documents 10a,b, ceux-ci seront encodés plus lentement qu'avec un encodage générique. Le surcoût initial est ensuite largement compensé par les gains qu'offre cette description durant les encodages suivants conformément au procédé objet de l'invention.

En référence à la figure 3, on a représenté l'algorithme général d'analyse des documents XML 10. On débute par l'étape 100 où l'on détermine s'il y a un document à analyser et éventuellement à encoder. Dans l'affirmative, on récupère le document à l'étape 110, 15 évènement par évènement par l'intermédiaire d'un module d'extraction, par exemple similaire au module 21 de la figure 1. Tant qu'il reste des évènements (étape 120), on récupère l'évènement en question à l'étape 130. A l'étape 140, on analyse l'évènement conformément aux 20 mécanismes décrits ci-après en référence aux figures 4 et 5. On détermine, à l'étape 150, si l'évènement est à encoder. Dans l'affirmative (étape 160), on effectue l'encodage à partir des informations fournies à l'étape d'analyse 140 pour chacun des items composant l'événement. On peut réaliser les étapes d'indexation et de recherche dans les 25 tables d'encodage 34 (incluant les structures de description 26) en une seule fois lors de l'étape 140 afin de réaliser un encodage à un coût raisonnable. Puis on passe à l'évènement suivant au niveau de l'étape 120. Lorsque l'ensemble du document a été analysé (plus d'évènement à analyser à l'étape 120) on repasse à l'étape 100 pour déterminer si un autre 30 document 10 doit être analysé. Dans l'affirmative, on poursuit l'analyse par les étapes 110 à 160 jusqu'à expiration de l'ensemble des documents.

Lorsque l'ensemble des documents a été analysé (réponse NON à l'étape 100), on passe alors à la génération de la description 26, 26' successivement des attributs à l'étape 170 puis des éléments à l'étape 180. Une description plus détaillée de cette génération est fournie ci-après en référence à la figure 6. Il est, par ailleurs, possible de générer une description 26 d'autres évènements, par exemple instructions de traitement, commentaires, CDATA. Des mécanismes équivalents sont alors utilisés. Le processus de génération du fichier de description 26' se termine à l'étape 190 avec la génération des tables d'encodage 34 et structures de description 26 à partir du fichier de description 26'. On génère ainsi les tables d'encodage permettant à un encodeur d'encoder très efficacement les documents similaires aux documents analysés. Plus les documents à encoder sont proches des documents analysés, plus l'encodage est efficace.

La figure 4 illustre les étapes d'analyse d'un évènement de type balise ouvrante et la figure 5 celles d'analyse d'un noeud texte. La description fournie ci-après présente les mécanismes d'analyse qu'il est possible d'appliquer à d'autres évènements, par exemple instructions de traitement, commentaires, CDATA.

On note que le traitement des évènements balise fermante sert uniquement à mettre à jour l'état courant 24 de l'analyseur (lors de la génération du fichier de description 26') et/ou de l'encodeur (lors de l'encodage du document 10c). En référence à la figure 4, l'analyse de la balise ouvrante débute par une étape 200 de récupération de l'évènement balise ouvrante (issue de l'étape 130). A l'étape 210, on détermine si cette balise ouvrante est un premier enfant de l'élément parent, c'est-à-dire si elle est le premier élément hiérarchiquement inférieur qui fait suite à l'élément parent. Pour ce faire, on peut garder en mémoire l'élément précédemment analysé pour déterminer si ce dernier est l'élément parent auquel cas la nouvelle balise ouvrante est probablement un premier enfant. 42 Dans l'affirmative, on ajoute, à l'étape 220, l'élément à la liste des premiers enfants de l'élément parent. Dans la négative, on ajoute, à l'étape 225, l'élément à la liste des voisins directs de l'élément précédent (dans le document en cours d'analyse) de même niveau. On rappelle ici que l'on peut tenir à jour une liste ordonnée de ces voisins directs. Suite aux étapes 220 et 225, on détermine si cette balise ouvrante contient des déclarations d'espace de nommage (étape 230). Dans l'affirmative, on récupère, à l'étape 235, ces déclarations 10 d'espace de nommage. En pratique, ces déclarations d'espace de nommage sont introduites en début de document XML 10. Pour chaque déclaration d'espace de nommage récupérée à l'étape 235, on conserve le préfixe, l'URI et leur association. Ces éléments servent à pré-remplir ultérieurement les tables d'encodage et structures de description 15 liées aux espaces de nommage et permettent une bonne prédiction de l'URI connaissant le préfixe. On conserve aussi la position de la déclaration d'espace de nommage pour l'élément "balise ouvrante". Cette information sert à prédire correctement les futures déclarations d'espace de nommage liées à cette balise ouvrante. 20 On ajoute ainsi, à l'étape 240, ces éléments liés à l'espace de nommage et sa position en mémoire, dans une structure de description associée à la balise ouvrante en cours d'analyse. On réitère les étapes 230 à 240 pour chacune des déclarations d'espace de nommage de la balise ouvrante. 25 On poursuit après par l'étape 250 préparant l'analyse des attributs de la balise ouvrante. En cas de réponse négative à l'étape 230, on passe directement à l'analyse des attributs de la balise ouvrante de l'étape 250. A l'étape 250, on détermine la présence ou non d'attribut dans la 30 balise ouvrante examinée. En l'absence d'attribut, on met fin au processus d'analyse (étape 280). 43 Lorsqu'un attribut est détecté, il est isolé et récupéré à l'étape 255. A l'étape 260, on prélève le nom de l'attribut et sa position pour cette balise ouvrante que l'on ajoute en mémoire dans la structure de description de la balise ouvrante en cours d'élaboration. On remarque ici que l'on procède de façon similaire pour les déclarations d'espace de nommage et pour les attributs. On effectue ensuite, à l'étape 270, une analyse de la valeur de l'attribut. Cette analyse est quasiment similaire à l'analyse des noeuds textes qui est présentée ci-après en référence à la figure 6 dans le cas de noeuds texte enfants directs.

On réitère les étapes 250 à 270 pour tous les attributs de la balise ouvrante, jusqu'à l'arrêt du processus d'analyse à l'étape 280. En référence à la figure 5, l'analyse d'un noeud texte débute par la récupération d'un noeud texte à l'étape 300. A l'étape 310, on détermine l'état d'indexation du noeud texte. Par exemple, un noeud texte prend un état d'indexation actif (c'est-à-dire que lors de l'encodage, ce noeud texte devra être associé à un index, cet index étant utilisé pour les autres itérations du même noeud texte lors du codage) lorsqu'on détermine dans le document XML 10 qu'il y a plusieurs itérations de ce même noeud texte. Cette étape permet de déterminer au moment de la génération de la description si les noeuds textes de tel ou tel élément ou attribut sont à indexer ou pas. En pratique, on peut utiliser un bit des valeurs littérales pour préciser si une indexation doit être prévue. En jouant sur l'indexation, il est ainsi possible de limiter l'espace mémoire d'une table d'encodage 34. Un critère d'indexation peut par exemple être la longueur de la valeur/texte, partant du principe que les valeurs/textes les plus longs ne sont généralement pas répétés. Ensuite, à l'étape 320, on détermine si le noeud texte est le premier enfant de l'élément parent. Dans l'affirmative, on conserve, dans la structure de description de la balise ouvrante en cours d'élaboration, à l'étape 330, le lien entre le noeud texte et l'élément parent, par exemple dans une liste ordonnée associée audit élément parent et listant l'ensemble de ses enfants. 44 Dans la négative, on conserve, à l'étape 340, le lien entre le noeud texte et l'élément voisin, par exemple dans une liste ordonnée associée audit élément voisin et listant l'ensemble de ses voisins. La distinction entre "enfant" et "voisin" est effectuée car, notamment 5 pour les noeuds texte espace, elle permet une prédiction plus efficace des noeuds textes en fonction de l'évènement précédent. On termine le processus d'analyse du noeud texte à l'étape 350. En référence à la figure 6, on décrit maintenant la génération des structures de description 26 (idem pour le fichier de description 26') à partir des 10 informations issues des analyses précédentes (figures 3 à 5) et stockées, par exemple, en mémoire d'un analyseur. A l'étape 400, on débute le processus par la génération des informations d'espace de nommage. Cette première étape consiste à générer les tables d'encodage 15 correspondant aux préfixes et URI utilisées. On y stocke notamment les associations préfixes-URI. Ces associations sont utilisées pour les définitions de nom d'élément et d'attribut. Ces associations permettent par ailleurs d'encoder plus rapidement les déclarations d'espace de nommage : un encodeur classique effectue une 20 recherche dans une table pour un préfixe et une recherche dans une table pour l'URI pour déterminer leurs états d'indexation. En conservant l'association selon l'invention, on permet à l'encodeur de n'effectuer généralement qu'une seule recherche dans une table : une fois la recherche du préfixe effectuée, on récupère l'état d'indexation du préfixe et son association la plus probable, ce 25 qui permet généralement de ne pas avoir à effectuer la recherche de l'URI. Lors de cette étape, on pré-encode également les valeurs littérales des préfixes et URI sous la forme d'une suite d'octets. Cette suite d'octets peut ensuite être utilisée directement par l'encodeur lors de l'encodage littérale des préfixes et URI. On évite ainsi cet encodage pour chacun des documents XML 30 10 à encoder. 45 On poursuit le processus de génération à l'étape 410 en déterminant s'il y a des attributs détectés durant l'analyse qui n'ont pas encore été générés dans les structures de description 26. Dans l'affirmative, on récupère ledit attribut à l'étape 411.

A l'étape 415, on génère les informations d'encodage du nom (espace de nommage et nom local) de l'attribut dans une structure spécifique qui est référencée par les différentes structures de description d'éléments qui lui sont liées. A l'étape suivante 420, on détermine si un algorithme spécifique doit être appliqué sur la valeur de l'attribut. Si tel est le cas (sortie NON à l'étape 420), on conserve cette information au niveau des informations d'encodage du nom de l'attribut (étape 425) dans la structure de description associée. Cette information est ainsi immédiatement accessible lors de l'encodage ce qui évite une recherche supplémentaire et diminue le temps de traitement. On passe ensuite à un attribut suivant (étape 410). Si ce n'est pas le cas (sortie OUI à l'étape 420), on teste, à l'étape 430, si l'une des valeurs de l'attribut a été réutilisée dans un même document. Par exemple, lorsque la construction du fichier de description 26' est réalisée si un nombre suffisant d'informations est collecté, on peut détecter la réutilisation des valeurs d'attributs parmi ces informations collectées. Dans la négative (sortie NON à l'étape 430), on conserve, à l'étape 435, cette information au niveau des informations d'encodage du nom de l'attribut. Cette information pourra notamment être interprétée par l'encodeur comme un souhait de ne pas indexer cette valeur, car aucun gain de redondance ne peut être obtenu. On poursuit à l'étape 440. Dans l'affirmative (sortie OUI à l'étape 430), on conserve cette information d'indexation (option par défaut) et on teste, à l'étape 440, si certaines valeurs apparaissent fréquemment pour cet attribut.

Ce test vise typiquement à détecter le cas d'attributs ayant fréquemment une valeur particulière. En cas de valeur suffisamment fréquente, 46 les gains apportés par une prédiction correcte surpasseront les pertes apportées par une prédiction incorrecte. II est à noter que cette fréquence est calculée sur l'ensemble des documents analysés. Ainsi, un attribut n'apparaissant qu'une seule fois dans un 5 document peut se voir attribuer une valeur fixe. En cas de valeurs fréquentes (sortie OUI à l'étape 440), on conserve ainsi, à l'étape 445, l'ensemble des valeurs fréquentes (typiquement 1 ou 2) au niveau des informations d'encodage du nom de l'attribut de l'étape 415. On passe ensuite à l'attribut suivant (étape 410). 10 En l'absence de valeurs fréquentes, on passe directement à l'attribut suivant (étape 410). On réitère les étapes 410 à 445 pour l'ensemble des attributs détectés lors de l'analyse. Lorsque tous les attributs ont été décrits (sortie NON à l'étape 410), 15 on passe à la génération des éléments en déterminant tout d'abord, à l'étape 450, s'il reste un élément rencontré durant l'analyse des différents éléments qui n'a pas été décrit. Dans la négative, on met fin au processus de génération des structures de description à l'étape 490. 20 Dans l'affirmative, on récupère ledit élément à l'étape 455. On poursuit à l'étape 460 par la génération des informations relatives au nom de l'élément, notamment son espace de nommage et son nom local comme dans le cas de l'attribut. Il s'agit notamment de préparer l'encodage UTF8/UTF16 de ces noms, éventuellement l'encodage de leurs index associés 25 si on peut détecter que leurs index ne changent pas d'un encodage à un autre. En outre, on référence ces différentes valeurs dans les différentes tables d'encodage 34. II est notamment possible de relier le préfixe (s'il existe) à son URI pour permettre une récupération de l'URI rapidement à partir du préfixe. On poursuit à l'étape 465 par la génération des informations 30 d'encodage nécessaires aux noeuds textes enfant direct et voisin direct. II s'agit notamment de déterminer si ces noeuds sont à indexer, si la valeur de ces noeuds est fixe (ce qui est souvent le cas lorsque les noeuds ne contiennent que 47 des espaces) ou est une énumération d'un ensemble restreint de valeurs. Si on détecte des valeurs fixes ou restreintes, on les ajoute au dictionnaire d'indexation des valeurs textuelles et on prépare l'encodage UTF8/UTF16 de ces valeurs.

A l'étape 470, on détecte ensuite les éléments enfants et voisins possibles que l'on mémorise dans la structure fichier de description 26' sous forme de pointeurs reliant les différentes structures impliquées. On peut conserver l'ensemble des possibilités d'enfants et voisins, ou la possibilité la plus fréquente parmi les enfants ou parmi les voisins. Cette information est ensuite utilisée pour effectuer la prédiction de l'élément à encoder suivant par le module de prédiction 32. Cette information est stockée pour chaque élément et récupérable à partir des structures de description 26. A l'étape 475, on détecte ensuite si les déclarations d'espace de nommage sont prédictibles ou pas. Il est en effet extrêmement fréquent que ces déclarations apparaissent pour le même élément, généralement dans le même ordre. Ces déclarations sont reliées aux déclarations des préfixes et URI des éléments et attributs. On conserve donc pour chaque élément une liste ordonnée des déclarations d'espace de nommage, ce qui permet une sérialisation très efficace de ces déclarations.

A l'étape 480, on effectue la même opération pour les attributs en conservant une liste ordonnée des attributs, ce qui permet de prédire les attributs d'un élément et leur ordre d'encodage. On peut par ailleurs conserver pour chaque attribut de l'élément une valeur ou un ensemble de valeurs se répétant. De même, on conserve l'information d'indexation de la valeur de l'attribut. On réitère les étapes 450 à 480 pour tous les éléments rencontrés durant l'analyse, puis on met fin au processus de génération à l'étape 490. On décrit maintenant, en référence aux figures 7 à 11, l'encodage des documents XML 10 selon l'invention avec notamment l'utilisation des structures de description 26 et des tables d'encodage 34 pour la prédiction d'items. 48 La figure 7a décrit notamment un encodage XML binaire sans description initiale 26. II est entendu que les structures de description 26 et les tables d'encodage 34 peuvent être créés au fur et à mesure de l'encodage de documents XML 10 et servir comme structures de description initiales pour les encodages ultérieurs. Ainsi, on envisage d'utiliser ce schéma uniquement pour le premier document XML 10 à encoder. La figure 7b décrit un encodage XML binaire avec description initiale 26. On débute le processus d'encodage par la création d'un encodeur.

En présence d'un fichier de description 26' (figure 7b), on récupère ce dernier à l'étape 511 puis on préconfigure à l'avance, à l'étape 512, l'encodeur 20 à partir du fichier 26'. Comme indiqué précédemment, cette configuration initiale comprend notamment la génération des structures de description 26 et des tables d'encodage 34.

En l'absence de description (figure 7a), on attend la récupération d'un premier document à encoder (étape 500) puis on crée l'encodeur 20 selon une configuration générique, par exemple avec des tables d'encodage 34 comprenant une grammaire par défaut. Lorsqu'un document XML 10 est à encoder (étapes 500 et 501), on détermine, aux étapes 530 et 531, si ce document contient encore un évènement XML à encoder. En pratique, le module d'extraction 21 extrait les items et évènements dans l'ordre du document XML 10. Ainsi, on détecte des évènements à encoder jusqu'à la fin du document. En l'absence d'évènement XML à encoder (sortie NON): ù on détruit (étape 520) la configuration de l'encodeur 20 et les tables d'encodage associées 34 dans le cas où aucune description 26 préalable n'est fournie. On retourne ensuite à l'étape 500. ù on attend (étape 501) un nouveau document à encoder dans le cas où une description préalable 26 est fournie. En effet, dans ce cas, on ne réinitialise pas l'encodeur pour chaque document 10 à encoder mais on conserve la même configuration comprenant les structures de description 26 et les tables d'encodage préremplies 34. 49 Lorsqu'un évènement XML à encoder a été déterminé, on procède à sa récupération via le module d'extraction 21, aux étapes 540 et 541. On effectue ensuite, aux étapes 550 et 551, une recherche des informations d'encodage dans les tables d'encodage 34 à l'aide des structures de description 26 et éventuellement en complément du fichier de description 26'. Lorsque les tables d'encodage 34 et les structures de description 26 sont pré-remplies , cette recherche est fortement guidée et généralement plus rapide que dans le cas contraire, surtout en cas de prédiction efficace.

On note que pour le premier événement du document à encoder, on ne dispose pas d'élément courant à partir duquel on peut effectuer une prédiction. On prévoit alors que, soit une structure de description 26 est considérée comme initiale (par exemple pour la première balise <html> d'un document HTML), soit on effectue un encodage générique du premier élément extrait, lequel fournit la porte d'entrée dans les structures de description 26 comme décrit précédemment. En fonction de l'état courant 24, on détermine donc l'item prédit 27. Notamment, on récupère également, lors de la prédiction 25, des informations d'encodage directement des tables d'encodage 34 à partir de l'élément prédit, limitant par conséquent les recherches dans les tables d'encodage 34. Dans l'étape 550 (pas de description a priori), la recherche est réalisée de façon conventionnelle. On encode ensuite l'évènement, aux étapes 560 et 561.

Lorsque la structure de description 26 de l'évènement est présente et récupérée dans les tables d'encodage 34 grâce à une prédiction exacte, l'encodage est plus rapide car certaines parties de l'évènement peuvent avoir été pré-encodées dans le fichier de description. Dans l'étape 560 (absence de description 26), l'encodage est 30 réalisée de façon conventionnelle. 50

On met ensuite à jour les tables d'encodage aux étapes 570 et 571 et éventuellement les structures de description 26, lorsque celles-ci sont mises à jour au fur et à mesure de l'encodage courant. Dans le cas où les tables d'encodage 34 ont été pré-remplies et qu'une prédiction efficace peut en être retirée, il est rare d'avoir besoin d'ajouter une nouvelle entrée dans les tables d'encodage, ce qui limite la mise à jour des tables d'encodage. On passe ensuite à l'évènement suivant (étapes 530 et 531). Les étapes de recherche 551, encodage 561 et mise à jour 571, en présence d'une description 26 et de tables 34 pré-remplies, sont décrites plus en détail ci-après en référence aux figures 8 à 11 pour successivement les cas d'une balise ouvrante, d'une déclaration d'espace de nommage, d'un attribut et d'un noeud texte. La présence et l'utilisation de structures de description 26 et de 15 tables 34 pré-remplies dans chacune de ces étapes permettent un gain de temps traitement important par rapport aux techniques conventionnelles.

En référence à la figure 8, on illustre l'encodage d'une balise ouvrante dans le cas où les tables 34 sont pré-remplies de sorte à disposer de 20 structures de description 26 de l'élément balise ouvrante à encoder. On obtient alors une prédiction de cette balise. A l'étape 600, on récupère la balise ouvrante à encoder (balise extraite 23). A l'étape 605, on teste si la prédiction 27 de l'item correspond à la 25 balise ouvrante à encoder. Cette étape est notamment réalisée au sein du comparateur 31. Dans la négative (sortie OUI à l'étape 605), on effectue une recherche générique (ou conventionnelle) de l'item dans les tables d'encodage 34 à l'étape 610. On récupère ainsi, à l'étape 615, la description de l'item s'il a 30 déjà été indexé, c'est-à-dire si une description de cet item est déjà dans les tables (et donc notamment le pointeur vers la structure de description correspondante). 51 Dans l'affirmative (sortie NON à l'étape 605), la prédiction exacte permet de disposer directement de la structure de description relative à la balise à encoder et d'éventuelles informations d'encodage, par exemple un index, fournies par exemple dès la prédiction 25.

Les étapes qui suivent illustrent l'encodage des informations présentes dans la balise ouvrante (déclarations d'espace de nommage, nom d'éléments, attributs). La figure 8 présente un ordre typique de l'encodage de ces informations, mais un ordre différent est parfaitement possible dans le cadre de la présente invention.

Dans le cas où l'item n'a pas de structures de description pré-remplie dans les tables 34, on revient alors aux méthodes classiques d'encodage de l'art antérieur. A l'étape 620, on détermine si la balise ouvrante contient des déclarations d'espaces de nommage à encoder, c'est-à-dire des nouvelles déclarations non encore encodées lors de l'encodage courant du document XML 10c. Dans l'affirmative, on effectue, à l'étape 625, l'encodage de ces déclarations à partir de la description récupérée (soit par prédiction, soit des tables d'encodage) de l'item. Un exemple de cet encodage est décrit ci-après en référence à la figure 9. En l'absence de déclarations à encoder et à la suite de l'étape 625, on encode l'espace de nommage de l'item à encoder. On reproduit ces étapes pour toutes les déclarations de nommage dans la balise. La description récupérée de l'item permet de savoir si l'item a déjà été encodé (l'information peut être contenue dans les tables d'encodage 34 comme indiqué précédemment), auquel cas on encode l'index correspondant donné par la description récupérée. Si l'item n'a pas encore été encodé, on encode alors son espace de nommage (les informations d'indexation de cet espace de nommage sont données par la description récupérée) à l'étape 630, et on fait de même avec le nom de l'item à l'étape 635 (encodage littéral). 2 On poursuit à l'étape 640, en effectuant une étape de mise à jour de l'indexation dans les tables d'encodage 34. On effectue également la prédiction 25 du prochain évènement à encoder, via par exemple l'élément enfant prédit dans la structure de 5 description de l'élément en cours d'encodage. Cette prédiction est aussi effectuée lors d'une balise fermante, où l'on prédit l'élément suivant via cette même structure de description. Dans le cas particulier de Fast Infoset, on peut conserver l'ensemble des descriptions dans la table d'indexation des noms d'éléments et la table d'indexation des noms d'attributs ('surrogates'), pour ainsi avoir un moyen général de récupérer la description. La description contient alors les informations permettant d'encoder l'élément et d'effectuer les prédictions futures. Dans le cas d'Efficient XML, la grammaire correspondant à chaque élément peut contenir cette description. On peut ainsi avoir deux types de grammaire, l'une basée sur des tables de hachage pour récupérer un index à partir d'un nom d'item, l'autre basée sur une liste ordonnée qui est parcourue lors de l'encodage de l'item. Le choix de la représentation de la grammaire interne est fonction de la régularité de l'item dans les documents encodés : si celui-ci est très régulier, on préfèrera la seconde représentation interne. Si l'item a une variabilité importante, on lui préfèrera la première représentation interne. On poursuit l'encodage par celui des attributs de la balise ouvrante. A l'étape 650, on détermine si la balise ouvrante contient des 25 attributs non encodés. En pratique, on parcourt les différents attributs dans l'ordre d'énumération à l'intérieur de la balise ouvrante. Dans l'affirmative, on procède à leur encodage en utilisant la structure de description prédite, à l'étape 655. Cet encodage sera décrit plus en détail en référence à la figure 10. 30 Dans la négative et après l'encodage de l'étape 655, l'encodage de la balise ouvrante est alors terminé. II est mis fin au processus d'encodage à l'étape 660. 53 On remarque ici, que si les structures de description 26 et les tables d'encodage pré-remplies 34 prédisent correctement l'item, aucune recherche générique ou un nombre limité de recherches dans les tables d'encodage 34 est effectué(e).

Par ailleurs, les données à encoder se trouvant éventuellement déjà dans une forme pré-encodée (par exemple des index pré-encodés, des chaînes de caractères pré-encodées), on gagne du temps lors des étapes d'encodage par rapport à l'encodage conventionnel de l'art antérieur. On décrit maintenant, en référence à la figure 9, l'encodage des 10 déclarations d'espace de nommage, notamment de l'étape 625. Puisque des déclarations d'espace de nommage ont été détectées à l'étape 620, on itère (étape 700) les étapes suivantes d'encodage 710 à 780 pour chacune des déclarations. En fin de traitement (plus de déclarations à encoder), le processus 15 de la figure 9 prend fin (étape 790) pour éventuellement retourner à l'étape 630. On récupère ainsi, à l'étape 710, successivement chacune des déclarations à encoder de la balise ouvrante. On détermine, à l'étape 720, si la déclaration à encoder correspond à 20 la déclaration prédite sur la base de la structure de description de l'élément en cours d'encodage. Dans l'affirmative, on récupère les informations (par exemple des index pré-encodés, des chaînes de caractères pré-encodées) de cette déclaration pour encoder successivement et efficacement le préfixe à l'étape 25 730 et l'URI à l'étape 740. On poursuit, à l'étape 750, en mettant à jour l'état d'indexation des items de la déclaration d'espace de nommage dans les tables d'encodage 34, et, à l'étape 760, en mettant à jour la prédiction pour la déclaration d'espace de nommage suivante. On dispose ainsi de la prédiction qui sera utilisée lors de 30 l'encodage de déclarations d'espace de nommage suivant. 4 Dans la négative (si la déclaration d'espace de nommage n'est pas correctement prédite), on effectue, à l'étape 770, une recherche générique de l'état d'indexation du préfixe dans les tables d'encodage 34. Si le préfixe n'est pas trouvé dans les tables d'encodage 34, on 5 effectue, à l'étape 780, une recherche générique de la déclaration dans les tables d'indexation à partir de l'URI. Si le préfixe retourné est un préfixe "par défaut", on passe directement à l'étape 780. S'il s'agit d'un préfixe indexé spécifique, on récupère la structure de description associée, laquelle donne l'URI généralement associé à ce préfixe (URI prédite) et on compare celle-ci avec l'URI à encoder (URI extraite). Si la comparaison échoue, on effectue, à l'étape 780, une recherche générique de la déclaration dans les tables d'indexation (d'encodage) 34 à partir de l'URI.

Dans le cas le moins favorable, on effectue ainsi les mêmes recherches que dans l'art antérieur sans surcoût. Dans les cas plus favorables, l'invention améliore la vitesse de traitement en diminuant le nombre de recherches effectuées. Une fois le préfixe récupéré par l'une quelconque des voies évoquées ci-dessus (étapes 770 et 780), on procède à l'encodage du préfixe 730 et poursuit le processus comme décrit ci-dessus pour les étapes 740 à 760. Une fois la prédiction d'espace de nommage mise à jour (étape 760) effectuée, on passe à la déclaration suivante (étape 700). On décrit maintenant, en référence à la figure 10, l'encodage des attributs, notamment ceux de la balise ouvrante lors de l'étape 655. L'encodage des attributs suit un schéma proche de celui de l'encodage des déclarations d'espace nommage de la figure 9. Puisque des attributs ont été détectées à l'étape 650, on itère (étape 800) les étapes suivantes d'encodage 805 à 870 pour chacune des 30 déclarations. En fin de traitement (plus d'attributs à encoder), le processus de la figure 10 prendra fin (étape 880) pour retourner par exemple à l'étape 660. 5 On récupère ainsi, à l'étape 805, successivement chacune des attributs à encoder. On détermine, à l'étape 810, si l'attribut à encoder correspond à l'attribut prédit sur la base de la structure de description 26 déterminée à partir 5 de l'item précédemment encodé. Dans la négative, on effectue une recherche générique dans les tables d'encodage 34 lors de l'étape 815 et on récupère les informations d'indexation de l'attribut. Dans l'affirmative et suite à la recherche de l'étape 815, on dispose ainsi des informations d'indexation de l'attribut soit par prédiction soit par la recherche de l'étape 815. On encode ensuite l'espace de nommage de l'attribut à l'étape 820 et le nom de l'attribut à l'étape 825, comme il est fait pour une balise ouvrante (voir figure 6). On poursuit en encodant la valeur de l'attribut de manière similaire à l'encodage des noeuds textes dont un exemple est fourni ci-après en lien avec la figure 11. L'encodage de la valeur de l'attribut est représenté de façon simplifiée sur la figure 10 par le cadre en traits discontinus. A l'étape 830, on détermine, dans le cas où une prédiction de l'attribut a été fournie, si cette prédiction comprend la valeur de l'attribut à 20 encoder. Dans la négative ou en cas d'absence de la prédiction de l'attribut, on teste, à l'étape 835, si la valeur d'attribut est à indexer, par exemple en tenant compte de la taille de l'attribut. Si c'est le cas, on récupère de façon conventionnelle, à l'étape 840, 25 l'état d'indexation de la valeur dans les tables d'encodage 34, puis on encode la valeur à partir de cette information lors de l'étape 850. Si la valeur n'est pas à indexer, on passe directement à l'encodage de l'étape 850. L'encodage est dans ce cas effectué de façon littérale, sans aucune recherche préalable générique dans les tables d'encodage 34. 30 Dans le cas où la prédiction de la valeur d'attribut est exacte (sortie OUI de l'étape 830), on utilise la prédiction pour encoder efficacement cette 56 valeur, par exemple on récupère, dans les tables 34 pré-remplies et à partir de cette prédiction, une valeur pré-encodée ou un index. On poursuit à l'étape 860 en mettant à jour l'état d'indexation des items de l'attribut et à l'étape 870 en mettant à jour la prédiction pour l'attribut suivant. On dispose ainsi de la prédiction qui sera utilisée lors de l'encodage de l'attribut suivant. Une fois la prédiction d'attribut suivant effectuée, on passe à l'attribut suivant (étape 800), jusqu'à épuisement des attributs. On décrit enfin, en référence à la figure 11, l'encodage des noeuds texte. Cet encodage peut également s'appliquer, moyennant des adaptations mineures aux spécificités des attributs, à l'encodage des valeurs d'attribut comme représenté par le cadre en traits discontinus de la figure 10. On note que la possibilité de valeurs fixes est notamment très importante dans le cas où l'on préserve les espaces typographiques entre items. II est à noter que la description de l'item définit deux prédictions pour les noeuds textes : le premier noeud texte enfant et le noeud texte voisin. Lorsque l'on récupère un noeud texte pour encodage, on détermine dans une première étape 900 si une prédiction du noeud texte a été effectuée. Dans la négative (sortie NON), on recherche, lors de l'étape 905, un type d'encodage tenant éventuellement compte du typage des valeurs d'attributs (string, float, int, etc.), à effectuer. Dans l'affirmative ou suite à l'étape 905, on détermine si un encodage typé spécifique est à utiliser ou pas (étape 910). Cet encodage typé se déduit du résultat de l'étape 905 ou de la présence d'informations d'encodage typé dans la structure de description prédite. Si tel est le cas (sortie NON à l'étape 910), on utilise cet encodage (étape 915) pour encoder le noeud texte. II est alors mis fin à l'algorithme à l'étape 960. Si ce n'est pas le cas (sortie OUI à l'étape 910), on teste si la valeur est à indexer ou pas (étape 920). Cette indication est présente dans la structure de description prédite, par exemple. Par défaut, on peut utiliser un test sur la 57 longueur de la chaîne de caractères pour déterminer l'opportunité d'indexer ou non le texte. Dans le cas où cette valeur n'est pas à indexer (sortie NON à l'étape 920), on effectue, à l'étape 925, un encodage non indexé du texte, par exemple un encodage littéral. Il est à noter qu'on évite dans ce cas une recherche générique dans les tables d'encodage 34, ce qui permet un encodage plus rapide, au détriment d'une compression potentiellement moins bonne. II est par conséquent utile que la prédiction soit suffisamment précise. L'encodage non indexé 925 est suivi de la fin du processus d'encodage du noeud texte 960.

Dans le cas où cette valeur est à indexer (sortie OUI à l'étape 920) notamment parce que la structure de description prédite inclut une valeur pour ce noeud texte, on teste si la valeur prédite de ce noeud texte est correcte (par exemple identité des chaînes de caractères avec le noeud texte à encoder) lors de l'étape 930.

Dans l'affirmative (sortie NON à l'étape 930), on encode cette valeur à partir des informations d'encodage de la structure de description prédite, lors de l'étape 935. Dans la négative (sortie OUI à l'étape 930), on effectue, à l'étape 940, une recherche et une récupération générique de l'état d'indexation de la valeur textuelle à encoder dans les tables d'encodage 34. On effectue alors un encodage indexé de la valeur récupérée lors de l'étape 945. Au sortir des étapes 935 et 945, on met à jour l'état d'indexation relatif à la valeur textuelle, dans les tables d'encodage 34 et éventuellement dans les structures de description 26 (étape 950).

Il est alors mis fin à l'algorithme d'encodage du noeud texte à l'étape 960. Ainsi l'invention permet d'accélérer l'encodage de données hiérarchisées en s'appuyant, de façon générale, sur une table d'encodage pré-générée comprenant au moins une structure de description, et de façon spécifique, sur d'autres mécanismes complémentaires, tels la prédiction d'item et le pré-encodage de valeurs.

58 Le décodage d'un document encodé réalisé selon l'invention est mené de façon conventionnelle car le document encodé se suffit à lui-même. Par exemple, la routine de décodage d'une valeur peut être réalisée comme suit : la valeur est-elle indexée ? oui, récupération de l'index (entier) puis récupération de la valeur à partir de l'index et de la table associée au type (préfixe, URI, nom local) de la valeur; non, récupération de la chaîne de caractère à partir du flux XML binaire (décodage UTF-8 ou UTF-16), et ajout de cette chaîne de récupération dans la table associée au type de la valeur. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

59 Annexe 1 10 15 20 25 30 <bp:prediction xmins:bp="htpp://example.org/bx-prediction"> <bp:attributes> <bp:attribute name="id" indexable="true" value="idI"/> <bp:attribute name="ratio" type="float"/> </bp:attributes> <bp:elements root="QName"> <bp:element name="soap:Envelope" indexable="true" isRepeating="false" beforeFirstChild=" " fistChild="soap:Header"/> </bp:elements> <bp:examples> <soap:Envelope xmins:soap="http://.../soap/envelope/" bp: root="true" bp:spacePrediction="true" bp: isRepeating="false" bp:hierarchyPrediction="true"> <soap:Header> <headerAck xmlns="http://example.org/ack" bp: isRepeating="true"/> </soap:Header> <soap:Body> <ack xmlns="http://example.org/ack" bp:nextSibling="comp" bp:type="int"/> </soap:Body> </soap:Envelope> <headerAck2 xmlns="http://example.org/ack" bp: nextSibling="headerAck" bp:type="int"/> </bp:examples> </bp:prediction> 60 Annexe 2 <soap:Envelope xmins:soap="http://.../soap/envelope/"> <soap:Header> <headerAck xmins="http://example.org/ack"/> </soap: Header> <soap:Body> <ack xmins="http:l/exampie.org/ack"/> <lsoap:Body> <Isoap:Envelope>10

Claims (25)

REVENDICATIONS

1. Procédé de traitement d'un document (10c) comprenant des données hiérarchisées organisées en une pluralité d'items, ledit procédé comportant : - une étape préalable (512) de génération d'au moins une table dite "d'encodage" (34) comprenant des informations d'encodage organisées en une pluralité de structures d'encodage (34) associées chacune à un item, ladite étape préalable de génération étant basée sur le codage préalable d'autres documents de données hiérarchisées (10a, 10b), -une étape de codage dudit document de données hiérarchisées, comprenant : a. une étape d'extraction (541, 600, 710, 805) d'un item à coder ; b. une étape de détermination, dans ladite table d'encodage, d'une structure d'encodage associée audit item à coder ; c. une étape d'encodage (625, 655, 730, 820, 850, 935) dudit item extrait à partir de ladite structure d'encodage déterminée.

2. Procédé selon l'une des revendications précédentes, dans lequel les étapes a, b et c sont réitérées pour une pluralité d'items dudit document de données hiérarchisées (10a, 10b, 10c).

3. Procédé selon la revendication 1 ou 2, dans lequel l'étape de détermination comprend une étape b') de prédiction (640, 760, 870) dudit item à coder.

4. Procédé selon la revendication 3 en dépendance de la revendication 2, dans lequel la prédiction (640, 760, 870) est fonction de l'item encodé lors l'itération précédente.

5. Procédé selon la revendication précédente, dans lequel la prédiction b') (640, 760, 870) est effectuée à l'aide d'un ensemble de structures de description (26) d'items reliées entre elles de sorte à former une description globale a priori, ladite prédiction consistant à déterminer un item dont la structure de description associée est reliée à la structure de description de l'item encodé lors de l'itération précédente.

6. Procédé selon la revendication précédente, dans lequel lesdites structures de description (26) et les structures d'encodage (34) sont reliées de sorte qu'un item donné soit représenté par une structure de description et une structure d'encodage_

7. Procédé selon l'une des revendications 5 et 6, dans lequel lesdites structures de description (26) forment une chaîne de structures d'attributs principaux.

8. Procédé selon la revendication précédente, dans lequel au moins une structure d'attributs principaux comprend un pointeur vers une structure d'attribut suivant.

9. Procédé selon l'une des revendications 5 à 8, dans lequel lesdites structures de description (26) forment une chaîne de structures d'éléments principaux.

10. Procédé selon la revendication 9, dans lequel au moins une structure d'éléments principaux comprend un pointeur vers une structure d'élément hiérarchiquement inférieur, dit élément enfant.

11. Procédé selon l'une des revendications 9 et 10, dans lequel au moins une structure d'éléments principaux comprend un pointeur vers une structure d'élément de même niveau hiérarchique, dit élément suivant.

12. Procédé selon l'une des revendications 9 à 11, dans lequel au moins une structure d'éléments principaux comprend un pointeur vers une structure d'attribut.

13. Procédé selon l'une des revendications 9 à 12, dans lequel au moins une structure d'éléments principaux comprend un pointeur vers une 25 structure de déclarations d'espace de nornmage.

14. Procédé selon l'une des revendications 1 à 13, dans lequel lors de ladite génération préalable (512), on initialise ladite table d'encodage (34) à l'aide d'un fichier de description (26').

15. Procédé selon la revendication précédente, dans lequel ledit 30 fichier de description (26') est propre à une application (11) ayant généré le document (10c) de données hiérarchisées.

16. Procédé selon l'une des revendications 1 à 15, dans lequel le document de données hiérarchisées (10c) et les autres documents de données hiérarchisées (10a, 10b) ont été générés par une même application (11).

17. Procédé selon l'une des revendications 1 à 15, dans lequel ladite génération préalable (512) comprend un pré-encodage littéral d'au moins une valeur associée à au moins un item et le stockage de ladite valeur pré-encodée dans la structure d'encodage associée audit item.

18. Procédé selon l'une des revendications précédentes, dans lequel ladite au moins une table d'encodage comprend, dans les structures d'encodage associées chacune à un item, un indicateur agencé pour indiquer si ledit item a déjà été codé lors d'une étape de codage c) du codage dudit document (10c) de données hiérarchisées.

19. Procédé selon la revendication 18, dans lequel ledit indicateur comprend un drapeau prenant une première valeur ("faux") en début de codage dudit document et prenant une deuxième valeur ("vrai') lors du premier encodage c) de l'item correspondant pour ledit document.

20. Procédé selon la revendication 18, dans lequel ledit indicateur comprend un premier compteur (Ct) incrémenté à chaque encodage c) de l'item correspondant, et on associe à chaque item dudit document (10c) un deuxième compteur (Cv) incrémenté à chaque encodage c) de l'item lors du codage dudit document (10c), ladite indication de savoir si ledit item a déjà été codé résultant de la comparaison desdits deux compteurs (Cv, Ct).

21. Dispositif de traitement (20) d'un document (10c) comprenant des données hiérarchisées organisées en une pluralité d'items, ledit dispositif comportant : - un moyen de génération, préalable à un encodage dudit document, d'au moins une table dite "d'encodage" (34) comprenant des informations d'encodage organisées en une pluralité de structures d'encodage (34) associées chacune à un item, ladite génération étant basée sur le codage préalable d'autres documents de données hiérarchisées (10a, 10b),GLI - un moyen de codage dudit document de données hiérarchisées, comprenant : a. un moyen d'extraction (21) apte à extraire un item à coder dudit document ; b. un moyen de détermination, dans ladite table d'encodage, d'une structure d'encodage associée audit item à coder ; c. un moyen d'encodage (32) apte à coder ledit item extrait à partir de ladite structure d'encodage déterminée (34).

22. Dispositif selon la revendication 21, dans lequel le moyen de détermination comprend un moyen de prédiction (25) de l'item à coder.

23. Dispositif selon l'une des revendications 20 et 21, comprenant un moyen de mémorisation d'état courant (24) agencé pour mémoriser des informations relatives aux items extraits par ledit moyen d'extraction (21), ledit moyen de prédiction (25) étant agencé pour prédire ledit item en fonction desdites informations mémorisées dans le moyen de mémorisation d'état courant.

24. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de traitement conforme à l'une quelconque des revendications 1 à 20 lorsque le programme est chargé et exécuté par le système informatique.

25. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de traitement selon l'une quelconque des revendications 1 à 20, lorsqu'il est chargé et exécuté par le microprocesseur.