FR2945363A1 - Procede et dispositif de codage d'un document structure - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif (2) de codage d'un document structuré (10) composé d'événements à coder (22) présentant des valeurs (41 ). Une application particulière, non exclusive, de la présente invention est le codage de document XML en un fichier de type EXI. Le procédé comprend les étapes suivantes: - parcourir le document pour traiter des événements; - constituer (E306, E307) des canaux de valeurs (32) regroupant des valeurs d'événement selon au moins un critère; - coder (E309) les canaux ainsi constitués par codage des valeurs d'événement (41) de chacun de ces canaux à l'aide d'au moins un dictionnaire de codage (27); procédé dans lequel l'étape de constitution comprend, pour chaque événement à coder parcouru ayant une valeur (41), l'association (E307) de cette valeur à coder à un desdits canaux (32) par référence, dans ledit canal, à une entrée (45) du dictionnaire de codage (27).

Description

La présente invention concerne un procédé et un dispositif de codage d'un document structuré composé d'événements. Une application particulière, non exclusive, de la présente invention est le codage d'un document XML (acronyme de "eXtensible Markup Language" pour langage de balisage extensible) en un fichier type XML Binaire, par exemple selon la recommandation EXI (Efficient XML Interchange). Le format XML est une syntaxe pour définir des langages informatiques, ce qui permet de créer des langages adaptés à des utilisations différentes pouvant cependant être traités par de mêmes outils. Un document XML est composé d'éléments, chaque élément étant délimité par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et une balise fermante comportant elle aussi le nom de l'élément (par exemple: </balise>). Chaque élément peut contenir d'autres éléments de façon hiérarchique ou des données textuelles. Un élément peut également être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont alors 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: <1-- Commentaire--> ) et des instructions de traitement, qui peuvent préciser à une application informatique quels traitements appliquer au document XML (par exemple : <?montraitement?> ). Dans la terminologie XML, l'ensemble des termes élément , attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement sont regroupés sous le nom générique de item . Ces items XML peuvent être décrits en termes d'événements, également appelés événements XML. Ainsi, à chaque partie d'un document correspond un événement. Pour un élément <balise></balise>, on distingue d'abord un événement "début d'élément" correspondant à <balise> et étant caractérisé par le nom balise , puis un événement "fin d'élément" qui, selon la topologie des langages de balisage, contient un rappel au nom d'élément correspondant, ici /balise . Les autres événements les plus fréquents sont les événements chaîne de caractères pour les données textuelles, commentaire pour les commentaires, ou encore attribut pour les attributs. Pour la suite de la description, on appelle "valeur d'événement" les valeurs que peuvent prendre ces différents événements, qu'il s'agisse indifféremment de chaînes de caractères, de valeurs numériques, etc. Plusieurs langages différents basés sur le langage XML peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace selon la terminologie anglo-saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier , pour Identifiant uniforme de ressource), par exemple http://canon.crf.fr/xml/monlangage . L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: xmins:ml="http://canon.crf.fr/xml/monlangage" associe le préfixe ml à l'URI http://canon.crf.fr/xml/monlangage ).

Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de : (par exemple: <ml:balise ml:attribut="valeur"> indique que l'élément balise découle de l'espace de nommage ml et qu'il en est de même pour l'attribut attribut).

Malgré les nombreux avantages de la syntaxe XML, elle présente le principal inconvénient 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 pallier cet inconvénient, des mécanismes pour coder le contenu du document XML sous une forme plus compressée ont été mis en place.

C'est notamment le cas des formats XML Binaire tels que les formats EXI et Fast Infoset, qui prennent en compte les informations structurelles du document XML. Par exemple, la recommandation EXI prend en compte l'ordre d'apparition des différents événements au sein du document structuré XML pour construire une ou plusieurs grammaires évolutives qui permettent d'encoder les événements les plus fréquents sur un faible nombre de bits. 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 dans le flux binaire codé, et les informations contenues dans l'événement et non décrites dans la production sont codées à la suite.

Ainsi, par exemple, il est possible d'utiliser une grammaire pour chaque élément ayant un nom donné. Lors de la première occurrence d'un élément fils dans le contenu de cet élément, une nouvelle entrée décrivant le type de cet élément fils est ajoutée dans la grammaire avec un index associé. Lors des occurrences suivantes d'un élément fils similaire, ce nouvel élément fils est décrit en utilisant l'index associé. Par ailleurs, les informations de type chaîne de caractères (alphanumériques notamment) relatives au nom des items et à leurs valeurs sont encodées par référence à des entrées de dictionnaires de codage. Généralement le nom d'un item est encodé à la première occurrence de ce dernier pour former partie d'une production de la grammaire, tandis que les valeurs ne sont pas intégrées dans les productions et sont susceptibles de différer à chaque nouvelle occurrence de l'événement.

Un ensemble de dictionnaires de chaînes de caractères, aussi appelés dictionnaires de codage, est alors utilisé comprenant: - un dictionnaire des URI associant une URI à un index de codage; - un dictionnaire des préfixes associés aux URI; - un dictionnaire des noms locaux (ou "local name") des noms qualifiés que sont les éléments et les attributs. On rappelle ici qu'un nom qualifié se définit par un nom local (le nom de l'élément ou attribut), un préfixe et une URI (si ces derniers sont utilisés dans le document); - un dictionnaire des valeurs de type chaîne de caractère, partitionné selon les noms qualifiés auxquels se rapportent les valeurs stockées. Le codage classique EXI est réalisé au fur et à mesure du parcours du document XML à coder. Ainsi, traditionnellement, les informations codées de structure et de valeurs sont entrelacées selon leur ordre d'apparition dans le document XML d'origine.

Afin d'améliorer encore la compression, deux modes du codage EXI proposant une autre organisation de ces informations codées à l'intérieur du flux EXI généré ont été mis en place: un mode dit de "pré-compression" et un mode dit de "compression", se distinguant l'un de l'autre par la simple mise en oeuvre supplémentaire ou non d'un algorithme final de compression, par exemple de type DEFLATE, pour le mode "compression". Dans ces modes spécifiques, les événements XML sont regroupés en blocs de taille fixe et paramétrable, la taille du bloc définissant le nombre de valeurs d'événements, généralement les valeurs d'attributs (AT) et les valeurs de chaînes de caractères (CH), à l'intérieur du bloc.

Le codage EXI d'un document est alors opéré bloc par bloc, en séparant à l'intérieur de ceux-ci les informations de structure et les informations de valeurs d'événement. Les valeurs de codage des informations de structure (c'est-à-dire les codes de priorités) avec leur contenu associé à l'exception des valeurs des événements sont regroupées sous la forme d'un canal de structure. Ce canal de structure conserve l'ordre et l'organisation générale de la structure du document XML.

Les valeurs des événements d'un bloc sont, quant à elles, regroupées sous forme de plusieurs canaux de valeurs en conservant à l'intérieur d'un canal de valeurs l'ordre des valeurs dans le document XML. La valeur d'un événement est notamment placée dans le canal de valeurs identifié par le nom qualifié de l'événement en question ou de l'événement parent lorsqu'il s'agit d'une valeur de chaîne de caractères (CH). On regroupe ainsi dans une même liste des informations similaires, diminuant l'entropie de celles-ci, afin de les compresser de façon plus efficace. On observe que, dans l'ensemble des canaux de valeurs résultants, les informations relatives aux événements du document XML sont dans un ordre différent de leur ordre d'apparition dans le document XML. Dans le mode "compression", une compression de type DEFLATE est alors opérée sur chacun des canaux de structure et de valeurs ainsi formés, avec la mise en place optionnelle de stratégies de regroupement des canaux (essentiellement de valeurs) en fonction de leur taille (en nombre de valeurs). Le mode "pré-compression" n'effectue, quant à lui, qu'une réorganisation des données en blocs, comme expliqué ci-dessus. Cette réorganisation des données, dans les deux modes, s'effectue au détriment de l'utilisation efficace de la mémoire dans l'encodeur EXI comparé à un encodage EXI classique. En effet, outre la mémorisation des dictionnaires et grammaires lors de l'encodage, les valeurs d'événements et les informations de structure sont par ailleurs mémorisées afin de les organiser et les coder selon les canaux évoqués. La figure 1 illustre cette situation avec un document XML 10.

