FR2924244A1 - Procede et dispositif d'encodage et de decodage d'information - Google Patents

Abstract

Le procédé d'encodage d'information représentant plusieurs versions d'un contenu, comporte :- une étape (110) de détermination d'une structure comportant des items de contenu et d'une pluralité de versions du contenu associé à ladite structure,- une étape (140) d'association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour fournir une information d'association et- une étape (150) d'encodage d'un fichier unique, par exemple binaire, comportant une information représentative de ladite association, ladite structure et lesdites valeurs des versions du contenu associé aux items de contenu, par exemple dans un format XML.

Description

La présente invention concerne un procédé et un dispositif d'encodage et de décodage d'information. Elle s'applique, en particulier, à la description de document selon la syntaxe XML. XML (acronyme de Extensible Markup Language , c'est à dire langage de balisage extensible) est une syntaxe pour définir des langages informatiques. XML permet de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et se terminant par une balise fermante comportant elle aussi le nom de l'élément (par exemple: </balise>). Chaque élément peut contenir d'autres éléments ou des données textuelles. Un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple: <balise attribut="valeur">).

La syntaxe XML permet aussi de définir des commentaires (par exemple: ( !-- Commentaire--> ) et des instructions de traitement, qui peuvent préciser à une application informatique quels traitements appliquer au document XML (par exemple: <?montraitement?> ). On considère ici que des données XML sont décrites en termes d' items , chaque item pouvant être un début d'élément (<balise>), une fin d'élément (</balise>), un attribut, un contenu textuel, un commentaire ou une instruction de traitement. Plusieurs langages XML différents peuvent contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages XML différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ( Namespace , en anglais). Deux éléments seront identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier pour identifiant uniforme de ressource), par exemple, http://canon.crf.fr/xml/monlangage . L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: 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"> ). 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. D'autre part, un document XML peut être édité manuellement avec un simple éditeur de texte. En outre, comme un document XML contient sa structure intégrée aux données, ce document est très lisible même sans en connaître la spécification. Le principal inconvénient de la syntaxe XML est d'être très prolixe. Ainsi la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi une durée de traitement important lors de la génération et surtout de la lecture de documents XML. Pour remédier à ces inconvénients, des méthodes pour encoder un document XML ont été recherchées. Le but de ces méthodes est de coder le contenu du document XML sous une forme plus compacte, mais permettant de reconstruire facilement le document XML. Cependant, la plupart de ces méthodes ne conservent pas l'ensemble des avantages du format XML. Parmi ces méthodes, la plus simple consiste à coder les données de structure dans un format binaire au lieu d'utiliser un format textuel. En outre, la redondance des informations structurelles dans le format XML peut être supprimée ou au moins diminuée (par exemple, il n'est pas forcément utile de préciser le nom de l'élément dans la balise ouvrante et la balise fermante).

Une autre méthode est d'utiliser une table d'index, en particulier pour les noms d'éléments et d'attributs qui sont généralement répétés dans un document XML. Ainsi, lors de la première occurrence d'un nom d'élément, celui-ci est codé normalement dans le fichier et un index lui est associé. Puis, pour les occurrences suivantes de ce nom d'élément, l'index est utilisé à la place de la chaîne complète, réduisant la taille du document généré, mais facilitant aussi la lecture : il n'y a plus besoin de lire la chaîne complète dans le fichier et la détermination de l'élément lu peut être réalisée par une comparaison d'entiers au lieu d'une comparaison de chaînes de caractères.

Enfin, au-delà de ces méthodes élémentaires, il existe des méthodes plus évoluées consistant notamment à prendre en compte plus d'informations structurelles afin de compresser davantage les données. On peut citer le cas d'Efficient XML, format utilisé comme base pour la standardisation d'un format XML binaire par le groupe EXI du W3C, qui prend en compte l'ordre d'apparition des différents items au sein d'un document pour construire une grammaire qui permet d'encoder les items les plus fréquents sur un faible nombre de bits. Une autre prise en compte d'informations structurelles consiste à détecter des motifs structurels aptes à représenter les données. Dans un certain nombre de cas, des données textuelles existent en plusieurs versions et sont stockées sous forme de données structurées (par exemple en XML). Par exemple, la localisation de données consiste à adapter un texte à un public donné. La localisation peut consister à traduire un texte, mais aussi à modifier un horaire en fonction d'une zone géographique ou à convertir une monnaie d'une devise à une autre. On traite principalement du cas des langues distinctes. Cependant on note que l'invention s'applique à toute forme de données structurées existant en plusieurs versions. Ceci peut notamment être le cas pour des fichiers décrivant des profils d'utilisateurs (la structure du profil est toujours la même, mais le contenu diffère), ou encore pour les fichiers SVG (acronyme de Scalable Vector Graphics pour graphiques vectoriels adaptables), qui décrivent des tracés, des formes géométriques et des animations dans un format structuré, et pour lesquels deux fichiers peuvent partager une même structure mais avoir des contenus différents. On peut encore mentionner le cas de documents correspondant à deux versions différentes d'un même standard (par exemple SOAP 1.1 et SOAP 1.2) pour lesquelles la structure peut être identique mais les contenus différents. Enfin, dans le cas où le contenu d'un document structuré est modifié, on possède plusieurs contenus pour une même structure. Lorsque des données structurées existent en plusieurs versions (par exemple deux documents XML décrivant une même interface, l'un contenant du texte en anglais et l'autre en français), le stockage des données et l'accès à l'information ne sont pas optimaux : en effet, les informations de structures sont redondantes puisque les mêmes données sont décrites, et seuls les contenus changent. D'autre part, la lecture de données XML n'étant pas efficace, l'accès aux informations contenues dans les différents fichiers n'est pas rapide. De plus, le fait d'avoir plusieurs fichiers rend difficile la maintenance des fichiers : s'il faut modifier une partie de la structure, il est nécessaire d'opérer la même modification dans tous les fichiers, ce qui n'est pas sans comporter d'importants risques d'erreurs (différences dans la structure des différents documents, qui sont pourtant supposés décrire les mêmes données).

Une première solution envisageable afin de ne conserver qu'un seul fichier consiste à intégrer les différents fichiers dans un même document. Cependant, cette solution ne permet pas de supprimer la redondance structurelle car il est nécessaire d'ajouter des informations de balisage pour prendre en compte les différentes versions dans le même document, et, du fait de l'utilisation du XML, l'accès à l'information demeure peu efficace. Une seconde solution consiste à n'utiliser qu'un seul fichier structuré, ce fichier contenant non pas une version du contenu mais des références vers des valeurs figurant dans un catalogue, typiquement une base de données. A chaque attribut et à chaque contenu textuel est associé un index, et grâce à une fonction, connaissant cet index et une version de contenu, on peut interroger le catalogue et obtenir la valeur correspondant à cet index pour la version choisie. Ce type de mécanisme est notamment décrit dans le document US 2002/0143523, où l'application principale consiste à afficher une version d'un site web adaptée à un public donné. Le document US 2004/0267803 décrit un procédé dans lequel on définit, dans un document XML, des parties à traduire. Une fois ces parties définies, on extrait du document sa structure d'un côté et les chaînes à traduire de l'autre, puis les chaînes en question sont traduites, et un fichier est alors créé pour chaque version de contenu par insertion des chaînes dans la structure. Cette méthode n'est cependant pas satisfaisante car il existe toujours plusieurs fichiers, ce qui complique la maintenance et atténue les performances, en termes d'accès à l'information. La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé d'encodage d'information représentant plusieurs versions d'un contenu, caractérisé en ce qu'il comporte : - une étape de détermination d'une structure comportant des items de contenu et d'une pluralité de versions du contenu associé à ladite structure, - une étape d'association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour fournir de l'information d'association et - une étape d'encodage d'un fichier unique comportant une information représentative de ladite association, ladite structure et lesdites valeurs des versions du contenu associé aux items de contenu. La présente invention fournit ainsi une méthode pour créer un fichier unique contenant les données dans une forme non redondante, ce fichier pouvant être lu de manière efficace. Ainsi, tout en bénéficiant d'un accès rapide aux données, les risques d'avoir des versions différentes structurellement sont réduits et la maintenance rendue plus aisée. Du fait que l'on concentre les données en un seul fichier, il est beaucoup plus facile de gérer la synchronisation des différentes versions de contenu qu'avec des ressources dispersées. Ainsi, même si toutes les versions ne sont pas renseignées, il n'y a pas de risque, en éditant le fichier, d'aboutir à une version susceptible de provoquer des erreurs. Dans le cas de différentes langues, au pire, on accède à la version par défaut. Si la personne qui modifie la structure ne connaît pas toutes les versions, ou traductions, une autre personne pourra reprendre le fichier et modifier la valeur par défaut par la version ou traduction adéquate.

Selon des caractéristiques particulières, au cours de l'étape d'encodage, on encode le fichier unique dans un format binaire d'encodage d'un document structuré. Selon des caractéristiques particulières, l'information qui représente plusieurs versions d'un contenu comportant au moins un élément possédant un nom ou au moins un attribut possédant un nom, au moins un nom d'élément ou d'attribut est traité comme un item de contenu. Dans ce cas, le document XML devient entièrement traduisible. Selon des caractéristiques particulières, au cours de l'étape d'association, l'information d'association comporte, pour au moins un item de contenu, un type indiquant la nature de l'item de contenu et un contenu. Selon des caractéristiques particulières, le procédé d'encodage tel que succinctement exposé ci-dessus comporte une étape de comparaison dudit type avec une liste de type prédéterminée et, si ledit type n'apparaît pas dans ladite liste, pour ledit item de contenu, on ne conserve qu'une seule version de contenu. Ainsi, on spécifie que les commentaires ou instructions ne possèdent qu'une seule version et on allège l'encodage. Selon des caractéristiques particulières, au cours de l'étape d'encodage du fichier unique, ledit fichier unique représente chaque association entre versions de contenus et items avec, dans la structure unique, une liste référençant, pour chaque item ayant un contenu, les différentes versions disponibles dudit contenu. Ainsi, il n'est pas nécessaire de lire toutes les valeurs au début, et c'est au moment de la lecture de chaque item ayant un contenu qu'on lit la liste de valeurs. Cette variante est particulièrement adaptée à un format d'accès aléatoire aux données.

Selon des caractéristiques particulières, au cours de l'étape d'encodage du fichier unique, ledit fichier unique représente chaque association entre versions de contenus et items avec, d'une part une structure et, d'autre part, une table de contenus donnant la liste, pour chaque version, des différentes valeurs et, pour chaque item ayant un contenu, les différentes versions, chaque item de contenu étant repéré par un index spécifique et on encode, d'abord, la table de contenu et, ensuite, la structure. Ceci permet, lors du décodage, de d'abord lire toutes les versions de contenu puis de lire la structure de manière efficace.

Selon des caractéristiques particulières, au cours de l'étape d'encodage du fichier unique, pour encoder les items de contenu, on encode un index de l'item, ledit index indiquant quelle liste de valeurs considérer lors du décodage, parmi une pluralité de listes correspondant aux différentes versions du contenu.

Selon des caractéristiques particulières, au cours de l'étape d'encodage du fichier unique, on encode au moins une liste de valeurs récursive, des valeurs formant des sous-listes de ladite liste de valeurs récursive. Cette propriété est importante dans le cas où l'on définit des familles de versions, par exemple pour différentes variantes linguistiques locales. Selon des caractéristiques particulières, au cours de l'étape d'association, au moins une version est définie par référence à une autre version. On obtient alors une famille de versions, ce qui permet d'optimiser 25 l'encodage. Selon des caractéristiques particulières, l'information qui représente plusieurs versions d'un contenu comportant une pluralité de documents, au cours de l'étape de détermination d'une structure comportant des items de contenu, on effectue une étape de comparaison de structures d'au moins deux 30 desdits documents sans prendre en compte les contenus.

Selon des caractéristiques particulières, à la suite de l'étape de comparaison, si les structures diffèrent, on effectue une étape d'uniformisation des dites structures. Selon des caractéristiques particulières, au cours de l'étape d'association, on détermine un type associé à chaque item de contenu, entre un type signifiant que l'item prend une valeur unique et au moins un type signifiant que l'item prend une valeur dans une liste de valeurs, ladite liste de valeur étant formée au cours de ladite étape d'association. Selon des caractéristiques particulières, les types comportent au 10 moins un type indiquant que la liste comporte des sous-listes. Selon un deuxième aspect, la présente invention vise un procédé de décodage d'information, caractérisé en ce qu'il comporte : - une étape de décodage d'un fichier unique représentant une structure comportant des items de contenu, une pluralité de versions du 15 contenu associé à ladite structure et une information représentative d'une association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour obtenir ladite structure et, pour au moins la version identifiée dans ladite requête, l'information d'association et la version du contenu de chaque item de contenu 20 et - une étape d'association de ladite structure avec, pour la version identifiée dans ladite requête, la valeur de contenu de chaque item de contenu. Selon des caractéristiques particulières, le procédé de décodage tel que succinctement exposé ci-dessus comporte, en outre : 25 - une étape de réception d'une requête de transmission d'une version d'un contenu à une application, - une étape de fourniture de ladite version du contenu à ladite application. Selon des caractéristiques particulières, au cours de l'étape de 30 réception d'une requête, on met en oeuvre une interface XML. L'intégration de la présente invention est ainsi particulièrement aisée.

Selon un troisième aspect, la présente invention vise un dispositif d'encodage d'information représentant plusieurs versions d'un contenu, caractérisé en ce qu'il comporte : - un moyen de détermination d'une structure comportant des items de contenu et d'une pluralité de versions du contenu associé à ladite structure, - un moyen d'association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour fournir de l'information d'association et - un moyen d'encodage d'un fichier unique comportant une information représentative de ladite association, ladite structure et lesdites valeurs des versions du contenu associé aux items de contenu. Selon un quatrième aspect, la présente invention vise un dispositif de décodage d'information, caractérisé en ce qu'il comporte : - un moyen de décodage d'un fichier unique représentant une structure comportant des items de contenu, une pluralité de versions du contenu associé à ladite structure et une information représentative d'une association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour obtenir ladite structure et, pour au moins la version identifiée dans ladite requête, l'information d'association et la version du contenu de chaque item de contenu et - un moyen d'association de ladite structure avec, pour la version identifiée dans ladite requête, la valeur de contenu de chaque item de contenu. Selon un cinquième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'encodage et/ou du procédé de décodage objets de la présente invention tels que succinctement exposés ci-dessus. Selon un sixième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé d'encodage et/ou du procédé de décodage objets de la présente invention tels que succinctement exposés ci-dessus. Les avantages, buts et caractéristiques de ce procédé de décodage, de ce dispositif d'encodage, de ce dispositif de décodage, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé d'encodage objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés dans lesquels : - les figures 1 à 3 et la figure 6A représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé d'encodage d'un fichier unique contenant une structure et plusieurs versions de contenu objet de la présente invention ; - les figures 4, 5 et 6B représentent, sous forme de logigrammes, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé de décodage d'un fichier contenant une structure et plusieurs versions de contenu objet de la présente invention ; - la figure 7 représente, sous forme d'un logigramme, des étapes mises en oeuvre pour l'édition d'un fichier contenant une structure et plusieurs versions de contenu ; - les figures 8, 9A et 9B présentent un exemple de document XML, différentes versions de contenu et un exemple de fichier encodé et - la figure 10 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention. La présente invention met en oeuvre un format binaire d'encodage de document structuré en format XML dans les modes de réalisation décrits et représentés. On note que différents formats XML binaires existent et que la présente invention n'est liée ni à XML, ni à un format binaire. Avec XML binaire, un document XML est encodé sous forme binaire, ce qui réduit sa taille et permet aussi d'accélérer la lecture des données. Chaque item du document XML est codé avec un type d'item (début d'élément, fin d'élément, attribut, texte, commentaire, instruction de traitement), un éventuel nom (élément ou attribut) et un éventuel contenu (valeur d'attribut, valeur de texte, valeur de commentaire, valeur d'une instruction de traitement). Lorsque l'on dispose d'une structure et de plusieurs versions de contenu, chaque item ayant un contenu est associé aux différentes valeurs que prend le contenu dans chacune des versions de contenu, et l'on encode ces associations dans un format XML binaire. Par la suite, au décodage, une version de contenu est sélectionnée et quand on décode un item ayant un contenu, on cherche cette version parmi les différentes valeurs associées. Pour une application, la communication avec le décodeur se fait par l'intermédiaire d'une interface XML de type connu, et il en résulte une intégration aisée. Concernant les versions de contenu, tous les items ayant un contenu ne sont pas intéressants à considérer. En effet, les commentaires ou les instructions de traitement ont peu de chance d'apparaître en plusieurs versions, au contraire des valeurs d'attributs ou du contenu textuel. Aussi, dans des modes de réalisation, on spécifie une liste de types d'item pour lesquels plusieurs versions sont à prendre en compte, effectuer une comparaison de chaque type d'item rencontré avec le contenu de ladite liste et, pour les items ayant un contenu mais n'apparaissant pas dans cette liste, une seule version est conservée. Par ailleurs, les noms d'éléments ou d'attributs peuvent être traités comme des valeurs de contenu. Dans ce cas, le document XML devient entièrement traduisible.

La figure 1 représente différentes étapes de la création d'un fichier comprenant une structure et plusieurs contenus associés à cette structure. Au cours d'une étape 100, on obtient des données structurelles et des données de contenu. Cette obtention peut se faire par l'intermédiaire d'une interface graphique, l'utilisateur sélectionnant une liste de documents à ouvrir, ces documents étant supposés avoir la même structure mais des contenus différents (par exemple des contenus en français pour un premier document et en anglais pour un second). Dans le cas de contenus en plusieurs langues, l'utilisateur spécifie, pour chaque jeu de données, la version, ou langue à laquelle elle correspond. Parmi les versions, il existe une version par défaut : si on ne précise aucune version, il s'agit de la première version soumise. Une version peut aussi être définie par référence à une autre version, et on obtient alors une famille de versions. Un exemple de famille de versions, dans le cas de différentes langues, concerne la langue anglaise : anglais britannique, anglais américain, anglais canadien. La définition de famille est utilisée avantageusement lors de l'encodage du fichier, comme décrit en regard de la figure 3.

Puis, au cours d'une étape 110, on compare les structures des différents documents. La comparaison de documents structurés est un problème connu (on parle, pour XML, de xml diff ), et il s'agit ici de comparer les documents sans prendre en compte les contenus. Dans le cas où les structures diffèrent, au cours d'une étape 120, on décide si l'on souhaite uniformiser les structures. Cette décision peut relever d'un paramètre de l'application de création de fichiers, ou bien l'on peut demander directement à l'utilisateur de choisir. Si l'on décide de ne pas les uniformiser, alors le traitement prend fin au cours d'une étape 190. En effet, la création du fichier regroupant les contenus pour une même structure implique que les données structurelles soient identiques d'une source à l'autre. Si, en revanche, on choisit d'uniformiser les données, au cours d'une étape 130, l'uniformisation est réalisée grâce aux informations obtenues lors de la comparaison des structures. On note que l'uniformisation peut se faire par union, c'est-à-dire en prenant tous les éléments des différentes structures, ou par intersection, c'est-à-dire en ne prenant que les éléments communs aux différentes structures. Une manière simple de procéder consiste à retenir, pour chaque partie de structure, celle qui se présente le plus fréquemment, ce qui peut amener à faire à la fois des unions et des intersections.

Suivant les modifications faites sur la structure, des modifications sont aussi apportées aux différents contenus. Dans le cas de l'ajout d'un item ayant un contenu, on ajoute une valeur de contenu par défaut dans les données correspondantes. Il existe nécessairement une valeur par défaut puisque s'il y a un ajout, cet ajout correspond à au moins une des structures, et des données de contenu sont associées à cette structure. Cette référence à la valeur par défaut peut être modifiée ultérieurement. Dans le cas de suppression d'un item ayant été rejeté lors de l'uniformisation, par exemple lorsque celle-ci se fait par intersection, ledit item ayant un contenu, la valeur correspondante est, elle aussi, supprimée des données de contenu correspondantes. Puis, une structure unique étant réalisée, on parcourt chaque jeu de données et l'on ajoute chaque valeur à la liste des valeurs de l'item correspondante au cours d'une étape 140. Puis, on encode le fichier avec la structure et les associations de contenus correspondant aux versions, comme illustré en figure 2. Le traitement prend fin à l'étape 190. On note que les associations entre versions de contenus et items peuvent être conservées sous différentes formes. On peut ainsi conserver chaque association directement dans la structure unique (pour chaque item ayant un contenu, il existe une liste avec les différentes versions), ou bien, par exemple, constituer une table des contenus listant, pour chaque version, les différentes valeurs et, pour chaque item ayant un contenu, les différentes versions (l'item étant repéré par son index parmi les items ayant un contenu) ; un tel exemple de table des contenus est représenté en figures 9A et 9B. On note aussi que la création du fichier ne se fait pas nécessairement à partir de plusieurs fichiers XML ayant une même structure et définissant chacun une version différente de contenu. Ainsi, on peut disposer d'un fichier XML et de fichiers uniquement textuels, le fichier représentant la structure et les fichiers textuels les différents contenus. Dans ce cas, la vérification, effectuée au cours de l'étape 110, de la validité des données structurelles consiste à vérifier que l'on a bien autant d'items de contenu dans la structure que de valeurs de contenu dans chacun des fichiers textuels. Un autre mode de réalisation possible consiste à ouvrir un premier document XML puis à choisir de créer une nouvelle version, et l'utilisateur peut alors saisir, une à une, les valeurs traduites. Dans un mode de réalisation, l'utilisateur fournit un fichier XML et un ensemble de versions et l'application crée les jeux de contenus adaptés aux versions considérées (dans le cas de langues, l'application assurerait la traduction des différentes chaînes de caractères). Enfin, un mode de création par édition d'un fichier contenant plusieurs versions de contenus est décrit en figure 7.

