FR2919400A1

FR2919400A1 - Procede et dispositif d'encodage d'un document structure et procede et dispositif de decodage d'un document ainsi encode.

Info

Publication number: FR2919400A1
Application number: FR0756689A
Authority: FR
Inventors: Romain Bellessort; Youenn Fablet
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2007-07-23
Filing date: 2007-07-23
Publication date: 2009-01-30
Also published as: US20100192056A1; WO2009136225A2; WO2009136225A3; US8627200B2

Abstract

Le procédé d'encodage de données hiérarchisées organisées en une pluralité d'événements comporte :- une étape d'obtention d'un ensemble d'information d'au moins un événement à encoder et- une étape de récupération d'une grammaire en fonction de l'ensemble d'information, ladite grammaire permettant de décrire au moins ledit ensemble d'information,- une étape de détermination si au moins une partie définie par un critère prédéterminée, dudit ensemble d'information d'au moins un événement à encoder peut être prédite de manière univoque à partir de ladite grammaire,- si le résultat de l'étape de détermination est positif, une étape d'encodage d'une information dite « de conformité » représentative de ce résultat positif et- une étape d'encodage de l'information de chaque dit événement à encoder non comprise dans ledit ensemble d'information.

Description

La présente invention concerne un procédé et un dispositif d'encodage d'un

document structuré et un procédé et un dispositif de décodage d'un document ainsi encodé. XML (acronyme de Extensible Markup Language , c'est à dire langage de balisage extensible) 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 pouvant contenir d'autres éléments ou des données textuelles. 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: ( I-- 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'événements, chaque événement 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 seront 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: 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. Par ailleurs, 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, 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 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 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 sera 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 plus d'informations structurelles afin de compresser davantage les données. On peut citer le cas d'Efficient XML, format utilisé comme base pour la standardisation d'un format XML binaire par le groupe EXI du W3C (acronyme de Worldwide Web consortium), qui prend en compte l'ordre d'apparition des différents événements au sein d'un document pour construire des grammaires qui vont permettre d'encoder les événements les plus fréquents sur un faible nombre de bits.