Le flux EXI obtenu pour le mode "pré-compression" ou "compression" correspond aux informations codées du canal de structure 11 et aux informations codées des canaux de valeurs 12 ordonnés selon l'ordre d'apparition des noms qualifiés dans le document XML, et donc tels qu'illustrés en 13, 14, 15, 16, puis compressées via DEFLATE (pour le mode "compression"). Les index 0x00 et 0x02 des canaux 13 et 15 correspondent respectivement aux deuxièmes occurrences des valeurs "2007-09-12" et "EXI", dont les premières occurrences sont les première (index 0) et troisième (index 2) valeurs rencontrées dans le document. Les informations de structure devant précéder les informations de valeurs, l'aspect mémorisation apparaît clairement sur cette figure. En effet, tout le document (ou du moins les valeurs et les informations de structure jusqu'à ce qu'un nombre de valeurs égal à la taille du bloc ait été rencontré) a besoin d'être mémorisé afin d'ordonner et surtout d'indexer les valeurs a posteriori selon l'ordre défini par la spécification EXI. Il en résulte, par rapport à l'encodage EXI classique, un besoin supplémentaire de mémoire pour stocker ces canaux. La mise en oeuvre de ces deux modes d'encodage dans des appareils à ressources limitées, tels des téléphones mobiles ou appareils photos, peut être remise en cause pour manque de mémoire embarquée. On peut toutefois jouer sur le paramètre de taille de bloc pour contrôler l'utilisation des ressources mémoire de l'appareil. Toutefois, ce paramètre ne renseigne que le nombre de valeurs d'événements à prendre en compte. Il ne reflète pas le nombre d'octets effectivement utilisés en mémoire pour le stockage des valeurs de codage, d'autant plus que la taille (en octets) des valeurs au sein d'un même document XML peut varier de façon importante: en effet, les valeurs sont des chaînes de caractère dont la longueur varie. Ainsi, ce paramètre de taille de bloc s'avère délicat à ajuster. On connaît par ailleurs, de la demande US 2008/082556, une utilisation de la décomposition sous forme de canaux. La méthode de codage et compression décrite utilise des informations a priori pour représenter, sous forme d'automate fini, la structure du document XML à compresser. L'ensemble des informations du document est encodé sous forme de valeurs de codage, lesquelles sont ensuite séparées en différents sous-flux de métadonnées ou de valeurs, selon des critères choisis. Cette méthode présente également l'inconvénient de nécessiter un grand espace mémoire puisque les valeurs de codage de l'ensemble du document sont d'abord stockées avant d'être réparties en sous-flux. En outre, du fait de ce stockage intégral avant répartition, un codage/compression à la volée ne peut être mené. Les solutions de l'état de la technique présentent ainsi l'inconvénient majeur d'utiliser un espace mémoire important.

La présente invention vise à résoudre au moins un des inconvénients de l'art antérieur, en proposant notamment une utilisation plus efficace de la mémoire. La mise en oeuvre de l'invention sur des appareils à ressources limitées en est ainsi facilitée. A cet effet, l'invention vise notamment un procédé de codage d'un 10 document structuré composé d'événements à coder présentant des valeurs, comprenant les étapes suivantes: - parcourir le document pour traiter des événements; - constituer des canaux de valeurs regroupant des valeurs d'événements selon au moins un critère; 15 - coder les canaux de valeurs ainsi constitués par codage des valeurs d'événement de chacun de ces canaux de valeurs à l'aide d'au moins un dictionnaire de codage; procédé dans lequel l'étape de constitution comprend, pour chaque événement à coder parcouru ayant une valeur, l'association de cette valeur à 20 coder à un desdits canaux de valeurs par référence, dans ledit canal de valeurs, à une entrée du dictionnaire de codage. En utilisant des références vers le dictionnaire de codage pour constituer les canaux, on s'affranchit du stockage des valeurs d'événement avant constitution des canaux. Notamment, on ne stocke qu'une seule instance 25 de chaque valeur au niveau du dictionnaire et non une pluralité d'occurrences de cette valeur dans les canaux de valeurs. Les ressources mémoire consommées sont donc moindres. L'entrée référencée est alors celle correspondant à la valeur à coder, dans le dictionnaire. 30 Par ailleurs, selon l'invention, les canaux de valeurs sont progressivement constitués lors du parcours du document, ce qui permet un traitement à la volée plus aisé et un codage par blocs accéléré. En outre, ce codage progressif par blocs offre un moyen efficace pour contrôler l'utilisation de la mémoire que le décodeur ferait au même stade de traitement du document XML. Il est ainsi possible d'arrêter un bloc lorsque l'utilisation supposée de la mémoire du décodeur est optimale.

Enfin, l'utilisation de références vers le dictionnaire déporte les recherches d'entrées, dans le dictionnaire, lors de l'étape de constitution et non plus lors des opérations de codage effectif. Comme ce dernier peut requérir d'importantes ressources, le procédé de l'invention permet ainsi de répartir la charge de traitement et, par exemple, d'utiliser des équipements dotés de moins de ressources. Dans un mode de réalisation, l'étape de constitution comprend, préalablement à ladite association, une étape d'ajout, dans ledit dictionnaire de codage, d'une entrée correspondant à ladite valeur à coder si cette dernière ne s'y trouve pas déjà. La compatibilité avec le format EXI est ainsi conservée puisque les dictionnaires sont évolutifs. L'association est alors réalisée sur cette nouvelle entrée. En particulier, la nouvelle entrée ajoutée est partielle en ce qu'elle ne comprend pas, lors de son ajout, d'index de codage calculé pour le codage de la valeur correspondante. Notamment, au moins un index de codage associé à l'entrée peut alors être calculé lors de l'étape de codage des canaux de valeurs. En déplaçant ces calculs d'index lors du parcours des canaux de valeurs pour leur codage, on rend la constitution des canaux de valeurs plus rapide. En particulier, l'au moins un index de codage d'une entrée nouvellement ajoutée prend une première valeur particulière lors de cet ajout.

Cette première valeur particulière indique que les occurrences ultérieures de cette même valeur seront codées à l'aide d'un index. Contrairement aux techniques connues telles la recommandation EXI où l'index dans le dictionnaire prend la valeur d'un compteur indiquant le nombre courant de valeurs différentes dans le dictionnaire, ici les index de codage prennent la même valeur particulière lors de l'insertion d'une nouvelle entrée. Le calcul des index de codage est déporté ultérieurement.

On tire profit de cette dernière particularité pour, comme on le verra par la suite et grâce à l'utilisation de cette première valeur particulière, identifier facilement les entrées non traitées lors du codage des canaux de valeurs pour obtenir le flux EXI final.