La figure 2 détaille l'encodage d'un fichier, une fois la structure, les versions et les contenus déterminés. Au cours d'une étape 200, on encode des versions, comme illustré en figure 6A. Puis, à partir d'une étape 210, on traite les associations entre les items et les valeurs de contenu pour chaque item ayant un contenu. A cet effet, au cours de l'étape 210, on détermine s'il reste une association non-traitée. Si oui, au cours d'une étape 220, détaillée en regard de la figure 3, on encode la liste de valeurs de cette association. Sinon, on passe à une étape 230, au cours de laquelle on détermine s'il reste un item non traité dans la structure du document. Si oui, au cours d'une étape 240, on encode cet item. Sinon, au cours d'une étape 290, le traitement prend fin.

Le codage des items n'est pas ici détaillé et dépend du format XML binaire adopté. Typiquement, pour chaque type d'item, un identifiant différent est utilisé (une solution simple consiste à utiliser un octet pour chaque identifiant, mais cette solution n'est pas optimale). L'identifiant peut aussi être contextuel et dépendre des items précédemment rencontrés dans le document (affectation d'identifiants courts de manière à optimiser la compression). Le procédé d'encodage décrit ici encode d'abord les valeurs et ensuite la structure : ceci permet, lors du décodage, de d'abord lire toutes les versions de contenu puis de lire la structure de manière efficace. Une variante consiste à encoder les listes de valeurs non pas au début du document mais directement à la suite de chaque item ayant un contenu. Dans ce cas, il n'est pas nécessaire de lire toutes les valeurs au début, et c'est au moment de la lecture de chaque item ayant un contenu que l'on devra lire la liste de valeurs. Cette variante est particulièrement adaptée à un format d'accès aléatoire aux données. Une autre possibilité concernant l'encodage des items de contenu consiste à préciser l'index de l'item que l'on encode, cet index permettant de savoir quelle liste de valeurs considérer lors du décodage, cependant il est plus avantageux de ne pas coder cette information et de laisser le décodeur se charger de savoir quel est l'index de l'item qu'il décode. La figure 3 décrit l'encodage d'une liste L de valeurs Li, ces valeurs étant différentes versions d'un même contenu, toutes ces valeurs étant, par 5 conséquent, associées à un même item. Bien que, pour un item donné, il n'existe qu'une liste L de valeurs Li, cette liste de valeurs Li peut être récursive, c'est-à-dire qu'une suite de valeurs Li peut former une sous-liste de L. Cette propriété est importante dans le cas où l'on définit des familles de versions. 10 Si l'on prend l'exemple d'un contenu en plusieurs langues, on pourra associer au sein d'une même famille l'anglais britannique et l'anglais américain. Au sein d'une famille, la probabilité d'avoir des contenus identiques est élevée, et il est donc intéressant de prendre en compte cette particularité lorsqu'on encode l'information. 15 L'encodage de la liste L débute à une étape 310 au cours de laquelle on détermine s'il existe une liste A déjà encodée telle que A soit identique à L. Si oui, au cours d'une étape 311, on encode une référence à A puis le traitement prend fin au cours d'une étape 390. L'encodage de la référence, comme l'encodage de n'importe quelle liste, débute par la précision d'un type, 20 ici le type référence . Ensuite, on encode un nombre, ce nombre permettant de savoir à quelle liste A on fait référence. Par exemple, si A est la troisième liste encodée, on peut écrire le chiffre 2 , les indexes débutant à la valeur 0 . S'il n'existe pas de liste A déjà encodée telle que A soit identique à L, 25 au cours d'une étape 320, on compare les valeurs Li pour déterminer si elles sont identiques entre elles. Si oui, on encode la liste L avec le type valeur unique , puis en précisant cette valeur, au cours d'une étape 321. La valeur peut être codée soit par écriture de la chaîne en question, soit par référence à une chaîne précédemment rencontrée s'il en existe une identique à la chaîne 30 que l'on souhaite encoder. Si les valeurs Li ne sont pas identiques, on encode la liste avec le type standard , la liste n'ayant pas de propriété particulière, au cours d'une étape 330, c'est-à-dire que l'on écrit un identifiant binaire correspondant à l'information type standard , cette information permettant au décodage de savoir qu'une liste de valeurs suit. On traite alors une à une les valeurs Li. A cet effet, au cours de l'étape 330, on considère la première valeur Li. Puis, au cours d'une étape 331, on détermine s'il reste une valeur Li non traitée. Si oui, on regarde si Li correspond à la version principale d'une famille, au cours d'une étape 340. Cette information est connue d'après l'ensemble des versions à traiter. Si c'est le cas, au cours d'une étape 341, on encode la sous-liste correspondant à cette famille de versions, et le traitement reprend à l'étape 331 avec la valeur Li+n+1, si elle existe, où n représente le nombre de valeurs dans la sous-liste de la famille de versions. Si la valeur Li n'est pas la valeur principale d'une famille F, on détermine si la valeur Li fait référence à la valeur par défaut de L, au cours d'une étape 350. Ce cas se présente, par exemple, lorsqu'un ajout d'item ayant un contenu est nécessaire pour uniformiser les structures, comme exposé en regard de la figure 1. En effet, il existe au moins une version des données de contenu pour lesquelles il n'y a pas de valeur correspondant à cet item, sinon il n'y aurait pas eu besoin d'uniformiser. Par défaut, on ajoute, parallèlement à l'ajout de l'item structurel, une référence à la valeur par défaut dans les données de contenu. Si Li est une référence à la valeur par défaut de L, au cours d'une étape 351, on encode le type défaut , puis l'on reprend le traitement à l'étape 331. Si Li n'est pas une référence à la valeur par défaut, au cours d'une étape 360, on compare Li aux différentes valeurs Aj déjà encodées. S'il existe une valeur Aj identique à Li, au cours d'une étape 361, on encode Li comme une référence à Aj, type référence , puis index de Aj, et on considère la valeur Li suivante, si elle existe pour retourner à l'étape 331. Sinon, au cours d'une étape 380, on écrit directement Li (type standard , longueur de la chaîne, et chaîne elle-même) et on reprend le traitement à l'étape 331 avec la valeur Li suivante, si elle existe. Lorsque toutes les valeurs Li ont été traitées, le traitement prend fin à l'étape 390. La figure 4 présente le décodage d'un document encodé en mettant en oeuvre les étapes décrites dans les figures 1 à 3 et 6A.

Le décodage est effectué par un décodeur sur demande d'une application externe. Cette application interagit avec le décodeur selon les interfaces classiques pour décoder un document structuré. L'interface décrite ici correspond à ce que l'on nomme StAX (acronyme de Streaming API for XML pour Interface de programmation en streaming pour XML), c'est-à-dire une interface dans laquelle c'est l'application qui dirige le décodage du fichier en faisant la requiert du décodeur de passer à l'item suivant. Il existe d'autres interfaces pour lire un fichier XML, par exemple DOM (acronyme de Document Object Model pour Modèle Objet de Document) et SAX (acronyme de Simple API for XML pour Interface de programmation Simple pour XML). Ces interfaces peuvent aussi être utilisées pour décoder les fichiers, l'invention n'étant pas liée à une interface particulière. Pour effectuer le décodage, au cours d'une étape 400, le décodeur reçoit une requête de décodage d'un document D dans une version V .

Le décodeur initialise un index de contenu à 0 , cet index étant utilisé pour savoir quel index rechercher dans la table de contenu lorsque l'on rencontre un item ayant un contenu. Puis, au cours d'une étape 410, on décode les versions disponibles, comme exposé en regard de la figure 6B. Au cours d'une étape 420, on cherche si la version V, identifiée au cours de l'étape 400, fait partie de ces versions disponibles. Si non, au cours d'une étape 421, on modifie la version V, qui devient la version par défaut. A la suite de l'étape 421 ou si le résultat de l'étape 420 est positif, au cours d'une étape 430, on procède au décodage des valeurs de contenus dans leurs différentes versions, comme exposé en regard de la figure 5. Ces différentes versions sont conservées pour la lecture de la suite du document. A cet effet, on construit une table des contenus, cette table permettant de connaître le contenu à partir d'une version et d'un index. La réception d'une requête de décodage de l'item suivant, au cours d'une étape 440, déclenche le décodage de l'item suivant, au cours d'une étape 450. Ce décodage est effectué par analyse de données déjà lues ou par lecture de données complémentaires. Au cours d'une étape 460, on détermine s'il s'agit d'un item ayant un contenu. Si oui, au cours d'une étape 461, on obtient la version V de ce contenu en sachant quelle chaîne de caractères rechercher grâce à l'index de contenu et à la version V sélectionnée. L'index de contenu est alors incrémenté. Au cours d'une étape 470, qu'il s'agisse d'un item ayant un contenu ou pas, on transmet à l'application le type de l'item, l'application pouvant alors demander les informations propres à chaque type d'item, notamment le nom de l'élément si l'item est un début d'élément, ou bien la valeur de contenu si l'item a un contenu. Dans des variantes, au cours de l'étape 470, on compare le type d'item à une liste de types d'item pour lesquels plusieurs versions sont à prendre en considération et, pour les items dont le type n'apparaît pas dans cette liste, on ne conserve qu'une seule version. Ainsi, on spécifie que les commentaires ou instructions ne possèdent qu'une seule version et on allège l'encodage. Au cours d'une étape 480, on détermine si l'item est la fin du document. Si oui, le traitement prend fin au cours d'une étape 490, le fichier étant entièrement décodé. Sinon, on retourne à l'étape 440 dans l'attente d'une requête pour l'item suivant. Dans la variante du procédé d'encodage décrite en regard de la figure 2, il est possible d'encoder les différents contenus directement à la suite de chaque item ayant un contenu. Dans ce cas, il n'existe pas de table des contenus au début du document, et cette étape 430 est remplacée par une lecture des contenus lors du décodage de chaque item ayant un contenu. La figure 5 décrit le décodage d'un ensemble de valeurs Li d'une liste L correspondant à un ensemble de versions EV . Le traitement débute, au cours d'une étape 500, par l'obtention du type de la liste décodée. Puis, au cours d'une étape 510, on détermine si ce type est celui d'une référence à une liste. Si oui, au cours d'une étape 511, on lit cette référence et on la copie. Le traitement prend alors fin au cours d'une étape 590. Si le résultat de l'étape 510 est négatif, au cours d'une étape 520, on détermine si le type est celui d'une valeur unique . Si oui, au cours d'une étape 521, on lit cette valeur unique puis on la copie pour chaque version afin de construire la liste L et le traitement prend fin au cours de l'étape 590.

Si le résultat de l'étape 520 est négatif, la liste est de type standard . On examine alors les valeurs une à une, à partir d'une étape 530. Au cours de l'étape 530, on détermine s'il reste une valeur à traiter. Sinon, le traitement s'achève à l'étape 590. Si oui, au cours d'une étape 540, on détermine si, d'après la liste des versions, il s'agit d'une valeur principale pour une famille F. Dans l'affirmative, on décode la sous-liste associée à la famille F, au cours d'une étape 541, puis on retourne à l'étape 530. Si la valeur n'est pas une valeur principale pour une famille, au cours d'une étape 550, on détermine s'il s'agit d'une référence à la valeur par défaut pour la liste courante. Si oui, on obtient cette valeur par défaut et on la copie pour la valeur en cours de décodage, au cours d'une étape 551, et on retourne à l'étape 530. En revanche, si la valeur n'est pas une référence à la valeur par défaut, au cours d'une étape 570, on décode directement la chaîne de caractères de la valeur, et on retourne à l'étape 530.

Le traitement décrit en regard de la figure 5 permet de créer une liste de valeurs, chaque valeur étant réellement une chaîne de caractères. Ainsi, lorsque l'on recherche une chaîne de caractères dans une version donnée, celle-ci est immédiatement accessible. Néanmoins, en variante, on conserve les informations sur les valeurs comme des références à d'autres valeurs lorsqu'elles sont de telles références. Cette variante induit un traitement plus complexe pour accéder à une valeur donnée. Les figures 6A et 6B décrivent respectivement l'encodage et le décodage des versions contenues dans un document, un exemple d'encodage étant fourni en figures 9A et 9B.

L'encodage d'un ensemble de versions EV débute lors d'une étape 600 par l'encodage du nombre de versions dans l'ensemble EV. On évalue alors, lors d'une étape 610, s'il reste une version V à traiter dans l'ensemble EV. Si c'est le cas, au cours d'une étape 620, on détermine si V est la version principale d'une famille de versions. Si non, au cours d'une étape 630, on encode un type simple . Si oui, au cours d'une étape 640, on encode un type complexe puis le nombre de versions dans la famille. A la suite de l'une ou l'autre des étapes 630 et 640, au cours d'une étape 645, on encode l'identifiant de la version, puis le traitement reprend à l'étape 610. Quand toutes les versions ont été traitées, le traitement prend fin à l'étape 650. En ce qui concerne l'étape 645, l'encodage des identifiants de versions peut se faire par l'intermédiaire des identifiants internes, partagés entre l'encodeur et le décodeur. Cette solution peut permettre des gains en termes de compression de l'information. Cependant elle ne garantit pas l'interopérabilité puisqu'une application qui accéderait aux versions lors du décodage sans connaître leur signification ne pourrait pas les exploiter correctement. Une solution garantissant l'interopérabilité consiste à utiliser des valeurs normalisées pour les identifiants de versions. Dans le cas des langues, on peut ainsi utiliser la norme ISO-639 qui définit des codes courts pour chaque langue. En ce qui concerne le décodage de versions, illustré en figure 6B, il débute, au cours d'une étape 660, par la lecture du nombre de versions à décoder. Puis, au cours d'une étape 661, on détermine s'il reste une version V à traiter. Si c'est le cas, au cours d'une étape 670, on lit le type de la version V. Puis, au cours d'une étape 675, on détermine si ce type est complexe . Si oui, on lit le nombre de versions dans la famille de versions, au cours d'une étape 680.

Si le résultat de l'étape 675 est négatif ou à la suite de l'étape 680, au cours d'une étape 685, on effectue la lecture de l'identifiant de la version puis on retourne à l'étape 661. Si, au cours de l'étape 661, on détermine que toutes les versions ont été traitées, le traitement prend fin, lors d'une étape 690. La figure 7 décrit l'ajout d'un item ayant un contenu, par édition d'un fichier préalablement encodé. Cette édition se fait par l'intermédiaire d'une interface graphique. Le traitement débute au cours d'une étape 700 durant laquelle un document binaire contenant plusieurs versions de contenu est lu puis affiché. Dans cette interface graphique, un mode de représentation avantageux consiste à présenter dans deux éléments graphiques distincts la structure et les différentes versions de contenus. Ensuite, un utilisateur modifie la structure du document en ajoutant des informations structurelles, parmi lesquelles au moins un item ayant un contenu, au cours d'une étape 710. Cette modification peut se faire par édition directe de la structure, comme on édite un fichier textuel, ou avec des outils fournis par l'interface graphique, par exemple pour l'ajout de composants à un emplacement de la structure. Lorsque l'item ayant un contenu est ajouté, au cours d'une étape 720, une valeur par défaut est demandée à l'utilisateur et celui-ci la saisit ou la sélectionne. Cette valeur est alors insérée dans la version de contenu par défaut et, pour toutes les autres versions, une référence vers à cette valeur par défaut est insérée, au cours d'une étape 730. Le traitement prend alors fin au cours d'une étape 790. De manière analogue, on peut décrire la suppression d'un item ayant un contenu. Cependant cette opération est plus simple puisqu'il suffit de supprimer de toutes les versions de contenu la valeur associée à l'item correspondant. L'homme du métier sait donc la réaliser sans qu'il ne soit nécessaire de plus la décrire. On constate ici un des avantages que procure le fait de concentrer les données en un seul fichier : il est beaucoup plus facile de gérer la synchronisation des différentes versions de contenu qu'avec des ressources dispersées. Ainsi, même si toutes les versions ne sont pas renseignées, il n'y a pas de risque, en éditant le fichier, d'aboutir à une version susceptible de provoquer des erreurs. Dans le cas de différentes langues, cela permet, dans le pire des cas, d'accéder à la version par défaut. Si la personne qui modifie la structure ne connaît pas toutes les traductions, une autre personne pourra reprendre le fichier et modifier la valeur par défaut par la traduction. Le processus de localisation est ainsi rendu plus aisé. La figure 8 présente un document XML 805 décrivant une interface graphique, la structure 810 extraite de ce document, les items de contenus étant représentés par la chaîne CONTENT , la structure encodée sous forme textuelle 815 et sous forme binaire 820, les équivalences entre identifiants textuels et leur forme binaire étant rappelées dans une table 825 prévue à cet effet.

L'encodage décrit est donné à titre indicatif. Il s'agit d'un encodage au niveau des octets (et non au niveau des bits) qui permet notamment de désigner un élément XML par référence, lorsque son nom a été encodé. La référence est un nombre désignant le rang d'apparition de l'élément dans le document. Ici, on a une référence 1 pour l'élément button , un seul élément apparaissant avant celui-ci ( interface ). Les figures 9A et 9B présentent des versions de contenu 855 associées à la structure de la figure 8, ainsi que l'encodage 860 des versions, l'encodage 865 des données de contenu, sous forme textuelle, un tableau d'équivalence 850 permettant de faire le lien avec la forme binaire. Pour chaque version de contenu, il existe une chaîne de caractères associée à chacune des valeurs CONTENT de la structure présentée figure 8. Ainsi, la première version û en anglais britannique û correspond aux valeurs présentes dans le document XML de la figure 8. Comme pour la figure 8, l'encodage des versions et des données est ici présenté sous forme textuelle, un tableau d'équivalence permettant de faire le lien avec la forme binaire. Dans cet exemple, on considère quatre versions : anglais britannique, anglais américain, français et espagnol. Il se peut que chacune de ces versions existe à la base dans un document XML propre ayant la structure présentée en figure 8. L'anglais britannique et l'anglais américain forment une même famille, dont l'anglais britannique est choisi arbitrairement comme version principale. L'utilisation de la famille permet de grouper les valeurs quand elles sont identiques au sein de la famille. Dans cet exemple, la manière choisie pour encoder les versions repose sur l'utilisation de deux types : le type simple et le type complexe . Un type simple définit uniquement une version, tandis qu'un type complexe définit un nombre de versions puis une version, le nombre de versions correspondant au nombre de versions suivantes qui appartiennent à la même famille. En l'occurrence, le premier type encodé est le type complexe , avec deux versions, ces deux versions correspondant d'abord à l'anglais britannique puis à l'anglais américain, l'anglais américain étant codé avec un type simple . Une autre solution consiste à encoder non pas des types mais directement le nombre de versions d'une famille donné, puis à encoder lesdites versions. Par exemple, on aurait ici : 2 : anglais britannique, anglais américain ; 1 : français ; 1 : espagnol. Cependant, avec un tel système, on perd la récursivité, c'est-à-dire la possibilité d'avoir une sous-famille à l'intérieur d'une famille, par exemple des versions différentes suivant les régions américaines. Une fois les versions encodées, on peut spécifier les différents contenus. Dans cet exemple, on encode ces contenus par jeux de valeurs correspondant à un même contenu dans la structure XML (par exemple Open, Open, Ouvrir, Abrir ). L'encodage débute par la précision d'un type.

Pour le premier jeu de valeurs, le type précisé est le type standard. On encode alors le contenu associé à la première version : il s'agit de Open , qui est aussi le contenu de la deuxième version (il s'agit de la même famille), et on utilise donc le type Valeur simple pour n'encoder qu'une valeur pour les deux versions. L'encodage de la valeur en elle-même se fait par précision de sa longueur (nombre de caractères), puis par écriture de la valeur elle-même. Pour la version française, on utilise le type Chaîne standard , de même pour la version espagnole. L'encodage du jeu de valeurs suivant ( Close, Close, Fermer, Cerrar ) relève du même principe. En revanche, pour le jeu de valeurs suivant il n'existe qu'une valeur : picture.png . Au lieu du type standard , on utilise le type Valeur simple , puis coder cette valeur une seule fois. Le jeu de valeurs suivant est, comme les deux premiers, standard , cependant il existe une différence dans l'encodage de la valeur Option pour la version française : en effet, la valeur Option ayant déjà été encodée, plutôt que de l'encoder une seconde fois, on y fait référence en utilisant le type Référence puis en spécifiant l'index de la chaîne encodée à laquelle on fait référence. Option ayant été la huitième valeur encodée, l'index vaut 7 puisque le décompte des index débute à la valeur 0 . Le dernier jeu de valeurs est, lui aussi, encodé avec le type standard . Cependant pour les deux versions de la même famille (anglais britannique et américain), les valeurs sont différentes. Contrairement aux valeurs précédentes pour cette famille, on n'utilise donc pas le type Valeur simple mais le type Standard , puis on encode les deux chaînes distinctes, Colour et Color . Enfin, on peut remarquer que pour la version espagnole Color , on utilise une référence à la onzième chaîne indexée (index 10 ), • Color .

Cet exemple illustre l'utilisation du mode de codage par valeur unique, aussi bien au niveau de toutes les versions que d'une famille de versions, ainsi que l'utilisation de références à des chaînes précédemment codées. On observe, en figure 10, un mode particulier de réalisation du dispositif de codage et du dispositif de décodage objets de la présente invention, 900 et différents périphériques adaptés à implémenter chaque aspect de la présente invention. Dans le mode de réalisation illustré en figure 10, le dispositif 900 est un micro-ordinateur de type connu connecté, dans le cas du codeur, par le biais d'une carte graphique 904, à un moyen d'acquisition ou de stockage de documents structurés 901, par exemple une interface avec un réseau informatique local ou avec une mémoire, adapté à fournir des données d'un document structuré. Le dispositif 900 comporte une interface de communication 918 reliée à un réseau 934 apte à transmettre, en entrée, des données numériques à coder ou à décoder et, en sortie, des données codées ou décodées par le dispositif 900. Le dispositif 900 comporte également un moyen de stockage 912, par exemple un disque dur, et un lecteur 914 de disquette 916. La disquette 916 et le moyen de stockage 912 peuvent contenir des données à coder ou à décoder, des données codées ou décodées et un programme informatique adapté à implémenter le procédé d'encodage ou le procédé de décodage objets de la présente invention. Selon une variante, le programme permettant au dispositif de mettre en oeuvre la présente invention est stocké en mémoire morte ROM (acronyme de read only memory pour mémoire non réinscriptible) 906. Selon une autre variante, le programme est reçu par l'intermédiaire du réseau de communication 934 avant d'être stocké.

Le dispositif 900 possède un écran 905 permettant de visualiser les données à coder ou décodées ou servant d'interface avec l'utilisateur pour paramétrer certains modes d'exécution du dispositif 900, à l'aide d'un clavier 910 et/ou d'une souris par exemple.

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

Le dispositif décrit ici et, particulièrement, l'unité centrale 903, sont susceptibles d'implémenter tout ou partie des traitements décrits en regard des figures 1 à 7, pour mettre en oeuvre chaque procédé objet de la présente invention et constituer chaque dispositif objet de la présente invention.

Claims (12)

REVENDICATIONS

1 - Procédé d'encodage d'information (805, 855) représentant plusieurs versions d'un contenu, caractérisé en ce qu'il comporte : - une étape (110) de détermination d'une structure (810, 815, 820) comportant des items de contenu et d'une pluralité de versions (855) du contenu associé à ladite structure, - une étape (140) d'association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour fournir une information d'association et - une étape (150, 200 à 290, 310 à 390) d'encodage d'un fichier unique (865) comportant une information représentative de ladite association, ladite structure et lesdites valeurs des versions du contenu associé aux items de contenu.

2 - Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape d'encodage (150, 200 à 290, 310 à 390), on encode le fichier unique (865) dans un format binaire d'encodage d'un document structuré.

3 û Procédé selon la revendication 2, caractérisé en ce que, l'information (805, 855) représentant plusieurs versions d'un contenu comportant au moins un élément possédant un nom ou au moins un attribut possédant un nom, au moins un nom d'élément ou d'attributs est traité comme un item de contenu.

4 û Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape d'association (140), l'information d'association comporte, pour au moins un item de contenu, un type indiquant la nature de l'item de contenu et un contenu.

5 û Procédé selon la revendication 4, caractérisé en ce qu'il comporte une étape (470) de comparaison dudit type avec une liste de types prédéterminée et, si ledit type n'apparaît pas dans ladite liste, pour ledit item de contenu, on ne conserve qu'une seule version de contenu.

6 û Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (150, 200 à 290, 310 à 390) d'encodage du fichier unique (865), ledit fichier unique représente chaque association entre versionsde contenus et items avec, dans la structure, une liste (855) référençant, pour chaque item ayant un contenu, les différentes versions disponibles dudit contenu.

7 û Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (150, 200 à 290, 310 à 390) d'encodage du fichier unique (865), ledit fichier unique représente chaque association entre versions de contenus et items avec, d'une part, une structure et, d'autre part, une table de contenus donnant la liste, pour chaque version, des différentes valeurs et, pour chaque item ayant un contenu, les différentes versions, chaque item de contenu étant repéré par un index spécifique et on encode, d'abord, la table de contenu et, ensuite, la structure.

8 û Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'étape (150, 200 à 290, 310 à 390) d'encodage du fichier unique, pour encoder les items de contenu, on encode un index de l'item, ledit index indiquant quelle liste de valeurs considérer lors du décodage, parmi une pluralité de listes correspondant aux différentes versions du contenu.

9 û Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, au cours de l'étape (150, 200 à 290, 310 à 390) d'encodage du fichier unique, on encode au moins une liste de valeurs récursive, des valeurs formant des sous-listes de ladite liste de valeurs récursive.

10 û Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que au cours de l'étape (140) d'association, au moins une version est définie par référence à une autre version.

11 û Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que, l'information qui représente plusieurs versions d'un contenu comportant une pluralité de documents, au cours de l'étape (110) de détermination d'une structure comportant des items de contenu, on effectue une étape de comparaison de structures d'au moins deux desdits documents sans prendre en compte les contenus.

12 û Procédé selon la revendication 11, caractérisé en ce que, à la suite de l'étape de comparaison, si les structures diffèrent, on effectue une étape (120, 130) d'uniformisation des dites structures.13 û Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que, au cours de l'étape (140) d'association, on détermine un type associé à chaque item de contenu, entre un type signifiant que l'item prend une valeur unique et au moins un type signifiant que l'item prend une valeur dans une liste de valeurs, ladite liste de valeurs étant formée au cours de ladite étape d'association. 14 û Procédé selon la revendication 13, caractérisé en ce que, les types comportent au moins un type indiquant que la liste comporte des sous-listes. 15 - Procédé de décodage d'information représentant plusieurs versions d'un contenu, caractérisé en ce qu'il comporte : - une étape (410) de décodage d'un fichier unique représentant une structure comportant des items de contenu, une pluralité de versions du contenu associé à ladite structure et une information représentative d'une association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour obtenir ladite structure et, pour au moins la version identifiée dans ladite requête, l'information d'association et la version du contenu de chaque item de contenu et - une étape (430 à 470) d'association de ladite structure avec, pour la version identifiée dans ladite requête, la valeur de contenu de chaque item de contenu. 16 û Procédé selon la revendication 15, caractérisé en ce qu'il comporte, en outre : - une étape (400) de réception d'une requête de transmission d'une version d'un contenu à une application, - une étape (461, 470) de fourniture de ladite version du contenu à ladite application. 17 û Procédé selon la revendication 16, caractérisé en ce que, au cours de l'étape (400) de réception d'une requête, on met en oeuvre une interface XML. 18 - Dispositif (900) d'encodage d'information représentant plusieurs versions d'un contenu, caractérisé en ce qu'il comporte :- un moyen (903, 908) de détermination d'une structure comportant des items de contenu et d'une pluralité de versions du contenu associé à ladite structure, - un moyen (903, 908) d'association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour fournir de l'information d'association et - un moyen (903, 908) d'encodage d'un fichier unique comportant une information représentative de ladite association, ladite structure et lesdites valeurs des versions du contenu associé aux items de contenu. 19 - Dispositif (900) de décodage d'information, caractérisé en ce qu'il comporte : - un moyen (903, 908) de décodage d'un fichier unique représentant une structure comportant des items de contenu, une pluralité de versions du contenu associé à ladite structure et une information représentative d'une association, à chaque item de contenu de ladite structure, de chaque valeur du contenu associé audit item, dans une version du contenu, pour obtenir ladite structure et, pour au moins la version identifiée dans ladite requête, l'information d'association et la version du contenu de chaque item de contenu et - un moyen (903, 908) d'association de ladite structure avec, pour la version identifiée dans ladite requête, la valeur de contenu de chaque item de contenu. 20 - Programme d'ordinateur chargeable dans un système informatique (900), ledit programme contenant des instructions permettant la mise en oeuvre du procédé d'encodage selon l'une quelconque des revendications 1 à 14 et/ou du procédé de décodage selon l'une quelconque des revendications 15 à 17. 21 - Support (906, 912, 914, 916) d'informations lisibles par un ordinateur (900) ou un microprocesseur (903), amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé d'encodage selon l'une quelconque des revendications 1 à 14 et/ou du procédé de décodage selon l'une quelconque des revendications 15 à 17.