FR2939535A1 - Procede et systeme de traitement pour la configuration d'un processseur exi - Google Patents

Abstract

La présente invention concerne un procédé et un système de traitement pour la configuration d'un processeur de codage/décodage de documents structurés type XML. Le procédé comprend la génération (E110) d'au moins un modèle unifié (MU) représentatif de la structure d'un type d'élément à partir d'au moins un document structuré de configuration (10A, 10B, 10C), ledit modèle unifié (MU) comprenant une information (f ) sur des transitions (TR) entre items (ID, IS) réalisées dans les occurrences dudit type d'élément au sein des documents de configuration, et l'optimisation (E120, E605) dudit modèle unifié (MU), à l'aide des informations (f ) de transitions (TR), par suppression (E612) d'au moins une transition (TR) et/ou regroupement (E622) d'au moins deux transitions (TR). Ainsi, les informations de transitions permettent de configurer le processeur avec un nombre limité et adapté de productions pour le codage ou le décodage des documents structurés.

Description

La présente invention concerne un procédé et un système de traitement pour la configuration d'un processeur de codage/décodage de documents structurés. Elle s'applique, en particulier, aux documents de type XML (acronyme de Extensible Markup Language pour langage de balisage extensible).

Le langage XML est une syntaxe pour définir des langages informatiques. XML permet ainsi de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et se terminant par une balise fermante comportant, elle aussi, le nom de l'élément (par exemple: </balise>). Chaque élément peut contenir d'autres éléments de façon hiérarchique, constituant une structure hiérarchique de données, ou des données textuelles. D'autre part, un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple : <balise attribut="valeur">). La syntaxe XML permet aussi de définir des commentaires (par exemple: <!-- Commentaire-->) et des instructions de traitement, qui peuvent préciser à une application informatique les traitements à appliquer au document XML (par exemple : <?montraitement?> ), ainsi que des sections d'échappement qui permettent d'éviter qu'une section de texte soit interprétée comme une balise lorsqu'elle en a la forme (par exemple : <![CDATA[<texte>Echappement</texte>]]> où <texte> est reconnu comme une chaîne de caractère et non pas une balise). Dans la terminologie XML, l'ensemble des termes élément (identifié par une balise ouvrante), attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement définissant les données XML sont regroupés sous le nom générique de item . Plusieurs langages différents basés sur le XML peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace selon la terminologie anglo-saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier , pour Identifiant uniforme de ressource), par exemple http://canon.crf.fr/xml/monlangage . L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: l'attribut xmins:ml="http://canon.crf.fr/xml/monlangage" associe le préfixe ml à l'URI http://canon.crf.fr/xml/monlangage ). Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de : (par exemple: <ml:balise ml:attribut="valeur"> indique que l'élément balise découle de l'espace de nommage ml et qu'il en est de même pour l'attribut attribut). Le format 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. Toutefois, le principal inconvénient de la syntaxe XML est d'être très prolixe, amenant parfois la taille d'un document XML à ê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 à cet inconvénient, des 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, permettant de reconstruire facilement le document XML. Une méthode simple consiste par exemple à remplacer les items XML par des symboles. D'autres méthodes plus évoluées existent, notamment les formats XML Binaire, parmi lequel on connaît le format EXI ("Efficient XML Interchange") ou Fast Infoset, permettant de conserver nombre d'avantages du format XML malgré le codage. EXI est un format XML Binaire actuellement standardisé par le W3C qui utilise un ensemble de grammaires pour coder un document XML. Pour pouvoir coder les items compris dans un document XML, la spécification Efficient XML divise chacun des éléments rencontrés dans le document à coder, en parties élémentaires appelées événements, par exemple une balise ouvrante ou un attribut.

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 le codage de l'événement suivant). Pour coder un événement XML à l'aide d'une grammaire, la production contenant la description la plus précise de l'événement XML est utilisée. La valeur de codage contenue dans cette production est utilisée pour représenter l'événement, et les informations contenues dans l'événement et non décrites dans la production sont codées. Une grammaire selon Efficient XML est évolutive. Dans un certain nombre de cas, après l'occurrence d'un événement XML déjà décrit par une production de la grammaire (s'il n'est pas décrit par une production, il ne peut être encodé par la grammaire), la grammaire est modifiée pour inclure une nouvelle production correspondant à cet événement XML. Cette production peut soit contenir une description plus précise de l'événement, diminuant le nombre d'informations à coder pour représenter l'événement, soit avoir une valeur de codage plus compacte. Les valeurs de codage, ou codes , sont exprimées sous forme de priorités ayant, généralement, entre 1 et 3 niveaux. Coder une valeur de codage revient à coder les valeurs de sa priorité. Selon le mode de codage le plus avantageux en termes de compression, chaque niveau est codé sur un nombre de bit minimum pour pouvoir coder la plus grande valeur de ce niveau associée à une production de la grammaire. Par exemple, pour un niveau prenant des valeurs de 0 à 6, on utilise 3 bits de codage. Pour coder un document XML, un ensemble de grammaires est utilisé. Quelques grammaires servent à coder la structure propre au document XML. En outre, pour chaque type d'élément XML présent dans le document (un type d'élément XML étant un ensemble d'éléments ayant le même nom), un même 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. Mais elles peuvent aussi être des règles spécifiques à un type de document lorsqu'elles sont construites au préalable. Cela permet d'obtenir un codage (ou décodage) plus efficace en termes de compression. 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 à partir des productions. 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 et de productions identique à celui qui était utilisé lors du codage. Deux types d'alignement sont fournis par le format EXI pour représenter les valeurs de codage : un format en octets alignés (en anglais, "byte-aligned"), pour lequel les données encodées sont alignées au niveau des octets, c'est-à-dire que chaque nouvelle chaîne de caractères débute sur un nouvel octet, par exemple, et un format en bits groupés (en anglais, "bitpacked"), pour lequel les données sont encodées sur le plus petit nombre de bits possibles. Dans ce dernier mode, les chaînes de caractères ne commencent donc pas nécessairement sur un nouvel octet. Le premier mode peut être décodé plus efficacement, tandis que le second produit des fichiers davantage compressés.

Pour obtenir des codages ou décodages plus efficaces, on a vu qu'il est intéressant de configurer à l'avance le moteur logiciel d'encodage ou de décodage avec des données externes de configuration représentatives a priori des documents à traiter.

On a ainsi envisagé de détourner l'utilisation des fichiers de description de structure Schéma XML, à cette fin. La norme XML Schema ou schéma XML définit un langage permettant de décrire la structure d'un ou plusieurs documents XML, au travers d'un document XML. Ce dernier décrit l'ensemble des éléments et des attributs pouvant être présents dans un document XML conforme à ce document XML Schema, ainsi que certaines relations entre ces éléments et ces attributs. L'utilisation classique de cette norme, également appelé "EXI Schema" lorsqu'il est rapporté au format EXI, concerne la validation de documents XML comme étant conformes à la structure attendue (celle du schéma XML). Du fait de sa nature descriptive, le document Schéma XML apparaît comme un bon candidat pour configurer les processeurs EXI. En effet, un schéma XML décrivant un modèle de données, il est possible de construire des grammaires représentant ce modèle lors de l'initialisation du codeur/décodeur. Les traitements de codage par l'encodeur (ou de décodage) sont alors réduits à la simple traduction de la description en termes de grammaires et productions. La création des grammaires à partir d'un schéma XML est notamment décrite dans la spécification EXI. Cette dernière prévoit notamment un sous-mode autorisant des déviations par rapport au schéma XML de configuration, pour les cas où un document ne respecte pas parfaitement le modèle défini dans le fichier de description de structure XML Schema. Dans ce cas, l'encodeur/décodeur prévoit d'insérer des productions génériques supplémentaires dans les grammaires afin de pouvoir encoder les parties qui ne respectent pas strictement le schéma. De cette manière, on profite de la connaissance du schéma sans pour autant nécessiter des documents parfaitement conformes.

Cependant, la création préalable de grammaires à partir d'un schéma XML, ou même à partir d'un fichier de configuration classiquement utilisé, n'offre pas systématiquement des résultats optimaux pour le codage ultérieur. En effet, en ce qui concerne le schéma XML, ce dernier est créé dans le but de vérifier la conformité de documents par rapport à ce schéma, et non dans le but de compresser des documents. Notamment, les schémas XML s'appuient sur différents modèles élémentaires qui ne reflètent que partiellement les transitions possibles entre les différents items qu'ils définissent.

On illustre cela par les trois documents de configuration 10A, 10B, 10C de la figure 1 que l'on utilise pour configurer un processeur de codage. Chacun de ces documents décrit un cercle. Pour chaque cercle, on précise le rayon (attribut r ) et les coordonnées du centre (attributs x et y ). Pour le document 10B, on précise en outre la couleur de la bordure du cercle (attribut border-color ) et la largeur de cette bordure (attribut border-width ). Enfin, pour le document 10C, on précise également une couleur de fond (attribut background-color ). Un schéma XML résultant de ces documents contient les informations suivantes : - la racine du document est un élément document , lequel contient un élément circle ; - l'élément circle possède les attributs background-color (optionnel), border-color (optionnel), border-width (optionnel), r (requis), x (requis) et y (requis).

Ensuite, si l'on construit des grammaires à partir de ces informations selon la spécification EXI Schema, sans déviation, on obtient, pour l'élément circle , les grammaires GramO, Gram 1, ... représentées à la figure 2. On constate que certaines productions, celles représentées en gras souligné dans les tables de la figure 2, ne sont jamais utilisées lorsque l'on encode les documents 10A, 10B et 10C. Ceci est dû au fait que lorsque l'on distingue simplement les attributs optionnels et requis, on ne peut pas savoir quelles sont les transitions qui ont vraiment lieu. Les grammaires construites permettent donc d'encoder les documents, mais pas de manière optimale. De telles défaillances sont également observées dans les fichiers de configuration classiques.

Dans ce dessein, l'invention vise à résoudre cet inconvénient de l'art antérieur pour améliorer de façon systématique les performances résultant du traitement par le processeur ainsi configuré. A cette fin, la présente invention vise notamment un procédé de traitement pour la génération de données de configuration d'un processeur de codage/décodage de documents structurés comprenant des items, le procédé comprenant une étape de génération d'au moins un modèle unifié représentatif de la structure d'un type d'élément à partir d'au moins un document structuré de configuration, ledit modèle unifié comprenant une information sur des transitions entre items réalisées dans les occurrences dudit type d'élément au sein dudit au moins un document structuré de configuration, et le procédé comportant une étape d'optimisation dudit modèle unifié, à l'aide des informations de transitions, par suppression d'au moins une transition et/ou regroupement d'au moins deux transitions. L'invention tire profit des spécificités de codage par productions/grammaires, notamment de la notion de priorités (c'est-à-dire les valeurs de codage des productions). En effet, en supprimant des transitions ou en en regroupant, l'invention réduit le nombre d"'objets transition" (c'est-à-dire des productions) à traiter pour un même niveau de priorité. Le processeur EXI qui est ensuite configuré à l'aide de ces informations doit alors générer un nombre plus limité de priorités sur ce niveau, ce qui peut conduire à une réduction du nombre de bits pour coder cette valeur dans le document binaire résultant. Il convient, en effet, d'étudier cette réduction au regard également du surcoût qu'entraînerait le codage des éléments correspondants aux transitions groupées/supprimées.