En particulier, le codage des canaux de valeurs pour générer au moins un flux codé comprend: - le parcours desdits canaux de valeurs de sorte à récupérer, dans ledit dictionnaire de codage, un index de codage pour chaque valeur à coder, à l'aide de ladite référence; - le remplacement, dans ledit dictionnaire de codage, de l'au moins un index de codage associé à une référence parcourue, par une valeur courante d'index, lorsque cet au moins un index de codage vaut ladite première valeur particulière. Ainsi, les index de codage sont déterminés une seule fois lors de la 15 génération du flux codé final, en tenant compte du ré-ordonnancement des valeurs du fait de la constitution des canaux de valeurs. Selon une caractéristique particulière, l'au moins un index de codage comprend un index local de codage correspondant à une partition locale associée à un canal de valeurs et un index global de codage. L'utilisation des 20 partitions permet d'obtenir des index locaux de codage sur un nombre de bits plus petit que les index globaux. Ainsi, un codage contextuel à l'aide des index locaux permet l'obtention d'un flux codé plus compressé. Dans un mode de réalisation particulier, l'index global d'une entrée du dictionnaire est remplacé par la valeur d'un compteur d'index global qui est 25 incrémenté à chaque nouvelle référence parcourue dont l'entrée associée comprend un index global égal à la première valeur particulière. Similairement, l'index local d'une entrée du dictionnaire est remplacé par la valeur d'un compteur d'index local qui est remis à zéro à chaque nouveau canal de valeurs parcouru et incrémenté à chaque nouvelle référence 30 parcourue dans ce canal de valeurs, dont l'entrée associée comprend un index global égal à la première valeur particulière.

Ces deux dispositions permettent, lors du parcours des références composant les canaux de valeurs, de générer efficacement les valeurs de codage associées (locale et globale) à chacune des entrées du dictionnaire, en tenant compte du ré-ordonnancement du fait de la constitution des canaux.

L'utilisation de l'un ou l'autre des deux index est explicitée plus loin. Dans un mode de réalisation, une entrée du dictionnaire de codage comprend en outre une valeur codée correspondant au codage littéral de ladite valeur associée à cette entrée, et ladite valeur codée est supprimée dudit dictionnaire lors du codage, à l'aide de ladite valeur codée, de la valeur d'événement associée à ladite référence parcourue. L'utilisation de la valeur codée littéralement concerne généralement la première occurrence d'une valeur. Cette disposition permet de libérer progressivement la mémoire de l'encodeur lors du codage du document, puisque les occurrences ultérieures de la valeur sont alors codées par l'index de codage en mémoire du dictionnaire et non plus pas la valeur codée littéralement. Cet espace libéré peut notamment servir à stocker le fichier codé. Dans un mode de réalisation, l'au moins un index de codage d'une entrée nouvellement ajoutée prend une deuxième valeur particulière lors de cet ajout, de sorte à indiquer que les occurrences ultérieures de la valeur de l'événement ne sont pas encodées à l'aide d'un index. L'index de codage peut alors prendre au moins deux valeurs lors de l'ajout de l'entrée dans le dictionnaire: la première ou la deuxième valeur particulière. Cette disposition permet, lors de la génération du flux codé, d'identifier aisément lorsqu'un index ne doit pas être généré et/ou utilisé pour coder une valeur d'un des canaux de valeurs. Ce peut être le cas pour des valeurs très longues et peu fréquentes. Dans ce cas, on préfère effectivement coder la valeur à chaque occurrence plutôt que de la conserver dans le dictionnaire, ce qui est coûteux en terme de mémoire au décodage.

En particulier, l'étape de codage des canaux de valeurs comprend l'ajout d'une valeur prédéterminée à l'au moins un index de codage de l'entrée associée à une référence d'un canal de valeurs à coder, lorsque cette entrée comprend initialement un index de codage égal à la deuxième valeur particulière, et la suppression, dans le dictionnaire de codage, de cette entrée, lorsque cet index de codage devient égal à la première valeur. On évite ainsi d'utiliser inutilement la mémoire du système avec des entrées du dictionnaire non utilisées pour le codage: lorsque le codeur détecte que cette valeur ne sera plus utilisée, il la supprime de son dictionnaire de valeurs afin de récupérer des ressources mémoire. Dans un mode de réalisation de l'invention, lesdits canaux de valeurs sont formés par regroupement des valeurs d'événement selon le nom qualifié de l'événement qui leur est associé. Ces regroupements permettent d'obtenir des canaux de valeurs présentant une entropie plus faible, et donc d'obtenir une meilleure compression de ceux-ci. On conserve également de la sorte une compatibilité avec le format EXI. Selon une caractéristique particulière, on choisit, comme index d'encodage d'une valeur d'événement référencée dans un canal à coder, un index local de codage de l'entrée associée à la valeur de l'événement lorsque le nom qualifié associé audit canal est le nom qualifié associé audit événement; et on choisit un index global de codage si ces noms qualifiés diffèrent. De la sorte, on utilise un critère simple à mettre en oeuvre pour améliorer la compression du flux codé en utilisant les index locaux, établis sur un nombre de bits plus faible que les index globaux. En outre, on prévoit que l'on complète l'index d'encodage avec une information de marquage renseignant s'il résulte de l'index global ou de l'index local. Cette disposition permet au décodeur de décoder efficacement le flux codé reçu. En d'autres termes, cela signifie que l'on encode l'occurrence d'une valeur d'événement référencée dans un canal de valeurs, à l'aide d'un index global associé à l'ensemble des canaux de valeurs lorsque ladite occurrence n'appartient pas au même canal de valeurs que la première occurrence de ladite valeur; et à l'aide d'un index local associé uniquement audit canal de valeurs, dans l'autre cas.