Dans ce cadre, une grammaire est composée d'un ensemble de productions, chaque production comprenant une description d'é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 (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 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 1 à 3 niveaux. Coder une valeur de codage revient à coder les valeurs de sa priorité. Chaque niveau est codé sur un nombre de bit(s) 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ées. 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 ou 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.

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> L'encodeur n'ayant pas rencontré d'élément person auparavant, 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 seront 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 (le nom n'est pas précisé), et CH correspond à un événement de contenu textuel. 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é, l'encodeur sélectionne la grammaire de codage du contenu de l'élément person , décrit 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 L'encodeur 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, comme la production ne précise pas le nom de l'élément, firstName est codé. On poursuit ensuite l'encodage 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 firsttName 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) : ElementContent : Characters 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 Une fois le contenu de firstName codé, l'encodeur 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 : ElementContent : L'événement suivant est le début de l'élément lastName . Comme 20 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 25 avec les trois bits 100 . Le nom de l'élément, lastName est ensuite codé. 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 30 correspondant au début de l'élément lastName et elle devient alors : ElementContent : SE (lastName) ElementContent 0 SE (firstName) ElementContent 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 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 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 10 codé avec la production : SE (firstName) ElementContent 1 La production 3.0 SE (*) ElementContent correspond aussi à cet événement, mais est moins précise (elle ne précise pas 15 le nom de l'élément). C'est donc la première production qui est utilisée. L'encodeur code donc la priorité de cette production, à savoir 1 , qui est codée avec les deux bits 01 . Il n'y a pas besoin de coder le nom de l'élément, puisque celui-ci est précisé par la production. L'encodeur code ensuite le contenu de l'élément firstName . 20 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. 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 25 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 contenu 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. 30 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 : 0 SE (lastName) ElementContent3 EE 1 SE (*) ElementContent2 2.0 CH ElementContent2 2.1 ElementContent3 : 0 EE 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é. 25 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 : 30 SE (lastName) ElementContent3 0 ElementContent3 : 15 20 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 zéro bits.

La présente invention se situe particulièrement dans le cadre où aucun schéma XML n'est utilisé par l'encodeur. De ce fait, au début de l'encodage du document, les règles génériques s'appliquent pour chaque nouvel élément rencontré. En reprenant l'exemple précédent, à la fin de l'encodage du premier élément person , on obtient les règles illustrées en figure 1. L'élément lastName est inséré en dernier dans les règles car il est le dernier des éléments enfants de l'élément person . L'ordre d'insertion des productions respecte, dans cet exemple, l'ordre d'apparition des éléments. Le groupe de travail EXI du W3C travaille actuellement à la standardisation d'un format XML binaire basé sur Efficient XML. Dans ce cadre, différentes améliorations ont été proposées, parmi lesquelles l'utilisation de grammaires coalescentes ou d'événements combinés. Dans les deux cas, il s'agit de grouper, dans une seule production, plusieurs événements dont on sait qu'ils se produisent successivement. Ces propositions ont été faites dans le cadre de l'utilisation de schémas XML, un schéma XML étant une description du contenu d'un document XML, c'est-à-dire une définition des éléments XML utilisés et leur contenu (attributs, éléments enfants, contenu textuel,...). En effet, grâce à un schéma XML, il est possible de savoir que certains événements vont se suivre, par exemple un début d'élément et des attributs requis pour cet élément, ou encore la fin d'un élément enfant et la fin de l'élément parent. L'idée évoquée consiste donc à déterminer de tels événements, puis à définir une production les regroupant. Cette approche nécessite donc un traitement spécifique afin d'identifier des événements qui se succèdent, puis l'ajout d'une ou plusieurs productions aux grammaires : il s'agit donc d'un processus coûteux en calculs, et dont l'impact peut être négatif. En effet, si l'on se base sur les schémas, on peut définir des règles avec un risque faible d'erreurs (cas où la production groupant les événements n'est pas la production à utiliser). En revanche, dans le cas où l'on n'utilise pas de schéma, le risque d'erreur est plus élevé et il se peut donc que l'on insère une production rarement utilisée, cette insertion provoquant l'augmentation du coût de codage de chaque production.

La présente invention vise à remédier à ces inconvénients. Selon un premier aspect, la présente invention vise un procédé d'encodage de données hiérarchisées organisées en une pluralité d'événements comportant : - une étape d'obtention d'un ensemble d'information d'au moins un 10 événement à encoder et - une étape de récupération d'une grammaire en fonction de l'ensemble d'information, ladite grammaire permettant de décrire au moins ledit ensemble d'information, caractérisé en ce qu'il comporte, en outre : 15 - une étape de détermination si au moins une partie définie par un critère prédéterminée, dudit ensemble d'information d'au moins un événement à encoder peut être prédite de manière univoque à partir de ladite grammaire, - si le résultat de l'étape de détermination est positif, une étape d'encodage d'une information dite de conformité représentative de ce 20 résultat positif et - une étape d'encodage de l'information de chaque dit événement à encoder non comprise dans ledit ensemble d'information. En effet, 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 25 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. En particulier, l'encodage actuel d'EXI ne tire pas partie de cet ordre d'insertion : dans l'exemple ci-dessus, la présence de l'élément lastName 30 en tant qu'enfant de person y est encodé sur le même nombre de bits (deux, ici) qu'il se trouve après ou avant l'élément firstName . Cette remarque s'applique aussi à l'encodage du contenu de l'élément lastName : un élément contenant uniquement du texte une première fois dans un document a de grandes chances de ne contenir que du texte dans l'ensemble de ses occurrences suivantes. Actuellement un élément lastName ne contenant que du texte utilisera deux bits pour déclarer qu'il a un noeud texte enfant et deux bits pour déclarer qu'il a un événement fin d'élément, quatre bits au total. On note qu'en mettant en oeuvre la présente invention, contrairement à l'approche proposée au W3C qui cherche à étudier des données pour déterminer des événements qu'il est intéressant de grouper au sein d'une même production, on utilise les grammaires définies pour déterminer la conformité des données, par exemple XML, à encoder. La mise en oeuvre de la présente invention est d'autant plus efficace que l'ensemble des productions ajoutées (non génériques) d'un élément particulier décrit exactement les occurrences suivantes de cet élément. Selon des caractéristiques particulières, au cours de l'étape de détermination on récupère au moins un évènement généré à partir de productions de ladite grammaire ordonnées de manière prédéfinie et on compare l'ensemble d'information d'au moins un évènement généré avec l'ensemble d'information d'au moins un évènement à encoder. Par exemple, à la première étape de détermination concernant une grammaire, on génère des événements à partir des productions de ladite grammaire et, pour les autres étapes de détermination concernant cette grammaire, on met, de nouveau, en oeuvre ces événements générés. La durée d'encodage est ainsi améliorée. Selon des caractéristiques particulières, le procédé d'encodage tel que succinctement exposé ci-dessus comporte, si le résultat de l'étape de détermination est négatif, une étape d'encodage dudit ensemble d'information. Selon des caractéristiques particulières, au cours de l'étape d'obtention, ledit ensemble d'information d'au moins un événement à encoder comporte de l'information de structure d'au moins un événement à encoder.

Selon des caractéristiques particulières, au cours de l'étape d'obtention, ledit ensemble d'information d'au moins un événement à encoder comporte une information indiquant si la valeur dudit événement peut être encodée par référence à une valeur précédemment encodée. Par exemple, des événements sont indexés et on met en oeuvre cet index.

Selon des caractéristiques particulières, l'ensemble d'information d'au moins un événement à encoder est divisé en une pluralité de sous-ensembles d'information et en ce que le résultat de l'étape de détermination est positif si une sélection prédéterminée de sous- ensembles d'information d'au moins un événement à encoder peuvent être prédits de manière univoque à partir de ladite grammaire. Par exemple, on détermine la prédictibilité par sous-ensembles que sont les attributs, les éléments ou événements enfants directs ou l'ensembles des éléments ou événements descendants. Selon des caractéristiques particulières, un sous-ensemble est sélectionné en fonction du nombre de fois où ledit sous-ensemble d'information a pu être prédit de manière univoque à partir de ladite grammaire et/ou du nombre de fois où ledit sous-ensemble d'information n'a pas pu être prédit, lors du codage d'au moins un événement à encoder précédent parmi la pluralité d'événements.

Selon des caractéristiques particulières, si le résultat de l'étape de détermination est positif et l'ensemble d'information comprend au moins un sous-ensemble d'information non sélectionné, le procédé comporte en outre une étape d'encodage de chaque sous-ensemble d'information non sélectionné.

Selon des caractéristiques particulières, si le résultat de l'étape de détermination est négatif et l'ensemble d'information comprend au moins un sous-ensemble d'information sélectionné, le procédé comporte une étape d'encodage d'une information dite de non conformité représentative de ce résultat négatif.

Selon des caractéristiques particulières, un sous-ensemble d'information dudit ensemble d'information comporte les informations relatives aux événements de type textuel, ou plus particulièrement de type espace.

Selon des caractéristiques particulières, un sous-ensemble d'information dudit ensemble d'information comporte les informations relatives aux événements de type d'attribut. Selon des caractéristiques particulières, un sous-ensemble 5 d'information dudit ensemble d'information comporte les informations relatives aux événements de type début d'élément. Grâce à chacune de ces dispositions, même si l'ensemble d'information à encoder diffère légèrement de ce qui est prédit par la grammaire, son encodage comporte une information permettant de reconstruire 10 la partie qui peut être prédite. L'efficacité du procédé objet de la présente invention s'étend donc aux événements présentant une légère variation avec ce qui est prédictible. Selon des caractéristiques particulières, au cours de l'étape de récupération d'une grammaire, on récupère ladite grammaire en fonction d'au 15 moins un événement précédemment encodé. Selon des caractéristiques particulières, le procédé d'encodage tel que succinctement exposé ci-dessus comporte, en outre, une étape de mise à jour de la grammaire récupérée à partir de l'ensemble d'information d'au moins un événement à encoder. 20 Selon des caractéristiques particulières, lors de la mise en oeuvre d'une étape d'encodage de tout ou partie dudit ensemble d'information, l'étape de mise à jour de la grammaire récupérée prend en compte l'ordre des événements à encoder. Par exemple, les sous-ensembles non sélectionnés sont encodés 25 selon des méthodes de codages connues dans l'art antérieur. Selon des caractéristiques particulières, les données hiérarchisées sont les données d'un document structuré XML. Selon des caractéristiques particulières, au moins une dite grammaire est une grammaire EXI. 30 Selon un deuxième aspect, la présente invention concerne un procédé de décodage de données hiérarchisées organisées en une pluralité d'événements caractérisé en ce qu'il comporte : - une étape d'obtention d'une information dite de conformité représentative de ce qu'au moins une partie d'un ensemble d'information d'au moins un événement à décoder peut être prédit de manière univoque à partir d'une grammaire, - une étape d'obtention de ladite grammaire et -une étape de génération de l'information prédite de manière univoque à partir de ladite grammaire. Selon des caractéristiques particulières, l'étape d'obtention de l'information dite de conformité comporte une étape de décodage de l'information de conformité. Selon des caractéristiques particulières, au cours de l'étape d'obtention de l'information dite de conformité , l'information de conformité est obtenue en fonction de décodages passés. Selon un troisième aspect, la présente invention vise un dispositif 15 d'encodage de données hiérarchisées organisées en une pluralité d'événements comportant : - un moyen d'obtention d'un ensemble d'information d'au moins un événement à encoder et - un moyen de récupération d'une grammaire en fonction de l'ensemble 20 d'information, ladite grammaire permettant de décrire au moins ledit ensemble d'information, caractérisé en ce qu'il comporte, en outre : - un moyen de détermination si au moins une partie définie par un critère prédéterminée, dudit ensemble d'information d'au moins un événement à 25 encoder peut être prédite de manière univoque à partir de ladite grammaire, - un moyen d'encodage adapté, si le résultat de l'étape de détermination est positif, à encoder une information dite de conformité représentative de ce résultat positif et adapté à encoder l'information de chaque dit événement à encoder non comprise dans ledit ensemble d'information. 30 Selon un quatrième aspect, la présente invention vise un dispositif de décodage de données hiérarchisées organisées en une pluralité d'événements caractérisé en ce qu'il comporte : - un moyen d'obtention d'une information dite de conformité représentative de ce qu'au moins une partie d'un ensemble d'information d'au moins un événement à décoder peut être prédit de manière univoque à partir d'une grammaire, - un moyen d'obtention de ladite grammaire et - un moyen de génération de l'information prédite de manière univoque à partir de ladite grammaire. Selon un cinquième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'encodage ou du procédé de décodage, tels que succinctementexposés ci-dessus. Selon un sixième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé d'encodage ou du procédé de décodage, tels que succinctement exposés ci-dessus. Les avantages, buts et caractéristiques de ce dispositif d'encodage, de ce procédé de décodage, de ce dispositif de décodage, de ce programme d'ordinateur et de ce support d'informations étant similaires à ceux du procédé d'encodage objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels : la figure 1 représente un exemple d'encodage connu d'un élément de document XML, les figures 2 et 3 représentent des exemples d'encodage d'un élément de document XML obtenus par la mise en oeuvre d'un mode de réalisation particulier du procédé d'encodage objet de la présente invention, la figure 4 représente un document XML particulier, - la figure 5 représente un autre document XML, les figures 6 et 7 représentent un résultat d'encodage du document illustré en figure 5, respectivement, suivant le format Efficient XML, et en mettant en oeuvre un mode de réalisation particulier du procédé d'encodage objet de la présente invention, les figures 8 à 15 représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé d'encodage objet de la présente invention, les figures 16 et 17 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 et la figure 18 représente, schématiquement, un mode de réalisation particulier d'un dispositif pour implémenter les procédés d'encodage et/ou de décodage objets de la présente invention.

Bien que la présente invention soit décrite pour des données structurées d'un document XML, la présente invention ne se limite pas à ce type de document mais s'étend, au contraire, à l'encodage et au décodage de toutes données hiérarchisées organisées en une pluralité d'événements. La figure 1 décrit l'encodage classique EXI. On note qu'en figure 1, comme, plus loin, en figures 2 et 3, la colonne de gauche correspond aux données encodées et la colonne de droite correspond à l'état de la règle pour l'élément person après l'encodage de ces données. On observe que, grâce à la mise en oeuvre du mode de réalisation particulier du procédé d'encodage objet de la présente invention illustré dans les figures, on modifie l'ordre d'insertion de la production correspondant à l'élément midName pour que l'ordre des productions corresponde à l'ordre des éléments : la production midName se retrouve ainsi entre les productions firstName et lastName , comme illustré en figure 2. Lors de la rencontre d'un nouvel élément person , la mise en oeuvre de l'invention consiste à comparer le contenu de l'élément person avec sa grammaire. On détermine la structure la plus probable de l'élément person à partir de l'ensemble des grammaires de l'élément person et de 17 ses enfants connus ( firstName , midName et lastName ), comme illustré en figure 3. On peut ensuite comparer l'élément person à encoder avec la structure déterminée par la grammaire. Si la structure déterminée correspond aux données à encoder, on dit alors que les données à encoder sont conformes à la grammaire, on peut alors utiliser un encodage spécifique : - on encode le fait que la structure déterminée corresponde à l'élément à encoder par l'intermédiaire d'un bit mis à 1 et - on encode l'ensemble des valeurs de l'élément dans leur ordre 10 d'apparition. Si les données à encoder ne sont pas conformes à la structure déterminée par la grammaire, on effectue un encodage différent pour l'élément person : - on encode l'absence de conformité par un bit mis à 0 et 15 - on encode l'élément person de façon connue dans l'art antérieur en incluant les priorités et les valeurs. II est à noter que, dans ce dernier cas, on effectue les comparaisons sur les enfants de l'élément person . La comparaison exposée ci-dessus fonctionne très bien lorsque les 20 structures sont exactement répétitives. Cependant, certains documents, comme celui donné dans l'exemple illustré en figure 4, contiennent des éléments dont la comparaison avec la grammaire ne sera jamais bonne. II s'agit, par exemple, d'éléments dont le contenu est un choix entre plusieurs éléments. Dans l'exemple de la figure 4, l'élément struct ne sera jamais conforme à ce qui 25 est prédit par la grammaire. La comparaison de l'élément value avec sa grammaire ne fonctionne donc pas, du fait de la variabilité du contenu de l'élément struct . Pour résoudre ce problème, dans des modes de réalisation particuliers, dont celui décrit en regard des figures, on introduit le concept 30 d'opacité des règles : l'élément struct n'étant pas conforme avec sa grammaire, on marque la grammaire comme opaque au bout d'un certain nombre d'encodages de cet élément. La comparaison de l'élément value ne tient alors plus compte du contenu de l'élément struct et peut, de nouveau, prédire la structure exacte de l'élément value . L'exemple de document de la figure 4 illustre le principe de l'opacité des enfants d'un élément. On définit des niveaux d'opacité s'appliquant aux 5 différentes parties d'un élément : - opacité des enfants : lorsque la variance des éléments est élevée, opacité des attributs : lorsque la variance des attributs est élevée, - opacité des noeuds texte : lorsque la variance de présence des noeuds texte est importante. 10 Les niveaux d'opacité de chaque grammaire sont déterminés au niveau de l'encodeur suivant le résultat des encodages précédents. Ils sont calculés au niveau du décodeur suivant le résultat des décodages précédents, ce qui permet de ne pas avoir à encoder cette donnée d'opacité explicitement dans le flux et donc de ne pas réduire le taux de compression. 15 Les espaces ( whitespace en anglais) se trouvent généralement entre deux débuts d'élément, deux fins d'élément ou entre un début et une fin d'élément. Dans Efficient XML, les espaces génèrent l'insertion d'une production Characters dans la grammaire qui ne les distinguent pas des autres noeuds textes. Préférentiellement, pour être efficace, la comparaison 20 entre grammaire et données XML mise en oeuvre par la présente invention prend en compte ces espaces. A cet effet, on note que les éléments au contenu mixte (élément contenant des enfants éléments et des noeuds textes qui ne sont pas des espaces) sont relativement rares. De ce fait, la présence conjointe dans une 25 grammaire d'une production CH et d'une ou plusieurs productions SE correspond généralement à la présence d'espaces entre les débuts/fins d'élément. Dans un tel cas, on modifie la comparaison entre grammaire et données XML pour inclure un test des noeuds texte. Le résultat de ce test est positif lorsque tous les noeuds texte direct de l'élément comparés sont des 30 espaces. On peut, par ailleurs, ajouter la contrainte que l'ensemble des noeuds texte soient déjà indexés. Si la comparaison échoue plusieurs fois, on décide alors de rendre ces noeuds texte opaques.

Dans le cas où une production spécifique aux espaces serait utilisée (production Whitespace , définissant éventuellement une valeur pour la chaîne d'espaces), cette méthode fonctionnerait également. En effet, au lieu de détecter les productions Characters correspondant à des espaces, il suffirait d'appliquer l'insertion d'espace quand l'on rencontre une production Whitespace . A partir d'un document simple, illustré en figure 5, on décrit ci-dessous le résultat de l'encodage de ce document suivant le format Efficient XML, illustré en figure 6, d'une part, et en mettant en oeuvre la présente invention et en se basant sur Efficient XML, illustré en figure 7, d'autre part. Pour plus de commodités, les flux XML binaires des figures 6 et 7 ont été modifiés pour être plus lisibles : l'encodage des noms et valeurs d'éléments commencent toujours au début d'un octet. Dans les figures 6 et 7, les caractères en gras correspondent aux priorités encodées pour définir la structure du document. Les autres caractères correspondent aux noms d'éléments et valeurs d'éléments encodés en UTF-8. Les deux flux sont exactement identiques jusqu'à la seconde occurrence de l'élément person (le premier caractère en italiques dans les figures). Dans les deux cas, on débute par fermer le premier élément lastName et le premier élément person , ce qui donne la série de bit 0 puis 01 qui forment le début du caractère 0x31 . On encode ensuite l'événement début d'élément person , qui va former la fin du caractère 0X31 , le caractère 0x00 et les trois premiers bits 001 du caractère 0x20 et 0x30 . Les deux encodages vont ensuite diverger : Efficient XML continue par encoder la priorité correspondant au début d'élément firstName , ce qui forme le caractère 0x20 . Au contraire, la mise en oeuvre de la présente invention détermine d'abord si la nouvelle occurrence de l'élément person correspond à la structure prédite par la grammaire. Comme c'est le cas dans notre exemple, un unique bit mis à 1 est ajouté, ce qui forme le caractère 0x30 . L'encodeur objet de la présente invention encode ensuite les valeurs textuelles contenues dans l'élément person ( Mary et Wesson ) jusqu'au dernier caractère 0x40 qui correspond à l'encodage de la priorité de l'évènement fin d'élément addressbook . L'encodeur Efficient XML encode la valeur Mary puis la priorité de fin d'élément firstName , la priorité de début d'élément lastName ce qui forme le caractère 0x00 , la valeur Wesson puis les priorités de fin d'élément lastName , person et addressbook ce qui forme le caractère 0x28 . Le décodeur objet de la présente invention a un fonctionnement symétrique de celui de l'encodeur, comme illustré en figures 16 et 17. Dans le mode de réalisation particulier du procédé d'encodage objet de la présente invention illustré en figure 8, on effectue, d'abord, l'obtention d'un document XML, au cours d'une étape 100. Puis, au cours d'une étape 110, on détermine si le document a été entièrement traité. Si oui, le traitement prend fin lors d'une étape 190. Sinon, au cours d'une étape 120, on obtient un ensemble d'information d'au moins un événement à encoder. Dans le mode de réalisation décrit en figure 8, il s'agit des données d'un seul événement XML, précisément l'événement XML suivant le dernier événement déjà encodé et, au cours d'une étape 130, on détermine si cet événement correspond à un début d'élément. Si non, au cours d'une étape 150, on détermine la conformité de l'événement, qui peut être vraie, fausse ou inconnue. Dans ces deux derniers cas, on considère que l'événement n'est pas conforme, et on passe à une étape 151 au cours de laquelle la priorité associée à l'événement est encodée, selon le fonctionnement classique d'encodage. A la suite de l'étape 151 ou si, au cours de l'étape 150, on a déterminé que la conformité est vraie, au cours d'une étape 152, on détermine si l'événement a une valeur. Si oui, cette valeur est encodée au cours d'une étape 153. Dans le cas où la prédiction de la conformité comprend l'état d'indexation de la valeur, c'est-à-dire si cette valeur a déjà été indexée ou non, on encode la valeur sans préciser son état d'indexation. Si on détermine à l'étape 152 que l'événement n'a pas de valeur, ou à la suite de l'étape 153, on passe à une étape 180 de mise à jour des grammaires, détaillée en figure 14. Si, au cours d'une étape 130, on détermine que l'événement correspond à un début d'élément, au cours d'une étape 140, on obtient la grammaire utilisée pour le contenu de l'élément que l'on traite, appelée G et, au cours d'une étape 145, on détermine si cette grammaire G est opaque. Les grammaires génériques, qui ne décrivent pas un élément précis, et qui sont utilisées notamment pour la première instance de chaque élément, sont, par défaut, opaques. En effet, puisqu'elles sont génériques, on sait qu'elles ne décrivent pas correctement les données XML rencontrées. Si le résultat de l'étape 145 est positif, au cours d'une étape 160, on encode la priorité associée à l'événement, puis on passe à l'étape 180. En effet, dans le cas d'une grammaire opaque, il n'est pas nécessaire de comparer les données aux grammaires, ni d'encoder une information de conformité, car on utilise toujours les priorités pour encoder les événements. Si le résultat de l'étape 145 est négatif, c'est-à-dire si la grammaire n'est pas opaque, au cours d'une étape 170, on détermine si le début d'élément traité appartient à un contenu déjà considéré conforme à ladite grammaire.

Pour un élément ayant un parent, cela signifie que lorsque l'on a déterminé la conformité des enfants du parent, le résultat a été positif. Cette information est donc connue car on a encodé le parent avant d'encoder l'enfant. Toutefois, il se peut qu'un élément n'ait pas de parent (cas de l'élément racine d'un document XML), ou bien que la détermination n'ait pas pu être faite sur l'élément parent (cas où les données sont bufférisées et où la taille du buffer est trop faible pour contenir l'élément parent en entier). Dans ce cas, la conformité est inconnue, et le traitement est équivalent à celui d'une conformité connue et fausse, c'est-à-dire d'une non-conformité. Si le résultat de l'étape 170 est négatif, au cours d'une étape 171, décrite plus en détail en regard de la figure 9, on détermine la conformité du contenu de l'élément par rapport aux grammaires décrivant l'élément et son contenu et, en cas de conformité, les événements conformes sont marqués comme tels. Ensuite, au cours d'une étape 172, on encode la priorité liée au début d'élément puis, au cours d'une étape 173, on encode la conformité du contenu de l'élément, connue grâce à l'étape 171. La conformité est codée sur un bit valant 0 Si les données ne sont pas conformes et 1 si les données sont conformes. On passe alors à l'étape 180 de mise à jour des grammaires. Si le résultat de l'étape 170 est positif, c'est-à-dire si l'événement est un début d'élément appartenant à un contenu conforme, on passe à l'étape 180. En effet, dans ce cas, la conformité du contenu est déjà connue et il n'est pas nécessaire de coder de priorité. A la suite de l'étape 180, on retourne à l'étape 110 afin d'itérer les étapes illustrées en figure 8 tant que la fin du document n'a pas été atteinte. Une variante de la figure 8 consiste à utiliser un buffer ne contenant qu'un seul événement. Dans ce cas, la conformité est évaluée pour tout type d'événement, et non uniquement pour les débuts d'éléments (cas de la figure 8), et l'évaluation de la conformité consiste à vérifier si l'événement à coder est décrit par la production suivante dans la grammaire (la production courante étant celle ayant servi à encoder l'événement précédent). Si l'événement est bien celui attendu selon la grammaire, l'information de conformité, vraie ou fausse, est encodée sur un bit et on n'encode pas la priorité associée à l'événement. Si ce n'est pas le cas, on code l'information de non-conformité, ou discordance, puis la priorité. L'intérêt de cette variante vient du fait que tout en étant peu coûteuse en mémoire (taille faible du buffer), elle permet de coder les événements conformes sur un seul bit. De plus, dans le cas des débuts d'éléments, il est possible d'évaluer aussi la conformité des attributs (qui ne sont pas nécessairement vus comme des événements distincts), et donc de coder le début de l'élément et les attributs sur un seul bit en cas de conformité (pour les attributs, il est aussi nécessaire de coder les valeurs, par ailleurs). La figure 9 détaille des étapes de détermination de conformité d'un élément. Au cours d'une étape 200, on obtient un élément à traiter. Pour procéder à la détermination de la conformité de l'élément, le contenu de cet élément doit être entièrement connu. Dans le cas où les données XML sont bufférisées, il se peut que la taille du buffer ne permette pas de contenir le contenu de l'élément nécessaire au calcul de la conformité de l'élément. On détermine donc si le contenu connu est suffisant, au cours d'une étape 205, et sinon, le traitement prend fin lors d'une étape 290. Si, en revanche, le contenu est connu, on détermine si la conformité du contenu de l'élément est déjà connue, au cours d'une étape 210.

Cela se produit dans le cas où l'élément étudié est un enfant d'un élément ayant déjà été traité, cet élément parent n'ayant pas été identifié comme conforme. En effet, si l'élément parent avait été identifié comme conforme, alors tout le contenu de cet élément aurait été encodé comme du contenu conforme, et l'on ne serait donc pas arrivé à l'étape 171 de la figure 8 qui lance la détermination de la conformité, le résultat de l'étape 170 étant alors positif. Dans le cas où la conformité est connue, il n'est pas nécessaire de refaire la détermination de la conformité, et le traitement prend donc fin au cours de l'étape 290.

Si la conformité n'est pas connue, on débute la détermination de la conformité par l'initialisation à vrai de la conformité des attributs et des enfants, au cours d'une étape 220. On procède ainsi car, dans le cas où les attributs et les enfants sont opaques (voir figure 9), on considère que n'importe quel contenu sera conforme (mais, du fait de l'opacité, les données seront encodées de manière classique avec des priorités). Au cours d'une étape 230, on détermine si les attributs sont opaques. Cette information est associée à la grammaire associée à l'événement. Si le résultat de l'étape 230 est négatif, au cours d'une étape 231 détaillée en regard de la figure 10, on détermine si les attributs sont conformes. Si ce n'est pas le cas, on passe la conformité des attributs à faux , au cours d'une étape 232, puis on met à jour l'opacité des attributs, au cours d'une étape 235, détaillée en regard de la figure 15. Dans le cas où le résultat de l'étape 231 est positif, on passe aussi à l'étape 235 de mise à jour de l'opacité des attributs. Si le résultat de l'étape 230 est positif, c'est-à-dire si les attributs sont opaques ou à la suite de l'étape 235, au cours d'une étape 240, on détermine l'opacité des enfants, les enfants étant tous les descendants directs de l'élément considéré. On note que les enfants sont le plus souvent des noeuds de contenu textuel ou des éléments, mais qu'il peut aussi s'agir de commentaires ou d'instructions de traitement. De manière similaire à ce qui est fait pour les attributs, on commence, dans le cas où les enfants ne sont pas opaques, par déterminer la conformité des enfants, au cours d'une étape 241. Deux types de conformité existent pour les enfants : la conformité directe, qui concerne les enfants directs, et la conformité générale, qui concerne les enfants ainsi que leurs propres enfants, et ceci récursivement. La conformité utilisée ici est la conformité générale. Si la conformité générale n'est pas positive, alors on passe la conformité es enfants à faux au cours d'une étape 242. A la suite de l'étape 243 u si le résultat de l'étape 241 est positif, au cours d'une étape '\245 , n met à jour l'opacité des enfants. En variante, on peut ne pas effectuer la mise à jour de l'opacité des enfants. Ainsi, on peut, par exemple, décider à l'avance de fixer l'opacité des enfants par l'intermédiaire de paramètres au début de l'encodage et, dans ce cas, l'opacité restera la même tout au long de l'encodage. Cette variante peut aussi s'appliquer au cas des attributs. En variante, on effectue systématiquement la détermination de la conformité, même dans le cas où la grammaire est opaque, et on recalcule la proportion des absences de conformité après chaque détermination de conformité. De cette manière, une grammaire opaque peut perdre son caractère opaque si la proportion des absences de conformité repasse sous un seuil d'opacité décrit en regard de la l'étape 750 illustrée en figure 15. Si le résultat de l'étape 240 est négatif, ou à la suite de l'étape 245, au cours d'une étape 250, on détermine si les attributs et le contenu sont conformes. Si oui, au cours d'une étape 270, l'élément est considéré comme conforme. Sinon, au cours d'une étape 260, l'élément est considéré comme non-conforme. Dans les deux cas, le traitement prend ensuite fin au cours d'une étape 290. On note que, dans le cas où les attributs sont opaques et où les enfants sont conformes, il est nécessaire de coder le premier enfant en indiquant sa priorité. En effet, les attributs étant opaques, ils sont codés avec des priorités, et le décodeur n'a pas la possibilité de savoir que l'on passe des attributs aux enfants si on ne le lui indique pas. En encodant le premier enfant avec sa priorité, le décodeur est capable de faire la transition entre les attributs et les enfants, et une fois le premier enfant décodé, de passer dans la gestion d'enfants conformes. Le processus de comparaison des données XML avec les grammaires (détermination de la conformité) nécessite, comme détaillée en figure 10 et 11, de naviguer en parallèle dans les données XML et dans les grammaires. Afin de réduire le coût de la comparaison, il peut être intéressant, lors de la première détermination de conformité pour une grammaire donnée, de générer les événements XML correspondants (c'est-à-dire les événements obtenus lorsque l'on parcourt la grammaire) et de les stocker dans une structure associée à cette grammaire, par exemple sous la forme d'une liste d'événements. Ainsi, si la grammaire ne change pas, on peut se dispenser de naviguer dans les grammaires lors de la détermination de la conformité, car il suffit de comparer les événements XML à encoder aux événements attendus d'après la grammaire. Dans le cas où la grammaire change, on modifie la liste d'événements pour refléter la modification apportée à la grammaire. Un problème qui peut survenir, lorsque l'on souhaite générer les événements XML à partir des grammaires, vient des grammaires définissant des boucles. C'est le cas, par exemple, de la grammaire décrivant un élément A, cet élément A contenant lui-même un autre élément A. Afin d'éviter de saturer la mémoire, on peut fixer une limite arbitraire au nombre d'événements générés (par exemple lié à la taille du buffer, puisque l'on ne pourra jamais comparer plus d'événements qu'il n'y en a dans le buffer). Une autre solution, plus évoluée, consiste à construire uniquement les événements XML correspondant aux enfants directs d'un élément, puis à itérer sur les sous-éléments si l'évaluation a été réussie. Dans ce cas, il arrive nécessairement un moment où l'évaluation échoue, la grammaire formant une boucle mais les données XML traitées n'en formant pas, et le problème est donc résolu (dans le cas d'un élément A contenant un autre élément A, il arrive nécessairement une instance de A dans les données XML traitées qui ne contient pas A, sinon le document serait infini). Enfin, puisque l'évaluation échoue de manière certaine dans le cas d'une boucle, une des grammaires concernées par la boucle va nécessairement devenir opaque : à partir de ce moment, le problème de l'évaluation ne se pose plus.

La figure 10 décrit la détermination de la conformité des attributs Ai d'un élément XML. Au cours d'une étape 300, on initialise l'index i des attributs de l'élément et on obtient a , premier attribut contenu dans la grammaire G correspondant à l'élément considéré. On note que le premier attribut a est nul si la grammaire ne contient aucun élément. Puis, au cours d'une étape 310, on détermine si le nombre d'attributs Ai de l'élément est égal au nombre d'attribut dans la grammaire. Si ce n'est pas le cas, les attributs Ai ne peuvent pas être conformes par rapport à la grammaire, et l'on passe donc la conformité à faux , au cours d'une étape 360, avant de mettre fin au traitement, au cours d'une étape 390. Si, au contraire, le nombre d'attributs Ai de l'élément est égal au nombre d'attributs dans la grammaire, au cours d'une étape 320, on détermine 10 si l'index i est inférieur au nombre d'attributs. Si c'est le cas, cela signifie qu'il reste au moins un attribut à traiter, et au cours d'une étape 350, on compare l'attribut Ai à l'attribut a obtenu à partir de la grammaire. Si ces deux attributs ne sont pas égaux, c'est-à-dire s'ils ont des noms différents, la conformité est marquée comme fausse, au cours 15 d'une étape 360 et le traitement prend fin à l'étape 390. En revanche, si les attributs sont identiques, on incrémente l'index i et l'on remplace a par l'attribut suivant de G. On note que a étant nul si tous les attributs de G ont déjà été traités, au cours d'une étape 340, puis l'on revient à l'étape 320 de manière à réitérer la comparaison d'attributs. 20 Lorsque, au cours de l'étape 320, on détermine que i est égal au nombre d'attributs, au cours d'une étape 330, la conformité passe à vrai , tous les attributs ayant été comparés avec succès et le traitement prend fin à l'tape 390. On note que le mécanisme décrit ici fonctionnerait identiquement si 25 l'on cherchait à prendre en compte la déclaration d'espaces de nommage, ou namespaces en anglais. Ces déclarations, comme les attributs, ont lieu dans les débuts d'élément. En pratique, ce type de conformité n'est pas dans tous les cas intéressant car de nombreux documents XML ne contiennent que quelques déclarations d'espaces de nommage, et ceci dans l'élément racine. 30 La figure 11 décrit la détermination de la conformité des enfants ENi d'un élément E . Au cours de ce traitement, deux types de conformité sont déterminés : la conformité directe des enfants ENi , et la conformité générale, qui prend en compte les descendants des enfants ENi , selon une analyse de conformité récursive. La conformité directe est utilisée pour les considérations d'opacité, tandis que la conformité générale est utilisée pour l'encodage du contenu de l'élément selon qu'il est conforme ou non à la grammaire. Le fait de distinguer ainsi la conformité directe de la conformité générale permet d'éviter que, dès que le contenu d'un enfant n'est pas conforme, le contenu du parent devienne à son tour non-conforme, comme, par exemple, dans le document illustré en figure 4. Le traitement débute à une étape 400 d'initialisation des conformités directe et générale à la valeur vraie et celle de EN avec la valeur ENO correspondant au premier enfant ou la valeur 0 s'il n'existe aucun enfant. On calcule ensuite l'index attendu d'après la grammaire, au cours d'une étape 410 détaillée en regard de la figure 12, index qui correspond à l'index dans la grammaire de la production décrivant le prochain événement à survenir si les données sont conformes. D'autre part, on calcule aussi l'index réellement obtenu grâce à la grammaire et à l'évènement courant, au cours d'une étape 420. On note quela grammaire retourne l'index de la production décrivant un événement donné quand on lui fournit le type de l'événement et, si l'événement a un nom, son nom. Puis, au cours d'une étape 430, on compare l'index attendu et l'index obtenu. Si ces index ne sont pas égaux, cela signifie que les enfants ne sont pas conformes à la grammaire : la conformité directe est donc fausse et, par conséquent, la conformité générale est aussi fausse, ce qui est marqué au cours d'une étape 435, et le traitement prend fin au cours d'une étape 490.

En revanche, si les index sont égaux, cela signifie que les enfants traités jusqu'ici sont conformes, et l'on passe donc à une étape 440 qui consiste à déterminer si l'événement est un début d'élément. On note que, pour plus de clarté, on parle de sous-élément pour différencier, d'un côté, l'élément ou élément principal et, de l'autre, les sous-éléments, éléments enfants de l'élément principal. L'étape 440 consiste donc à déterminer si l'événement est un début de sous-élément.

Si l'événement n'est pas un début de sous-élément, au cours d'une étape 450, on détermine si l'on se trouve ou non à la fin du sous-élément, ce qui consiste à déterminer, d'une part, s'il ne reste plus aucun enfant à traiter et, d'autre part, si le prochain événement à survenir dans la grammaire est la fin de l'élément principal, ces deux conditions étant réalisées pour une fin de sous-élément. Si l'on se trouve effectivement à la fin du sous-élément, le traitement prend fin à l'étape 490. Sinon, on passe à l'enfant suivant, au cours d'une étape 480, l'enfant suivant étant éventuellement nul s'il ne reste aucun enfant, puis l'on reprend le traitement à l'étape 410.

Dans le cas où le résultat de l'étape 440 est positif, c'est-à-dire si l'événement est un début de sous-élément, au cours d'une étape 460, détaillée en figure 9, on détermine la conformité du sous-élément. Si la conformité n'est pas positive, on passe la conformité générale à faux , au cours d'une étape 475. On note que la conformité directe n'est pas concernée puisque l'enfant EN était bien l'enfant attendu selon la grammaire, c'est uniquement son contenu qui peut ne pas être conforme. Si le résultat de l'étape 460 est positif ou à la suite de l'étape 475, au cours d'une étape 480, on obtient l'enfant suivant et on retourne à l'étape 410. Dans le cas où l'on effectue la comparaison en prenant en compte les espaces, au cours d'un traitement illustré en figure 13, la comparaison peut aussi inclure une étape où l'on détermine si les espaces ont déjà été encodés et font donc partie des tables de vocabulaire indexé. En effet, si c'est le cas, il n'est pas nécessaire d'encoder une information au niveau de chaque espace pour spécifier si celui-ci fait référence à un mot indexé, un espace indexé en l'occurrence, ou si sa valeur est réellement écrite comme une chaîne de caractères, ces caractères étant par exemple des espaces ou des retours à la ligne. Ce procédé peut facilement être généralisé aux noeuds textuels et aux valeurs d'attributs. Ces valeurs présentant une probabilité plus faible de redondance, il peut être intéressant dans ce cas de définir l'opacité les concernant comme vraie initialement ; dans le cas où l'évaluation est positive (typiquement dans le cas où les valeurs sont incluses dans un ensemble restreint : énumération, booléen, ...), l'opacité deviendra fausse selon un critère fonction du nombre d'instances de l'événement parent et du nombre de valeurs possibles. La figure 12 décrit le calcul de l'index attendu d'après une grammaire, le calcul débutant à l'étape 500. Il convient de remarquer que le calcul de l'index attendu repose sur la navigation dans les grammaires, cette navigation étant déterminée par Efficient XML. Dans le mode de réalisation décrit et représenté, on n'apporte pas de nouveauté dans cette navigation, et celle-ci n'est donc pas détaillée : de la même manière que lorsqu'un document est encodé avec Efficient XML, il est parfois nécessaire d'empiler des grammaires, quand la profondeur du document augmente et/ou en début d'élément ou de dépiler des grammaires, quand la profondeur du document diminue et/ou en fin d'élément. D'autre part, Efficient XML sépare la grammaire conceptuelle d'un élément en deux grammaires, l'une correspondant au début de l'élément, grammaire qui contient notamment les attributs, et l'autre contenant les enfants de l'élément. Toutefois, il arrive que la grammaire du début d'élément contienne elle aussi un enfant, et il est donc nécessaire quand on procède aux comparaisons d'utiliser les deux grammaires. Au cours d'une étape 510, on détermine s'il s'agit d'une initialisation, c'est-à-dire si c'est la première fois, pour l'élément dont on détermine la conformité des enfants, que l'on calcule l'index attendu. Si c'est le cas, au cours d'une étape 515, on recherche, dans la grammaire, la première production insérée pouvant être un enfant de l'élément. Par insérée , on entend qu'il ne s'agit pas d'une production présente dans la grammaire par défaut. Par pouvant être un enfant , on entend qu'il ne s'agit pas d'un attribut ou de la déclaration d'un espace de nommage mais, par exemple, d'un début d'élément, d'un contenu textuel ou d'un commentaire. S'il ne s'agit pas d'une initialisation, le traitement se poursuit par l'étape 520 où l'on détermine si un changement de grammaire est nécessaire, un cas qui se présente lorsque l'on passe de la grammaire décrivant le début de l'élément à la grammaire décrivant ses enfants. Si c'est le cas, au cours d'une étape 521, on obtient la nouvelle grammaire, puis on calcule, au cours d'une étape 522, l'index attendu de la même manière qu'au cours de l'étape 515, l'index de la première production insérée pouvant être un enfant d'élément. Si le résultat de l'étape 520 indique qu'il n'y a pas besoin de changer de grammaire, on décrémente simplement la valeur courante de l'index attendu pour la détermination de conformité courante, au cours d'une étape 530. En effet, d'après la manière dont sont insérées les règles dans la grammaire, on sait que l'événement suivant, si les données sont conformes à la grammaire, sera celui correspondant à la production qui suit immédiatement, c'est-à-dire celle d'index immédiatement inférieur.

Après les étapes 515, 522 ou 530, au cours d'une étape 540 on détermine si l'index attendu vaut -1 . Si c'est le cas, cela signifie qu'on a traité tous les enfants, et donc que le prochain événement est la fin de l'élément. On modifie donc la valeur de l'index attendu avec l'index de la production décrivant la fin de l'élément, au cours d'une étape 541. A la suite de l'étape 541 ou si le résultat de l'étape 540 est négatif, le traitement prend fin au cours d'une étape 545. On décrit, en regard de la figure 13, le calcul de l'index attendu dans le cas où l'on suppose que l'on travaille sur un document contenant des espaces, ou whitespaces en anglais. Certains points de détails apparaissant sur la figure 12 n'apparaissent pas sur la figure 13 dans le but d'insister sur l'aspect spécifique à la prise en compte d'espaces. En particulier, en figure 13, on ne mentionne pas le cas de changement de grammaire, et on n'aborde pas le cas où l'index vaut -1 et où l'on choisit alors l'index correspondant à la production décrivant la fin de l'élément, cette correspondance étant ici implicite. Pour effectuer le calcul de l'index attendu, au cours d'une étape 560, on détermine si l'index attendu doit être initialisé. Si oui, au cours d'une étape 561, l'index attendu prend la valeur de l'index correspondant à la première production insérée décrivant un enfant et le traitement prend fin au cours d'une étape 590. En revanche, si l'index n'est pas à initialiser, au cours d'une étape 570, on détermine si le précédent index calculé, qui est encore l'index courant, correspond à un espace. Si oui, au cours d'une étape 571, on donne à l'index attendu la valeur de l'index sauvegardé précédemment, c'est-à-dire de l'index que l'on aurait dû utiliser pour l'événement courant mais que l'on a remplacé par l'index correspondant à un espace. Le traitement prend alors fin au cours de l'étape 590.

Si, au cours de l'étape 570, on détermine que le précédent index calculé ne correspond pas à un espace, au cours d'une étape 580, on décrémente la valeur de l'index attendu puis, au cours d'une étape 581, on détermine si l'index est celui d'un début ou d'une fin d'élément. Si c'est le cas, au cours d'une étape 582, on détermine si l'index précédemment calculé était aussi celui d'un début ou d'une fin d'élément. Si oui, cela signifie que l'on a deux débuts d'élément, deux fins d'éléments, un début et une fin d'élément ou bien une fin et un début d'élément consécutifs, et donc qu'il faut insérer un espace entre les deux si l'on souhaite que la grammaire corresponde aux données. On note que, dans le cas où une fin d'élément suit un début d'élément, cette insertion n'est pas toujours nécessaire, et il peut donc être intéressant de ne pas traiter différemment ce cas du cas standard. Au cours de l'étape 583, on sauvegarde l'index attendu calculé au cours de l'étape 580, pour pouvoir l'utiliser au prochain calcul de l'index attendu, puis on donne à l'index attendu la valeur de l'index de la production décrivant le contenu textuel. A la suite de l'étape 583 ou si le résultat de l'une des étapes 581 et 582 est négatif, le traitement prend fin au cours de l'étape 590. La figure 14 décrit la mise à jour d'une grammaire G après utilisation d'une production P. Ce traitement est appliqué aussi bien lors de l'encodage que lors du décodage. Au cours d'une étape 610, on détermine si la priorité de production utilisée est de niveau 0 , c'est-à-dire une priorité s'écrivant avec un seul chiffre, par exemple 0 , 1 ou 2 , par opposition à une priorité de niveau 1 s'écrivant avec deux chiffres comme, par exemple, 2.0 ou de niveau 2 s'écrivant avec trois chiffres comme, par exemple 2.0.0 . Si la priorité est de niveau 0 , cela signifie que P décrit aussi bien que possible l'événement que l'on a encodé, et il n'y a donc pas besoin d'ajouter une nouvelle production P' plus complète à la grammaire. On passe donc à une étape 690 où le traitement s'achève.

Si, en revanche, la priorité de la production utilisée n'est pas de niveau 0 , cela signifie que l'on a utilisé une règle générique, dont la priorité requiert plus de bits pour être encodée, et il est donc intéressant d'ajouter une nouvelle règle P' ayant une priorité de niveau 0 , laquelle autorise un encodage plus efficace. En effet, le nombre de bits requis est plus faible, et s'il s'agit d'un événement ayant un nom, le nom sera intégré à la production P', ce qui évitera de l'encoder lors des occurrences suivantes. On note que le fait d'insérer de nouvelles productions ayant une priorité de niveau 0 et incluant éventuellement un nom n'est pas propre à l'invention : il s'agit du fonctionnement normal d'Efficient XML. En revanche, par la mise en oeuvre de la présente invention, la position d'insertion des productions reflète l'ordre d'apparition des événements XML, tandis qu'avec Efficient XML les productions sont simplement insérées au début des grammaires.

Au cours d'une étape 620, on détermine l'index i de la dernière production ayant une priorité de niveau 0 à avoir été utilisée pour encoder un événement de la grammaire considérée, cet index étant mis à jour à chaque fois qu'une priorité de niveau 0 est utilisée. Par défaut, c'est-à-dire dans le cas où aucune production n'a été utilisée, cet index vaut 0 . La nouvelle production P', obtenue classiquement, notamment par ajout du nom à P si l'événement considéré à un nom et, sinon, copie simple de P, est alors insérée à l'index i dans la grammaire, au cours d'une étape 630. Puis, on incrémente les priorités des productions suivantes (toutes celles dont le niveau 0 valait i ou plus). De cette manière, on conserve bien l'unicité des priorités. On note qu'avec Efficient XML, puisque les productions sont insérées en position 0, toutes les priorités doivent être incrémentées. Le traitement prend alors fin au cours de l'étape 690. La figure 15 décrit la mise à jour de l'opacité pour une grammaire G. La manière de mettre à jour l'opacité ne varie pas suivant le type d'opacité considérée (opacité des attributs, opacité des enfants). C'est pourquoi on parle d'opacité de manière générique en regard de cette figure 15 mais, en pratique, on met à jour l'opacité d'une grammaire G pour un critère donné : mise à jour de l'opacité pour les attributs, mise à jour de l'opacité pour les enfants, chaque type d'opacité étant caractérisé avec ses propres variables : nombre de comparaisons effectuées et nombre d'absences de conformité rencontrées. On débute le traitement par l'incrémentation du nombre de comparaisons effectuées, au cours d'une étape 710. Ensuite, au cours d'une étape 720, on détermine si les données sont conformes, c'est-à-dire si la comparaison a été réussie ou non. Si c'est le cas, alors le traitement prend fin au cours d'une étape 790. En revanche, dans le cas où les données ne sont pas conformes, au cours d'une étape 730, on incrémente le nombre d'absences de conformité rencontrées. Puis, au cours d'une étape 740, on compare le nombre de comparaisons effectuées avec un nombre prédéterminé. Ce nombre prédéterminé correspond au nombre minimal de comparaisons à effectuer avant de pouvoir considérer une grammaire comme opaque au vu du seuil d'opacité. En effet, si l'on a fait une seule comparaison et qu'une absence de conformité a été déterminée, le taux d'absence de conformité est de 100%. Toutefois il n'est pas pertinent de rendre la grammaire opaque car peu de données ont été traitées. On prédétermine donc un nombre minimal de comparaisons à effectuer endessous duquel la proportion d'absences de conformité n'est pas comparée au seuil d'opacité défini ci-dessous en relation avec l'étape 750 (dans l'absolu, ce nombre minimal peut par exemple valoir cinq ou dix : plus il est faible et plus on risque de rendre une grammaire opaque sans que cela soit fondé ; plus il est grand et plus on risque d'échouer dans des déterminations de conformité à cause d'un élément qu'il serait plus pertinent de considérer comme opaque. En conséquence, si l'on sait, à l'avance, quels types de documents on va encoder, il est intéressant de fixer le nombre minimal après avoir fait des expérimentations sur des fichiers de ce type. Si le nombre de comparaisons effectuées est inférieur au nombre minimal de comparaisons à effectuer, alors le traitement prend fin au cours de l'étape 790. Dans le cas contraire, au cours d'une étape 750, on compare la proportion des absences de conformité à un seuil d'opacité prédéterminé. Là encore, le seuil d'opacité est un compromis et il peut donc être intéressant de le fixer après des expérimentations si l'on se destine à travailler sur un type précis de fichier. Dans l'absolu, on peut estimer qu'à partir de 10 ou 20% d'absences de conformité, il est pertinent de déclarer la grammaire opaque pour le critère considéré. Si la proportion des absences de conformité est supérieure au seuil d'opacité, au cours d'une étape 760, les données sont déclarées opaques. A la suite de l'étape 760 ou si la proportion des absences de conformité est inférieure au seuil d'opacité, le traitement prend fin à l'étape 790. La figure 16 décrit le décodage d'un document encodé selon le mode de réalisation particulier du procédé d'encodage objet de la présente invention décrit précédemment. Au cours d'une étape 800, on obtient le document. Puis, au cours d'une étape 810, on détermine si l'on décode des données conformes aux grammaires. On sait si les données sont conformes grâce aux données précédemment décodées. Par défaut, les données ne sont pas conformes. Dans le cas où les données ne sont pas conformes, au cours d'une étape 811, on obtient l'événement à suivre par le décodage d'une priorité et, le cas échéant, par le décodage des informations complémentaires à cet événement, notamment son nom pour le début d'un élément. Puis, au cours d'une étape 812, on détermine si l'événement décodé est un début d'élément. Si c'est le cas, au cours d'une étape 813, on détermine si la grammaire décrivant le contenu de cet élément est opaque. Si ce n'est pas le cas, au cours d'une étape 814, on lit le bit indiquant la conformité du contenu de l'élément, bit valant 1 pour des données conformes et 0 pour des données non-conformes. Puis on passe à une étape 830 de génération de l'événement décodé. Si, au cours de l'étape 813, on a déterminé que la grammaire est opaque, on effectue l'étape 830. En effet, la grammaire étant opaque, il n'y a pas de bit de conformité à décoder. Si, au cours de l'étape 810, on a déterminé que les données sont conformes, au cours d'une étape 820, on obtient l'événement à partir de la grammaire courante. A la suite de l'étape 820 ou si le résultat de l'étape 812 est négatif, c'est-à-dire si l'événement n'est pas un début d'élément), au cours d'une étape 821, on détermine si l'événement en cours de décodage possède une valeur, ce qui est le cas des événements de contenu textuel notamment. Si oui, au cours d'une étape 822, on décode la valeur de l'événement. A la suite de l'étape 822 ou si, au cours de l'étape 821, on a déterminé que l'événement n'a pas de valeur, on passe à l'étape 830 de génération de l'événement. Après l'étape 830, au cours d'une étape 840, détaillée en regard de la figure 17, on procède à la mise à jour des données d'opacité. Puis, au cours d'une étape 850, on procède à la mise à jour des grammaires. Au cours d'une étape 860, on détermine si l'événement décodé est la fin du document. Si c'est le cas, le traitement prend fin au cours d'une étape 890. Sinon, le traitement se poursuit à l'étape 810. La figure 17 décrit la mise à jour des données d'opacité pendant le décodage d'un document. Ces données concernent ici les attributs et les enfants. Toutefois, ces données peuvent, de la même manière, s'appliquer à d'autres données, par exemple aux espaces de nommage que l'on peut traiter de la même manière que les attributs, comme exposé ci-dessus. Au cours d'une étape 910, on détermine si la grammaire courante est opaque pour le critère courant. Si c'est le cas, le traitement prend fin au cours d'une étape 990. Si la grammaire n'est pas opaque, on compare l'index attendu avec l'index obtenu, au cours d'une étape 920. L'index attendu est l'index de la production qui doit survenir si l'on suit l'ordre de la grammaire, tandis que l'index obtenu est l'index réellement obtenu lorsque l'on cherche la production décrivant l'événement décodé dans la grammaire. On note que, si les données décodées sont des données conformes, l'index attendu sera nécessairement le même que l'index obtenu. Cependant il est nécessaire de mettre à jour les données d'opacité, y compris dans ce cas de succès de la comparaison, puisque les données ont été encodées comme conformes.

Si les index attendu et obtenu sont différents, au cours d'une étape 930, on retient que, pour la grammaire courante et le paramètre courant, typiquement attributs ou enfants, la comparaison a été montrée une absence de conformité et le traitement prend fin au cours d'une étape 990. En effet, pour incrémenter des compteurs, il est nécessaire d'attendre d'avoir atteint la fin de l'élément. Sinon les données d'opacité ne seraient pas identiques à celles utilisées par l'encodeur quand le document a été encodé.

Dans le cas où l'index attendu et l'index obtenu sont identiques, au cours d'une étape 940, on détermine si l'événement décodé correspond à la fin de l'élément décrit par la grammaire courante. Si ce n'est pas le cas, le traitement prend fin à l'étape 990. S'il s'agit de la fin de l'élément, alors on incrémente le nombre de comparaisons effectués pour cette grammaire, au cours d'une étape 950, puis, au cours d'une étape 960, on détermine, pour les attributs et pour les enfants, si la grammaire doit être déclarée opaque. Pour cela, on commence par déterminer s'il y a eu une absence de conformité pour les attributs. Si oui, au cours d'une étape 961, on incrémente le nombre d'absences de conformité pour les attributs. Puis, au cours d'une étape 962, on compare la proportion des absences de conformité au seuil d'opacité. Le fait que le nombre de comparaisons doivent être supérieur à un nombre minimal n'est pas indiqué sur la figure 17, cependant c'est le cas, de manière totalement similaire à ce qui est fait lors de l'encodage. II est d'ailleurs crucial qu'encodeur et décodeur partagent des mêmes valeurs pour ces paramètres, sinon le décodage n'est pas possible. Si la proportion des absences de conformité est supérieure au seuil d'opacité, alors la grammaire est considérée comme opaque pour les attributs, au cours d'une étape 963. Si le résultat de l'une ou l'autre des étapes 960 et 962 est négatif, ou à la suite de l'étape 963, au cours d'une étape 970, on détermine si la comparaison a montré une absence de conformité concernant les enfants. Si oui, au cours d'une étape 971, on incrémente le nombre d'absences de conformité pour les enfants. Puis, au cours d'une étape 972, on compare la proportion des absences de conformité au seuil d'opacité. Si la proportion des absences de conformité est supérieure au seuil d'opacité, au cours d'une étape 973, la grammaire est considérée comme opaque pour les enfants. Si le résultat de l'une ou l'autre des étapes 970 et 972 est négatif ou après l'étape 973, le traitement prend fin au cours de l'étape 990. On note que, bien que, ci-dessus, il n'ait été considéré qu'une seule valeur de seuil d'opacité, aussi bien pour les attributs que pour les enfants, dans des variantes, on met en oeuvre différentes valeurs de ce seuil selon la proportion à laquelle elle s'applique. 37 On observe, en figure 18, un dispositif objet de la présente invention, ou codeur, 1000 et différents périphériques adaptés à implémenter la présente invention. Dans le mode de réalisation illustré en figure 18, le dispositif 1000 est un micro-ordinateur de type connu connecté, par le biais d'une carte d'entrée 1004, à 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 1000 comporte une interface de communication 1018 reliée à un réseau 1034 apte à transmettre, en entrée, des données à encoder ou à décoder et/ou, en sortie, des données encodées ou décodées, par le dispositif. Le dispositif 1000 comporte également un moyen de stockage 1012, par exemple un disque dur, et un lecteur 1014 de disquette 1016. La disquette 1016 et le moyen de stockage 1012 peuvent contenir des données à encoder ou à décoder, des données encodé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) 1006. Selon une autre variante, le programme est reçu par l'intermédiaire du réseau de communication 1034 avant d'être stocké. Ce même dispositif 1000 possède un écran 1008 permettant de visualiser les données à encoder ou décodées ou de servir d'interface avec l'utilisateur pour paramétrer certains modes d'exécution du dispositif 1000, à l'aide d'un clavier 1010 et/ou d'une souris par exemple.

Une unité centrale CPU (acronyme de central processing unit ) 1003 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 1000, les programmes stockés dans une mémoire non volatile, par exemple la mémoire morte 1006, le disque dur 1012 ou la disquette 1016, sont transférés dans une mémoire vive RAM (acronyme de random access memory pour mémoire à accès aléatoire) 1008 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 1016 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 1002 permet la communication entre les différents éléments inclus dans le dispositif 1000 ou reliés à lui. La représentation, en figure 18, du bus 1002 n'est pas limitative et notamment l'unité centrale 1003 est susceptible de communiquer des instructions à tout élément du dispositif 1000 directement ou par l'intermédiaire d'un autre élément du dispositif 1000.

Claims

REVENDICATIONS

1 - Procédé d'encodage de données hiérarchisées organisées en une pluralité d'événements comportant : - une étape d'obtention d'un ensemble d'information d'au moins un événement à encoder et - une étape de récupération d'une grammaire en fonction de l'ensemble d'information, ladite grammaire permettant de décrire au moins ledit ensemble d'information, caractérisé en ce qu'il comporte, en outre : - une étape de détermination si au moins une partie, définie par un critère prédéterminée, dudit ensemble d'information d'au moins un événement à encoder peut être prédite de manière univoque à partir de ladite grammaire, - si le résultat de l'étape de détermination est positif, une étape d'encodage d'une information dite de conformité représentative de ce résultat positif et - une étape d'encodage de l'information de chaque dit événement à encoder non comprise dans ledit ensemble d'information.

2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination on récupère au moins un évènement généré à partir de productions de ladite grammaire ordonnées de manière prédéfinie et on compare l'ensemble d'information d'au moins un évènement généré avec l'ensemble d'information d'au moins un évènement à encoder.

3 û Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce qu'il comporte, si le résultat de l'étape de détermination est négatif, une étape d'encodage dudit ensemble d'information.

4 û Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape d'obtention, ledit ensemble d'information d'au moins un événement à encoder comporte de l'information de structure d'au moins un événement à encoder.

5 û Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, au cours de l'étape d'obtention, ledit ensemble d'information d'au moins unévénement à encoder comporte une information indiquant si la valeur dudit événement peut être encodée par référence à une valeur précédemment encodée.

6 û Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'ensemble d'information d'au moins un événement à encoder est divisé en une pluralité de sous-ensembles d'information et en ce que le résultat de l'étape de détermination est positif si une sélection prédéterminée de sous-ensembles d'information d'au moins un événement à encoder peuvent être prédits de manière univoque à partir de ladite grammaire.

7 û Procédé selon la revendication 6, caractérisé en ce qu'un sous-ensemble est sélectionné en fonction du nombre de fois où ledit sous-ensemble d'information a pu être prédit de manière univoque à partir de ladite grammaire et/ou du nombre de fois où ledit sous-ensemble d'information n'a pas pu être prédit, lors du codage d'au moins un événement à encoder précédent parmi la pluralité d'événements.

8 û Procédé selon l'une quelconque des revendications 6 à 7, caractérisé en ce que, si le résultat de l'étape de détermination est positif et l'ensemble d'information comprend au moins un sous-ensemble d'information non sélectionné, le procédé comporte en outre une étape d'encodage de chaque sous-ensemble d'information non sélectionné.

9 û Procédé selon l'une quelconque des revendications 6 à 8, caractérisé en ce que, si le résultat de l'étape de détermination est négatif et l'ensemble d'information comprend au moins un sous-ensemble d'information sélectionné, le procédé comporte une étape d'encodage d'une information dite de non conformité représentative de ce résultat négatif.

10 û Procédé selon l'une quelconque des revendications 6 à 9, caractérisé en ce qu'un sous-ensemble d'information dudit ensemble d'information comporte les informations relatives aux événements de type textuel.

11 û Procédé selon l'une quelconque des revendications 6 ou 10, caractérisé 30 en ce qu'un sous-ensemble d'information dudit ensemble d'information comporte les informations relatives aux événements de type d'attribut.12 û Procédé selon l'une quelconque des revendications 6 à 11, caractérisé en ce que un sous-ensemble d'information dudit ensemble d'information comporte les informations relatives aux événements de type début d'élément. 13 û Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que, au cours de l'étape de récupération d'une grammaire, on récupère ladite grammaire en fonction d'au moins un événement précédemment encodé. 14 û Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comporte, en outre, une étape de mise à jour de la grammaire récupérée à partir de l'ensemble d'information d'au moins un événement à encoder. û Procédé selon la revendication 14, caractérisé en ce que, lors de la mise en oeuvre d'une étape d'encodage de tout ou partie dudit ensemble d'information, l'étape de mise à jour de la grammaire récupérée prend en compte l'ordre des événements à encoder. 15 16 û Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que les données hiérarchisées sont les données d'un document structuré XML. 17 û Procédé selon l'une quelconque des revendications 1 à 16, caractérisé en ce que au moins une dite grammaire est une grammaire EXI. 18 - Procédé de décodage de données hiérarchisées organisées en une pluralité d'événements caractérisé en ce qu'il comporte : - une étape d'obtention d'une information dite de conformité représentative de ce qu'au moins une partie d'un ensemble d'information d'au moins un événement à décoder peut être prédit de manière univoque à partir d'une grammaire, - une étape d'obtention de ladite grammaire et - une étape de génération de l'information prédite de manière univoque à partir de ladite grammaire. 19 û Procédé selon la revendication 18, caractérisé en ce que l'étape 30 d'obtention de l'information dite de conformité comporte une étape de décodage de l'information de conformité.20 û Procédé selon la revendication 18, caractérisé en ce que, au cours de l'étape d'obtention de l'information dite de conformité , l'information de conformité est obtenue en fonction de décodages passés. 21 - Dispositif d'encodage de données hiérarchisées organisées en une 5 pluralité d'événements comportant : - un moyen d'obtention d'un ensemble d'information d'au moins un événement à encoder et - un moyen de récupération d'une grammaire en fonction de l'ensemble d'information, ladite grammaire permettant de décrire au moins ledit ensemble 10 d'information, caractérisé en ce qu'il comporte, en outre : - un moyen de détermination si au moins une partie, définie par un critère prédéterminée, dudit ensemble d'information d'au moins un événement à encoder peut être prédite de manière univoque à partir de ladite grammaire, 15 - un moyen d'encodage adapté, si le résultat de l'étape de détermination est positif, à encoder une information dite de conformité représentative de ce résultat positif et adapté à encoder l'information de chaque dit événement à encoder non comprise dans ledit ensemble d'information. 22 - Dispositif de décodage de données hiérarchisées organisées en une 20 pluralité d'événements caractérisé en ce qu'il comporte : - un moyen d'obtention d'une information dite de conformité représentative de ce qu'au moins une partie d'un ensemble d'information d'au moins un événement à décoder peut être prédit de manière univoque à partir d'une grammaire, 25 - un moyen d'obtention de ladite grammaire et - un moyen de génération de l'information prédite de manière univoque à partir de ladite grammaire. 23 - Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé 30 d'encodage selon l'une quelconque des revendications 1 à 17 ou du procédé de décodage selon l'une quelconque des revendications 18 ou 20.24 - Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé d'encodage selon l'une quelconque des revendications 1 à 17 ou du procédé de décodage selon l'une quelconque des revendications 18 ou 20.