Pour illustrer un avantage de l'invention, on peut décider de supprimer les transitions du début d'élément <circle> vers l'item backgroundcolor et vers l'item border-color dans l'exemple précédent, sur la base de leurs fréquences de transition (10%) trop faibles. La grammaire GramO ne contiendrait alors plus que deux productions, et on n'utiliserait qu'un seul bit pour coder la priorité. Comme on le verra par la suite, les productions en gras souligné de la figure 2 peuvent également être évitées et le nombre de priorités est alors diminué. Les valeurs de codage résultantes sont codées sur un plus petit nombre de bits. En outre, un nombre plus réduit de productions est considéré par le processeur lorsqu'il s'agit de chercher la production à utiliser pour le codage d'un item.

En particulier, on réduit le nombre comptabilisant les transitions non groupées et les groupements de transitions issues d'un même item à une valeur inférieure ou égale à une puissance de 2, elle-même inférieure au nombre des transitions avant optimisation. En particulier, on réduit à une valeur de puissance de 2. La puissance de 2 immédiatement inférieure au nombre des transitions avant optimisation délimite le nombre de priorités (et donc de productions) à partir duquel un bit supplémentaire de codage est nécessaire. En limitant le nombre de transitions/productions (vues sur le niveau de priorité considéré) à 2n, on utilise uniquement 2n productions et "n" bits sont suffisants pour le codage des priorités associées à ces productions. On gagne en coût de codage pour chaque élément codé si avant on utilisait 'n+1' bits. La réduction à exactement une valeur de puissance de 2 assure qu'aucune valeur de codage (dans ces "n" bits) ne demeure inutilisée. On peut itérer successivement plusieurs réductions, chaque fois, vers un nombre égale à la puissance de deux inférieure.

Selon une caractéristique particulière, on itère ladite étape d'optimisation, notamment sur les transitions composant un regroupement. Cette itération permet également de gagner des bits de codage sur les niveaux de priorités supérieurs des grammaires. Dans un mode de réalisation, le procédé peut comprendre une étape de génération d'au moins une grammaire de codage/décodage à partir dudit modèle unifié optimisé, ladite au moins une grammaire comprenant des productions associant un item à une valeur de codage et à une grammaire suivante. En particulier, le procédé comprend une étape de transmission de l'au moins une grammaire, éventuellement par fichier, à destination d'un processeur de codage/décodage de documents structurés. Dans cette configuration, les grammaires sont générées avant transmission au processeur EXI. Il convient de s'assurer que le transmetteur de telles grammaires et le processeur EXI sont compatibles du point de vue du fichier servant à cette transmission: chacun peut l'interpréter. Il résulte de cette configuration que le processeur EXI n'a plus qu'à lire ces grammaires reçues et générer les objets "grammaires" correspondants dans sa mémoire vive pour le traitement (encodage/décodage) des documents structurés. La charge de travail du processeur est donc fortement réduite pour chaque nouvel encodage/décodage. Selon une caractéristique particulière, le procédé comprend, au niveau dudit processeur, une étape d'optimisation de l'au moins une grammaire par suppression d'au moins une production et/ou regroupement d'au moins deux transitions correspondant à deux productions de sorte à réduire le nombre de valeurs d'un niveau de priorité, en particulier en réduisant ce nombre à une valeur inférieure ou égale à une puissance de 2, elle même inférieure au nombre avant optimisation. Ici, on opère une deuxième optimisation permettant de prendre en compte des spécificités du processeur EXI : par exemple la prise en compte de déviation, la préservation des commentaires, etc. Dans une variante de transmission, ledit au moins un modèle unifié est transmis, éventuellement sous forme de fichier, à destination d'un processeur de codage/décodage d'un document structuré, et ladite optimisation est effectuée au niveau dudit processeur de codage/décodage. Ici, un plus grand nombre de traitements est effectué au niveau du processeur. Cependant, on peut conduire ici une optimisation globale plus performante pour tenir compte des spécificités du processeur (déviation, etc.). Dans encore une autre variante, ledit au moins un modèle unifié optimisé est transmis, éventuellement sous forme de fichier, à destination d'un processeur de codage/décodage d'un document structuré, et ledit procédé comprenant, au niveau dudit processeur, une deuxième étape d'optimisation dudit modèle unifié optimisé par suppression d'au moins une transition et/ou regroupement d'au moins deux transitions. Encore ici, cette deuxième optimisation permet de prendre en compte, avec un coût de traitement minime au niveau du processeur, les spécificités propres à celui-ci. On peut par exemple supprimer une ou regrouper deux transitions pour disposer d'une production libre (donc d'un code libre d'un niveau de priorité). Cette production va recevoir une production générique pour assurer des déviations ou pour coder des commentaires (en cas de préservation de ceux-ci). On ajoute donc cette spécificité du processeur sans pénaliser la première optimisation réalisée, c'est-à-dire sans coût supplémentaire pour le codage des productions conservées. Dans un mode de réalisation spécifique au schéma XML, on prévoit que : - à partir d'un modèle unifié pour un type d'élément, on liste les items de type "attribut" en précisant leur optionalité dans ce type d'élément et on liste les items de type "éléments" sous forme de "choix" ou de "séquence", - ladite étape d'optimisation comprend la suppression d'au moins un item ainsi listé, et on génère un fichier de description de structure XML Schema ("XML Schema Description") à l'aide des items de la liste optimisée, Notamment, c'est ce fichier Schéma XML que l'on transmet au processeur EXI pour configuration initiale de celui-ci conformément à la norme EXI. En particulier, on supprime, dudit fichier de description, un élément ou un attribut peu fréquent dans les documents structurés de configuration. Afin de notamment mener cette analyse d'élément peu fréquent, on prévoit que lesdites informations de transitions renseignent les fréquences de transition pour une pluralité de transitions correspondant à un même item de départ. Cette information unique de fréquence de transition permet au processeur de codage/décodage à la fois de connaître les transitions réalisées et donc générer les grammaires/productions correspondantes, mais également d'adopter une politique de codage, par exemple favorable aux transitions les plus fréquentes.

En particulier, le procédé comprend une étape de génération d'au moins une grammaire de codage/décodage à partir dudit modèle optimisé, et dans lequel ladite au moins une grammaire comprend des productions associant un item à une valeur de codage et à une grammaire suivante, et on choisit des valeurs de codage associées aux productions d'un item en fonction desdites fréquences de transition de sorte à prendre des valeurs de codage sur un petit nombre de bits pour des fréquences de transition élevées. On assimile ici "item" à "événement" sauf dans le cas d'un item élément, pour lequel on désigne deux événements pour le début (balise ouvrante) et la fin (balise fermante) de l'élément. En particulier, ledit modèle unifié comprend la liste des items rencontrés dans les occurrences d'un type d'élément, l'ensemble des transitions rencontrées pour chacun desdits items listés et des indications représentatives des fréquences de transition associées. Cette liste inclut notamment les items initiaux pour le type d'élément considéré et la fréquence de transition depuis le début d'élément (du type d'élément considéré) vers ces items initiaux. Cette fréquence de transition vers les items initiaux correspond sensiblement à la fréquence d'occurrences de chacun de ces items initiaux dans le type d'élément considéré.

Grâce à cette liste unifiée, le processeur EXI peut se configurer rapidement pour un codage/décodage efficace de documents. En particulier, ladite optimisation comprend la suppression d'au moins une transition la moins probable. Cette suppression est celle qui, statistiquement, minimise la perte de compression du document à coder. En particulier, on ajoute à une liste du modèle unifié optimisé, les noms des items dont les transitions sont supprimées, de sorte à constituer un dictionnaire de valeurs pour ledit processeur. En variante, ladite optimisation comprend le groupement d'au moins deux transitions les moins probables. Dans ce cas, lors de la génération de productions pour configurer le processeur, les productions correspondant aux transitions regroupées peuvent présenter une même valeur de premier niveau de priorité pour le codage de la valeur correspondante, et on utilise alors un deuxième niveau de priorité pour distinguer les différentes productions à l'intérieur de ce regroupement. De façon similaire, on peut grouper, de façon récursive, des productions/transitions à l'intérieur d'un regroupement (par groupe de puissance de 2) et utiliser de la sorte un troisième niveau de priorité. On peut aussi regrouper d'autres transitions, de sorte, idéalement, à disposer de 2n groupes de transitions (les transitions non regroupées comptant chacune pour un groupe). Cette configuration par regroupement optimise la compression des données : toutes les transitions sont conservées, mais on maximise l'utilisation de chaque bit de codage en s'assurant de conserver des groupes de 2' transitions. Dans un mode de réalisation, on envisage de combiner le regroupement et la suppression de transitions/productions pour atteindre la puissance de 2 inférieure. Dans un mode de réalisation de l'invention, la constitution dudit modèle unifié comprend une étape de création d'un modèle simple représentatif de chaque structure différente pour chaque type d'élément rencontré dans l'au moins un document de configuration, chaque modèle comprenant un compteur du nombre d'occurrences de cette structure dans l'au moins un document de configuration. On dispose ainsi d'une description fine de toutes les combinaisons de structures pour un même type d'éléments, ainsi que du nombre d'apparitions de ces structures dans chaque document. Ce nombre d'apparitions permet, entre autres, un calcul ultérieur des fréquences de transition. En particulier, les modèles simples associés à un même type d'élément sont groupés ensemble. Ce regroupement permet, par la suite, un traitement plus rapide en vue de générer le modèle unifié ci-dessus pour le type d'élément considéré.

Selon une autre caractéristique particulière de l'invention, on recense, dans lesdits modèles simples de structure, les valeurs de contenu rencontrées pour chaque item rencontré dans les occurrences correspondantes dudit type d'élément. Les valeurs de contenus ainsi récupérées sont susceptibles d'être fournies au processeur de codage/décodage qui, dès lors, peut préremplir des dictionnaires de valeurs. Le traitement de codage/décodage ultérieur est alors accéléré.

Dans un mode de réalisation, le procédé comprend une étape de fusion de l'ensemble des modèles simples associés à un même type d'élément, de sorte à générer ledit modèle unifié du type d'élément, l'étape de fusion comprenant le calcul des fréquences d'une transition à partir du nombre d'occurrences des modèles simples et de la présence de la transition dans chacun des modèles simples. Selon une caractéristique particulière de l'invention, le procédé comprend, une étape de constitution de groupes des documents de configuration de sorte à traiter, séparément, l'ensemble des modèles simples décrivant les documents de chaque groupe pour former des modèles unifiés spécifiques à chaque groupe. Cette configuration permet d'appréhender de façon séparée différents types de documents de configuration et de choisir, le cas échéant, les données externes de configuration résultant d'un groupe de documents le plus cohérent avec le document à coder. On obtient de la sorte une meilleure efficacité de codage et de compression. En particulier, les groupes de documents sont distincts (également appelés "classes" par la suite). Ainsi, on génère des données de configuration du processeur de codage/décodage avec le modèle unifié spécifique à un groupe représentatif du document structuré à coder/décoder. Dans un mode de réalisation de l'invention, le type d'élément définissant un modèle unifié tient compte du contexte dans ledit au moins un document de configuration, notamment des éléments de hiérarchie supérieure (dans la structure du document) comprenant ledit type d'élément. Cette disposition permet de différencier deux éléments portant le même nom mais dont une utilisation différente est faite dans le document. Cette différenciation permet ainsi, notamment lorsque ces deux éléments sont structurellement très différents, de conserver un codage efficace du document structuré.