Dans un mode de réalisation de l'invention, on crée lesdits canaux de valeurs au fur et à mesure du parcours dudit document en conservant leur ordre de création. On évite ainsi au codeur de maintenir l'ordre d'apparition des noms qualifiés dans le document aux fins de trier les canaux de valeurs lors de leur encodage. Il en résulte un gain en consommation de mémoire, ainsi qu'un codage plus rapide en l'absence de tri ultérieur. En particulier, préalablement audit parcours des canaux de valeurs, on recombine des canaux de valeurs parmi la pluralité de canaux de valeurs en fonction d'au moins un critère de sorte à obtenir au moins un canal de valeurs recombiné. Cette configuration permet d'optimiser la compression des valeurs de codage. Selon une caractéristique particulière, on code les canaux de valeurs successivement selon ledit ordre de création, ledit au moins un canal de valeurs recombiné, lorsqu'il existe, étant codé préalablement. On conserve ainsi la compatibilité avec la recommandation EXI. Dans un autre mode de réalisation de l'invention, le procédé comprend, pour chaque association d'une valeur à un canal de valeurs, les étapes suivantes: - estimer un nombre de bits nécessaires pour coder ladite valeur d'événement; - augmenter un compteur de bits dudit nombre de bits estimé; - utiliser ledit compteur de bits pour diviser ledit document structuré en une pluralité de blocs de données à coder séparément. Le nombre de bits nécessaires est typiquement celui nécessaire à la représentation de l'index de codage ou à la représentation de la valeur codée lors de la première occurrence d'une valeur à coder. Notamment, le nombre de bits estimé vaut le nombre de bits nécessaires pour représenter le nombre, augmenté de 1, d'entrées dudit dictionnaire de codage. Cette disposition permet une estimation à coût quasi nul de l'occupation mémoire qu'aura le décodeur au même stade du traitement. En effet, généralement l'index de codage est le nombre le plus faible disponible. En variante, l'estimation du nombre de bits nécessaires pour représenter la valeur codée associée à la valeur à coder est applicable à la première occurrence car on encode dans ce cas la valeur codée et non encore les index de codage, ou aux valeurs à coder non indexables. Selon une caractéristique particulière, on arrête la constitution des canaux de valeurs et on procède à leur codage lorsque ledit compteur de bits atteint une valeur prédéfinie de sorte à générer au moins un flux codé correspondant à une partie du document. Ceci permet d'émettre une portion de flux dont la taille est compatible avec une taille de mémoire tampon du décodeur pour que celui-ci puisse décoder à la volée le flux ainsi codé. Cette portion de flux est ainsi traitée comme un bloc tel que défini pour les options "compression" et "pré- compression" de EXI. Le bloc codé est donc directement décodable. Notamment, on itère la génération d'au moins un flux codé en fonction de la valeur prédéfinie, pour coder une pluralité de parties successives du document structuré. Selon ces dispositions, on contrôle aisément l'utilisation de la mémoire. On encode le document structuré par blocs d'événements de taille variable, où chaque bloc résulte de l'atteinte de la valeur prédéfinie par le compteur à chaque itération. Le décodage de chaque bloc ne nécessitera pas, quant à lui, de mémoire au-delà de la valeur prédéfinie, que l'on choisit donc en fonction des capacités du décodeur prévu. De plus, les blocs deviennent adaptables au contenu du document. L'invention vise également un dispositif de codage d'un document structuré composé d'événements à coder présentant des valeurs, comprenant: - un moyen apte à parcourir le document pour traiter des événements; - un moyen de constitution de canaux de valeurs regroupant des valeurs d'événements selon au moins un critère; - un moyen de codage des canaux de valeurs ainsi constitués par codage des valeurs d'événement de chacun de ces canaux de valeurs à l'aide d'au moins un dictionnaire de codage; dispositif dans lequel ledit moyen de constitution est apte à associer, pour chaque événement à coder parcouru ayant une valeur, cette valeur à coder à un desdits canaux de valeurs par référence, dans ledit canal de valeurs, à une entrée du dictionnaire de codage. La référence peut être mise en oeuvre au moyen de liens informatiques, tels que des pointeurs vers l'entrée correspondante du 10 dictionnaire. Le dispositif présente des avantages similaires à ceux du procédé exposé ci-dessus, notamment l'utilisation réduite de ses ressources mémoire. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de codage exposé précédemment. 15 L'invention concerne également un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de codage conforme à l'invention lorsque ce programme est chargé et exécuté par le système 20 informatique. L'invention concerne également un programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de codage conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. 25 Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans 30 lesquels : - la figure 1 représente un fichier XML et des canaux de structure et valeurs conformément à la spécification EXI; - la figure 2 montre un codeur EXI 2 pour la mise en oeuvre de l'invention, activée par un utilisateur depuis une application 1 offrant une interface utilisateur; - la figure 3 illustre, sous forme de logigramme, des étapes de codage selon l'invention d'un document XML selon le format EXI en mode "pré-compression" ou "compression" précisé dans les options de codage; - la figure 4 montre, sous forme de logigramme, des étapes de codage d'une valeur d'événement selon l'invention; - la figure 5 illustre un dictionnaire de chaîne de caractères pour le 10 codage selon l'invention; - les figures 6a et 6b illustrent, sous forme de logigrammes, des étapes pour le codage, en mode "pré-compression", d'un bloc construit selon les enseignements de l'invention; - la figure 7 illustre, sous forme de logigramme, des étapes pour le 15 codage, en mode "compression", d'un bloc construit selon les enseignements de l'invention; et - la figure 8 montre une configuration matérielle particulière d'un dispositif apte à une mise en oeuvre du procédé selon l'invention; La figure 2 montre un codeur EXI 2 pour la mise en oeuvre de 20 l'invention, activée par un utilisateur depuis une application 1 offrant une interface utilisateur. Le codeur 2 prend en entrée un document XML 10 à coder selon d'éventuelles options de codage 17 que l'utilisateur a précisées. Une telle option de codage peut notamment consister au choix d'un des modes "pré- 25 compression" ou "compression". L'utilisateur peut également indiquer, via l'interface utilisateur, une contrainte mémoire 18, que le codeur 2 utilise pour la formation des blocs de codage comme décrit par la suite. Cette contrainte mémoire précise notamment une limite de mémoire disponible au niveau d'un décodeur pour le flux EXI 30 compressé selon l'invention. Cette limite est notamment due au fait que le décodeur est mis en oeuvre sur un terminal mobile de faible capacité mémoire. Cette taille de bloc peut également être fournie par un dispositif de mise en paquets des informations EXI en vue de leur échange via un protocole de communication réseau spécifique. Le parcours du document XML 10 par le codeur 2 se fait de façon classique par un analyseur syntaxique XML 21 qui extrait progressivement les informations sous forme d'événements XML 22. Les éventuelles options de codage 17 sont traitées par le module de configuration 20 qui les répercute sur les différents modules de codage 23 (codage des priorités), 24 (codage des noms) et 25 (codage des valeurs) afin de paramétrer ces derniers en fonction des valeurs de ces options. Ces différents modules de codage utilisent des données 'type d'événement', 'nom qualifié d'événement' et 'valeur d'événement' récupérées depuis l'analyseur 21 respectivement par le module de récupération de type 35, le modules de récupération de nom 29 et le module de récupération de valeur 28. Par exemple, le codeur de priorités 23 code soit tous les types 15 d'événement XML, soit une sous-partie de ceux-ci, en fonction des valeurs des options de préservation. Le codeur EXI 2 produit au final un flux EXI 19 généré par son générateur de bits 30. Ce générateur de bits 30 est également configuré par le module de configuration 20, notamment en ce qui concerne les options 20 d'alignement ("byte-aligned"), de compression, de taille de bloc, de conditions d'indexation et de contrainte mémoire 18 à respecter. Par exemple, si le mode d'alignement indiqué dans les options de codage 17 correspond au mode "pré-compression", le générateur de bits 30 organise les informations selon les canaux de structure et de valeurs avant de 25 les coder et les émettre sous forme d'événements EXI 39 vers l'application 1. Pour cela, le générateur de bits 30 contient un canal de structure 31 qui permet de stocker les codes de priorité ainsi que les noms d'éléments et d'attributs définissant la structure du document XML 10, et des canaux de valeurs 32 permettant de stocker les différentes valeurs des événements XML 30 de type texte ou les valeurs d'attributs. Ces valeurs sont celles récupérées au niveau de l'analyseur 21, par le module de récupération des valeurs 28. Pour générer le flux EXI, ces valeurs sont ensuite codées par le module 25 à l'aide des dictionnaires de chaînes de caractères ou dictionnaires de codage 27. Les tailles des informations ainsi stockées au cours du codage sont comptabilisées par le compteur de bits 33 qui permet de savoir si le compteur a atteint la contrainte mémoire 18 fixée par l'application 1. L'invention s'intéresse notamment à une gestion optimisée de la mémoire utilisée par le codeur lors du codage du document XML 10, notamment l'espace mémoire utilisé pour le stockage des dictionnaires de codage 27 et des canaux de valeurs 32. L'invention s'intéresse également, sous certains aspects, à optimiser la décomposition du document XML 10 en blocs de sorte à respecter des contraintes mémoire liées par exemple au décodeur. Il en résulte des blocs de taille variable en termes de nombres de valeurs d'événements, ce qui diffère des solutions de l'état de la technique. En référence aux figures 3 à 7, il est maintenant décrit la formation des flux compressés selon le procédé de l'invention et compatibles avec la spécification EXI. La figure 3 montre, sous forme de logigramme, des étapes de codage selon l'invention d'un document XML 10 selon le format EXI en mode pré-compression ou compression précisé dans les options de codage 17.

Ce processus débute par une étape E200 de réception d'un événement XML à coder au niveau de l'analyseur 21. Nous illustrerons la suite à l'aide de l'événement attribut "date="2007-09-12" de la figure 1. A l'étape E201, on teste si cet événement est à coder ou non. Le résultat dépend des options de codage 17 choisies au niveau de l'application 1.

