FR2931271A1 - Procede et dispositif de codage d'un document structure et procede et dispositif de decodage d'un document ainsi code - Google Patents

Abstract

Le procédé de codage d'un document structuré comporte :- une étape (705) de détermination s'il existe une succession de prédictions correctes pour des items d'un ensemble d'items du document et- si le résultat de ladite étape de détermination est positif, une étape (710) de codage du nombre de prédictions correctes successives.Dans des modes de réalisation, ce procédé comporte, en outre, si un ensemble d'items du document possède des valeurs associées, une étape de codage des dites valeurs associées audit ensemble d'items du document.

Description

La présente invention concerne un procédé et un dispositif de codage d'un document structuré et un procédé et un dispositif de décodage d'un document ainsi codé. Elle s'applique, en particulier, au codage d'un document décrit en langage de balisage, notamment le langage XML (acronyme de Extensible Markup Language , c'est à dire langage de balisage extensible). XML est une syntaxe pour définir des langages informatiques. XML permet 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 ou des données textuelles. Par ailleurs, 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 quels traitements appliquer au document XML (par exemple: <?montraitement?> ). On considère dans la suite que des données XML sont décrites en termes d'item, chaque item pouvant être un début d'élément (<balise>), une fin d'élément (</balise>), un attribut, un contenu textuel, un commentaire ou une instruction de traitement. Plusieurs langages XML différents peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages XML différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace en anglais). 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 de ressource uniforme), 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: xmlns: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"> ).

XML présente de nombreux avantages et est devenu un standard 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. De plus, 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 surtout de la lecture de documents XML. Pour remédier à ces inconvénients, des méthodes pour coder 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 compacte, mais 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 dans 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, ce qui réduit la taille du document généré et facilite la lecture. En effet, il n'y a plus de besoin de lire la chaîne complète dans le fichier et 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 plus d'informations structurelles afin de compresser davantage les données. On peut citer le cas d' Efficient XML (marque déposée), format utilisé comme base pour la standardisation d'un format XML binaire par le groupe EXI (acronyme de Efficient XML Interchange pour interchange XML efficace) du W3C (acronyme de world wide web consortium pour consortium de la toile mondiale), qui prend en compte l'ordre d'apparition des différents items au sein d'un document pour construire une grammaire qui permet de coder les items les plus fréquents sur un faible nombre de bits.

Efficient XML utilise un ensemble de grammaires pour coder un document XML. Une grammaire est composée d'un ensemble de productions, chaque production comprenant une description d'item, ou événement XML, une valeur de codage associée et l'indication de la grammaire suivante à 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écrite dans la production sont codées. Une grammaire 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, la grammaire est modifiée pour inclure une nouvelle production 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 sont exprimées sous forme de priorités ayant de un à trois niveaux. Coder une valeur de codage revient à coder les valeurs de sa priorité. Chaque niveau est codé sur un nombre de bits minimum pour pouvoir coder la plus grande valeur de ce niveau associée à une production de la grammaire.

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 être des règles génériques, communes à tous les documents XML et construites à partir de la syntaxe XML. Elles peuvent aussi être des règles spécifiques à un type de document, construites à partir d'un schéma XML (http://www.w3.org/XML/Schema) 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. De plus, 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.