En particulier, ledit contexte tient compte de deux niveaux de hiérarchie, par exemple l'élément de niveau supérieur contenant l'élément en cours d'examen. Retenir seulement deux niveaux de hiérarchie pour définir le contexte garantit un traitement rapide de la détermination du contexte d'un élément. Egalement, on peut prévoir que le contexte tient compte de l'ensemble des niveaux de hiérarchie jusqu'à la racine de structure dans lesdits documents de configuration. Ainsi, on vérifie l'intégralité du contexte (XML) dans lequel se trouvent les deux éléments à comparer avant de décider s'ils sont identiques. Selon une caractéristique de l'invention, on fusionne les modèles unifiés de deux types d'élément de même nom mais de contexte différent. Cette fusion peut être menée lorsque ces deux modèles unifiés sont similaires ou lorsque la différence entre ces deux modèles est inférieure à une valeur seuil, par exemple lorsqu'ils ne diffèrent que par un seul attribut/item. En particulier, cette différence est déterminée par la comparaison des deux modèles de façon récursive sur les items de type éléments contenus dans ces modèles. On tient ainsi compte des éléments de niveaux hiérarchiques inférieurs. L'invention vise également un procédé de configuration d'un processeur de codage/décodage, comprenant la génération de données de configuration selon le procédé exposé ci-dessus et la configuration d'au moins une table de codage dudit processeur à l'aide du modèle unifié optimisé ainsi obtenu. Corrélativement, l'invention a trait à un système de traitement pour la génération de données de configuration d'un processeur de codage/décodage de documents structurés comprenant des items, le système comprenant : - des moyens de génération d'au moins un modèle unifié représentatif de la structure d'un type d'élément à partir d'au moins un document structuré de configuration, ledit modèle unifié comprenant une information sur des transitions entre items réalisées dans les occurrences dudit type d'élément au sein dudit au moins un document structuré de configuration, - des moyens d'optimisation dudit modèle unifié, à l'aide des informations de transitions, par suppression d'au moins une transition et/ou regroupement d'au moins deux transitions. De façon optionnelle, le système peut comprendre des moyens se rapportant aux caractéristiques du procédé de configuration exposé précédemment. Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de génération ou de configuration conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. Un programme d'ordinateur lisible par un microprocesseur, comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de génération ou de configuration conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente trois documents de configuration utilisés pour générer des données de configuration d'un processeur de codage/décodage ; - la figure 2 illustre les grammaires EXI obtenues par un processeur de codage/décodage selon l'état de la technique ; - les figures 3a à 3d illustrent différents modèles et grammaires obtenues par la mise en oeuvre de l'invention sur les documents de la figure 1 ; - la figure 4 représente, sous forme de logigramme, des étapes de traitement selon la présente invention ; - les figures 4a à 4d présentent différents modes de réalisation de l'enchaînement des étapes de la figure 4 ; - la figure 5 représente, sous forme de logigramme, des étapes pour la modélisation de données de la figure 4 ; - la figure 6 représente, sous forme de logigramme, des étapes pour la création d'un modèle de données de la figure 5 ; - la figure 7a représente, sous forme de logigramme, des étapes pour l'unification de modèles obtenus dans la figure 5 ; - la figure 7b représente, sous forme de logigramme, des étapes complémentaires de la figure 7a pour la génération d'un schéma XML selon l'invention : - la figure 8 représente, sous forme de logigramme, des étapes pour l'unification de modèles obtenus dans la figure 5 dans le cas d'éléments contextuels ; - les figures 9a à 9c représentent, sous forme de logigramme, des étapes d'optimisation des modèles unifiés des figures 7a, 7b et 8, notamment par suppression ou par regroupement de transitions ; - la figure 10 représente, sous forme de logigramme, des étapes pour la séparation, sous forme de groupes, des modèles obtenus dans la figure 5 ; et - la figure 11 montre une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre des procédés selon l'invention. Comme évoqué ci-dessus, la spécification EXI définit deux modes de construction des grammaires divergeant principalement dans la manière selon laquelle sont apprises les grammaires. D'une part, le mode par défaut sans schéma s'appuie initialement sur des grammaires par défaut adaptées à décrire tout type de contenu, puis celles-ci sont affinées en fonction des données traitées. D'autre part, dans le mode avec schéma XML, des grammaires décrivant les documents (avec ou sans déviations) sont initialement créées à l'aide du schéma XML et modifiées par la suite.

Le mode où l'on utilise un schéma est nommé dans la spécification EXI EXI Schéma . Toutefois, dans le cadre de ce document, on le nommera EXI Non-évolutif , en raison du caractère non modifiable des grammaires utilisées. A l'opposé, le mode sans schéma est ci-après désigné mode EXI Evolutif , au sens où les grammaires utilisées sont susceptibles d'évoluer au fur et à mesure du traitement d'un document. Le mode EXI Schéma (EXI Non-évolutif) propose une option pour gérer les déviations, comme évoqué précédemment. En cas d'activation de cette option, un processeur EXI d'encodage/décodage peut encoder et décoder un document même s'il n'est pas strictement conforme au schéma XML utilisé, grâce notamment à l'ajout de productions génériques permettant de traiter n'importe quel contenu.

Les modes de réalisation proposés ci-après en mode EXI Non-évolutif sont décrits principalement sans déviation. L'homme du métier n'aura aucune difficulté à les étendre à un mode gérant les déviations, par simple ajout de telles productions génériques. Néanmoins, dans certains traitements, des items sont supprimés des modèles utilisés pour représenter les données à coder selon l'invention, par exemple en raison de leur rareté (il peut être plus avantageux de ne pas le prendre en compte afin de ne pas définir de production les décrivant). Dans ce cas, il y a lieu de prévoir une gestion des déviations car, autrement, il serait impossible d'encoder les items supprimés.