Si l'événement est à coder, on procède successivement au codage des informations de structures (étapes E202 à E210), puis à celui des valeurs de l'événement s'il y en a (étapes E211, E213). La présente invention se concentre sur ce dernier codage. A l'étape E202, le codeur de priorités 23 vérifie s'il existe dans la grammaire courante une production spécifique permettant de représenter l'événement courant dont il a récupéré le type du module 35. A titre illustratif uniquement, selon la notation EXI, on peut rechercher une production de type SE(qname) ou AT(qname) ou CH avec un code de longueur 1, où qname est le nom qualifié de l'événement courant. Dans notre exemple, on recherche une production AT(date). Si aucune production n'est trouvée, le type de l'événement est codé, à l'étape E203, en utilisant une production générique (type AT(*)) de la grammaire courante. Puis, s'il s'agit d'un événement possédant un nom qualifié (test à l'étape E204, dans notre exemple "date"), la valeur de son URI est codée en E205 par le codeur de nom 24, puis celle de son ou ses préfixes en E207 si ceux-ci doivent être conservés (test à l'étape E206). En cas de test E206 faux et suite à l'étape E207, le nom local, "date" dans notre exemple, est récupéré du module 29 puis codé par le codeur de nom 24 lors de l'étape E208. Toutes ces informations sont stockées les unes à la suite des autres 15 dans le canal de structure 31 du générateur de bits 30, comme on peut le voir dans la troisième ligne du canal 11, figure 1. L'étape suivante E209 consiste pour le codeur de priorités 23 à mettre à jour la table des grammaires 26 en ajoutant une production spécifique (AT(date)) et/ou en créant une nouvelle grammaire conformément à la 20 spécification EXI pour chaque nouveau début d'élément (SE). Chaque donnée écrite dans le canal de structure entre les étapes E202 et E209 contribue à incrémenter le compteur de bits 33 d'autant de bits qu'il est nécessaire pour représenter chacune des priorités utilisées et les noms qualifiés codés. Dans le cas d'un test E202 positif, où une production spécifique 25 AT(date) a été trouvée, l'événement XML est alors uniquement codé, lors de l'étape E210, à l'aide du code de priorité associé à la production trouvée. Dans notre exemple, c'est le cas pour la deuxième occurrence de "date="2007-09-12", produisant la ligne 15 du canal 11. Le compteur de bits 33 est alors augmenté de la longueur binaire de 30 cette priorité. Suite au codage des informations de structure, l'analyse de l'événement XML courant par le récupérateur de valeur 28 permet au cours du test E211 de déterminer si une valeur d'événement est à coder. Dans notre exemple, la valeur "2007-09-12" est à coder. Si ce n'est pas le cas, le codage se poursuit en considérant l'événement suivant dans le document XML en E212.

Sinon, cette valeur d'événement est codée par le codeur de valeur 25 au cours de l'étape E213 qui est décrite ci-après en référence à la figure 4. L'événement suivant est ensuite considéré à l'étape E212. La figure 4 montre, sous forme de logigramme, des étapes de codage d'une valeur d'événement selon l'invention.

A l'étape E300, le codeur de valeur 25 reçoit une valeur d'événement XML à coder, correspondant à la valeur en sortie "oui" de l'étape E211. Le test E301 au niveau du codeur de valeur 25 vérifie si cette valeur à coder est nouvelle ou bien si elle est déjà présente dans le ou un des dictionnaires de codage 27.

Cette étape assure qu'une seule occurrence est stockée par valeur d'événement, limitant ainsi la consommation mémoire du codeur EXI 2. Si cette valeur est nouvelle (première occurrence de "2007-09-12" par exemple), cette valeur d'événement est codée littéralement en E302 selon la spécification EXI.

Ensuite cette valeur est pré-indexée dans le dictionnaire de codage 27 lors de l'étape E303. Ce dictionnaire 27 est par exemple mis en oeuvre sous la forme d'une table de hachage qui associe, à une valeur donnée, une entrée particulière. Cette entrée est définie à la fois dans la partition de valeurs globale (représentant l'ensemble du dictionnaire) et dans une partition de valeurs locale (associée à un nom qualifié QName en anglais) définies par la spécification EXI. Comme illustré sur la figure 5, le dictionnaire de codage 27 comprend donc des partitions 40 de valeurs 41, chaque partition dite "locale" 40 étant associée à un nom qualifié. A chaque entrée 45 correspondant à une valeur 41 sont associés un index de partition globale (index global 42), un index de partition locale (index local 43) propre à la partition 40 à laquelle l'entrée considérée appartient et, de manière optionnelle, sa valeur codée 44 calculée à l'étape E302. L'index local 43 est relatif à la partition locale de valeurs 40 ce qui permet de représenter, de façon efficace en terme d'accès et peu coûteuse en terme de mémoire, l'index de l'entrée considérée. L'étape de recherche E301 permet de conserver, pour une autre occurrence de la valeur d'événement, un lien vers l'entrée du dictionnaire correspondant à cette même valeur. La pré-indexation de l'étape E303 consiste à créer une nouvelle entrée 45 dans le dictionnaire 27 pour la valeur d'événement en question, et à mettre l'index global 42 de cette nouvelle entrée à '-l' si la chaîne est indexable, à '-2' sinon. L'index local 43 est déterminé conformément à la spécification EXI, c'est-à-dire qu'il correspond à l'index local 43 précédent dans la même partition 40 plus '1'. Ainsi, on incrémente progressivement, depuis 0, les index locaux à l'intérieur d'une même partition 40. En variante, cet index local 43 peut également être mis à '-1' lors de l'ajout de l'entrée correspondante et calculé lors de l'étape E459 comme décrit ci-après. Suite à l'insertion E303 ou suite à l'identification d'une entrée dans le dictionnaire de codage 27 (sortie 'non' de l'étape E301), le compteur de bits 33 est respectivement incrémenté, à l'étape E304, du nombre d'octets correspondant à la taille de la valeur codée 44 lorsqu'il s'agit d'une première occurrence (nouvelle entrée dans la table) ou d'une valeur non indexable, ou du nombre d'octets nécessaires à la représentation de la taille du dictionnaire de valeurs 27 plus 1, pour les occurrences ultérieures indexables. Ce dernier cas permet d'estimer la taille de la valeur codée par référence à une entrée du dictionnaire, et donc le nombre de bits nécessaires pour représenter l'index à utiliser pour coder la valeur. L'avantage direct est que l'estimation de la taille en octets du bloc codé courant se fait à un coût quasi nul. Le procédé se poursuit par la constitution de canaux de valeurs. Comme on le verra ci-après, l'invention prévoit un canal par nom qualifié, donc les valeurs sont regroupées dans un même canal de valeurs selon le critère d'appartenance à un même nom qualifié. Afin d'optimiser la réorganisation des valeurs selon le nom qualifié auxquelles elles sont rattachées, le codeur de valeur 25 récupère du codeur de nom 24 le nom qualifié ("date" dans notre exemple) relatif à la valeur codée en E302 et vérifie si un canal de valeur existe déjà pour ce nom qualifié en E305. Si aucun canal de valeur ne correspond (c'est le cas lors de la première occurrence de l'attribut "date" dans le document XML), le codeur de valeur 25 indique, en E306, au générateur de bits 30 de mettre à jour sa liste de canaux de valeurs avec un nouveau canal associé à ce nom qualifié. Dans notre exemple, cela correspond à la création du canal 13 (vide à ce moment). Grâce à cette étape E306, les canaux de valeurs se trouvent ordonnés dès leur création. Ceci permet d'éviter au codeur 2 de maintenir l'ordre d'apparition des noms qualifiés et de parcourir au moment du codage du bloc l'ensemble des canaux valeurs afin de les trier selon cet ordre d'apparition, comme c'est le cas dans les solutions de l'art antérieur. Un gain en consommation mémoire est ainsi obtenu, de même qu'une rapidité de codage puisque le tri n'est plus nécessaire. Suite à l'étape E306 ou si un canal associé au nom qualifié de la valeur à coder est présent ('non' en sortie du test E305, par exemple pour la deuxième occurrence d'un attribut "date" dans le document XML 10 de la figure 1), le codeur de valeur 25 insère (étape E307) dans le nouveau canal de valeurs ou celui déjà existant un lien (ou une référence) vers l'entrée 45 du dictionnaire 27 associée à la valeur à coder. Il s'agit de l'entrée trouvée lors de la recherche dans le dictionnaire de valeurs 27 en E301 ou nouvellement créée lors des étapes E302 et E303. Ce lien peut prendre la forme d'un pointeur vers ladite entrée 45 du dictionnaire 27. Contrairement à ce qui a pu se faire dans les solutions connues de l'art antérieur, l'invention ne stocke pas directement de valeurs d'événement à coder mais de simples références aux entrées du dictionnaire correspondant à ces valeurs.

Cette constitution des canaux par référence aux entrées du dictionnaire, plutôt que de stocker la valeur elle-même, permet d'éviter le stockage multiple d'une même valeur et donc offre une gestion mémoire plus efficace ainsi qu'une précision accrue dans l'estimation de la taille du bloc de codage. En outre, cette référence ou ce lien donne accès immédiatement à l'index de codage (local ou global) dans le dictionnaire sans effectuer de recherche supplémentaire autre que la vérification de l'étape E301. Au sortir de l'étape E307, on vérifie, à l'étape E308, si le compteur de bits 33 a atteint la valeur limite prédéfinie fixée par l'application 1 via la contrainte mémoire 18. Si ce n'est pas le cas, le codeur de valeur 25 se met en attente d'une nouvelle valeur à coder en E300, ce qui correspond à la fin de l'étape E213 de la figure 3 qui se poursuit par la recherche d'un événement suivant à coder en E212. Si le test de l'étape E308 indique au contraire que la contrainte mémoire est atteinte, on suspend le parcours du document XML pour générer une portion du flux EXI codé final à partir des canaux générés à cet instant. On voit ainsi que l'on forme un bloc qui ne contient pas nécessairement le même nombre d'événements et valeurs XML à chaque fois. Le bloc est donc de taille variable en ce qui concerne le nombre d'événements XML et adaptée en fonction de la contrainte mémoire 18 fixée. Ainsi, le générateur de bits 30 procède à la construction du bloc en assemblant les canaux de structure et de valeurs. C'est l'objet de l'étape de codage des canaux de valeurs E309 qui est décrite ci-après en lien avec les figures 6 et 7 pour aboutir à l'obtention de la portion de flux EXI soit "pré-compressé", soit "compressé", correspondant à la portion du document XML parcourue. L'étape E309 est suivie de la remise à zéro de tous les canaux de structure 31 et de valeurs 32 lors de l'étape E310, en vue du codage du bloc suivant (bouclage sur l'étape E300). Ainsi, la génération de blocs codés dont la taille est inférieure à une valeur limite prédéfinie est itérée.

La figure 6a montre, sous forme de logigramme, des étapes pour le codage, en mode "pré-compression", d'un bloc construit selon les enseignements de l'invention. Si le nombre de valeurs codées pour le bloc est inférieur à 100 (test E400), qui est le nombre limite de valeurs codées par bloc selon la spécification EXI, un seul flux compressé est construit qui contient successivement les informations du canal de structure (E401) concaténées avec les valeurs référencées dans les canaux de valeurs 32, en prenant les canaux les uns après les autres dans l'ordre de leur constitution.

Les valeurs référencées dans les canaux de valeur 32 ayant été pré-indexées lors de l'étape E303, elles doivent être indexées selon l'ordre des canaux de valeurs 32. Cette indexation, objet de l'étape E402, est décrite en référence à la figure 6b ci-après. Aussitôt indexées, les valeurs sont insérées dans le flux compressé 19 à la suite des autres valeurs précédemment indexées, puis l'ensemble est émis vers l'application 1 au cours de cette même étape E402. Si le nombre de valeurs codées pour le bloc est supérieur à 100 (sortie oui du test E400), les informations du canal de structure 31 sont d'abord émises (étape E403) de façon similaire à l'étape E401.

Dans ce mode de réalisation, l'ordre d'émission des valeurs est généralement différent de l'ordre des canaux de valeurs 32 en raison de recombinaisons comme expliqué ci-après. Ceci influe sur l'indexation des valeurs codées. Dans ce cas, leur indexation se déroule comme suit. Une première passe sur les canaux de valeurs 32, en E404, permet d'identifier tous les canaux possédant moins de 100 valeurs, puis de rassembler les valeurs de ces canaux en un même flux compressé. Les valeurs référencées dans ce canal "recombiné" sont alors indexées (codées) puis le canal est émis immédiatement après le canal de structure 31. Pour cela, pour chaque canal de valeur 32 possédant moins de 100 valeurs, le générateur de bits 30 parcourt la liste des liens vers les entrées du dictionnaire 27 comme décrit ci-après en lien avec la figure 6b.

La deuxième passe consiste ensuite à considérer en E405 les canaux de valeurs 32 ayant plus de 100 valeurs. Pour chacun de ces canaux, le générateur de bits 30 crée un flux compressé selon les étapes de la figure 6b. Les flux sont alors émis.

Les étapes de la figure 6b permettent de générer les index de codage 42, 43 associés à chacune des entrées 45 du dictionnaire 27 pour un canal à coder, aux fins de produire le flux EXI compressé (lorsque itéré pour l'ensemble des canaux). Il s'agit donc de la représentation au sens EXI des chaînes de valeurs contenues dans ces canaux.

Selon l'invention, il s'agit d'un mécanisme d'indexation a posteriori qui évite tout traitement d'indexation préalable inutile du fait de la réorganisation des valeurs en canaux. Grâce à la pré-indexation de l'étape E303, les valeurs n'apparaissent qu'une fois dans le dictionnaire de chaînes de valeurs 27 du codeur 2.

A l'étape E450, le générateur de bits 30 récupère, dans le canal courant à coder, le premier lien vers une entrée 45 du dictionnaire 27. L'entrée ainsi récupérée donne un accès à la chaîne de valeurs codée 44 selon EXI, à son index global 42 et à son index local 43 ainsi qu'à un identifiant de nom qualifié (non représenté et qui définit la partition 40).

Grâce à ces informations, le générateur de bits 30 récupère en E451 l'index global 42 de la chaîne de valeurs représentée par l'entrée 45 courante. A l'étape E452, un test vérifie si l'index global 42 est positif ou nul. S'il est positif ou nul, cela signifie que la valeur à coder a déjà été rencontrée et indexée. Dans ce cas, à l'étape E453, on vérifie si le nom qualifié associé à cette entrée 45 (donc le nom qualifié définissant la partition 40 associée) est le même que le nom qualifié associé au canal de valeurs 32 courant. Si c'est le cas, l'index local 43 (plus compact car limité au nombre d'entrées 45 dans la partition correspondante 40) est utilisé pour coder la valeur.

Ainsi, à l'étape E454, on récupère l'index local 43 de l'entrée 45 courante auquel on associe un marqueur, par exemple un bit, permettant d'identifier qu'il s'agit d'un index local (et non global). Cet index local 43 est calculé lors de la première occurrence de la valeur d'événement 41 associée, comme décrit ci-après en lien avec l'étape E459. Sinon (sortie non de l'étape E453), à l'étape E455, le générateur de bits 33 récupère l'index global 42 associé à l'entrée 45 courante. Il lui ajoute un marqueur binaire indiquant "index global".

La valeur marquée obtenue à l'étape E454 ou E455 est alors inscrite, à l'étape E456, dans le flux compressé à émettre vers l'application 1 (la compression de la valeur n'est effectuée que lorsque le mode compression est actif). Le traitement se poursuit ensuite en considérant, à l'étape E457, le lien suivant dans le canal de valeurs 32 courant, et en itérant de la sorte jusqu'au dernier lien contenu dans ce canal de valeurs courant. En revanche, si le test de l'étape E452 indique un index global 42 négatif (en l'espèce égal à -1 ou -2), cela signifie que la valeur courante n'a pas encore été rencontrée et indexée.