Par 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> <IastName>Smith</IastName> </person> Le codeur n'ayant pas rencontre d'élément person auparavant, une grammaire par défaut est créée pour cet élément. II s'agit d'une grammaire ne contenant que des productions génériques. Durant le codage de l'élément person , de nouvelles productions sont 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 correspond à l'événement de fin d'élément, SE (*) correspond à un événement de début d'élément quelconque (le nom n'est pas précisé), et CH correspond à un événement de contenu textuel. Lors du codage, après avoir reçu l'événement correspondant au début d'élément person (SE (person)) et l'avoir codé, le codeur sélectionne la grammaire de codage du contenu de l'élément person , décrite ci-dessus. Ensuite, le codeur 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 Le codeur code donc la priorité 1.0 . Comme le premier niveau de priorité comprend deux valeurs distinctes ( 0 et 1 ), ce niveau peut être codé sur un bit, avec la valeur 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, EE 0 SE (*) ElementContent 1.0 CH ElementContent 1.1 comme la production ne précise pas le nom de l'élément, firstName est codé. On poursuit ensuite le codage du contenu de firstName . Pour ce faire, on recherche la règle associée à cet élément. Comme aucun élément firstName n'a été rencontré, on créé une grammaire firstName à partir de la grammaire par défaut. L'élément fisrtName contient un noeud texte pour unique enfant. Une fois ce noeud texte codé, on met à jour la grammaire de firstName en insérant une production texte (CH) : Une fois le contenu de firstName codé, le codeur modifie la 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. La grammaire devient alors : ElementContent : SE (firstName) ElementContent 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 L'événement suivant 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 Le premier niveau de priorité ayant maintenant trois valeurs possibles, il est codé sur deux 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é. ElementContent : Characters 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 Puis le contenu de lastName est codé à l'aide de la grammaire associée à l'élément lastName . Après cela, la grammaire est modifiée pour y ajouter une production correspondant au début de l'élément lastName et elle devient alors : ElementContent : SE (lastName) ElementContent 0 SE (firstName) ElementContent 1 EE 2 SE (*) ElementContent 3.0 CH ElementContent 3.1 Si, par la suite, dans le document, le codeur rencontre un autre élément person similaire, cet élément est 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 15 codé avec la production : SE (firstName) ElementContent 1 La production SE (*) ElementContent 3.0 correspond aussi à cet événement, mais est moins précise (elle ne 20 précise pas le nom de l'élément). C'est donc la première production qui est utilisée. Le codeur code donc la priorité de cette production, à savoir 1 , qui est codée avec les deux bits 01 . II n'y a pas besoin de coder le nom de l'élément, puisque celui-ci est précisé par la production. Le codeur code ensuite 25 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. Le codeur code ensuite, de manière similaire, l'événement de début 30 de l'élément lastName , en codant uniquement la priorité 0 avec les deux bits 00 . 10 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.

Si un schéma est disponible pour décrire le contenu de person , à savoir un élément firstName et un élément lastName , il est possible de construire, dès le départ, la grammaire générée après la fin du codage du premier élément person . Cependant, si le schéma précise en outre que les éléments firstName et lastName doivent être ordonnés à l'intérieur de l'élément person , firstName précédant lastName , il est possible de générer les grammaires suivantes pour décrire le contenu de person . ElementContentl : SE (firstName) ElementContent2 0 EE 1 SE (*) ElementContentl 2.0 CH ElementContentl 2.1 ElementContent2 : SE (lastName) ElementContent3 0 EE 1 SE (*) ElementContent2 2.0 CH ElementContent2 2.1 ElementContent3 : EE 0 SE (*) ElementContent2 1.0 CH ElementContent2 1.1 Ces grammaires se servent de l'ordre connu d'apparition des éléments firstName et lastName pour séparer les productions en plusieurs grammaires et diminuer le nombre de productions par grammaire et, par conséquent, le nombre de bits nécessaires pour coder une priorité. Ces grammaires peuvent même être réduites si l'on n'accepte pas les déviations par rapport au schéma et deviennent alors : ElementContentl : SE (firstName) ElementContent2 0 ElementContent2 : SE (lastName) ElementContent3 0 ElementContent3 : EE 0 Dans ce cas, chaque grammaire ne contenant qu'une seule priorité, cette priorité n'a pas besoin d'être codée. Ainsi l'ensemble des événements décrivant le contenu de l'élément person tel que décrit ci-dessus est codé en 0 bits. Le format Fast Infoset , spécifié par le standard ITU-T Rec. X.891 I ISO/IEC 24824-1 , permet une représentation plus compacte d'un document XML en utilisant des codes d'évènements binaires et des tables d'index.

Dans ce format, les types d'évènements sont décrits en tant que liste qui utilise 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 d'information XML précis. Ces tables permettent de coder une information donnée de manière littérale (UTF8 ou UTF16 à préciser) la première fois que cette information est rencontrée durant un codage. Cette information est ensuite ajoutée dans la table. Ultérieurement, cette information est détectée dans la table, on récupère l'index dans cette table et on code la valeur de cet index à la place de l'information. On peut ainsi noter un certain nombre de tables d'indexation : - les préfixes et URI qui définissent les espaces de nommage sont indexés dans deux tables spécifiques, - les valeurs d'attributs et les valeurs de noeuds textes sont indexées dans deux tables spécifiques - les noms locaux d'attributs et d'éléments sont indexés dans une table spécifique, - les noms qualifiés (qui regroupe préfixe, URI et nom local) d'éléments et les noms qualifiés d'attributs sont: indexés dans deux tables spécifiques. II est à noter que le standard Fast Infoset permet au codeur de décider si telle ou telle valeur d'attribut ou de noeud texte est à indexer. Ceci permet notamment de ne pas nécessité une importante taille de mémoire utilisée par le codeur. La décision d'indexer ou non une valeur d'attribut ou un noeud texte est donc codée dans le flux Fasi: Infoset pour permettre au décodeur d'indexer ou non les valeurs décodées.

La demande de brevet US20070276827 présente un procédé pour compresser des données hiérarchisées, notamment XML. Le principe est de déterminer si un élément XML correspond à un modèle ou à prédiction particulière. Si tel est le cas, on effectue un codage de cet élément. On peut noter que déterminer la correspondance d'un élément XML à un modèle, nécessite la connaissance de l'élément XML en entier, ce qui nécessite un stockage des données XML en mémoire avant encodage. Ce principe est acceptable dans certaines utilisations, notamment lorsque les données sont déjà présentes sous la forme d'un arbre en mémoire. Néanmoins, dans de nombreux cas d'utilisations, les données XML sont sous la forme d'un flux d'événements, auquel cas le codeur doit effectuer un stockage de ces données. Cette étape supplémentaire ajoute un coût souvent rédhibitoire en termes de consommation de mémoire et de temps de traitement. On peut, par ailleurs, noter que la mise en correspondance au niveau de l'élément XML, souvent efficace, peut s'avérer trop restrictive : la redondance de sous-parties d'éléments se répétant n'est pas ou peu prise en compte, ce qui a un impact négatif sur les taux de compression obtenus par ces techniques. La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de codage d'un document structuré, caractérisé en ce qu'il comporte : - une étape de détermination s'il existe une succession de prédictions correctes pour des items d'un ensemble d'items du document et - si le résultat de ladite étape de détermination est positif, une étape de codage du nombre de prédictions correctes successives. A la base de la présente invention, les inventeurs ont déterminé que les structures des éléments XML ont tendance à se répéter. La mise en oeuvre de la présente invention tire partie de cette redondance potentielle pour mieux utiliser les grammaires et compresser de manière plus compacte les éléments qui sont déjà décrits par une grammaire. Ainsi, on étudie la conformité de prédiction au niveau de chaque item, par comparaison entre l'item attendu par prédiction et l'item obtenu. Et, au lieu de coder un bit de conformité pour chaque évaluation de conformité, on code le nombre de prédictions correctes successives. Par exemple, si on prédit correctement dix items successifs, on code le nombre décimal 10 (pour lequel quatre bits sont nécessaires), au lieu de coder dix fois un bit de conformité.

La mise en oeuvre de la présente invention permet l'obtention de gains en termes de compression, puisqu'il y a une gestion plus fine des prédictions. Elle fournit aussi des gains en termes de performances, de vitesse et de mémoire, en optimisant l'usage de cette dernière et en facilitant le codage de chaque item correctement prédit. Elle donne aussi des gains en termes de taille de librairie du fait de la faible complexité et du faible surcoût en taille de code par rapport au format de base, par exemple EXI ou Fast Infoset. Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe une succession de prédictions correctes, on effectue, pour chaque item dudit ensemble d'items : - une étape de détermination s'il existe au moins une prédiction applicable et - si oui, une étape de détermination si une dite prédiction applicable est correcte. Selon des caractéristiques particulières, pour chaque item dudit ensemble d'items, s'il existe au moins une prédiction applicable et si aucune prédiction applicable n'est correcte, on code la structure dudit item, on code le nombre de prédictions correctes successives et on réinitialise le nombre de prédictions correctes successives. Selon des caractéristiques particulières, pour chaque item dudit ensemble d'items, s'il n'existe pas de prédiction applicable, on code la structure dudit item sans réinitialiser le nombre de prédictions correctes successives. Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, pour chaque item dudit ensemble d'items, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, on modifie ladite prédiction. Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, pour chaque item dudit ensemble d'items, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, il n'existe pas de prédiction applicable pour ledit item. Selon des caractéristiques particulières, pour chaque item dudit ensemble d'items, s'il existe une pluralité de prédictions applicables et si l'une des prédictions applicables est correcte, on code un identifiant de la prédiction applicable correcte.

Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe une succession de prédictions correctes pour des items dudit ensemble d'items du document, on met en oeuvre au moins une prédiction invariante pour lesdits items de l'ensemble des items de ladite partie de l'ensemble d'items du document.

Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus comporte une étape de mise à jour d'au moins une prédiction en fonction des items du document. Les prédictions sont ainsi plus adaptées au document. Grâce à chacune de ces dispositions, le nombre d'items codés par l'intermédiaire du nombre de prédictions correctes successives est augmenté. Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus, comporte, en outre, si une partie des items de l'ensemble d'items du document possède des valeurs associées, une étape de codage des dites valeurs associées à l'ensemble d'items du document. Ce codage est efficace car les valeurs associées sont plus rarement correctement prédites que les structures des éléments, notamment XML. Selon des caractéristiques particulières, au cours de l'étape de codage de valeurs associées, on effectue une étape de mémorisation des valeurs associées à ladite partie de l'ensemble d'items du document. Selon des caractéristiques particulières, au cours de l'étape de codage, pour chaque prédiction correcte, on code et on stocke des informations qui ne sont pas prédites dans une mémoire tampon. Typiquement, la valeur d'un événement de contenu textuel ou d'un attribut peut ne pas être prédite correctement, auquel cas on code ces informations, par exemple, suivant le codage classique EXI, dans une mémoire tampon, ou buffer . Les informations en mémoire tampon sont ici uniquement des informations codées, ce qui n'induit donc pas de réel surcoût en termes d'espace mémoire occupé. Au lieu d'écrire ces informations dans le flux codé, on les écrit dans un buffer dont le contenu est, ultérieurement, copié dans le flux codé. Selon des caractéristiques particulières, au cours de l'étape de codage, on détermine si la taille de la mémoire tampon est suffisante pour stocker les nouvelles données codées et, si non, on code les données stockées dans la mémoire tampon et le nombre de prédictions correctes successives. La taille de la mémoire tampon peut être fonction de la méthode de stockage sous- jacente. Ainsi, s'il s'agit d'un envoi de données par un protocole tel que TCP/IP, on peut déterminer la taille du buffer en fonction de la taille des paquets IP (acronyme de Internet Protocol pour protocole internet). On peut noter que cette taille de mémoire tampon peut être modifiée à tout moment par le codeur. La gestion de la mémoire tampon est ainsi optimisée. Selon des caractéristiques particulières, au cours de l'étape de codage, on met en oeuvre un nombre maximum de prédictions correctes et lorsque le nombre de prédictions correctes successives atteint ledit nombre maximum, on code ledit nombre maximum. Grâce à ces dispositions, on limite le nombre de données binaires, ou bits, nécessaires pour coder le nombre de prédictions correctes successives 10 au nombre de bits nécessaires pour coder ce nombre maximum. Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus, comporte une étape de mise à jour dudit nombre maximum en fonction du nombre de fois où ce nombre maximum est atteint. 15 Grâce à ces dispositions, le nombre de bits de codage du nombre de prédictions correctes successives est dynamique et donc adapté au document. Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe une succession de prédictions correctes pour des items successifs d'au moins un ensemble d'items du document, on effectue, d'une 20 part, une prédiction de l'indexation des valeurs des items et, d'autre part, une prédiction de structure des items. Selon des caractéristiques particulières, ledit document structuré est en langage XML. Selon des caractéristiques particulières; au cours de l'étape de 25 codage, on code des données au format Efficient XML, chaque prédiction étant faite en fonction d'une grammaire EXI (acronyme de Efficient XML Interchange pour interchange XML efficace). Selon des caractéristiques particulières, au cours de l'étape de codage, on code des données au format Fast Infoset, chaque prédiction étant 30 effectuée en fonction de tables Fast Infioset. Selon un deuxième aspect, la présente invention vise un procédé de décodage d'un document structuré, caractérisé en ce qu'il comporte : - une étape de décodage d'un nombre de prédictions successives correctes, - une étape de prédiction d'information structure pour chaque item du document correctement prédit, en mettant en oeuvre ledit nombre de prédictions correctes successives et - une étape de décodage d'information structurelle d'un événement du document non prédit. Selon des caractéristiques particulières, au cours de l'étape de décodage de la valeur d'un item du document correctement prédit, on détermine s'il existe une pluralité de prédictions applicables et, si oui, on détermine si un identifiant de prédiction a été codé et, si oui, on décode ledit item en fonction de la prédiction identifiée par ledit identifiant. Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, on modifie ladite prédiction.

Selon des caractéristiques particulières, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, il n'existe pas de prédiction applicable pour ledit item. Selon des caractéristiques particulières, au cours de l'étape de décodage du nombre de prédictions successives correctes, on met en oeuvre un nombre maximum de prédictions correctes et en ce qu'il comporte une étape de mise à jour dudit nombre maximum en fonction du nombre de fois où ce nombre maximum est atteint.

Selon des caractéristiques particulières, le procédé de décodage objet de la présente invention, tel que succinctement exposé ci-dessus, comporte une étape de décodage de la valeur de chaque item du document correctement prédit, au cours de laquelle on effectue, d'une part, une prédiction de l'indexation des valeurs des items et, d'autre part, une prédiction de structure des items. La présente invention vise, selon un troisième aspect, un dispositif de codage d'un document structuré, caractérisé en ce qu'il comporte : - un moyen de détermination s'il existe une succession de prédictions correctes pour des items d'un ensemble d'items du document et - un moyen de codage adapté, si le résultat de ladite étape de détermination est positif, à coder le nombre de prédictions correctes successives. La présente invention vise, selon un quatrième aspect, un dispositif de décodage d'un document structuré, caractérisé en ce qu'il comporte : - un moyen de décodage d'un nombre de prédictions successives correctes, - un moyen de prédiction d'information structurelle pour chaque item du document correctement prédit en mettant en oeuvre ledit nombre de prédictions correctes successives et - un moyen de décodage d'information structurelle d'un événement du document non prédit. Selon un cinquième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre d'un procédé objet de la présente invention tel que succinctement exposé ci-dessus. Selon un sixième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé objet de la présente invention tel que succinctement exposé ci-dessus.

Les avantages, buts et caractéristiques particulières de ce dispositif, de ce programme et de ce support d'information étant similaires à ceux du procédé tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexes, dans lesquels : - les figures 1 à 3 représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé de codage objet de la présente invention, - les figures 4 et 5 représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé de décodage objet de la présente invention, - la figure 6 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention, - la figure 7 représente, sous forme d'un logigramme, des étapes mises en oeuvre dans des modes de réalisation simplifiés des procédés de codage et de décodage objets de la présente invention et - la figure 8 représente, schématiquement, des données codées en mettant en oeuvre un mode de réalisation particulier du procédé de codage objet de la présente invention. On observe, en figure 7, qu'un mode de réalisation particulier du procédé de codage d'un document structuré comporte, au moins : - une étape 705 de détermination s'il existe une succession de prédictions correctes pour des items d'un ensemble d'items du document et - si le résultat de ladite étape de détermination est positif, une étape 710 de codage du nombre de prédictions correctes successives. Puis, au cours d'une étape 715, on effectue le codage des éventuelles valeurs des items correctement prédits et de codage d'information structurelle et d'éventuelles valeurs d'items non prédit.

Après une étape 720 de transmission des données codées, dans un mode de réalisation particulier du procédé de décodage objet de la présente invention, on effectue au moins : - une étape 725 de décodage d'un nombre de prédictions successives correctes, - une étape 730 de prédiction d'information structurelle pour chaque item du document correctement prédit en mettant en oeuvre ledit nombre de prédictions correctes successives et - une étape 735 de décodage d'information structurelle de chaque item du document non prédit. Dans un but explicatif, on décrit d'abord, ci-après, un exemple de codage des données XML suivantes : <list> <person> <firstName>John</firstName> <IastName>Smith</IastName> <city>London</city> </person> <person> <firstName>Mary</firstName> <IastName>W esson</IastName> <city>Plymouth</city> </person> </Iist> Après avoir traité le premier élément person , l'état des grammaires pour les différents éléments rencontrés est le suivant : Iist grammar SE person 0 EE 1 SE* 2.0 CH 2.1 person grammar SE city 0 SE firstName 1 SE lastName 2 19 EE 3 SE* 4.0 CH 4.1 firstName grammar 0 CH EE 1 SE* 2.0 CH 2.1 IastName grammar 0 CH EE 1 SE* 2.0 CH 2.1 city grammar 0 CH EE 1 SE* 2.0 CH 2.1 Lors du traitement du premier élément: person , on a associé 20 chaque production d'un item, nommé ITEM_A , à la production de l'item qui suit ITEM_A . Cela signifie que l'on a les associations suivantes : Production courante Production suivante Iist grammar : SE person persan grammar : SE firstName person grammar : SE firstName firstName grammar : CH 25 firstName grammar : CH firstName grammar : EE firstName grammar : EE persan grammar : SE lastName person grammar : SE lastName lastName grammar : CH lastName grammar : CH lastName grammar : EE lastName grammar : EE persan grammar : SE city 30 person grammar : SE city city grammar : CH city grammar : CH city grammar : EE city grammar : EE persan grammar : EE 10 15 person grammar : EE * (pas de prédiction disponible) Lorsque l'on traite le deuxième élément person , on détermine si le contenu de cet élément est conforme aux prédictions réalisées sur les productions suivantes. On commence donc par déterminer si, après Iist: SE person , on utilise la production person : SE firstName . C'est ici le cas. On incrémenter donc le compteur de prédictions correctes successives, qui vaut alors 1 . Selon les associations effectuées, on doit alors utiliser la production firstName : CH . Là encore, c'est bien le cas, l'événement suivant étant un événement de contenu textuel dont la valeur est Mary . Le compteur de prédictions correctes successives passe à 2 , et l'on code la valeur Mary de la même manière qu'on le ferait avec le codage EXI, mais au lieu de l'écrire directement dans le flux codé on l'écrit dans une mémoire tampon, ou buffer , le contenu de ce buffer étant par la suite (en fin de séquence de prédiction, c'est-à-dire si le maximum de bonnes prédictions est atteint ou si une mauvaise prédiction est rencontrée) copié dans le flux codé. Par rapport à un codage EXI classique, le contexte est exactement le même, et le codage de la valeur Mary dans le buffer est identique à celui de cette même valeur dans le flux codé dans le cas d'un codage EXI. Il convient de remarquer que l'événement, en lui-même, n'a pas besoin d'être mémorisé dans le buffer, c'est uniquement une donnée codée qui l'est. Il n'y a notamment pas besoin de conserver des informations hiérarchiques, par exemple l'information que cet événement est l'enfant de l'événement début d'élément person . Les structures du premier et du deuxième élément person étant identiques, les prédictions sont toujours correctes, et on pourrait donc incrémenter le compteur jusqu'à la fin de l'élément. Toutefois, afin de coder sur un nombre de bits adéquat le nombre de prédictions correctes successives, on se fixe préliminairement un nombre maximum de prédictions correctes successives à décompter, par exemple huit. Cela signifie que l'on sait, au départ, que le nombre de prédictions correctes successives décomptées n'excédera pas 8 et pourra donc être codé en trois (car 8 = 23) valeurs binaires, ou bits. Si peu de prédictions successives sont correctes, on ne perd donc que peu de bits à chaque fois (si on a trois prédictions correctes successives, on code 3 sur trois bits alors que, si le nombre maximum de prédictions correctes successives est 256, on code 3 en huit bits). Ici, le compteur de prédictions correctes successives atteint la valeur 8 avec la prédiction de la production person : SE city . On code alors le fait que l'on a atteint le nombre maximum de prédictions, puis l'on augmente ce nombre, par exemple avec la valeur 16 . Si, par la suite, on atteint ce maximum, on pourra l'augmenter de nouveau. Un seuil maximal pourra être fixé, par exemple 256 , de manière à toujours coder les prédictions sur un octet au maximum. Si au contraire le nombre maximal n'est jamais atteint, il est possible de le diminuer. Quand on arrive à la prédiction de person : SE city , on code donc le fait que l'on a atteint le nombre maximum de prédictions, puis l'on copie le contenu du buffer de données codées vers le flux codé (ici, le buffer contient les valeurs Mary et Wesson ). On recommence alors les mêmes étapes, le compteur de prédictions correctes successives étant remis à 0 . Quand on arrive à la fin du document, on passe d'un item person : EE à un item list : EE . Cette transition n'étant pas correctement prédite (c'est la première fois qu'elle se produit), on code : - le nombre courant de prédictions correctes successives (la valeur courante du compteur), - puis le contenu du buffer, et - enfin l'événement qui n'a pas pu être prédit, selon un codage EXI classique, par exemple code de la production utilisée et éventuelles informations complémentaires (ici, il s'agit d'une fin d'élément, et il n'y a donc pas d'information complémentaire). On présente une illustration du flux encodé tel que décrit ci-dessus à la figure 8, en omettant les données accessoires bien connues de l'homme du métier. Dans cette figure 8 : - le premier bloc de données 805, représenté en haut de la figure 8, représente la signification d'un flux binaire, qui est identique au codage EXI du fait de l'absence de prédiction disponible, - le deuxième bloc de données 810 comporte, d'abord, un nombre 815 de prédictions correctes successives N_PC égal à 8, codé en binaire par 1000 , puis une valeur d'item Mary 820 correspondant au champ CH firstName et une valeur d'item Wesson 825 correspondant au champ CHIastName, les valeurs 820 et 825 étant stockées en mode compressé, - le troisième bloc de données 830 comporte, d'abord, un nombre 835 de prédictions successives N_PC égal à 3, codé en binaire par 0011 , puis une valeur d'item Plymouth 840 correspondant au champ CH city et des symboles 01 correspondant aux champs EE(list) et ED, les valeurs 840 et 845 étant stockées en mode compressé. En ce qui concerne la construction des prédictions, le module de prédiction se divise en deux parties : - un module de collecte de données statistiques permettant la prédiction et - un module de prédiction pour un item XML proprement dit. Les données statistiques peuvent être collectées dans un premier temps ou par l'intermédiaire du codage de données XML similaires aux données à coder. Ces données statistiques peuvent aussi être initialisées à partir d'un schéma XML. Dans le cadre d'un mode préféré d'implémentation, on se limite à récupérer les données statistiques au fur et à mesure du codage des données XML. Le principal avantage est un coût très faible en termes de complexité de programme et de temps de traitement tout en conservant des performances très intéressantes en termes de compression. Les données statistiques exactes à collecter dépendent du modèle de prédiction. Différents systèmes de prédictions sont possibles, plus ou moins complexes. On peut dériver certains systèmes des méthodes de prédiction de branche étudiées pour les calculateurs (http://en.wikipedia.org/wiki/ Branch_prediction). Ces différentes méthodes s'appuient sur un historique qui peut contenir : - les N items précédemment codés, - les P éléments XML parents de l'item à coder et - les M occurrences passées d'un même item.

Le mode de réalisation préféré s'appuie sur un système qui met en oeuvre les moyens utilisés pour effectuer la compression XML binaire (tables Fast Infoset, grammaires EXI). Pour améliorer l'efficacité de ce système, on peut ajouter, au module de prédiction, une gestion des prédictions fausses.

Lorsque les prédictions tirées à partir d'un item sont souvent fausses, on peut alors décider de : - ne pas produire de prédiction et/ou - produire une prédiction comportant plusieurs productions avec différentes probabilités, Dans ces deux cas, la solution est d'envoyer, dans le flux binaire, un code permettant de récupérer la production de l'item proprement dit. Lorsqu'aucune prédiction n'est disponible, le code est exactement celui généré par le codage standard (code de la production par EXI ou code de l'événement Fast Infoset). Lorsque plusieurs possibilités de productions sont prédites, on peut obtenir le code à partir d'un codage de Huffman basé sur les différentes probabilités des prédictions. On ne décrira pas, dans la suite de la description, ce mode de réalisation particulier. Cependant, l'homme du métier n'aura aucune difficulté à adapter les procédés de codage (figure 1) et de décodage (figure 4) à ce mode de réalisation particulier. Dans un mode de réalisation simple, on affecte la même probabilité à chaque possibilité de production, ce qui permet de ne pas avoir à calculer les probabilités des productions ni à calculer dynamiquement les codes correspondants à chaque production. Dans un mode de réalisation simple, on se base uniquement sur l'item précédent (N=1) et sur une seule occurrence de l'item (M=1), généralement la dernière occurrence. On ne prend pas en compte directement les parents d'un item à coder (P=0). On présente ci-dessous l'intégration du module de prédiction à EXI et Fast Infoset. En ce qui concerne le module de prédiction EXI, l'intégration d'un moyen de prédiction dans EXI peut se faire de manière simple comme suit : - on code l'item de type B après avoir codé l'item précédent de type A, - pour coder l'item de type B, on récupère sa production B correspondante. Cette production B permet de coder l'item de type B de manière non ambiguë, - on peut alors relier la production A de l'item A à la production B.

Lors du codage d'un nouvel item A, on récupère la production A qui permet de prédire l'utilisation de la production B, c'est-à-dire le codage d'un nouvel item de type B, - cette liaison peut être faite à partir d'un schéma ou de données précédemment codées. Cette liaison peut être définie une fois pour toute (la première fois ou par avance). Cette rnéthode permet notamment de réduire le coût du codage en éliminant toute gestion des prédictions lors du codage. Dans un mode de réalisation préféré, cette liaison est mise à jour à chaque utilisation de la production de l'item A. On note que cette méthode ne nécessite pas de pré-connaissance du document à coder, ni schéma ni document(s) équivalent(s) et s'adapte rapidement au document à coder. En ce qui concerne l'absence de prédiction, on note qu'elle intervient principalement dans les deux cas suivants: - lorsqu'il n'y a pas assez d'informations d'historique obtenues : ce cas est fréquent au début du codage d'un document, notamment en présence de la première occurrence d'un élément, - lorsqu'une prédiction est trop souvent erronée pour être utilisée : ce cas se produit lorsqu'une grande variabilité est observée après une production donnée. Par exemple, certains éléments peuvent avoir un unique élément fils dont le nom varie fréquemment (équivalent à la contrainte xs:choice du langage de schéma XML Schema). Pour tenir compte de ce deuxième cas, on calcule une opacité d'une production en fonction d'un taux minimum de prédiction correcte. Cette opacité est principalement intéressante lorsque le moyen de prédiction se base sur un historique relativement faible et permet de pallier les défauts de prédiction avec une méthode peu coûteuse. On note que la détermination de l'opacité nécessite, pour le codeur et pour le décodeur, de conserver le nombre de prédictions correctes et le nombre de prédictions incorrectes.

On note qu'une série de prédictions peut être suivie par une série d'absence de prédictions, en cas de nouvel item non connu ou d'opacité. Dans ce cas, les productions non prédites sont codées dans les données stockées, ce qui permet un algorithme de décodage très simple (voir figure 4).

La prédiction permet de prédire des enchaînements d'items à l'intérieur d'un élément non encore rencontré. Dans l'exemple suivant : <root> <a> <b> </b> <c> </c> </a> <d > < b> </ b> <c> </c> </d > </root> En fonction du mode de réalisation, la prédiction peut prédire correctement comme suit (sont soulignées les prédictions correctes) : <root> <a><b></b><c></c></a,> <d><b></b><c></c></d,> <e> <b> </b> <c> </c> </e;> </root> Prédictions SE(b) ---> EE et SE(c) -+ EE <root> <a><b></b><c></c></a:> <d><b></b><c></c></d:> <e><b></b><c></c></e:> </root> Prédictions SE(b) -> EE(b) -* SE(c) -+ EE(c) -* EE La deuxième variante s'appuie sur le fait que : - une prédiction existe entre EE(b) et SE(c), - l'élément d est rencontré pour la première fois et - dans ce cas, on utilise la prédiction EE(b) -~ SE(c) même si elle n'a pas été validée dans le cadre de l'élément d. Dans ce cas particulier, on peut noter que la prédiction débute pour le deuxième élément 'b' et qu'elle s'arrête à la fin des données (noeud 'roof): en effet, aucune erreur de prédiction n'apparaît. On peut aussi noter que certains items n'ont aucune prédiction (passage de EE(d) à SE(e) par exemple). Dans ce cas, on n'incrémente pas le compteur de prédictions correctes et on utilise le code de la production correspondant à l'item dans les données stockées. Un cas particulier se présentant fréquernment est le cas d'éléments se répétant, comme dans les exemples suivant (sont soulignées les prédictions correctes et mises entre parenthèses les prédictions incorrectes): <root> <a><b></b></a> <a><b></b></a> <a><b></b></a> <a><b></b></a> <a><b></b></a> (</root>) <root> <a><b></b></a> <a><b></b></a> (</root>) Ces deux exemples mettent en lumière les points suivants : - il y a une prédiction de répétition de l'élément a et c à partir de la troisième occurrence de l'élément et - la fin de la répétition est interprétée comme une erreur de prédiction. Cette méthode permet de ne pas gérer la prédiction des répétitions différemment des autres cas de prédictions. On peut noter que cette méthode marche particulièrement bien pour des cardinalités importantes et marche moins efficacement pour des petites cardinalités (2, typiquement). La gestion d'erreur de prédiction (opacité ou prédictions multiples) permet alors de circonvenir ce cas particulier. Un autre mode de réalisation pour une bonne gestion des répétitions consiste à conserver un historique des occurrences passées (M=3 par exemple). Cet historique permet de déterminer s'il y a répétition d'un élément, auquel cas le module de prédiction définit deux ou plusieurs prédictions possibles et on incrémente le compteur de prédictions correctes successives tout en codant directement l'index de la prédiction correcte dans les données stockées. Un raffinement supplémentaire de ce mode de réalisation est de conserver le nombre de répétition passé permettant de prédire ainsi le nombre exact de répétition. On note que ces raffinernents sont particulièrement intéressants lorsque des erreurs se produisent et ne sont pas intéressants lorsqu'un moyen de prédiction simple est suffisant. De ce fait, on peut mettre en place ce système de collecte de statistiques plus coûteux uniquement sur les productions le nécessitant, c'est-à-dire les productions opaques. Dans un mode de réalisation, on collecte le nombre de prédictions correctes et le nombre de prédictions incorrectes pour chaque production. On marque la production comme opaque lorsque le nombre de prédictions correctes est insuffisant, et on commence à collecter des statistiques plus importantes pour cette production, par exemple en conservant un historique des occurrences passées (M=3). Cette collecte amène à une prédiction potentiellement plus efficace. On limite ainsi la collecte des statistiques aux productions pour lesquelles la prédiction est difficile, ce qui limite le surcoût de traitemeni.. On note que les règles de changement de prédiction doivent être partagées par le codeur et le décodeur.

En ce qui concerne le module de prédiction Fast Infoset, on se base sur une table d'indexation des éléments qui coni:ient, par défaut, une relation entre un index et un nom qualifié d'élément. On intègre à cette relation des données permettant la prédiction des éléments et attributs à venir. On peut aisément augmenter ces données pour prédire les fins d'éléments et noeuds textes. Ainsi, on obtient un moyen de prédiction qui s'intègre facilement à Fast Infoset. Les différents algorithmes présentés ultérieurement sont plus particulièrement dédiés à EXI mais s'adaptent aisément à Fast Infoset. On va maintenant décrire, en regard de la figure 1, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé de codage objet de la présente invention. Le codage débute par une étape 100 d'obtention de données XML à traiter. On traite chaque item des données XML de manière séquentielle, selon une itération passant par une étape 105 au cours de laquelle on détermine si tous les items XML sont traités et, si ce n'est pas le cas, une étape 110 au cours de laquelle on obtient l'item suivant. Lorsque tous les items XML sont traités, le processus de codage s'achève, au cours d'une étape 185.

Pour chaque item, le traitement débute, au cours d'une étape 115, par la détermination si au moins une prédiction est disponible ou applicable. Par exemple, aucune prédiction n'est disponible s'il n'y a pas de statistique ou si la production considérée est opaque. Inversement, plusieurs prédictions peuvent être applicables à la production associée à l'item considéré. Chaque prédiction disponible est déterminée par l'un des moyens décrits ci-dessus. On note que, dans des modes de réalisation, au cours de l'étape 115, on met en oeuvre au moins une prédiction invariante pour l'ensemble des items de ladite partie de l'ensemble d'items du document. Si au moins une prédiction est disponible, on détermine, au cours d'une étape 120, si cette prédiction disponible est correcte. Cette étape s'effectue généralement en comparant directement chaque prédiction obtenue à l'item à coder de la façon suivante : - comparaison des types d'événement, - comparaison des noms d'item (s'il en a un), - si l'item a une valeur, comparaison de l'indexation, si elle est disponible. Cette comparaison détermine si la prédiction définit un état d'indexation. Si tel est le cas, on détermine si la prédiction d'indexation est correcte ou non (voir plus bas, la partie sur le codage des valeurs et le stockage des données).

Dans le cas d'EXI, on peut aussi utiliser une deuxième méthode : récupérer la production de l'item à coder (fonction nécessaire au codage lorsqu'aucune prédiction n'est disponible) et comparer la production prédite et la production réelle. La première méthode, simple, permet notamment lorsque le moyen de prédiction est suffisamment juste, des gains en terme de temps de traitement comparativement à la deuxième méthode. Si une prédiction est correcte, on détermine, au cours d'une étape 122, si une seule prédiction était disponible. Si non, au cours d'une étape 124, on code un identifiant de la prédiction correcte parmi les prédictions disponibles. Si le résultat de l'étape 122 est positif, ou à la suite de l'étape 124, on incrémente le nombre de prédictions correctes, N_PC, lors d'une étape 125, puis on détermine, au cours d'une étape '135, s'il faut effectuer le codage/l'émission du nombre de prédictions correctes par l'intermédiaire d'un symbole de prédiction dans le flux binaire. On peut être amené à effectuer ce codage/l'émission pour plusieurs raisons : - la taille des données stockées lors de l'une des étapes 160 et 175 d'itérations précédentes devient trop importante pour le codeur, - le nombre de prédictions correctes atteint un nombre suffisamment important pour coder cette information dans le flux binaire (voir, plus bas, la partie sur le codage des symboles). Dans le cas où l'on souhaite coder le symbole de prédiction, on code ce symbole de prédiction au cours d'une étape 140 (décrite avec plus de précision en regard de la figure 2), ainsi que le nornbre de prédictions correctes successives N PC obtenu. On envoie ensuite les données stockées aux étapes précédentes dans le flux binaire (voir la partie sur le codage de symboles), au cours d'une étape 145. Le buffer de stockage des données est alors vide et on réinitialise N_PC à 0 . A la suite de l'étape 145, ou dans le cas où il n'est pas nécessaire d'effectuer l'émission du symbole, on met à jour les données servant à déterminer la prédiction, lors d'une étape 150. Cette étape 150 dépend du moyen mis en oeuvre pour la prédiction. Il peut par exemple s'agir de mettre à jour les statistiques de l'opacité, c'est-à-dire le nombre de prédictions correctes (étape 150) et le nombre de prédictions incorrectes (étape 180) pour la production associée à l'item considéré. Dans le cas particulier d'un moyen de prédiction avec un historique d'un item et avec gestion de l'opacité, on incrémente uniquement le cornpteur de prédictions correctes de la production associée à l'item considéré, lors de l'étape 150. Dans le cas particulier d'un moyen de prédiction avec un historique d'un item et sans opacité, aucune mise à jour n'est nécessaire à l'étape 150. L'étape de mise à jour 150 peut aussi consister à modifier la prédiction. Elle est, dans ce cas, préférentiellement effectuée uniquement si le nombre de fois où la prédiction est incorrecte est supérieur à un nombre prédéterminé, éventuellement fonction du nombre de fois où la prédiction est correcte. On augmente ainsi la pertinence de la prédiction : le nombre d'items codés par l'intermédiaire du nombre de prédictions correctes successives est augmenté. Ainsi, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, étape 115, on met en oeuvre, pour une production correspondant à l'item considéré, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, on considère la production comme opaque. On note que le nombre de prédiction incorrecte comparé à la valeur prédéterminée est éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, par le biais d'un taux de prédiction incorrecte sur le nombre de prédiction total. Comme on l'a vu, pour un item associé à une production opaque, on considère, au cours de l'étape 115, qu'il n'existe pas de prédiction applicable. Dans le cas où on détermine, au cours de l'étape 120, qu'aucune prédiction disponible n'est correcte, on passe à l'étape 165 au cours de laquelle on code le symbole de prédiction (codage décrit avec plus de précision en regard de la figure 2). Ce symbole inclut obligatoirement l'information du nombre exact de prédictions correctes (N_PC) rencontrées avant le dernier item. Il peut aussi inclure le fait que l'item suivant les N_PC items successifs correctement prédits n'a pas été correctement prédit. Au niveau du décodeur, il faudra lire le code de l'item (production EXI ou code Fast Infoset) directement dans le flux. A la suite du codage et de l'envoi de ce symbole, on envoie les données stockées lors des codages des items précédents, au cours d'une étape 170. Le buffer de stockage des données est alors vide et on réinitialise N PC à 0 . Il reste ensuite à récupérer le code réel de l'item (via la production de l'item à coder pour EXI ou par l'intermédiaire du type d'événement et les différentes tables d'indexation pour Fast Infoset). Puis, au cours d'une étape 175, on code l'item et on envoie le code obtenu directement dans le flux binaire.

Dans le cas où aucune prédiction n'est disponible à l'étape 115, on passe directement à l'étape 175. On récupère le code de l'item à coder. L'envoi du code correspondant à l'item est effectué lorsque le nombre de prédictions correctes successives N_PC est égal à zéro. Sinon, le code est stocké dans le buffer des données pour être envoyé ultérieurement (lors de l'une des étapes 145 ou 170). Dans le cas particulier du moyen de prédiction décrit auparavant (historique avec détection d'opacité), on met à jour la prédiction à partir des informations de codage de l'étape 175 (production récupérée à l'étape 175 par EXI ou entrée de table d'indexation pour Fast Infoset) ainsi que les statistiques d'opacité de la production de l'item précédent. On met ensuite à jour, au cours d'une étape 180, les données de prédiction de manière similaire à l'étape 150. Dans le cas particulier d'un moyen de prédiction avec un historique d'un item et avec gestion de l'opacité, on incrémente uniquement le compteur de prédictions incorrectes de la production associée à l'item considéré, lors de l'étape 180. Une fois les données de prédiction mises à jour au cours de l'une des étapes 150 ou 180, on détermine si l'item XML possède une valeur (item de type attribut, noeud texte, commentaire, PI...) au cours d'une étape 155. S'il n'y a pas de valeur, on retourne à l'étape 105. Sinon, on code la valeur au cours d'une étape 160, comme détaillé en regard de la figure 3, avant de retourner à l'étape 105. Le codage des symboles de prédiction est décrit en regard de la figure 2. Ce codage est effectué soit au cours de l'étape 140, soit au cours de l'étape 165. Le symbole contient principalement l'information du nombre de prédictions correctes. Il peut aussi inclure une information sur la validité de la prédiction qui suivra les N_PC prédictions successives correctes. Typiquement, certains symboles peuvent déclarer que la prédiction suivant les N_PC prédictions successives correctes est incorrecte.

Comme expliqué auparavant, on fixe un nombre de prédictions correctes successives maximum N_MAX , ce nombre maximum pouvant s'adapter à la régularité des données XML codées comme exposé par ailleurs.

Ce nombre maximum de prédictions correctes successives permet de coder N_PC relativement à ce nombre maximum, ce qui permet une représentation assez compacte de cette valeur. Dans un mode de réalisation, on peut utiliser un codage de Huffman adaptatif. La table de Huffman inclut, dans ce cas., N_MAX symboles. Lorsque N_MAX est augmenté ou diminué (pour tenir compte de la régularité des données XML), la table de Huffman s'agrandit ou diminue. Chaque symbole de la table de Huffman correspond à une valeur possible de N_PC. Pour chaque valeur N_PC codée, on met à jour la probabilité de la valeur N_PC et on recalcule les codes associés à chaque valeur. Comme certains symboles ont, au départ, une probabilité nulle, on peut : - ajouter un symbole NOUVEAU_SYMBOLE dans la table de Huffman qui indique qu'une nouvelle valeur N_PC est codée. A la suite de ce symbole, on code la valeur relativement à N_MAX ou - définir une taille de code maximum par l'intermédiaire de la méthode Length-limited Huffman coding (codage de Huffman à longueur limitée . Cette approche nécessite la mise à jour continuelle de la table de Huffman alors qu'on peut remarquer que la répartition des valeurs de N_PC n'est pas uniforme. Ainsi les valeurs N_PC supérieures à 32 sont peu fréquentes et se répètent peu. De ce fait, pour diminuer la taille de la table de Huffman, on peut ne conserver des symboles que pour des valeurs inférieures à un seuil relativement faible, 24 ou 32 par exemple. La figure 2 présente une rnéthode relativement performante et moins 25 coûteuse que la méthode utilisant un principe de codage de Huffman adaptatif. Dans cette méthode, on définit tout d'abord cinq symboles : - PREDICTION_COURTE : N_PC compris entre 0 et 3, - PREDICTION_ MOYENNE : N_PC indexé compris entre 4 et 11, 30 - PREDICTION_GRANDE : N_PC indexé compris entre 12 et 27, - PREDICTION MAX : N PC égal à N MAX et - PREDICTION_LITTERALE : N_PC compris entre 4 et N_MAX. On définit aussi trois types de documents : - des documents très répétitifs : le module de prédiction est très performant et le symbole PREDICTION_MAX est très souvent utilisé, - des documents assez répétitifs : le module de prédiction est assez performant pour obtenir des prédictions assez grandes et les symboles PREDICTION MOYENNE, PREDICTION COURTE sont souvent utilisés et - des documents très variables : le module de prédiction est peu performant et le symbole PREDICTION_COURTE est majoritairement utilisé.

Pour chacun de ces documents, on définit une table de Huffman adaptée. Table de Huffman pour documents très répétitifs : - PREDICTION_COURTE : code 10 - PREDICTION_ MOYENNE : code 110 - PREDICTION GRANDE:: code 1110 - PREDICTION MAX : code 0 - PREDICTION LITTERALE : code 1111 Table de Huffman pour documents assez répétitifs : - PREDICTION_COURTE : code 10 - PREDICTION MOYENNE : code 0 - PREDICTION GRANDE : code 110 - PREDICTION MAX : code 1110 - PREDICTION LITTERALE : code 1111 Table de Huffman pour documents peu répétitifs : - PREDICTION_COURTE : code 0 - PREDICTION MOYENNE : code 10 - PREDICTION GRANDE : code 110 - PREDICTION MAX : code 1110 - PREDICTION LITTERALE : code 1111 Le choix de la table de Huffman s'effectue sur un critère statistique d'occurrence des différents symboles : - TEST OCC1 : Si OCCURRENCE(PREDICTION_MAX) > OCCURRENCE(PREDICTION_COURTE), document de type très répétitif - TEST 0002 : Si OCCURRENCE(PREDICTION_MOYENNE) > OCCURRENCE(PREDICTION_COURTE), document de type assez répétitif - sinon, document de type peu répétitif. La figure 2 présente une implémentation possible de l'algorithme. On commence par déterminer, au cours d'une étape 200, si le nombre de prédictions correctes successives N_PC est inférieur à une valeur prédéterminée N_C , typiquement égale à quatre. Si oui, au cours d'une étape 205, on effectue un codage de symbole de PREDICTION_COURTE en déterminant le type de document par l'intermédiaire du test TEST_OCC2. On code ensuite, au cours d'une étape 210, la valeur N_PC relativement à la valeur N_C. Par exemple, lorsque la valeur de N_C est égale à quatre, on code la valeur N PC sur deux bits. On peut ensuite éventuellement mettre à jour la valeur N MAX, au cours d'une étape 260 décrite ultérieurement. Si le nombre de prédictions successives correctes N_PC est supérieur ou égal à la valeur N_C, on détermine si la valeur N_PC est égale à la valeur N MAX, au cours d'une étape 215, après avoir décrémenté N_PC de la valeur N_C. Si oui, on code le symbole PREDICTION_MAX au cours d'une étape 220, en déterminant le type de documents par l'intermédiaire du test TEST_OCC1. On passe ensuite à une étape 260 de mise à jour de la valeur N MAX. Si la valeur N PC est différente de la valeur N MAX, on détermine, au cours d'une étape 225, si la valeur N_PC est indexée. La valeur N_PC est indexée si elle a déjà été codée dans le flux binaire et si cette valeur est suffisamment petite pour avoir une bonne probabilité de se répéter (valeur inférieure ou égale à 27 dans le mode de réalisation présenté). On note que l'on conserve à cet effet, une table d'indexation représentant chaque valeur déjà codée en correspondance avec un index.

Si cette valeur n'a pas été indexée, on indexe cette valeur et on code le symbole PREDICTION_LITTERAL.E dont le code est statique, c'est-à-dire le même pour les trois tables envisagées, au cours d'une étape 230. Puis, on code la valeur littérale relativement à la valeur N__MAX au cours d'une étape 235. On passe ensuite à une étape 260 de mise à jour de la valeur N_MAX. Si la valeur N_PC est indexée, on détermine si la valeur N_PC est supérieure à une valeur prédéterminée N__M (typiquement 12) au cours d'une étape 240. Si non, on code le symbole PREDICTION_GRANDE en déterminant le type de document par l'intermédiaire du test TEST_OCC1, au cours d'une étape 250. Si la valeur N_PC est inférieure ou égale à la valeur N_M, on code le symbole PREDICTION_MOYENNE en déterminant le type de document par l'intermédiaire des tests TEST OCC1 et TEST_OCC2 au cours d'une étape 245. Une fois le symbole codé, on récupère l'index de la valeur N_PC et on code cet index au cours d'une étape 255. On passe ensuite à l'étape 260 de mise à jour de la valeur N_MAX. La mise à jour de la valeur N_MAX, au cours de l'étape 260 peut consister à augmenter ou diminuer N_MAX. On peut augmenter N_MAX lorsque la valeur N_PC atteint cette valeur N__MAX. Typiquement, on multiplie par deux la valeur de N_MAX lorsque le symbole PREDICTION_MAX a été codé, au cours de l'étape 220. Au contraire, on diminue la valeur N_MAX lorsque le symbole PREDICTION_MAX est rarement codé. Cette valeur N_MAX n'ayant un impact que sur le codage littéral de N_PC, on peut réduire la valeur N_MAX après le codage d'un symbole PREDICTION_LITTERALE. Dans les faits, on peut effectuer cette diminution après plusieurs codages du symbole PREDICTION_LITTERALE qui ne sont pas entrecoupés par le codage d'un symbole PREDICTION_MAX. En ce qui concerne le codage des valeurs et le stockage des données, on décrit, ci-après, un processus de stockage des données qui peut être implémenté de plusieurs façons. On peut tout d'abord conserver une liste de valeurs (chaînes de caractères, production). On peut aussi conserver ces valeurs sous la forme d'un flux binaire codé stocké en mémoire. Dans ce cas, les valeurs stockées sont codées en utilisant le format standard (EXI ou Fast Infoset), le résultat de ce codage est ensuite stocké dans un buffer. Cette méthode est préférable car plus efficace en termes de temps de traitement et d'utilisation mémoire En termes de temps de traitement, on ajoute uniquement le surcoût de gestion d'un buffer qui peut être compensé par le fait que l'écriture des données s'effectue en un bloc, ce qui peut être préférable, par exemple dans le cas de l'écriture dans un fichier. En termes de gestion mémoire, le codage décrit permet, lorsque le buffer est trop grand, d'envoyer le code correspondant à la valeur N_PC courante puis les données stockées. Cela permet de borner la taille du buffer en contrepartie d'une légère perte de performance de compression. Cette dernière méthode de stockage présente néanmoins un désavantage potentiel : le flux binaire n'est pas toujours orienté octet mais peut alternativement être orienté bit. Dans ce dernier cas, le flux binaire envoyé et le flux binaire stocké ne sont pas forcément alignés de la même façon car on doit effectuer un choix d'alignement au début du stockage des données qui ne sera pas le même que celui du flux une fois le symbole de prédiction codé. Plusieurs méthodes sont alors possibles : - fixer l'alignement du buffer et, au moment de l'envoi des données, ajouter le nombre nécessaire de bits au flux binaire pour respecter l'alignement des données stockées (étant à noter que l'on peut, éventuellement, prédire l'alignement ou coder le symbole de prédiction en fonction de cet alignement), - décaler l'ensemble des données stockées du nombre de bits nécessaires au moment de l'envoi et - certaines données nécessitent parfois d'être alignées (les chaînes de caractères dans EXI par exemple lorsque le mode aligné-octet est utilisé) auquel cas on peut conserver sous forme non codé les données stockées jusqu'à obtenir une donnée nécessitant un alignement particulier.

Ce procédé de stockage des données est notamment intéressant car il permet des gains en temps de traitement et mémoire important : - un item SE ou EE correctement prédit n'est pas stocké en mémoire, - un item SE ou EE non correctement: prédit est conservé sous la forme compressée, ce qui est compact et n'a pas d'impact en termes de temps de traitement ou sous la forme d'une production EXI ou une référence à une table Fast Infoset, - on ne conserve d'un item attribut ou noeud texte correctement prédit que sa valeur, sous forme compressée ou non, - on ne conserve d'un item attribut ou noeud texte non correctement prédit que sa production/référence et sa valeur (sous forme compressée ou non). On décrit le procédé de stockage des valeurs en regard de la figure 3. En premier lieu, on détermine, au cours d'une étape 300, s'il est prédit que la valeur soit indexée. Si une prédiction existe, on code l'index de la valeur, au cours d'une étape 305. Deux variantes de réalisation de cette étape sont possibles : - lors de la détermination de prédiction au cours de l'étape 120, l'état d'indexation a été déterminé, auquel cas l'étape 305 est toujours opérée sur des valeurs qui possède un index ou - aucune détermination n'est effectuée lors de l'étape 120. Dans ce cas, l'étape 305 détermine si la valeur est indexée. Si c'est le cas, on code l'index au cours de cette étape 305. Si ce n'est pas le cas, on code l'index maximum de la table puis on code la valeur littérale. La première variante inclut des erreurs de prédictions possibles dues à une mauvaise prédiction de l'indexation. La deuxième variante gère les erreurs de prédiction dues à une mauvaise prédiction de l'indexation par l'intermédiaire d'un codage légèrement plus long de la chaîne de caractères. Une troisième variante possible est de séparer les prédictions de structure et d'indexation. De ce fait, pour le codage d'un attribut ou d'un noeud texte, une prédiction est éventuellement effectuée sur la structure de l'item et une autre prédiction est éventuellement effectuée sur l'état d'indexation. L'algorithme des figures 1 et 3 s'adaptent aisément à cette variante. Si, au cours de l'étape 300, on détermine qu'aucune prédiction n'est disponible, on détermine si la valeur est indexée au cours d'une étape 310 (cette information peut provenir du résultat de l'étape 120). Si la valeur est indexée, on code l'état indexé puis la valeur de l'index au cours d'une étape 315. Sinon, on code l'état non indexé puis la valeur littérale, au cours d'une étape 320.

Lorsque la valeur est codée à la suite cle l'une des étapes 305, 315 ou 320, on détermine si la valeur est à stocker au cours d'une étape 325. Le stockage s'applique lorsqu'au moins une prédiction correcte a été faite, c'est-à-dire lorsque N_PC est strictement supérieur à zéro. Si le stockage n'est pas nécessaire, les données codées sont envoyées directement au cours d'une étape 330 et l'algorithme de la figure 3 s'achève au cours d'une étape 355. Si le stockage est nécessaire, on détermine si la taille du buffer est suffisante au cours d'une étape 335. Si la taille du buffer est suffisante, on stocke les données codées dans le buffer au cours d'une étape 340 et l'algorithme de la figure 3 s'achève au cours de l'étape 355. Si ce n'est pas le cas, on code le symbole de prédiction, au cours d'une étape 345, de manière similaire à l'étape 140 puis on envoie les données stockées et la valeur codée, au cours d'une étape 350, de manière similaire à l'étape 145 èt l'algorithme de la figure 3 s'achève à l'étape 355.

Le décodeur comprend trois parties principales, un module de décodage des informations binaires, un module de prédiction et un module de mise en forme des informations décodées. Le principe du module de prédiction clu décodage est similaire au module de prédiction du codage. La différence principale est que le codeur 20 construit la prédiction sur : - des informations XML à coder et - des tests de prédiction (pour l'opacité notamment). Le décodeur construit la prédiction sur : - des informations XML. binaire décodées (production EXI ou 25 référence Fast Infoset), - des tests de prédiction : lorsqu'une prédiction n'est pas disponible ou est déclarée comme non conforme, le décodeur peut devoir déterminer cette non-conformité, par exemple dans le cas où le décodeur doit calculer l'opacité d'une production EXI. 30 Le module de décodage fonctionne de manière symétrique au codeur : le décodeur décode un nombre de prédictions correctes qui est décrémenté lorsqu'une prédiction est disponible. La fonction centrale du décodeur est donc d'effectuer la construction des prédictions de manière symétrique à l'encodeur et de décoder correctement les symboles indiquant le nombre de prédictions correctes. La figure 4 illustre une réalisation possible du procédé de décodage objet de la présente invention.

Le procédé débute par l'obtention du flux binaire, au cours d'une étape 400. Puis, on détermine si le flux a été entièrement décodé, au cours d'une étape 405. S'il reste des informations à décoder, on détermine, au cours d'une étape 410, si une prédiction est disponible. Si aucune prédiction n'est disponible, on décode le code de l'item dans le flux binaire au cours d'une étape 445 (code de production EXI ou index dans une table Fast Infoset). On met ensuite à jour les données de prédiction au cours d'une étape 450. Si on détermine, au cours de l'étape 410 qu'une prédiction est disponible, on décode un nombre de prédictions correctes successives, au cours d'une étape 412 et détermine si le nombre cle prédictions correctes N_PC est strictement supérieur à zéro, au cours d'une étape 415. Si tel est le cas, on récupère l'item à partir de la prédiction, au cours d'une étape 420, et on décrémente la valeur N_PC, au cours d'une étape 425. On met ensuite à jour les données de prédiction lors de l'étape 450 (opacité, historique...). Si la prédiction comporte plusieurs possibilités, la récupération de l'item à partir de la prédiction, au cours de l'étape 420, nécessite le décodage du code correspondant à la prédiction utilisée au codage. Dans le cas où la valeur N_PC est déterminée comme nulle au cours de l'étape 415, on décode un symbole de prédiction au cours d'une étape 430 permettant de mettre à jour une valeur pour N_PC (voir figure 5). Puis, au cours d'une étape 435, on détermine si la prédiction courante est correcte. Si oui, on applique la prédiction pour récupérer l'item, au cours de l'étape 420 et on décrémente la valeur de N_PC, au cours de l'étape 425. Si la prédiction est incorrecte, on décode le code de l'item directement dans le flux binaire, au cours de l'étape 445.

A la suite de l'étape 450, le type de l'item est connu. Au cours d'une étape 455, on détermine si l'item a une valeur associée à décoder (typiquement s'il s'agit d'un item attribut ou noeud texte). Si l'item n'a pas de valeur à décoder, toutes les informations concernant l'item sont disponibles, une application peut alors utiliser ces informations, par exemple par l'intermédiaire d'une API XML (SAX, PULL...), au cours d'une étape 475. Si le décodeur doit décoder une valeur pour l'item, on détermine s'il y a une prédiction d'indexation, au cours d'une étape 460. Si non, on décode l'état d'indexation dans le flux binaire, au cours d'une étape 465. Une fois l'état d'indexation connu ou s'il n'y a pas de prédiction d'indexation, on décode la valeur de l'item au cours d'une étape 470. On passe alors à l'étape d'utilisation des informations de l'item 475. Le procédé s'arrête, au cours d'une étape 480, lorsque l'étape 405 détermine que le flux binaire a été intégralement décodé. Le décodage du symbole de prédiction est illustré en figure 5. Au cours d'une étape 510, on obtient un symbole binaire dans le flux binaire. Ce symbole binaire correspond à un code dans une table de Huffman. On récupère ensuite la table de Huffman utilisée à l'état courant, au cours d'une étape 520.

Pour ce faire, on réutilise les tests d'occurrence TEST_OCC1 et TEST_OCC2 tels que présentés au niveau du codage. On traduit ensuite le symbole binaire en un symbole de prédiction, au cours de l'étape 520, et on met à jour les compteurs utilisés par les tests d'occurrence TEST_OCC et TEST_OCC2. On détermine ensuite le type de symbole de prédiction, par exemple en débutant par PREDICTION_MAX au cours d'une étape 530. S'il s'agit du symbole PREDICTION_MAX, on met à jour la valeur de N_PC à N_MAX, au cours d'une étape 540. S'il ne s'agit pas du symbole PREDICTION_MAX, on détermine s'il s'agit d'un symbole de type indexé (PREDICTION MOYENNE ou PREDICTION_GRANDE) ou de type littéral (PREDICTION_LITTERALE ou PREDICTION COURTE), au cours d'une étape 550. S'il s'agit d'un symbole de type indexé, on décode un index relativement à la table du symbole associé, au cours d'une étape 560, ce qui permet de récupérer la valeur exacte de N_PC. Sinon, on décode la valeur littérale de N_PC relativement à N_MAX dans le cas du symbole PREDICTION_LITTERALE ou relativement à N_C dans le cas du symbole PREDICTION_COURTE, au cours d'une étape 570.

A la suite de l'une des étapes 540, 560 et 570, on met éventuellement à jour la valeur de N_MAX, au cours d'une étape 580. Cette mise à jour est effectuée de manière similaire à la mise à jour effectuée lors du codage des symboles par le codeur. Le procédé de décodage se termine alors au cours d'une étape 590. On observe, en figure 6, un dispositif objet de la présente invention, ou codeur, 600 et différents périphériques adaptés à implémenter la présente invention. Dans le mode de réalisation illustré en figure 6, le dispositif 600 est un micro-ordinateur de type connu connecté, par le biais d'une carte d'entrée 604, à un moyen d'acquisition ou de stockage de données hiérarchisées organisées en une pluralité d'événement, par exemple au moins un document XML. Le dispositif 600 comporte une interface de communication 618 reliée à un réseau 634 apte à transmettre, en entrée, des données à coder ou à décoder et/ou, en sortie, des données codées ou décodées, par le dispositif. Le dispositif 600 comporte également un moyen de stockage 612, par exemple un disque dur, et un lecteur 614 de disquette 616. La disquette 616 et le moyen de stockage 612 peuvent contenir des données à coder ou à décoder, des données codées ou décodées et un programme informatique adapté à implémenter le procédé objet de la présente invention. Selon une variante, le programme permettant au dispositif de mettre en oeuvre la présente invention est stocké en mémoire morte ROM (acronyme de read only memory pour mémoire non réinscriptible) 606. Selon une autre variante, le programme est reçu par l'intermédiaire du réseau de communication 634 avant d'être stocké. Ce même dispositif 600 possède un écran 608 permettant de visualiser les données à coder ou décodées ou de servir d'interface avec l'utilisateur pour paramétrer certains modes d'exécution du dispositif 600, à l'aide d'un clavier 610 et/ou d'une souris par exemple.

Une unité centrale CPU (acronyme de central processing unit ) 603 exécute les instructions du programme informatique et de programmes nécessaires à son fonctionnement, par exemple un système d'exploitation. Lors de la mise sous tension du dispositif 600, les programmes stockés dans une mémoire non volatile, par exemple la mémoire morte 606, le disque dur 612 ou la disquette 616, sont transférés dans une mémoire vive RAM (acronyme de random access memory pour mémoire à accès aléatoire) 608 qui contiendra alors le code exécutable du programme implémentant le procédé objet de la présente invention ainsi que des registres pour mémoriser les variables nécessaires à sa mise en oeuvre. Bien entendu, la disquette 616 peut être remplacée par tout support d'information amovible, tel que disque compact, clé ou carte mémoire. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé de codage objet de la présente invention. Un bus de communication 662 permet la communication entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation, en figure 6, du bus 662 n'est pas limitative et notamment l'unité centrale 603 est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600.

Claims (1)

1. REVENDICATIONS1 - Procédé de codage d'un document structuré, caractérisé en ce qu'il comporte : - une étape (115 à 125, 705) de détermination s'il existe une succession de prédictions correctes pour des items d'un ensemble d'items du document et - si le résultat de ladite étape de détermination est positif, une étape (145, 170, 710) de codage du nombre de prédictions correctes successives. 2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape (115 à 125, 705) de détermination s'il existe une succession de prédictions correctes, on effectue, pour chaque item dudit ensemble d'items : - une étape (115) de détermination s'il existe au moins une prédiction applicable et - si oui, une étape (120) de détermination si une dite prédiction applicable est correcte. 3 û Procédé selon la revendication 2, caractérisé en ce que, pour chaque item dudit ensemble d'items, s'il existe au moins une prédiction applicable et si aucune prédiction applicable n'est correcte, on code la structure dudit item, on code le nombre de prédictions correctes successives et on réinitialise le nombre de prédictions correctes successives (140, 145). 4 û Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce que, pour chaque item dudit ensemble d'items, s'il n'existe pas de prédiction applicable, on code la structure dudit item sans réinitialiser le nombre de prédictions correctes successives (175). 5 û Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que, au cours de l'étape (115) cle détermination s'il existe au moins une prédiction applicable, pour chaque item dudit ensemble d'items, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre deprédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, on modifie ladite prédiction. 6 ù Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que, au cours de l'étape (115) de détermination s'il existe au moins une prédiction applicable, pour chaque item dudit ensemble d'items, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, il n'existe pas de prédiction applicable pour ledit item. 7 ù Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que, pour chaque item dudit ensemble d'items, s'il existe une pluralité de prédictions applicables et si l'une des prédictions applicables est correcte, on code un identifiant de la prédiction applicable correcte (124). 8 ù Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'étape (705) de détermination s'il existe une succession de prédictions correctes pour des items dudit ensemble d'items du document, on met en oeuvre au moins une prédiction invariante pour lesdits items de l'ensemble d'items du document. 9 ù Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte une étape (150, 180) de mise à jour d'au moins une prédiction en fonction des items du document. 10 ù Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comporte, en outre, si une partie des items de l'ensemble d'items du document possède des valeurs associées, une étape (160) de codage des dites valeurs associées à ladite partie de l'ensemble d'items du document. 11 ù Procédé selon la revendication 10, caractérisé en ce que, au cours de l'étape de codage (160) de valeurs associées, on effectue une étape de mémorisation des valeurs associées à ladite partie de l'ensemble d'items du document. 12 ù Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que, au cours de l'étape (710) de codage, pour chaque prédiction correcte, on code et on stocke des informations qui ne sont pas prédites dans une mémoire tampon. 13 ù Procédé selon la revendication 12, caractérisé en ce que, au cours de l'étape (710) de codage, on détermine si la taille de la mémoire tampon est suffisante pour stocker les nouvelles données codées et, si non, on code les données stockées dans la mémoire tampon et le nombre de prédictions correctes successives. 14 ù Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que, au cours de l'étape (200, à 260, 710) de codage, on met en oeuvre un nombre maximum de prédictions correctes et lorsque le nombre de prédictions correctes successives atteint ledit nombre maximum, on code ledit nombre maximum. 15 ù Procédé selon la revendication 14, caractérisé en ce qu'il comporte une étape (260) de mise à jour dudit nombre maximum en fonction du nombre de fois où ce nombre maximum est atteint. 16 ù Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que, au cours de l'étape (705) de détermination s'il existe une succession de prédictions correctes pour des items d'au moins un ensemble d'items du document, on effectue, d'une part, une prédiction de l'indexation des valeurs des items et, d'autre part, une prédiction de structure des items. 17 ù Procédé selon l'une quelconque des revendications 1 à 16, caractérisé en ce que ledit document structuré est en langage XML. 18 ù Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce que, au cours de l'étape de codage, on code des données au format Efficient XML, chaque prédiction étant faite en fonction d'une grammaire EXI (acronyme de Efficient XML Interchange pour interchange XML efficace). 19 ù Procédé selon l'une quelconque des revendications 1 à 18, caractérisé en ce que, au cours de l'étape (710) de codage, on code des données au format Fast Infoset, chaque prédiction étant effectuée en fonction de tables Fast Infoset. 20 - Procédé de décodage d'un document structuré, caractérisé en ce qu'il comporte : - une étape (725) de décodage d'un nombre de prédictions successives correctes, - une étape (730) de prédiction d'information structurelle pour chaque item du document correctement prédit en mettant en oeuvre ledit nombre de prédictions correctes successives et - une étape (735) de décodage d'information structurelle de chaque item du document non prédit. 21 û Procédé selon la revendication 20, caractérisé en ce que, au cours de l'étape (730) de décodage de la valeur d'un item du document correctement prédit, on détermine s'il existe une pluralité de prédictions applicables et, si oui, on détermine si un identifiant de prédiction a été codé et, si oui, on décode ledit item en fonction de la prédiction identifiée par ledit identifiant. 22 û Procédé selon la revendication 21, caractérisé en ce que, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, on modifie ladite prédiction. 23 û Procédé selon l'une quelconque des revendications 21 ou 22, caractérisé en ce que, au cours de l'étape de détermination s'il existe au moins une prédiction applicable, on met en oeuvre, pour une production correspondant audit item, un nombre de prédictions correctes et un nombre de prédiction incorrectes et si le nombre de prédictions incorrectes pour ladite production est supérieur à une valeur prédéterminée, éventuellement fonction du nombre de prédictions correctes pour ladite prédiction, il n'existe pas de prédiction applicable pour ledit item.24 û Procédé selon l'une quelconque des revendications 20 à 23, caractérisé en ce que, au cours de l'étape (725) de décodage du nombre de prédictions successives correctes, on met en oeuvre un nombre maximum de prédictions correctes et en ce qu'il comporte une étape de mise à jour dudit nombre maximum en fonction du nornbre de fois où ce nombre maximum est atteint. 25 û Procédé selon l'une quelconque des revendications 20 à 24, caractérisé en ce qu'il comporte une étape (735) de décodage de la valeur de chaque item du document correctement prédit, au cours de laquelle on effectue, d'une part, une prédiction de l'indexation des valeurs des items et, d'autre part, une prédiction de structure des items. 26 - Dispositif de codage d'un document structuré, caractérisé en ce qu'il comporte : - un moyen (603, 606, 612, 616) de détermination s'il existe une 15 succession de prédictions correctes pour des items d'un ensemble d'items du document et - un moyen (603, 606, 612, 616) de codage adapté, si le résultat de ladite étape de détermination est positif, à coder le nombre de prédictions correctes successives. 20 27 û Dispositif de décodage d'un document structuré, caractérisé en ce qu'il comporte : - un moyen (603, 606, 612, 616) de décodage d'un nombre de prédictions successives correctes, - un moyen (603, 606, 612, 616) de prédiction d'information 25 structurelle pour chaque item du document correctement prédit en mettant en oeuvre ledit nombre de prédictions correctes successives et - un moyen (603, 606, 612, 616) de décodage d'information structurelle de chaque item du document non prédit. 28 û Programme d'ordinateur chargeable dans un système 30 informatique, ledit programme contenant des instructions permettant la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 25. 29 ù Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 25.5