En outre, même si l'invention est principalement décrite ci-après en regard du mode EXI Non-évolutif, il est envisagé de l'appliquer également à un processeur en mode EXI Evolutif. Dans ce cas, seul le mode de réalisation ci-après, basé sur la production de grammaires, est applicable afin d'enrichir les grammaires génériques utilisées par le processeur EXI avant codage/décodage. Ainsi, on dispose, dès le départ, de grammaires affinées, ce qui permet d'obtenir une meilleure compression des données sans pour autant empêcher les grammaires d'évoluer par la suite. En particulier, il peut être intéressant d'utiliser l'invention avec le mode EXI Evolutif si l'on travaille sur un sous-ensemble de documents présentant un nombre important de variations. En effet, dans ce cas, un nombre significatif d'événements est susceptible de ne pas être présent dans les grammaires obtenues par application de l'invention, et il est donc intéressant de conserver la capacité d'apprentissage du processeur EXI. Un autre cas intéressant est celui où l'on dispose de ressources limitées. En effet, certaines opérations requises par le mode EXI Non-évolutif peuvent être problématiques, telles que le traitement du schéma XML dans le but de créer les grammaires, ou le ré-ordonnancement des attributs (considérés dans l'ordre alphabétique dans le mode EXI Non-évolutif selon la spécification EXI). Dans ces cas, l'utilisation du mode EXI Evolutif, où aucun schéma n'est à traiter et aucun ré-ordonnancement des attributs n'est prévu, permet d'obtenir une compression efficace sans mettre en oeuvre d'opérations aussi coûteuses. On décrit maintenant les principales étapes du procédé selon l'invention en s'appuyant sur l'exemple des documents de configuration 10A, 10B, 10C de la figure 1, la figure 3 présentant, à ce titre, l'évolution de tables et modèles représentant ces documents pour la mise en oeuvre de l'invention.

La figure 4 décrit un exemple de procédé d'extraction d'information pour générer des données de configuration pour la compression EXI selon l'invention. Ce procédé débute, à l'étape E100, par la création de modèles simples M; pour les données de différents documents considérés 10i. Cette étape est notamment plus détaillée ci-après en référence à la figure 5. Dans le cadre de l'exemple de la figure 3, on dispose d'une famille de documents de type 10A, 10B et/ou 10C (ceux de la figure 1). Par exemple, on possède cent documents, 80% d'eux ayant la structure de 10A, 10% celle de 10B, et 10% celle de 10C, mais leur contenu pouvant varier (définitions de 100 cercles différents, i.e. les attributs background-color , border-color , border-width , r , x et y pouvant varier). L'étape E100 vise à modéliser les différentes structures de types de contenu rencontrés dans chacun des documents, ici l'élément défini par le nom circle . En considérant les cent documents ci-dessus, on obtient à l'issue de l'étape E100, pour l'ensemble des documents, les trois modèles MA, MB et Mc représentés sur la figure 3a.

Chaque modèle Mi représente, pour un document, une structure d'un type d'élément, et précise le nom de ce type d'élément, ici circle , suivi de la liste ordonnée des items rencontrés dans les occurrences de cette structure, ici des attributs uniquement.

Pour chaque document, on obtient autant de modèles Mi qu'il y a de types d'élément différent dans ce document. Le traitement de l'invention se poursuit, à l'étape E110, par l'unification des modèles Mi d'un même type d'élément dans l'ensemble des documents 10i en un modèle unique MUcircle pour ce type d'élément et représentatif de l'ensemble des modèles Mi rencontrés dans les documents. Lorsque plusieurs types d'élément sont présents dans les documents, on utilise un unique modèle unifié MU qui décrit les structures de l'ensemble des différents types de contenus rencontrés dans les documents. Dans ce modèle, pour chaque type d'élément rencontré, ici par exemple circle , on construit une liste des items présents et les transitions possibles pour chaque item, ainsi que les fréquences de transition. Cette étape E110 est décrite plus en détail en référence aux figures 7 et 8. Dans l'exemple précédent, on unifie les trois modèles MA, MB et Mc de manière à pouvoir en déduire par la suite un jeu de grammaires décrivant efficacement tous les modèles rencontrés. Ce modèle MUcircle obtenu est représenté en figure 3b. Il liste, dans la partie de gauche, la balise ouvrante identifiant le type circle d'élément traité et, dans l'ordre, les différents items (ici attributs) rencontrés dans l'ensemble des éléments circle des documents 10A, 10B et 10C. Ces éléments constituent les items de départs ID; pour les transitions entre items. Dans la partie de droite du modèle, sont précisés les items suivants ISi possibles pour chacun des items ID; de la partie de droite et leur fréquence d'occurrences.

Chaque couple { item ID; ; item ISi } renseigné définit une transition TRii réalisée dans un des documents 10i, et les fréquences d'occurrences correspondantes définissent les fréquences de la transition, notée fTR, pour un même item de départ. Du fait de la répartition des cent documents dans les trois formats 10A, 10B et 10C, il existe trois items initiaux réalisés: background-color , border-color et r , avec une fréquence d'occurrences de 80% pour l'item r (car 80% de documents 10A) et de 10% pour les deux autres. Ces fréquences correspondent ainsi à la transition entre la balise ouvrante de l'élément (<circle>) et le premier attribut rencontré. Dans l'exemple, il n'existe à chaque fois qu'un seul item suivant IS pour les autres items de départ ID, et ce jusqu'à la balise fermante de fin d'élément circle , d'où les fréquences fTR=100%. Grâce à ce modèle MUcircle, on connaît les transitions TR qui se produisent dans les différents documents 10A, 10B, 10C rencontrés pour l'élément circle , et l'on peut donc déjà produire des grammaires plus efficaces que dans le cas du schéma XML précédemment décrit. Notamment, en tenant compte de ces transitions, le processeur EXI peut être configuré à l'aide de ces données en produisant la grammaire GramO représentée en figure 3c. La première transition TR (de circle vers background-color , border-color ou r ) étant la seule à présenter un choix, on peut se limiter à une seule grammaire GramO proposant un choix. Le procédé selon l'invention se poursuit, à l'étape E120, par l'optimisation du modèle unifié MUcircle dans l'optique de la compression EXI. Ce traitement d'optimisation est décrit plus en détail ci-après en référence à la figure 9.

Au cours de ce traitement, des considérations sur les grammaires susceptibles d'être générées par le modèle unifié MUcircle sont effectuées, de manière à déterminer comment ce modèle peut être modifié pour obtenir une compression plus efficace. Notamment, il peut être avantageux d'affecter des niveaux de priorité différents en fonction des fréquences des transitions. Dans la grammaire GramO de la figure 3c, il y a trois codes de niveau un (0, 1 et 2) utilisés pour les trois choix de transition possibles. Par conséquent, deux bits sont nécessaires pour coder ce niveau. D'un point de vue de codage, il y a là une perte d'efficacité car on pourrait coder quatre productions sur deux bits, et ici on en traite seulement trois. Dans cet exemple, l'optimisation vise à grouper deux transitions de 5 sorte à ne conserver que deux codes de priorité de niveau "1" pour gagner un bit sur chaque code de niveau "1" codé. La transition la plus probable est la transition circle vers r (80%), les deux autres étant également probables (10%). Il est donc avantageux de regrouper les deux transitions les moins probables. On obtient 10 alors la grammaire représentée en figure 3d. De cette manière, dans 80% des cas, on utilise un seul bit au lieu de deux pour coder la transition vers l'attribut r . Dans les 20% de cas restant, on utilise un bit pour coder le niveau de priorité "1" et un autre bit pour coder le niveau de priorité "2", soit deux bits au total, c'est-à-dire le même nombre 15 qu'avec la grammaire non-optimisée. Statistiquement, on peut gagner 80 bits sur un total de 200 bits encodés avec la grammaire non-optimisée. On obtient un gain en compression par rapport à l'utilisation de la grammaire GramO obtenue avec un schéma XML selon l'art antérieur (figure 2), où deux bits sont nécessaires pour coder les quatre productions possibles, 20 qui est identique. Pour les autres transitions, il n'y a jamais de choix, une seule transition étant possible. Les grammaires créées sont donc toutes des grammaires contenant une unique production, celle-ci ne nécessitant donc aucun bit pour être codée. Comparativement au mode EXI Schéma, on 25 améliore là aussi la compression puisque l'on n'utilise aucun bit pour coder la transition de background-color vers border-color , alors que deux bits sont nécessaires avec les grammaires du mode EXI Schéma (trois productions dans la grammaire Gram1 de la figure 2, idem pour le codage de la transition border-color vers r de la grammaire Gram 2). 30 Une fois le modèle unifié MU optimisé, il est mis à disposition d'un processeur EXI, à l'étape E130, sous forme de données de configuration. Ces données constituent une connaissance externe, compréhensible par le processeur EXI, qui lui permet de générer des grammaires initiales. Plusieurs cas sont ici envisagés. Dans un premier cas (figure 4a), on génère (E131) directement des données de grammaires EXI exploitables par le processeur de codage/décodage. Ce sont généralement des "pseudo"-grammaires au sens où elles reprennent toutes les informations définissant une grammaire EXI mais sans en avoir le formalisme EXI. On calcule notamment les valeurs de codage (ou priorités) associées à chacune des productions de la grammaire.

On sérialise (E132) ensuite ces grammaires dans un fichier type XML que l'on transmet (E133) au processeur. Le processeur peut ensuite exploiter (El 50) ces informations pour se configurer. Cette configuration permet d'obtenir de meilleures performances car le codeur/décodeur ne fait que créer des objets "grammaires" par simple lecture (E150) des données externes de configuration (ces grammaires pré-générées) reçues. La génération de objets "grammaires" à partir d'une connaissance externe n'est pas explicitement décrite dans la spécification EXI, à l'exception du cas où l'on dispose d'un schéma XML (mode EXI Schéma), cependant, la spécification EXI mentionne également que les grammaires ne sont pas liées à XML Schéma et que n'importe quel langage de modélisation de données XML peut être utilisé pour créer des grammaires. L'utilisation directe de grammaires reste alors conforme à la spécification, pour autant que le processeur soit en mesure d'interpréter le fichier servant au transfert des grammaires générées (mêmes conventions de nommage par exemple).

Dans une variante (figure 4b), le modèle unifié optimisé MUoptimisé est sérialisé (E132) dans un fichier XML puis transmis (E133) au processeur EXI. Dans ce cas, le processeur EXI peut mener directement la génération (E150) des grammaires initiales pour exploitation, mais peut également mener une nouvelle optimisation (E120') de ce modèle pour tenir compte de certains paramètres locaux (définissant un contexte propre au processeur) avant génération des grammaires. Ce peut être par exemple la mise en oeuvre ou non de déviations comme introduite précédemment, mais également la conservation ou non de commentaires au sein du document XML à coder (en cas de conservation, il y a lieu de prévoir une production supplémentaire destinée à coder ces commentaires). Ici à chaque nouveau document à coder/décoder, les grammaires sont générées.

Dans une autre variante (figure 4c), on a transmis (El 11) le modèle unifié MU au processeur EXI, lequel réalise ensuite l'étape d'optimisation E120, en tenant compte notamment du contexte local. On effectue ainsi une seule opération d'optimisation. Des grammaires sont générées (E130) localement à partir du modèle ainsi unifié pour configurer (E150) le processeur EXI.

Dans un autre cas (figure 4d), on génère (E131') un schéma XML amélioré à partir du modèle optimisé de l'étape E120 et d'un traitement spécifique en vue de la création d'un tel schéma XML (traitement expliqué ci-après en référence à la figure 7b). Ce schéma XML amélioré est transmis (E133) au processeur EXI et permet ensuite la configuration (E150) du processeur par les mécanismes du mode EXI Schéma. Cette amélioration résulte de l'optimisation du modèle unifié, par exemple par suppression d'un item peu fréquent. Ce cas offre des taux de compression moins avantageux, mais s'intègre directement dans la spécification EXI (mode EXI Schéma). Comparativement à l'utilisation d'un schéma XML classique de l'art antérieur (destiné uniquement à la validation de données XML), la présente invention lorsqu'elle génère un schéma XML pour le processeur EXI, affine le contenu de ce schéma en considérant les grammaires qui en résulteront, de manière à déterminer le schéma qui permettra d'obtenir la meilleure compression suivant la spécification EXI.

Dans une variante, on peut intégrer au schéma, par exemple par l'ajout de commentaires, des informations relatives aux transitions. De cette manière, un processeur EXI capable de lire ces informations pourrait les utiliser pour produire des grammaires permettant une compression plus importante des données. Il convient de remarquer qu'une telle fonctionnalité n'est pas prévue par la spécification EXI, et donc que son utilisation ne serait possible qu'entre deux processeurs ayant la même compréhension de ces informations complémentaires insérées dans le schéma XML.

En résumé, soit l'optimisation E120 est réalisée hors du processeur EXI et ainsi, lors de l'étape E130, on sérialise le modèle unifié MUcircle optimisé dans un fichier que l'on transmet au processeur, ou on génère des "pseudo"-grammaires EXI que l'on transmet également au processeur, ou on sérialise directement un schéma XML, soit l'optimisation E120 est réalisée par le processeur qui reçoit, dans ce cas, le modèle unifié MU sérialisé dans un fichier de transmission, par exemple de type XML. Il est à noter qu'il est toujours possible de mener, au niveau du processeur, une nouvelle optimisation (E120') du modèle/des grammaires/du schéma XML reçu afin de tenir compte du contexte propre au processeur. On peut par exemple supprimer une transition/une production lorsque cette suppression permet de gagner un bit de codage pour chaque valeur à coder. Le choix de la transition/production à supprimer est par exemple faite en fonction des fréquences de transition.

Dans le cas où l'on sérialise les grammaires, elles sont mises à la disposition du processeur EXI dans un format XML pour obtenir une représentation compacte. Limiter la taille des données générées revêt une importance puisque le but premier de l'invention est la compression : si les données générées sont plus volumineuses que les gains de compression, l'invention perd de son intérêt. Toutefois, dans le cas où l'on génère des grammaires, l'invention présente aussi l'avantage de rendre le traitement des données plus rapide, en particulier comparativement au cas où l'on utilise un schéma XML. Enfin, il convient de souligner que le coût en espace mémoire de ces données externes de configuration du processeur est fixe (une seule description), tandis que les gains sont variables (on gagne sur chaque fichier encodé). Une solution alternative au fichier peut consister, si les interfaces de construction des grammaires sont connues par le processeur EXI, à générer, à partir du modèle MUcircle, des lignes de code permettant de créer, au niveau du processeur EXI, les grammaires correspondant au modèle unifié. Dans ce cas, il n'est pas nécessaire de lire un fichier à l'encodage et au décodage, mais il suffit au processeur EXI d'exécuter les lignes de code pour générer les grammaires. Le traitement pour la génération des données externes de configuration du processeur EXI prend fin à l'étape E140.

On note toutefois que pour le codage d'un document XML 20 ou pour le décodage d'un document binaire 20', le processeur EXI génère alors les grammaires à partir de ces données externes pour se configurer et procède au codage ou décodage de façon classique de ces documents à l'aide de ces grammaires (les faisant évoluer ou non selon le mode choisi).

Notamment, si on part du fichier sérialisé MU ou MUoptimisé, il faut calculer les codes de priorité ; si on part de pseudo-grammaires au format XML, alors il suffit de créer les objets grammaires correspondants par simple lecture. Enfin, si on part d'un schéma XML, il faut convertir le schéma en grammaires selon l'algorithme décrit dans la spécification EXI. Les coûts de configuration du processeur sont donc variables selon le mode choisi. On décrit maintenant plus en détail la modélisation de données issues d'un ensemble de documents (étape E100) en référence à la figure 5. A l'étape E200, on obtient un ensemble de documents 10A, 10B, 10C de configuration, par exemple des documents XML, SVG ou Open Office.

Etant donnée une famille de documents de même type, par exemple un ensemble de documents SVG (acronyme "Scalable Vector Graphics") ou de documents Open Office, l'invention peut s'appliquer à un sous-ensemble de cette famille. Le choix du sous-ensemble influe sur le temps de traitement et sur l'efficacité du modèle généré : en effet, plus il y a de documents dans le sous- ensemble, plus le temps de traitement augmente, et plus le modèle généré a de chances d'être représentatif de l'ensemble des documents de la famille considérée. Le traitement selon l'invention n'étant généralement réalisé qu'une fois pour une famille de documents donnée, il peut être intéressant de prendre en compte tous les documents de cette famille, même si le temps de traitement peut s'en trouver significativement allongé. Si l'on souhaite réduire ce temps de traitement, alors on peut considérer un sous-ensemble plus restreint, la taille du sous-ensemble étant aussi liée à la taille des documents : si ceux-ci sont courts, alors le modèle unifié MU reste relativement simple et donc rapide à générer ; si en revanche les documents sont longs, le modèle MU peut devenir plus complexe, et donc plus long à produire.

Par exemple, on peut envisager d'appliquer l'invention à l'ensemble des documents d'une famille de 100 documents de 10 Ko. Par contre, pour des raisons de temps de traitement, on préfère restreindre une famille de 100 documents de 1 Mo, à 10 ou 20 unités. On peut noter que pour ce type de famille, il est possible de considérer d'abord un sous-ensemble restreint afin d'évaluer rapidement l'efficacité du modèle pour la compression, puis d'augmenter la taille du sous-ensemble considéré si l'on souhaite essayer d'obtenir une meilleure compression. Enfin, un cas particulier consiste à appliquer l'invention à un sous-ensemble constitué d'un unique document, notamment dans le cas où la famille est elle-même constituée d'un seul document, ou bien dans le cas où l'on sait à l'avance que les documents varient extrêmement peu. Une fois un ensemble de documents 10i déterminé et récupéré, on passe à l'étape E210 où l'on évalue s'il reste un document 10; non traité. Le traitement d'un document consiste à le parcourir, à l'aide d'un analyseur syntaxique (ou "parsec"), dans l'ordre depuis le début du document jusqu'à la fin. Dans l'affirmative, on passe à l'étape E211 durant laquelle on évalue s'il reste un item IT non traité dans le document courant 10;. Si c'est le cas, on examine alors à l'étape E212 si l'item IT est un élément, en détectant par exemple la présence d'une balise ouvrante <element> et d'une balise fermante </element>. Dans la négative à l'étape E212, on retourne à l'étape E211. En revanche, s'il s'agit bien d'un élément à l'étape E212, on teste, à l'étape E213, si cet élément a déjà été rencontré précédemment.

On entend par "rencontré précédemment" le fait que l'on a déjà rencontré un élément de même nom dans le document 10;, et de manière optionnelle dans le même contexte. On décrit plus loin en référence à la figure 8 cette notion de contexte et les traitements qu'une prise en compte du contexte entraîne. Si l'élément IT n'a pas été rencontré, on crée, à l'étape E230, une structure StrElt liée à cette famille d'éléments (même nom et optionnellement même contexte). Cette structure StrElt est destinée à rassembler toutes les informations collectées concernant cet élément, en particulier son nom, les attributs rencontrés dans cet élément et leur ordre, ainsi que les enfants qu'il contient. Cette mémorisation est faite sous la forme de modèles M comme décrit ci-après, ceux-ci comptabilisant le nombre d'occurrences des attributs et enfants. On prend notamment en compte les différentes séquences d'attributs et d'enfants rencontrées par le biais de ces modèles comme décrit ci-après. Si l'élément IT considéré a été rencontré (sortie OUI de l'étape E213), la structure StrElt le décrivant a déjà été créée, et il suffit donc de l'obtenir lors de l'étape E220. Ces structures StrElt pour les éléments sont notamment stockées en mémoire du processeur de traitement. A l'issue des étapes E220 et E230, on passe à l'étape E240 de création d'un modèle "M" pour l'élément IT traité. Cette étape est décrite plus en détail en référence à la figure 6. A l'étape E300, on crée un modèle vide "M".

A l'étape E310, on évalue s'il reste un attribut non traité pour l'élément IT étudié. Dans l'affirmative, on obtient l'objet "Attr" correspondant à cet attribut à l'étape E320. De la même manière que l'on associe une structure StrElt à chaque type d'élément, on fait correspondre à chaque type d'attribut une structure "Attr" le décrivant, un type d'attribut étant déterminé par le nom de cet attribut et le type de l'élément dans lequel il se produit. Ainsi, deux attributs nom , l'un se produisant dans l'élément personne et l'autre dans l'élément ville , correspondent à deux objets différents (le type d'élément pouvant tenir compte du contexte comme évoqué précédemment).

Si, au début de l'étape E320, l'objet "Attr" requis n'existe pas, on le crée.

Une fois l'objet "Attr" obtenu, on l'ajoute, lors de l'étape E330, à la liste des attributs du modèle "M" en utilisant une liste ordonnée de pointeurs sur les différents objets attributs "Attr". On revient alors à l'étape E310, et quand il ne reste plus d'attribut non traité (sortie NON à l'étape E310), on passe à l'étape E340 où l'on examine s'il reste un enfant de l'élément IT étudié non traité. Dans l'affirmative, on obtient l'objet "Child" correspondant à cet enfant, lors de l'étape E350. Un tel objet est défini par le type de l'enfant (par exemple un élément enfant ou une valeur textuelle) et par le type de l'élément parent. De la même manière que dans le cas des attributs, si l'objet requis n'existe pas au début de l'étape E350, on le crée. Une fois l'objet "Child" obtenu, on l'ajoute à la liste des enfants du modèle "M" à l'aide d'un pointeur dans une liste ordonnée, lors de l'étape E360. On revient alors à l'étape E340, et quand tous les enfants ont été traités (sortie NON à l'étape E340), la création du modèle prend fin (étape E370). De retour à la figure 5, une fois le modèle M créé (sortie de l'étape E240), on compare, lors de l'étape E250, ce modèle M créé aux modèles déjà recensés dans la structure StrElt.

Si ce modèle M a déjà été rencontré, c'est-à-dire si un modèle ayant les mêmes attributs et les mêmes enfants, dans le même ordre, figure déjà dans la liste des modèles de la structure StrElt, on met à jour, lors de l'étape E270, la structure StrElt en augmentant le nombre d'occurrences du modèle concerné d'une unité.

Dans la négative (sortie NON de l'étape E250), le modèle M est ajouté à la liste des modèles de StrElt, lors de l'étape E280. Puisque l'on met à jour et l'on conserve le nombre d'occurrences de chaque modèle M, on peut facilement déterminer les fréquences de transition d'un item vers un autre lors de l'étape d'unification des modèles E110.

Suite aux étapes E270 et E280, on reprend le traitement à l'étape E211, et quand il ne reste plus d'item à traiter (fin du document), on revient à l'étape E210. Là, si tous les documents ont été traités, la modélisation des données prend fin, lors de l'étape E290. On décrit maintenant plus en détail l'unification des modèles simples M en un modèle unifié MU (étape E110) en référence aux figures 7 et 8.

La figure 7a décrit le cas général, tandis que la figure 7b apporte une restriction nécessaire dans le cas où l'on souhaite produire un schéma XML en fin de procédé. La figure 8 décrit, quant à elle, un traitement supplémentaire lorsque les types d'élément tiennent compte du contexte des éléments dans les traitements ci-dessus.

Dans le cas général de la figure 7a, on cherche à prendre en compte toutes les informations de transition mémorisées au niveau des modèles M stockés dans les structures StrElt des types d'élément. On commence à l'étape E400 par vérifier s'il reste un type d'élément non traité.

Dans l'affirmative, on liste, à l'étape E410, les différents attributs et enfants rencontrés dans les modèles simples M de la structure StrElt pour ce type d'élément. Lors de ce listage, on détermine notamment les items initiaux, c'est-à-dire les items (attributs ou enfants) susceptibles de se produire immédiatement après le début de l'élément considéré (après la balise ouvrante de l'élément). Concrètement, il s'agit de tous les items par lesquels les modèles M débutent. On détermine à ce stade, pour ces items initiaux, leurs occurrences respectives ce qui permet d'établir les fréquences de transition entre la balise ouvrante de l'élément considéré et chacun des items initiaux. On détermine ensuite, lors de l'étape E420 si l'un des attributs listés à l'étape E410 demeure à traiter. Si c'est le cas, on détermine, à l'étape E430, là encore grâce aux modèles M recensés, les items ISi qui peuvent succéder à l'attribut traité (grâce aux ordonnancements conservés dans le modèle M), ainsi que les fréquences de transition pour chaque item suivant possible. Ces fréquences sont obtenues à l'aide du nombre d'occurrences de chaque modèle, en sommant le nombre d'occurrences pour cette transition spécifique dans chaque modèle et en divisant cette somme par le nombre d'occurrences des transitions ayant l'attribut traité comme item de départ. On revient ensuite à l'étape E420. Quand tous les attributs ont été ainsi traités, on passe à l'étape E440 où l'on teste s'il reste un enfant listé à l'étape E410 non traité. Dans l'affirmative, on détermine, à l'étape E450, les enfants suivants IS; qui peuvent succéder à l'enfant traité, ainsi que les fréquences de transition (calculées de la même façon que pour les attributs) pour chaque item suivant possible.

On retourne alors à l'étape E440. Et quand il ne reste plus d'enfant à traiter, on revient à l'étape E400. Quand tous les types d'éléments ont été traités, l'unification des modèles prend fin lors de l'étape E490. Dans le cas où l'on souhaite, pour la mise à disposition de l'étape E130, produire un schéma XML destiné à la compression EXI, on ne peut pas s'appuyer simplement sur les fréquences de transition, car un schéma XML n'est pas systématiquement apte à les représenter. En effet, par exemple concernant les attributs, la seule information réellement prise en compte (sauf convention privée développée spécifiquement) concerne leur optionalité : on distingue uniquement les attributs requis des attributs optionnels. En référence à la figure 7b, lorsque l'on souhaite produire un schéma XML, on procède, dans la négative de l'étape E440, c'est-à-dire quand tous les enfants ont été traités, à la détermination de l'optionalité de chaque attribut (étape E460). Il suffit par exemple pour cela de déterminer si l'attribut se produit dans chaque modèle M de la structure StrElt du type d'élément traité. Ensuite, concernant les enfants, les schémas XML distinguent principalement deux types de contenus : les choix ("choice"), et les séquences ("sequence"). Un choix spécifie un ensemble d'enfants possibles, et n'importe lequel de ces enfants peut se produire. En utilisant les attributs minOccurs et maxOccurs prévus dans la spécification des schémas, on peut indiquer le nombre minimal et le nombre maximal d'occurrences pour ce choix, et donc répéter plusieurs fois le choix, ce qui autorise donc n'importe quelle transition d'un enfant vers un autre. Une séquence spécifie, quant à elle, un ensemble d'enfants possibles dans un ordre donné, les enfants pouvant se produire uniquement dans cet ordre. La notation prévue est la suivante: <sequence minOccurs= 'x" maxOccurs= "y"> <element name="element 1" min Occurs= "a1" maxOccurs= "b1">

<element name="element i" minOccurs="a," maxOccurs="b,">.

En utilisant les attributs optionnels minOccurs et maxOccurs, on peut spécifier le nombre de fois où chaque séquence peut se produire mais également où chaque enfant peut se produire dans une séquence pour le type d'élément considéré. Dans ce dernier cas, cela correspond à une transition de l'enfant considéré vers lui-même si maxOccurs vaut plus de 1 (deux occurrences de l'enfant pouvant être consécutives). A l'étape E461, on détermine alors si les enfants rencontrés dans les modèles M forment une séquence. Pour cela, on peut notamment étudier les enfants précédents et suivants pour chaque enfant, et si, pour le type d'élément considéré, un enfant apparaît à la fois parmi les enfants précédents et suivants, alors il ne peut pas s'agir d'une séquence. Cette méthode élémentaire ne permet pas de détecter tout type de séquence au sens XML Schéma, cependant il n'est pas intéressant de chercher à modéliser tout contenu comme une séquence, car si l'on doit pour cela considérer beaucoup de minOccurs et de maxOccurs, alors les grammaires résultantes seront nombreuses et peu avantageuses en termes de compression ; dans un tel cas, il est plus simple de modéliser les enfants comme un choix : cela nécessite moins de calculs, pour une efficacité similaire en compression. Comme on vient de la préciser, il peut exister plusieurs séquences possibles dans certains cas: si l'on a deux modèles, l'un avec des enfants a et b , l'autre avec des enfants a et c , alors les séquences a / b / c et a / c / b conviennent toutes les deux. Une seule est conservée pour la suite du traitement de l'invention.

Dans une variante, on peut chercher à déterminer une séquence quitte à ce qu'un élément se répète plusieurs fois dans cette séquence: si l'on a un modèle contenant les enfants a / b / c , et un modèle contenant les enfants a / c / b / d , alors on peut former la séquence a / c / b / C / d . Il est aussi important de bien déterminer, pour chaque élément de la séquence, les valeurs du minimum et du maximum du nombre d'occurrences de chaque élément, ces nombres étant pris en compte par la spécification EXI lors de la création des grammaires à partir d'un schéma (pour prévoir une transition d'un élément vers lui-même, par exemple). Si l'on détermine une séquence lors de l'étape E461, on retient ce modèle pour décrire les enfants lors de l'étape E470 ce qui permet in fine de produire uniquement les grammaires souhaités (donc d'obtenir une meilleure compression du document XML à coder par la suite).

Sinon, on représente les enfants à l'aide d'un choix (étape E480). Suite aux étapes E470 et E480, le traitement spécifique pour la génération d'un schéma XML s'achève, et l'on poursuit le traitement par un retour à l'étape E400. La figure 8 illustre des étapes supplémentaires pour l'unification des 20 modèles M dans le cas où les types d'élément tiennent compte des contextes des éléments, comme évoqué ci-dessus lors de l'étape E213. Dans certains cas, il est intéressant de prendre en compte le contexte et non uniquement l'élément lui-même : si dans un document on trouve deux éléments personne , mais que l'un est un enfant de l'élément 25 famille tandis que l'autre est un enfant de l'élément entreprise , il se peut que des informations différentes soient contenues dans chacun de ces deux éléments (pour la personne enfant de l'élément entreprise , on pourra par exemple avoir un élément enfant département ou fonction qui n'aurait pas lieu d'être pour la personne enfant de l'élément famille ). 30 Dans un tel cas, on distingue un élément personne_famille et un élément personne_entreprise dès l'étape E213 afin d'obtenir une meilleure compression.

En cas de prise en compte du contexte, dans les étapes ultérieures à l'étape E213, de tels éléments correspondent à des types d'élément différents qui sont traités séparément. On note que la prise en compte du contexte peut se faire sur deux niveaux de hiérarchie (comme dans l'exemple ci-dessus), ou davantage encore jusqu'à prendre en compte le contexte de l'élément depuis la racine du document 10i. Bien entendu, plus on considère de niveaux, plus le coût de traitement induit est élevé, en particulier pour mettre en oeuvre les étapes de la figure 8 lors de l'unification des modèles M.

Une alternative possible à l'examen des niveaux hiérarchiques supérieurs, qui est moins coûteuse mais potentiellement moins précise, consiste à utiliser un schéma XML préexistant de manière à déterminer s'il existe, dans le schéma, des éléments de même nom mais de structures distinctes. Cette façon de procéder est potentiellement moins précise car le schéma ne définit pas nécessairement plusieurs structures distinctes (dans l'exemple précédent, on pourrait avoir un unique élément personne dans le schéma, sa définition englobant les deux cas rencontrés). Il est aussi possible d'utiliser le schéma pour déterminer si la variabilité d'un élément est grande (existence ou non d'attributs ou d'enfants optionnels), et de lier la prise en compte du contexte à la variabilité des éléments. Toutefois, la prise en compte du contexte peut parfois aboutir à la création d'un nombre élevé de grammaires, auquel cas on évite de distinguer les types d'éléments selon leurs contextes, mais uniquement en fonction de leurs noms. Comme représenté sur la figure 8, l'unification des modèles contextuels M comprend, lors de l'étape E500, les étapes d'unification de la figure 7 appliquées à l'ensemble des types d'élément (au minimum ceux qui ont le même nom puisque l'éventuel regroupement s'applique à eux).

Les étapes suivantes visent alors à étudier ces modèles pour déterminer s'il est pertinent de conserver l'aspect contextuel dans tous les modèles unifiés. En effet, pour reprendre l'exemple précédemment cité, si l'on aboutit à deux modèles unifiés personne_famille et personne_entreprise , mais que les deux modèles sont équivalents dans le sens où ils décrivent les mêmes structures, alors il est préférable de fusionner les deux modèles en un unique modèle personne .

Ainsi, lors de l'étape E510, on évalue s'il reste un nom d'élément (commun à deux types contextuels différents) à ne pas encore avoir été traité. Dans l'affirmative, on obtient, à l'étape E520, la liste de tous les types d'éléments contextuels ayant le même nom. Dans l'exemple ci-dessus, ce sont les types dont l'élément se nomme personne . On récupère alors les modèles unifiés MU correspondant à chacun de ces types d'élément contextuels. En l'absence de plusieurs types d'élément contextuels ayant le même nom, on retourne à l'étape E510 pour considérer le nom suivant. On compare, à l'étape E530, les attributs contenus dans chacun de ces modèles unifiés : si deux modèles possèdent les mêmes attributs, alors il n'y a pas de raison de les distinguer de ce point de vue. De manière similaire, on compare, à l'étape E540, les enfants de ces différents modèles unifiés. Il est important à ce niveau de faire une comparaison récursive. En effet, même si les enfants sont identiques, il se peut que les enfants des enfants soient différents, or si l'on fusionne les deux modèles considérés, on risque de perdre l'information de contexte. Ainsi, si l'on a des types d'élément personne_famille et personne_entreprise , que chacun comprend un enfant nommé contact , mais que, pour la famille, ce contact se compose d'un élément adresse_postale , tandis que, pour l'entreprise, il se compose d'un élément adresse_electronique , alors il est intéressant de conserver la distinction entre personne_famille et personne_entreprise . Si aucune différence d'attributs et d'enfants n'est déterminée entre deux ou plusieurs modèles MU donnés, on fusionne ces modèles lors de l'étape 550. Cette fusion permet in fine au processeur EXI d'éviter la génération de grammaires inutiles. On note toutefois que des stratégies de groupement plus évoluées peuvent être utilisées. En particulier, il se peut que la fusion de deux modèles, même distincts, ne se traduise pas par une perte d'efficacité en termes de compression. En effet, ajouter par exemple un attribut n'induit pas nécessairement une augmentation du nombre de bits à utiliser pour coder le niveau de priorité des productions se situant dans la même grammaire.

Une fois les modèles unifiés groupés (ou si aucun regroupement ne doit être mené), on retourne à l'étape E510, et quand tous les noms d'éléments ont été traités, le traitement prend fin à l'étape E560. On décrit maintenant, en référence à la figure 9, l'étape d'optimisation du modèle unifié MU résultant de l'étape E110 pour un type d'élément donné. Cette figure illustre les étapes d'un traitement des modèles unifiés MU dans l'optique de la compression EXI, c'est-à-dire en prenant en compte les spécificités de la norme EXI pour déterminer quel modèle permet d'obtenir la meilleure compression. Ces traitements sont applicables à un processeur EXI, qu'il soit en mode EXI Evolutif ou en mode EXI Non-évolutif. La description qui suit est relative au cas EXI Non-évolutif sans déviation, le plus à même de produire des taux de compression élevés. Toutefois, le même procédé est applicable aux autres modes, notamment EXI Evolutif, auquel cas on prévoit l'ajout, dans les grammaires créées, de productions génériques (productions décrivant un attribut ayant un nom quelconque, un élément ayant un nom quelconque, un contenu textuel et une fin d'élément). L'optimisation d'un modèle unifié MU commence, à l'étape E600 de la figure 9a, par déterminer s'il reste un type d'élément à traiter.

Si c'est le cas, on obtient, à l'étape E601, le modèle unifié MU pour ce type d'élément, puis on évalue, à l'étape E602, s'il reste un item non traité dans ce modèle MU. Dans l'affirmative, on obtient, à l'étape E603, les NT transitions issues de cet item, puis on calcule, à l'étape E604, la valeur P2 correspondant à la puissance de 2 la plus proche strictement inférieure à NT. Dans notre exemple MUcircle de la figure 3, NT vaut 3 et P2 vaut 2.

Ces données sont ensuite utilisées, à l'étape E605, pour modifier les transitions en vue d'en diminuer le nombre de transitions à P2. Cette étape est détaillée aux figures 9b et 9c qui décrivent respectivement la suppression de transitions et le regroupement de transitions.

En effet, de cette manière il est possible de diminuer le nombre de code de niveau "1" distincts, et donc d'améliorer la compression. Le cas préféré consiste à avoir un nombre de codes utilisés de niveau "1" qui est une puissance de 2, car cela signifie qu'aucun code disponible n'est perdu. Typiquement, la modification par suppression concerne le cas où l'on souhaite générer un schéma XML, tandis que la modification par groupement concerne le cas où l'on souhaite générer des grammaires EXI. Néanmoins, la suppression peut aussi être étudiée pour le cas des grammaires. Suite à l'étape E605, on retourne à l'étape E602. Quand tous les items du modèle MU ont été traités, on retourne à l'étape E600. Là, quand tous les types d'éléments ont été traités, le traitement prend fin lors de l'étape E606. On décrit maintenant la modification des transitions par suppression, en référence à la figure 9b. A l'étape E610, on obtient les NT-P2+1 transitions les moins probables (fréquences de transition les plus faibles). En effet, en supprimant NT-P2+1 transitions, même si l'on ajoute ensuite une production générique afin de coder les transitions supprimées, on réduit le nombre de priorités de niveau "1" à une puissance de 2 et donc on gagne 1 bit de codage pour chaque item/transition à coder. A l'étape E611, on évalue si cette suppression est avantageuse du 25 point de vue de la compression EXI. Pour cela, on compare le nombre de bits économisés (1 bit par utilisation d'une transition) au nombre de bits supplémentaires que le codage des transitions supprimées implique. Concrètement, si la production est supprimée, il est nécessaire d'utiliser une production générique (production ne 30 spécifiant pas le nom d'un item), et donc de coder le nom de cet item. Il convient de remarquer que cette méthode ne fonctionne que dans le cas où toutes les transitions supprimées sont des transitions vers le même type d'item : en effet, chaque production générique ne peut coder qu'un seul type de transition (par exemple vers un attribut ou vers un début d'élément), et s'il existe plusieurs types de transitions parmi les transitions supprimées, alors il est nécessaire d'ajouter autant de types de productions génériques.

Généralement, cette situation ne permet pas de procéder à des suppressions avantageuses, toutefois on peut traiter ce cas en remplaçant l'obtention des NT-P2+1 transitions les moins fréquentes par l'obtention, par exemple, des NT-P2+2 transitions les moins fréquentes s'il y a deux types de transitions parmi ces NT-P2+2 transitions.

On peut souligner ici qu'il est intéressant de prendre en compte dans un tel cas le nombre de documents dans lesquels l'item en question apparaît : en effet, si un attribut, par exemple, se produit une fois dans N documents, ou bien s'il se produit N fois dans un document, le problème est différent puisque dans le premier cas, il faudra coder son nom littéralement pour chaque document (c'est-à-dire que l'on codera la chaîne de caractère qui représente son nom pour chaque document), tandis que dans le second cas on codera le nom littéralement une fois, puis on codera une référence à ce nom (après la première occurrence, on utilisera un symbole plus court que la chaîne de caractères, et le coût sera donc réduit).

Le coût supplémentaire lié au codage des transitions supprimées peut être vu comme : (Coût codage du nom) * (Nbr de documents ayant cette transition) + (Coût codage de l'index du nom codé) * (Nbr d'occurrences de cette transition) Le premier terme correspond au codage littéral du nom de l'item dont la production a été supprimée pour l'ensemble des documents et le deuxième terme correspond au codage de chacune des occurrences de cet item par référence au nom déjà codé (cette référence étant généralement un index pointant dans un dictionnaire de codage). On constate ici qu'un mode de réalisation particulièrement 30 intéressant consiste à générer une liste contenant les noms d'items supprimés, ces noms étant pris en compte lors de l'initialisation du processeur EXI : dans ce cas, il n'est jamais nécessaire de coder le nom littéralement, et le surcoût induit par le codage d'un item supprimé est diminué. Une telle liste peut être intégrée au schéma XML généré (par l'ajout, par exemple, d'éléments dont les noms correspondent à ceux des éléments supprimés, avec un contenu de type quelconque (élément any de la spécification XML Schéma)). Concernant les attributs, afin d'éviter des problèmes liées aux espaces de nommage, il est par exemple possible de définir un élément fictif contenant les attributs supprimés, de sorte que le processeur EXI les ajoute à ses listes de noms d'items et les encode donc efficacement lorsqu'il les rencontre. Une variante pour prendre en compte une telle liste consiste simplement à générer un fichier XML la décrivant puis à l'utiliser pour paramétrer un processeur EXI préalablement à tout traitement. Si la suppression est avantageuse, alors on supprime ces transitions 15 du modèle unifié MU lors de l'étape E612. Le traitement prend alors fin à l'étape E613. Si la suppression n'est pas avantageuse, on met fin au traitement à l'étape E613. Selon une caractéristique de l'invention, on itère ce procédé pour 20 évaluer s'il est intéressant de supprimer davantage d'items et donc de gagner un bit supplémentaire concernant le codage du premier niveau de priorité. La valeur P2 est alors calculée comme la puissance de 2 immédiatement inférieure à l'ancienne valeur P2 utilisée jusqu'alors. On rappelle ici que pour pouvoir coder ces items/transitions 25 supprimées, il convient de prévoir des productions génériques au niveau des grammaires correspondantes. On décrit maintenant la modification des transitions par regroupement, en référence à la figure 9c. On commence à l'étape E620 par obtenir les NT-P2+1 transitions les 30 moins probables. En effet, si ces transitions sont groupées, les productions correspondantes partageront le même code de niveau de priorité "1", et par conséquent, il y aura P2 codes de niveau "1" différents dans la grammaire considérée. Ainsi, aucun code de niveau 1 n'est perdu et on économise un bit pour coder chacune des productions non regroupées. Les productions regroupées sont alors distinguées, entre elles, par des codes de niveau de priorité "2" différents.

A l'étape E621, on examine si ce groupement est avantageux. Sans groupement, on utilise un nombre constant de bits pour chaque production, ce nombre étant égal à la puissance de 2 supérieure la plus proche de NT. Avec le groupement, on utilise P2 bits par production pour coder le premier niveau de priorité (et donc chacune des transitions non regroupées), et on utilise un nombre de bits pour coder le deuxième niveau de priorité égal à la puissance de 2 supérieure la plus proche du nombre de productions groupées, c'est-à-dire de NT-P2+1 (à noter que seules les productions regroupées présentent un deuxième niveau de priorité à coder). Si on économise plus de bits que l'on n'en perd (coûts en bits ci- dessus évalués en fonction des occurrences des transitions), alors les transitions sont groupées lors de l'étape E622. A la suite de cette étape, de même que dans la négative de l'étape E621, le traitement prend fin lors de l'étape E623. On comprend ici que lorsqu'on regroupe les transitions, cela signifie que lors de la génération subséquente des grammaires GramO, Gram1, ..., les productions associées à ces transitions présentent une même valeur à un niveau de priorité (celui pour lequel on a voulu réduire le nombre de valeurs prises) et se distinguent par des valeurs différentes au niveau de priorité suivant.

Selon une caractéristique de l'invention, on itère ce procédé pour évaluer s'il est intéressant de grouper davantage de transitions afin de gagner des bits supplémentaires concernant le codage des premiers niveaux de priorité. De même, on peut effectuer le même type de traitement au sein des transitions groupées pour étudier l'utilité du groupement des transitions au niveau "2". Dans ce cas, les productions sont distinguées par leur troisième niveau de priorité.

On décrit maintenant un mode de réalisation avancé de l'invention en référence à la figure 10. A l'issue de l'étape E100 de la figure 4, il est possible d'effectuer une étape facultative de séparation des modèles M en différents groupes, suivant les documents de configuration D; auxquels ils appartiennent. Ce traitement de séparation peut notamment être utile pour différencier des types de documents, et donc par la suite optimiser la compression pour chacun de ces types. On commence, à l'étape E700, par l'obtention des types d'éléments rencontrés (éventuellement contextuels). Le traitement qui suit a pour objectif de déterminer, parmi les documents considérés, des classes, pour ensuite appliquer les étapes E110 et suivantes non pas à l'ensemble des modèles créés, mais à l'ensemble des modèles nécessaires pour décrire chacune des classes identifiées. On vise ainsi à obtenir des grammaires plus efficaces pour la compression de documents de cette classe ou similaires. A l'étape E710, on détermine s'il reste un type d'élément E non traité, et dans l'affirmative on vérifie, à l'étape E720, s'il reste un modèle M non traité pour ce type d'élément E.

Si tel est le cas, on obtient, à l'étape E730, le groupe G de documents où apparaît le modèle M. A l'étape E740, on évalue alors si ce groupe a déjà été recensé. Dans la négative, on ajoute, à l'étape E750, le groupe G à la liste des groupes recensés.

Suite à l'étape E750, ou bien si G a déjà été recensé (sortie OUI de l'étape E740), on ajoute, lors de l'étape E760, le modèle M aux modèles liés à G. On retourne alors à l'étape E720, et s'il ne reste aucun modèle M non traité, alors on retourne à l'étape E710.

On peut remarquer que si, dans un but de clarté, cette figure décrit le recensement des groupes, cette opération peut être réalisée au cours de l'étape E100, lors de la modélisation des données.

Dans la négative de l'étape E710, c'est-à-dire lorsqu'il ne reste plus de type d'élément E non traité, on passe à l'étape E770 de fusion des groupes proches. Pour cela, on définit une distance Dist sur les groupes, par exemple 5 comme suit : Dist(G1, G2) = le nombre de modèles M différents liés à ces deux groupes G1 et G2, divisé par le nombre total de modèles M liés à ces deux groupes G1 et G2. Si la distance entre deux groupes est inférieure à un seuil 10 prédéterminé, par exemple 25%, alors on fusionne ces groupes en un seul groupe, par union des groupes. Cette étape de fusion des groupes permet de rassembler des documents différents mais dans lesquels apparaissent beaucoup de modèles similaires. Ensuite, à l'étape E780, par des considérations sur les groupes de 15 documents, on identifie des classes de documents. Pour cela, on détermine, pour chaque document et pour chaque groupe G de documents, quelle proportion l'ensemble des modèles M liés au groupe G représente dans l'ensemble des modèles liés au document. Par exemple, si un groupe G est lié à trois modèles, et que le document D;, 20 appartenant à G, instancie six modèles, dont les trois modèles de G, alors on peut dire que les modèles liés à G représentent D; à 50%. Pour évaluer cette "représentativité", on tient compte des modèles liés à G qui sont mis en oeuvre dans le document D. En effet, du fait de la fusion à l'étape E770, certains modèles liés à G peuvent ne pas être mis en 25 oeuvre dans certains documents du groupe. Si seulement deux des trois modèles de G sont mis en oeuvre par D;, G représente alors D; à 33% (deux modèles sur six). Ainsi, on détermine pour chaque document D; le groupe G qui le représente le plus. En partant du document le mieux représenté par un unique 30 groupe Gbest, on peut identifier une première classe, constituée par les documents de ce groupe Gbest qui sont suffisamment représentés par les modèles M liés à ce groupe Gbest (par exemple au moins à 50%).

On ôte alors les documents appartenant à cette première classe des autres groupes G dans lesquels ils apparaissent, puis l'on applique le même procédé pour déterminer une nouvelle classe. En itérant de la sorte, il se peut qu'on ne trouve pas de classe pour certains documents D. Dans ce cas, soit on crée une classe pour chacun de ces documents, soit on crée une classe regroupant l'ensemble de ces documents. Une fois ces classes définies, on sépare, à l'étape E790, différents groupes G de modèles en récupérant, pour chacune des classes, l'ensemble des modèles M susceptibles de se produire. Par la suite, on applique le traitement des étapes E110 et suivantes, à chacun de ces ensembles. Le traitement prend alors fin à l'étape E799. Dans un mode de réalisation en variante, on ne crée pas de classes mais on conserve un ensemble de groupes. Dans ce cas en effet, on peut par exemple faire émerger un groupe Gcommun correspondant à une base commune à l'ensemble des documents D;, qui contient par exemple tous les modèles instanciés par plus de 80% des documents, et d'autres groupes G; correspondant à autant de spécialisations de la base commune. Un document correspond alors à deux groupes : la base commune Gcommun plus une spécialisation G. L'avantage de cette variante vient du fait qu'elle permet un traitement plus efficace des données de configuration externes par le processeur EXI, en évitant d'avoir à traiter des données qui ont peu de chances d'être effectivement utilisées (par exemple en évitant de créer certaines grammaires).

Toutefois, il n'est pas intéressant d'appliquer l'invention à chacun de ces groupes, car on ne prévoit pas d'utiliser un groupe seul, mais une combinaison de groupes. Dans ce cas, plutôt que d'appliquer l'invention à chacune des combinaisons possibles (par exemple à chaque combinaison base commune / spécialisation), on conserve une description des groupes, y compris les informations relatives aux modèles M (notamment les informations de transition).

Puis, c'est seulement au moment de traiter un document pour son codage ou décodage que l'on obtient les groupes nécessaires, puis que l'on effectue les traitements selon l'invention afin de déterminer les grammaires ou, plus généralement, le contexte de codage le plus intéressant pour la compression de ce document. Cette version est également compatible avec une variante de l'invention dans laquelle le traitement E120 des modèles unifiés n'est pas appliqué avant de rendre les informations de grammaires disponibles à un processeur EXI, mais effectué au niveau du processeur EXI lui-même lors de la création des grammaires. Dans ce cas, les informations de grammaires obtenues par le processeur EXI ne sont pas liées à un mode particulier (évolutif ou non-évolutif), mais elles décrivent les modèles unifiés tels qu'obtenus à l'issue de l'étape E110. De cette manière, le processeur EXI peut utiliser ces informations dans n'importe quel mode, en prenant en compte les spécificités de chacun (ajout de productions génériques par exemple dans le mode évolutif). Dans le cas d'utilisation de Gcommun, les étapes E780 et E790 ne sont pas effectuées, mais on peut, optionnellement, remplacer l'étape E780 par une étape de traitement des groupes, afin de ne sélectionner que des groupes suffisamment fréquents, la fréquence étant alors liée au nombre de documents D; figurant dans un groupe G ainsi qu'au nombre de modèles liés à ce groupe (plus un groupe contient de documents, moins il a besoin d'être lié à un grand nombre de modèles pour être considéré comme représentatif, et réciproquement).

En référence à la figure 11, il est maintenant décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de traitement apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement 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ée à 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 ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en oeuvre de l'invention, notamment les modèles, structures et autres grammaires de la figure 3 ; - 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 disquette 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 70 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - Une interface de communication 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 63 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de traitement d'information, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

Le code exécutable permettant au dispositif de traitement 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 4 à 10, pour mettre en oeuvre le procédé objet de la présente invention et constituer le système objet de la présente invention. Le procédé de l'invention ne nécessite pas de modifier le format EXI, mais simplement de prendre en compte une connaissance initiale, de la même manière que l'on prend en compte un schéma XML dans le mode EXI Schéma. Ainsi l'invention permet d'obtenir une compression plus élevée tout en demeurant conforme à la spécification EXI. En termes de compression, la présente invention s'applique de préférence au format en bits groupés qu'au format en octets alignés. En effet, le plus souvent, l'invention permet de passer, par exemple, de 3 bits par production à 2 bits par production. Or quand on travaille sur des octets alignés, ce gain disparaît puisque l'on passe à un nouvel octet après avoir codé chaque niveau de priorité de la production.

Néanmoins, certains gains demeurent effectifs en mode octets alignés, notamment lorsque l'on détermine des transitions certaines. Dans ce cas (une transition correspond à une production unique dans sa grammaire), aucun bit/aucun octet n'est nécessaire pour coder cette production puisqu'elle est parfaitement déterminée.

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

Notamment, si l'on décrit principalement, dans les explications ci-dessus, l'aspect structurel des modèles M avec les transitions entre items, il est aussi possible de prendre en compte dans les modèles des valeurs de contenu (valeurs prises par les attributs ou les champs textuels d'éléments par exemple). Grâce à ces valeurs, on peut s'intéresser au type des données (entier, flottant, date, booléen...) afin par exemple de déterminer les types XML Schéma les plus adaptés pour les décrire (ceux qui permettront, une fois les données encodées, d'obtenir le meilleur taux de compression en fonction de leur représentation avec les codecs définis par EXI). Il est aussi possible d'identifier des valeurs qui se répètent pour un même item de contenu (par exemple un attribut pour lequel il n'existe qu'un faible nombre de valeurs possibles, auquel cas on peut le décrire au moyen d'une énumération au sens XML Schéma), ou bien des valeurs qui se répètent à travers les documents (valeurs présentes pour différents items de contenus). Dans ce cas, il peut être intéressant de lister ces valeurs dans un dictionnaire utilisé pour initialiser le processeur EXI, de manière à éviter de les coder littéralement. Enfin, il est encore possible de traiter les données de manière à en extraire des paramètres de codage utilisables par un codec intégrable à EXI. Dans le cas de données SVG par exemple, il est possible de conserver les différentes valeurs puis de les étudier pour déterminer, par exemple, un format de représentation adapté pour les nombres rencontrés, ou bien un dictionnaire de valeurs pouvant être utilisées efficacement pour la compression de ces données. En variante, si l'on souhaite effectuer un traitement moins coûteux et qu'un schéma est disponible pour les documents traités, on peut chercher à obtenir le type des données de contenu à partir du schéma. Ainsi, ces valeurs de contenu rencontrées pour chaque item ayant un 30 contenu (valeurs d'attributs, valeurs de champs textuels) sont intégrées sous forme de liste aux modèles M, lors de l'étape E240.

Notamment, les objets "Attr" et "Child" peuvent lister les valeurs que les attributs et enfants correspondants prennent dans les documents 10i. La comparaison E250 ne tient alors pas compte de ces valeurs listées, auquel cas, à l'étape E270, on met à jour si nécessaire la structure StrElt avec les nouvelles valeurs de contenu rencontrés. La détermination des types des données (chaîne de caractères, nombre entier, nombre décimal, booléen,...), ou l'identification des valeurs récurrentes, comme décrit ci-dessus, est notamment menée lors des étapes E430 (attributs) et E450 (enfants).

L'ensemble de ces informations relatives aux valeurs de contenus est alors mis à la disposition du processeur EXI de la même manière que les informations structurelles.

Claims (25)

1. REVENDICATIONS1. Procédé de traitement pour la génération de données de configuration d'un processeur de codage/décodage de documents structurés comprenant des items, le procédé comprenant une étape de génération (E110) d'au moins un modèle unifié (MU) représentatif de la structure d'un type d'élément à partir d'au moins un document structuré de configuration (10A, 10B, 10C), caractérisé en ce que ledit modèle unifié (MU) comprend une information (fTR) sur des transitions (TR) entre items (ID, IS) réalisées dans les occurrences dudit type d'élément au sein dudit au moins un document structuré de configuration (10A, 10B, 10C), et caractérisé en ce que le procédé comporte une étape d'optimisation (E120, E605) dudit modèle unifié (MU), à l'aide des informations (fTR) de transitions (TR), par suppression (E612) d'au moins une transition (TR) et/ou regroupement (E622) d'au moins deux transitions (TR).
2. 2. Procédé selon la revendication précédente, dans lequel on réduit le nombre comptabilisant les transitions (TR) non groupées et les groupements de transitions issues d'un même item (ID) à une valeur inférieure ou égale à une puissance de 2 (P2), elle-même inférieure au nombre (NT) des transitions avant optimisation.
3. 3. Procédé selon la revendication précédente, dans lequel on itère ladite étape d'optimisation (El 20).
4. 4. Procédé selon l'une des revendications précédentes, comprenant une étape de génération (E131, E150) d'au moins une grammaire (GramO, Gram1) de codage/décodage à partir dudit modèle unifié optimisé (MUoptimisé), ladite au moins une grammaire (GramO, Gram1, ...) comprenant des productions associant un item à une valeur de codage et à une grammaire suivante.
5. 5. Procédé selon la revendication 4, comprenant une étape de transmission (E133) de l'au moins une grammaire (GramO, Gram1) à destination d'un processeur de codage/décodage de documents structurés.
6. 6. Procédé selon la revendication précédente, comprenant, au niveau dudit processeur, une étape d'optimisation (E120') de l'au moins une grammaire (GramO, Gram1) par suppression (E612) d'au moins une production et/ou regroupement (E622) d'au moins deux transitions (TR) correspondant à deux productions de sorte à réduire le nombre de valeurs d'un niveau de priorité.
7. 7. Procédé selon la revendication 4, dans lequel ledit au moins un modèle unifié (MU) est transmis (El 11) à destination d'un processeur de codage/décodage d'un document structuré, et ladite optimisation (E120) est effectuée au niveau dudit processeur de codage/décodage.
8. 8. Procédé selon l'une des revendications 1 à 3, dans lequel ledit au moins un modèle unifié optimisé (MUoptimisé) est transmis (E133) à destination d'un processeur de codage/décodage d'un document structuré, et ledit procédé comprenant, au niveau dudit processeur, une deuxième étape d'optimisation (E120') dudit modèle unifié optimisé (MUoptimisé) par suppression (E612) d'au moins une transition (TR) et/ou regroupement (E622) d'au moins deux transitions (TR).
9. 9. Procédé selon l'une des revendications 1 à 3, dans lequel: - à partir d'un modèle unifié (MU) pour un type d'élément (IT), on liste (E460, E470, E480) les items de type "attribut" en précisant leur optionalité dans ce type d'élément et on liste les items de type "éléments" sous forme de "choix" ou de "séquence", - ladite étape d'optimisation (E120) comprend la suppression d'au moins un item ainsi listé, et - on génère (E130, E131') un fichier de description de structure XML Schema ("XML Schema Description") à l'aide des items de la liste optimisée.
10. 10. Procédé selon l'une des revendications précédentes, dans lequel lesdites informations de transitions renseignent les fréquences de transition (fTR) pour une pluralité de transitions (TR) correspondant à un même item de départ (ID).
11. 11. Procédé selon la revendication précédente, comprenant une étape de génération (E131) d'au moins une grammaire (GramO, Gram1) de codage/décodage à partir dudit modèle optimisé (MUoptimisé), et dans lequel ladite au moins une grammaire (GramO, Gram1, ...) comprend des productions associant un item à une valeur de codage et à une grammaire suivante, et on choisit des valeurs de codage associées aux productions d'un item en fonction desdites fréquences de transition (fTR) de sorte à prendre des valeurs de codage sur un petit nombre de bits pour des fréquences de transition élevées.
12. 12. Procédé selon l'une des revendications précédentes, dans lequel ledit modèle unifié (MU) comprend la liste des items (ID) rencontrés dans les occurrences d'un type d'élément (IT), l'ensemble des transitions (TR) rencontrées pour chacun desdits items listés et des indications représentatives des fréquences de transition (fTR) associées.
13. 13. Procédé selon l'une des revendications 1 à 12, dans lequel 15 ladite optimisation (E120, E605) comprend la suppression (E612) d'au moins une transition (TR) la moins probable.
14. 14. Procédé selon l'une des revendications 1 à 12, dans lequel ladite optimisation (E120, E605) comprend le groupement (E622) d'au moins deux transitions (TR) les moins probables. 20
15. 15. Procédé selon l'une des revendications précédentes, dans lequel la constitution dudit modèle unifié (MU) comprend une étape de création (E100, E240) d'un modèle simple (M) représentatif de chaque structure différente pour chaque type d'élément (IT) rencontré dans l'au moins un document de configuration (10A, 10B, 10C), chaque modèle (M) comprenant un 25 compteur du nombre d'occurrences de cette structure dans l'au moins un document de configuration.
16. 16. Procédé selon la revendication précédente, dans lequel les modèles simples (M) associés à un même type d'élément sont groupés (E270, E280) ensemble. 30
17. 17. Procédé selon l'une des revendications 15 et 16, comprenant une étape de fusion (E110) de l'ensemble des modèles simples (M) associés à un même type d'élément, de sorte à générer ledit modèle unifié (MU) du type d'élément (IT), l'étape de fusion comprenant le calcul des fréquences d'une transition (fTR) à partir du nombre d'occurrences des modèles simples (M) et de la présence de la transition (TR) dans chacun des modèles simples.
18. 18. Procédé selon l'une des revendications 15 à 17, comprenant, une étape de constitution (E780) de groupes des documents de configuration (10A, 10B, 10C) de sorte à traiter, séparément, l'ensemble des modèles simples (M) décrivant les documents de chaque groupe pour former des modèles unifiés spécifiques à chaque groupe.
19. 19. Procédé selon la revendication précédente, dans lequel on génère des données de configuration du processeur de codage/décodage avec le modèle unifié spécifique à un groupe représentatif du document structuré à coder/décoder.
20. 20. Procédé selon l'une des revendications précédentes, dans lequel le type d'élément définissant un modèle unifié (MU) tient compte du contexte dans ledit au moins un document de configuration (10A, 10B, 10C).
21. 21. Procédé selon la revendication précédente, dans lequel on fusionne (E550) les modèles unifiés (MU) de deux types d'élément de même nom mais de contexte différent.
22. 22. Procédé de configuration d'un processeur de codage/décodage, comprenant la génération de données de configuration selon le procédé de l'une quelconque des revendications précédentes et la configuration d'au moins une table de codage dudit processeur à l'aide du modèle unifié optimisé (MUoptimisé) ainsi obtenu.
23. 23. Système de traitement pour la génération de données de 25 configuration d'un processeur de codage/décodage de documents structurés comprenant des items, le système comprenant: - des moyens de génération (E110) d'au moins un modèle unifié (MU) représentatif de la structure d'un type d'élément à partir d'au moins un document structuré de configuration (10A, 10B, 10C), ledit modèle unifié (MU) 30 comprenant une information (fTR) sur des transitions (TR) entre items (ID, IS) réalisées dans les occurrences dudit type d'élément au sein dudit au moins un document structuré de configuration, - des moyens d'optimisation (E120, E605) dudit modèle unifié (MU), à l'aide des informations (fTR) de transitions (TR), par suppression (E612) d'au moins une transition (TR) et/ou regroupement (E622) d'au moins deux transitions (TR).
24. 24. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé conforme à l'une quelconque des revendications 1 à 22, lorsque le programme est chargé et exécuté par le système informatique.
25. 25. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 22, lorsqu'il est chargé et exécuté par le microprocesseur.15