Le test E458 permet de traiter séparément les deux cas: -1 ou -2. Dans le cas où l'index 42 vaut -1, l'étape E459 consiste en la mise à jour de l'entrée courante 45 du dictionnaire de valeurs 27 en mettant les index locaux 43 et globaux 42 égaux aux index dernièrement utilisés, incrémentés de 1.

Ces index sont notamment mémorisés dans deux compteurs. L'index global 42 est maintenu par un premier compteur dans le générateur de bits 30 pour l'ensemble du dictionnaire de codage 27 (partant de 0 pour la première entrée et incrémenté à chaque nouvelle entrée dans le dictionnaire).

L'index local 43 est stocké dans un deuxième compteur, mis à zéro à chaque début d'indexation d'un nouveau canal de valeurs (étape E450) puis incrémenté à chaque entrée de la partition correspondant au canal.

Si la valeur d'index global récupérée est inférieure à -1 (sortie 'oui' du test E458), cela signifie que la valeur ne doit pas être indexée. L'index global 42 correspondant est alors incrémenté d'une unité en E460 de sorte à prendre la valeur '-1'.

A détection de cette nouvelle valeur prise égale à -1, l'entrée 45 correspondante est alors effacée du dictionnaire de valeurs 27 au cours de cette même étape E460. Ceci permet de ne pas mobiliser les ressources mémoires du codeur inutilement en conservant dans le dictionnaire des valeurs inutiles.

Suite aux étapes E459 et E460, la valeur codée 44 représentant la chaîne est insérée dans le flux compressé en E461 avant émission (E456). Cette valeur codée 44 peut alors être supprimée de l'entrée correspondante, afin de récupérer de l'espace mémoire. En effet, les occurrences suivantes étant codées à l'aide des index, cette valeur codée n'a plus d'utilité. On poursuit ensuite à l'étape E457 comme décrit précédemment, jusqu'à épuisement des liens dans le canal de valeurs courant 32. La figure 7 montre, sous forme de logigramme, des étapes pour le codage, en mode "compression", d'un bloc construit selon les enseignements de l'invention. Si le nombre de valeurs codées pour le bloc est inférieur à 100 (test E500), toutes les valeurs référencées dans les canaux de valeurs 32 seront émises dans un même flux compressé selon les étapes E501 à E503, indexées selon l'ordre des canaux de valeurs 32 et concaténées avec les informations de structure compressées en E501. L'étape E501 consiste pour le compresseur 34 à appliquer l'algorithme de compression DEFLATE aux données contenues dans le canal de structure 31 et à les stocker dans le flux EXI compressé 19 en cours de construction.

L'étape suivante E502 consiste à indexer l'ensemble des valeurs des canaux de valeurs 32 selon les étapes de la figure 6b décrite ci-dessus, en conservant l'ordre des canaux. Toutefois dans ce cas, lors de l'étape E456, la valeur de codage obtenue est compressée par le compresseur 34 et insérée dans le flux compressé 19 en cours de construction. Enfin, en E503, le compresseur 34 finalise la compression du flux compressé et le générateur de bits 30 l'envoie à l'application 1. Cette finalisation comprend notamment l'ajout de l'information quant au nombre de valeurs contenues dans le bloc qui va être émis. Si au contraire plus de 100 valeurs ont été codées (sortie oui du test E500), deux passes sont nécessaires sur les canaux de valeurs 32, de façon similaire à ce qui a été décrit en lien avec la figure 6a.

Tout d'abord, les informations de structure 31 sont compressées en E504 par le compresseur 34 qui finalise (ajout du nombre de valeurs codées dans le bloc courant) le flux compressé 19 propre à ces informations. Ce flux est alors envoyé à l'application 1 au cours de l'étape E505. Une première passe permet de considérer les canaux de valeurs 32 référençant moins de 100 valeurs de sorte à les recombiner en un unique canal. Ces canaux sont alors parcourus au cours de l'étape E506 en conservant leur ordre de création. Leurs valeurs sont alors indexées et compressés selon les étapes de la figure 6b. A l'étape E507, le flux compressé ainsi obtenu est transmis à l'application 1 par le générateur de bits 30. La seconde passe itère (étapes E508 à E510) un traitement d'indexation, compression et émission sur les canaux de valeurs référençant plus de 100 valeurs, en conservant leur ordre de création. Au cours de l'étape E508, les valeurs référencées dans un canal 25 sont indexées et compressées selon les étapes de la figure 6b. Puis, pour chaque canal, le compresseur 34 émet, à l'étape E509, le flux compressé correspondant vers l'application 1. Ceci est réalisé jusqu'à atteindre le dernier canal de valeurs de la liste 32 (test E510). Comme on a pu le voir ci-dessus, l'invention permet d'ajuster 30 dynamiquement la taille des blocs de codage aux contraintes mémoire du décodeur. Dans un mode de réalisation, on prévoit alors d'inclure au début de chaque portion de flux EXI correspondant à un bloc codé, une information sur la taille du bloc généré par le codeur EXI 2 conformément à l'invention. Cela facilite le décodage des blocs. En pratique, en début de l'étape E309, le codeur EXI 2 insère dans le flux binaire généré une information précisant la taille du bloc qui suit (en nombre de valeurs représentées dans le bloc). Cette taille est représentée par son codage sous forme d'entier non signé. On peut à ce titre utiliser le codage d'entier non signé conformément à la spécification EXI. Pour signaler au décodeur que de telles informations de taille de blocs sont insérées dans le flux, on prévoit d'utiliser le champ blockSize prévu dans l'en-tête du flux binaire 19, que l'on met à la valeur -1 afin de signaler que les tailles de blocs sont variables et signalées dans le flux. Ainsi dans ce mode de réalisation, un décodeur EXI réalisant les étapes inverses du codeur EXI 2 est informé sur la nature du flux qu'il reçoit et peut ainsi considérer cette information relative à la taille du bloc avant de reconstruire le bloc en question. Ce mode de réalisation peut s'appliquer au cas d'un document (par exemple un document au format Microsoft Word) où chaque page est codée en tant qu'élément indépendant (self-contained, selon la terminologie EXI). Dans ce cas, la taille de bloc pourrait correspondre à la taille d'une page du document pour permettre une meilleure gestion mémoire lors de la reconstruction et la lecture de ce document et d'un point de vue utilisateur pour permettre d'afficher la page dès que ce bloc est reçu et décodé. L'invention s'applique plus largement à tout document structuré codé et émis vers une application supportant la pagination. Dans ce cas, la taille de bloc peut correspondre à la taille d'une page. Pour la complétude du traitement, le décodage du flux EXI 19 est mené de façon classique par le décodeur lorsque celui-ci est amené à traiter des flux EXI codés en mode "pré-compressé" ou "compressé". Toutefois, au lieu de manipuler des canaux de taille constante en nombre de valeurs dans le flux, le décodeur lit la valeur du champ blockSize dans l'en-tête du flux 19 pour identifier si les blocs sont de taille variable.

Si c'est le cas, le décodeur procède au décodage de chaque bloc en récupérant au préalable la taille de ce dernier, afin de traiter le bon nombre d'événement EXI. Le décodage de chacun des canaux de structure et de valeurs est conforme à la spécification EXI. Comme il ressort de ce qui précède, la présente invention permet de coder n'importe quel document XML en tenant compte des ressources mémoires du codeur ou du décodeur ou d'un paquetiseur EXI. Pour cela, elle segmente dynamiquement le document XML des blocs (tels que définis par la spécification EXI) de taille variable en fonction de contraintes, par exemple de mémoire. Il en résulte une consommation moindre de la mémoire, un codage plus efficace, tout en conservant un flux binaire compatible avec le format EXI. Par ailleurs, l'invention est compatible avec l'option bounded tables d'EXI, qui permet de ne pas indexer certaines chaînes de valeurs. En référence à la figure 8, il est maintenant décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de codage ou décodage d'un document structuré apte à une mise en oeuvre du procédé selon l'invention.

Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau. Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, relié à une carte d'entrée/sortie (non représentée) et fournissant au dispositif de traitement d'information des données multimédia, éventuellement sous forme de documents XML.

Le dispositif 50 comporte un bus de communication 51 auquel sont reliés : - une unité centrale de traitement CPU 52 se présentant par exemple sous la forme d'un microprocesseur ; - une mémoire morte 53 dans laquelle peuvent être contenus les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention ; - une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention nécessaires à la mise en oeuvre de l'invention ; - un écran 55 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - un lecteur de disquettes 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 63 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données. Dans le cas de données audio, le dispositif 50 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 62. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 50 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50. Les disquettes 52 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de codage ou décodage d'un document structuré, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Le code exécutable permettant au dispositif de codage ou décodage d'un document structuré la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 58 par exemple) avant d'être exécuté. L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC).

Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 2 à 7, pour mettre en oeuvre le procédé objet de la présente invention et constituer le dispositif objet de la présente invention.

Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (17)

1. REVENDICATIONS1. Procédé de codage d'un document structuré (10) composé d'événements à coder (22) présentant des valeurs (41), comprenant les étapes suivantes: - parcourir le document pour traiter des événements; - constituer (E306, E307) des canaux de valeurs (32) regroupant des valeurs d'événements selon au moins un critère; - coder (E309) les canaux de valeurs ainsi constitués par codage des valeurs d'événement (41) de chacun de ces canaux de valeurs à l'aide d'au moins un dictionnaire de codage (27); caractérisé en ce que l'étape de constitution comprend, pour chaque événement à coder parcouru ayant une valeur (41), l'association (E307) de cette valeur à coder à un desdits canaux de valeurs (32) par référence, dans ledit canal de valeurs, à une entrée (45) du dictionnaire de codage (27).
2. 2. Procédé selon la revendication précédente, dans lequel l'étape de constitution comprend, préalablement à ladite association, une étape d'ajout (E306), dans ledit dictionnaire de codage (27), d'une entrée (45) correspondant à ladite valeur à coder si cette dernière ne s'y trouve pas déjà.
3. 3. Procédé selon la revendication précédente, dans lequel la nouvelle entrée (45) ajoutée est partielle en ce qu'elle ne comprend pas, lors de son ajout, d'index de codage (42, 43) calculé pour le codage de la valeur correspondante.
4. 4. Procédé selon la revendication précédente, dans lequel l'au 25 moins un index de codage (42, 43) d'une entrée nouvellement ajoutée prend une première valeur particulière lors de cet ajout.
5. 5. Procédé selon la revendication précédente, dans lequel le codage des canaux de valeurs (32) pour générer au moins un flux codé (19) comprend: 30 - le parcours desdits canaux de valeurs de sorte à récupérer, dans ledit dictionnaire de codage (27), un index de codage pour chaque valeur à coder (41), à l'aide de ladite référence;- le remplacement (E459), dans ledit dictionnaire de codage (27), de l'au moins un index de codage (42, 43) associé à une référence parcourue, par une valeur courante d'index, lorsque cet au moins un index de codage (42, 43) vaut ladite première valeur particulière.
6. 6. Procédé selon la revendication 5, dans lequel une entrée (45) du dictionnaire de codage (27) comprend en outre une valeur codée (44) correspondant au codage littéral de ladite valeur associée à cette entrée, et ladite valeur codée (44) est supprimée dudit dictionnaire (27) lors du codage (E461), à l'aide de la valeur codée (44), de la valeur d'événement associée à ladite référence parcourue.
7. 7. Procédé selon la revendication 3, dans lequel l'au moins un index de codage (42, 43) d'une entrée nouvellement ajoutée prend une deuxième valeur particulière lors de cet ajout, de sorte à indiquer que les occurrences ultérieures de la valeur de l'événement ne sont pas encodées à l'aide d'un index.
8. 8. Procédé selon la revendication précédente, dans lequel l'étape de codage des canaux comprend l'ajout d'une valeur prédéterminée à l'au moins un index de codage (42) de l'entrée (45) associée à une référence d'un canal à coder, lorsque cette entrée comprend initialement un index de codage égal à la deuxième valeur particulière, et la suppression (E460), dans le dictionnaire de codage (27), de cette entrée, lorsque cet index de codage devient égal à la première valeur.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel on crée lesdits canaux de valeurs au fur et à mesure du parcours dudit 25 document en conservant leur ordre de création.
10. 10. Procédé selon la revendication précédente lorsqu'elle dépend de la revendication 5, dans lequel, préalablement audit parcours des canaux de valeurs, on recombine (E404, E506) des canaux parmi la pluralité de canaux de valeurs en fonction d'au moins un critère de sorte à obtenir au moins un canal 30 de valeurs recombiné.
11. 11. Procédé selon l'une des revendications précédentes, comprenant, pour chaque association d'une valeur à un canal de valeurs, les étapes suivantes: - estimer un nombre de bits nécessaires pour coder ladite valeur d'événement; - augmenter (E304) un compteur de bits (33) dudit nombre de bits estimé; - utiliser ledit compteur de bits pour diviser ledit document structuré en une pluralité de blocs de données à coder séparément.
12. 12. Procédé selon la revendication précédente, dans lequel le nombre de bits estimé vaut le nombre de bits nécessaires pour représenter le nombre, augmenté de 1, d'entrées (45) dudit dictionnaire de codage (27).
13. 13. Procédé selon la revendication 11 ou 12, dans lequel on arrête la constitution des canaux (32) et on procède à leur codage (E309) lorsque ledit compteur de bits atteint (E308) une valeur prédéfinie de sorte à générer au moins un flux codé (19) correspondant à une partie du document (10).
14. 14. Procédé selon la revendication précédente, dans lequel on itère la génération d'au moins un flux codé en fonction de la valeur prédéfinie, pour coder une pluralité de parties successives du document structuré.
15. 15. Dispositif de codage (2) d'un document structuré (10) composé 20 d'événements à coder (22) présentant des valeurs, comprenant: - un moyen apte à parcourir le document pour traiter des événements; - un moyen de constitution de canaux de valeurs (32) regroupant des valeurs d'événements selon au moins un critère; - un moyen de codage des canaux de valeurs ainsi constitués par codage des 25 valeurs d'événement de chacun de ces canaux de valeurs à l'aide d'au moins un dictionnaire de codage (27); caractérisé en ce que ledit moyen de constitution est apte à associer, pour chaque événement à coder parcouru ayant une valeur, cette valeur à coder à un desdits canaux de valeurs par référence, dans ledit canal 30 de valeurs, à une entrée du dictionnaire de codage.
16. 16. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant desinstructions pour un programme informatique adapté à mettre en oeuvre le procédé de codage conforme à l'une quelconque des revendications 1 à 14, lorsque le programme est chargé et exécuté par le système informatique.
17. 17. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de codage selon l'une quelconque des revendications 1 à 14, lorsqu'il est chargé et exécuté par le microprocesseur.