FR2930661A1

FR2930661A1 - Procede d'acces a une partie ou de modification d'une partie d'un document xml binaire, dispositifs associes

Info

Publication number: FR2930661A1
Application number: FR0950862A
Authority: FR
Inventors: Herve Ruellan; Franck Denoual
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-04-25
Filing date: 2009-02-11
Publication date: 2009-10-30
Anticipated expiration: 2029-02-11
Also published as: FR2930661B1; FR2930660A1; US20090271695A1

Abstract

La présente invention concerne des procédés d'accès et de modification d'une partie d'un document codé, par exemple un document structuré type XML Binaire, ainsi que des dispositifs associés.En particulier, le procédé d'accès comprend le décodage de la partie à accéder à l'aide d'une table de décodage (300', 310') ayant des entrées qui associent chacune un item non codé (220) à un champ codé (225).Le procédé est particulier en comprenant une étape de formation (430, 530) de ladite table pour le décodage à partir :d'au moins une table initiale (300, 310) de codage/décodage regroupant des entrées correspondant à une pluralité de champs codés du document et comprenant, pour au moins une entrée, une indication de la première occurrence (320, 330), à l'intérieur du document codé, de l'item associé à l'entrée; etd'une localisation (L), à l'intérieur du document codé, déterminée d'un premier champ codé de ladite partie à accéder.

Description

La présente invention concerne un procédé et un système d'accès à une partie d'un document codé, ainsi qu'un procédé et un système de modification d'une partie d'un document codé, par exemple un document structuré type XML Binaire (acronyme de "eXtensible Markup Language" pour langage de balisage extensible).

Le format XML est une syntaxe pour définir des langages informatiques, ce qui permet de créer des langages adaptés à des utilisations différentes pouvant cependant être traités par de mêmes outils. Un document XML est composé d'éléments, chaque élément 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 également être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont alors placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple: <balise attribut="valeur">). La syntaxe XML permet aussi de définir des commentaires (par exemple: <1-- Commentaire--> ) et des instructions de traitement, qui peuvent préciser à une application informatique quels traitements appliquer au document XML (par exemple : <?montraitement?> ). Dans la terminologie XML, l'ensemble des termes élément , attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement sont regroupés sous le nom générique de item . Dans un cadre plus général, l'ensemble de ces termes (formant par exemple l'élément défini entre une balise ouvrante et une balise fermante) peut être regroupé sous le nom générique de noeud .

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: 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). Pour traiter un document XML, celui-ci doit être lu en mémoire. Deux familles de méthodes de lecture d'un document XML existent.

La première famille de méthodes consiste à représenter l'intégralité du document XML en mémoire, sous forme d'arbre. Ces méthodes permettent un accès facile à toute partie du document XML, mais nécessitent un espace mémoire important. Un exemple de ces méthodes est l'interface de programmation DOM ( Document Object Model en anglais, ou Modèle Objet de Documents en français). On connaît une méthode d'accès à une partie de document XML non codé s'appuyant en partie sur cette méthode de lecture, en particulier le projet VTD-XML (http://vtd-xml.sourceforge.net/technical/O.html). Selon ce dernier, le document XML est prétraité et un arbre le représentant est construit en mémoire. Cet arbre est une représentation partielle du document XML, où seule la structure du document XML est contenue en mémoire. Le contenu du document XML n'est pas dupliqué en mémoire et est accessible depuis la structure à l'aide de pointeurs placés dans les noeuds de cette dernière. Cette méthode a l'avantage de permettre d'accéder rapidement à n'importe quel noeud du document XML, puisque la navigation jusqu'au noeud recherché s'effectue à partir de l'arbre contenu en mémoire, sans pour autant nécessiter une place mémoire importante, puisque le contenu des noeuds du document XML n'est pas stocké en mémoire. Une deuxième famille de méthodes consiste à représenter chaque noeud du document XML par un ou plusieurs événements. L'intégralité du document XML est alors décrite par la succession de ces événements. Ces méthodes permettent de traiter un document XML au fur et à mesure de sa lecture (mode streaming selon la terminologie anglo-saxonne). Un avantage de ces méthodes réside dans le peu d'espace mémoire requis pour leur traitement. Néanmoins, elles imposent une navigation dans le document uniquement dans l'ordre de lecture de celui-ci. Des exemples de ces méthodes sont les interfaces de programmation SAX ( Simple API for XML en anglais, ou Interface de programmation simple pour XML en français) et StAX ( Streaming API for XML en anglais, ou Interface de programmation au fur et à mesure pour XML en français).

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. Tout d'abord, le format XML permet en particulier de disposer de nombreux outils pour traiter les fichiers générés. Egalement, 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. Néanmoins, le principal inconvénient de la syntaxe XML est d'être très prolixe. Ainsi la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi un temps de traitement important lors de la génération et surtout de la lecture de documents XML.

Pour pallier ces inconvénients, des mécanismes ont été mis en place dont le but est de coder le contenu du document XML sous une forme plus efficace, permettant de reconstruire facilement le document XML. Cependant, la plupart de ces mécanismes ne conservent pas l'ensemble des avantages du format XML. Il existe néanmoins de nouveaux formats qui permettent de stocker les données contenues dans un document XML. Ces différents formats sont regroupés sous l'appellation XML Binaire . Parmi ces mécanismes, 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). Ce type de mécanisme est utilisé par tous les formats XML Binaire. Un autre mécanisme consiste à utiliser une ou plusieurs tables 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é, tout en facilitant également la lecture. En effet, il n'y a plus besoin de lire la chaîne complète dans le fichier, et en outre, la détermination de l'élément lu peut être réalisée par une comparaison d'entiers au lieu d'une comparaison de chaînes de caractères. Ce type de mécanisme est utilisé par des formats tels que Fast Infoset ou Efficient XML Interchange (EXI) (nom commerciaux). Fast Infoset est un format ITU-T et ISO permettant de coder un document XML sous une forme binaire. Ce format utilise en particulier des indicateurs binaires pour décrire les différents noeuds contenus dans le document XML, ainsi que des tables d'index pour les noms d'éléments, les noms d'attributs, les valeurs d'attributs et les valeurs textuelles. EXI est un format en cours de standardisation par le W3C (acronyme de World Wide Web Consortium , organisation produisant des standards pour le Web) permettant de coder un document XML sous une forme binaire. Il reprend des mécanismes similaires à ceux de Fast Infoset. Cependant, il ajoute un mécanisme de grammaires dynamiques décrivant la structure des éléments. Pour chaque élément ayant un nom donné, une grammaire décrit le contenu des éléments portant ce nom. Cette grammaire évolue en fonction du contenu rencontré pour les éléments portant ce nom lors du codage ou du décodage. Ces grammaires peuvent être considérées comme une forme d'indexation des noeuds contenus dans un élément. Ainsi, par exemple, il est possible d'utiliser une grammaire pour chaque noeud élément ayant un nom donné. Lors de la première occurrence d'un noeud fils dans le contenu de ce noeud, une nouvelle entrée décrivant le type de ce noeud fils est ajoutée dans la grammaire avec un index associé. Lors des occurrences suivantes d'un noeud fils similaire, ce nouveau noeud fils est décrit en utilisant l'index associé.

Ces grammaires et autres tables d'index sont créées au fur et à mesure du codage du document XML en document XML Binaire, ainsi qu'au fur et à mesure du décodage du document XML Binaire. Ces tables sont ainsi appelées tables de codage et/ou décodage. A titre illustratif, le format EXI prévoit les différentes tables de codage 20 ou décodage suivantes : - table des URI ; - tables de préfixes associés à une URI. Il y a une table de préfixes par URI ; - tables de noms locaux (ou "local name") associés, chacune, à une 25 URI. Il y a une table de noms locaux par URI ; - tables locales des valeurs de contenu textuel et d'attributs. Il y a une table locale de valeurs pour chaque élément et pour chaque attribut, et une table globale de valeurs regroupant les valeurs de toutes ces tables locales ; - grammaires ou tables de structures permettant de décrire la 30 structure du contenu d'un élément. Il y a plusieurs tables de structures pour chaque élément.

L'utilisation de formats XML Binaire permet d'une part, d'obtenir des documents plus compacts et, d'autre part, de traiter ces documents (les lire ou les écrire) plus rapidement. Cependant, l'utilisation de formats XML Binaire comporte des inconvénients.

En particulier, on illustre un inconvénient de ce format en référence aux figures 1 et 2. La figure 1 représente un exemple de document XML listant des personnes, la liste contenant les noms (dans les éléments nommés lastname ) et prénoms (dans les éléments nommés firstname ) de deux personnes, à savoir Mary Smith et John Smith . Il est à noter que pour des raisons de présentations, le contenu de ce document est présenté indenté sur plusieurs lignes, mais qu'il convient d'ignorer les espaces présents sur la figure lors des traitements décrits dans la suite du texte. Les deux personnes décrites dans ce document ont le même nom de famille ( lastname ) : Smith . Si l'on utilise un mécanisme d'indexation des valeurs, la première occurrence de Smith est codée telle quelle, comme une chaîne de caractère à laquelle est associé un index. Par contre, la deuxième occurrence de Smith est codée à l'aide de cet index uniquement. Ce mécanisme est similaire lors du décodage: lors de l'occurrence de la valeur Smith dans le document à décoder, cette valeur est associée à l'index utilisé pour le codage. Ainsi, toute occurrence ultérieure de cet index dans le document à décoder indique que la valeur contenue dans le document à cet emplacement est Smith . Ce codage par index selon le format EXI est illustré par la figure 2 qui montre des exemples de tables créées pour coder ou décoder le document XML de la figure 1 dans un format XML Binaire. Ces deux tables reposent sur le principe de substitution, lors du codage, d'une partie du document XML par un index. Que ce soit le processus de codage d'un document ou celui de décodage du même document codé, les tables de codage et de décodage sont identiques. Pour la suite de la description, les termes "de codage" et "de décodage" des tables qualifient uniquement le processus plus général dans lequel elles sont utilisées.

La table 200 est une table d'index pour les valeurs textuelles contenues dans le document XML. Cette table d'index est créée lors du codage ou du décodage du document XML. A chaque fois qu'une nouvelle valeur textuelle 220 est rencontrée, cette valeur est ajoutée à la fin de la table et la première valeur d'index 225 non utilisée lui est associée. Lors du codage, cette nouvelle valeur est codée dans le document XML Binaire. Lors du décodage, cette nouvelle valeur est décodée à partir du document XML Binaire. Quand une même valeur textuelle est à nouveau rencontrée dans un document (par exemple dans le cas de Smith à la ligne 175 du document de la figure 1), cette valeur textuelle 220 est remplacée par son index 225. Dans le cas du codage, on utilise la valeur de l'index 225 comme valeur de codage (éventuellement elle-même codée) dans le document XML Binaire (et non la valeur textuelle 220), la valeur de l'index étant obtenue à partir de la table 200. Dans le cas du décodage, la valeur de l'index est décodée depuis le document XML Binaire, puis la valeur textuelle est obtenue à partir de la table 200. Ainsi, lors du codage, la table 200 permet d'obtenir un index 225 à partir d'une valeur textuelle 220. Lors du décodage, la table 200 permet d'obtenir une valeur textuelle à partir d'un index. La table 200 montre l'état de la table d'index pour les valeurs textuelles à la fin du codage ou du décodage du document de la figure 1. La table 210 est une grammaire (ou table d'index) pour le contenu de l'élément person du document de la figure 1. Cette grammaire est créée lors du codage ou du décodage du document XML. A chaque fois qu'un nouveau type de contenu 230 est rencontré pour un élément person , une nouvelle entrée (appelée également production) est ajoutée au début de cette grammaire. Ainsi, l'entrée 211 correspondant au début d'un élément lastname 230 a été ajoutée après l'entrée 212 correspondant au début d'un élément firstname . Les autres entrées 213, 214 et 215 sont présentes par défaut dans la grammaire. Chaque entrée décrit un type du contenu rencontré (ou pouvant être rencontré dans le cas des entrées présentes par défaut) et y associe un index 235. Le fonctionnement de cette table 210 est similaire à celui de la table 200. Il est à noter que dans la description, les valeurs d'index pour la table 210 sont recalculées à chaque ajout d'une nouvelle entrée dans cette table. La table 210 montre l'état de la grammaire de l'élément person à la fin du codage ou du décodage du document de la figure 1.

Dans cette table, le code SE correspond à l'événement de début d'élément. Ce code est suivi entre parenthèse du nom de l'élément, ou par * pour représenter un élément quelconque (dont le nom sera codé dans le document XML Binaire). Le code EE correspond à l'événement de fin d'élément et le code CH correspond à un noeud textuel.

Il est à noter que la figure 2 ne présente que deux tables, mais dans la pratique d'autres tables de codage ou de décodage peuvent être utilisées, comme listées précédemment à titre illustratif. Ces autres tables de codage ou de décodage auront généralement des structures similaires à celles des tables 200 ou 210. Par exemple, dans le cas du document de la figure 1, des tables de codage correspondant au contenu des éléments firstname et lastname sont utilisées. Ces tables ont des structures similaires à la table 210. De retour à la figure 1, si l'on veut accéder directement au nom de famille de la deuxième personne dans le document XML Binaire codé, il est nécessaire d'avoir lu au préalable le nom de famille de la première personne afin de connaître la chaîne de caractère associée à l'index utilisé pour coder le nom de famille de la deuxième personne. Ainsi, pour accéder à la partie souhaitée du document et donc la décoder, il est nécessaire de décoder tout le début du document afin de disposer des informations de décodage utilisées pour cette partie. Les formats XML Binaire rendent ainsi difficile l'accès direct à une information se trouvant au milieu du document sans décoder tout ce qui précède cette information. Le décodage du début du document représente en outre un coût de traitement important, notamment lorsqu'on accède régulièrement à diverses parties du document. L'invention vise à résoudre ces inconvénients de l'état de la technique.

A cet effet, l'invention concerne notamment un procédé d'accès à une partie d'un document à partir d'une version codée dudit document, le procédé comprenant le décodage de la partie à accéder à l'aide d'au moins une table de décodage ayant des entrées qui associent chacune un item non codé à un champ codé, et le procédé comprend une étape de formation de ladite au moins une table à partir : - d'au moins une table initiale de codage/décodage regroupant des entrées correspondant à une pluralité de champs codés du document et comprenant, pour au moins une entrée, une indication de la première occurrence, à l'intérieur du document codé, de l'item associé à l'entrée ; et - d'une localisation, à l'intérieur du document codé, d'un premier champ codé de ladite partie à accéder. La première occurrence d'un item correspond à la première apparition de l'item considéré dans le document. De façon symétrique, le premier champ codé d'une partie à accéder est celui qui présente une localisation dans le document qui est la plus proche du début de celui-ci. La table initiale correspond généralement à la table de codage (par exemple les tables 200, 210 de la figure 2) obtenue à la fin du codage du document complet. On retrouve alors dans cette table tous les items et champs codés associés qui sont présents dans le document codé. Ainsi, l'invention permet, à l'aide de cette indication de première occurrence, de retrouver facilement, depuis les tables complètes ou initiales référençant l'ensemble des entrées résultant de l'encodage du document, l'état des tables utilisées pour l'encodage et/ou le décodage au point souhaité d'accès du document alors même qu'aucun décodage n'a été effectué. L'invention est d'autant plus efficace que la construction des tables de codage/décodage est réalisée indépendamment de l'accès au document. Ainsi, à chaque accès ultérieur du document, ces tables initiales permettent de retrouver rapidement l'état au point d'accès du document.

Grâce à l'invention, il n'est plus nécessaire de décoder, et éventuellement de ré-encoder, la partie du document précédant le point d'accès lors de chaque accès au document.

L'invention s'applique aux documents électroniques structurés, en particulier les documents balisés codés en binaire, par exemple les documents XML Binaire tels qu'au format Fast Infoset ou EXI. En particulier, l'étape de formation comprend : - la détermination de ladite localisation, à l'intérieur du document codé, du premier champ codé de ladite partie à accéder ; et - la sélection des entrées de l'au moins une table initiale dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation déterminée, de sorte à former ladite au moins une table de codage/décodage ; ledit décodage de ladite partie à accéder étant, en outre, réalisé à l'aide des entrées sélectionnées. On comprend qu'un document présente un premier élément et un dernier élément définissant respectivement le début et la fin du document. Pour la suite de la description, toute notion d'ordre s'apprécie au regard du parcours classique des documents depuis leur élément de début vers leur élément de fin. Ainsi le premier champ codé de la partie à accéder est le champ codé de ladite partie qui est le plus proche du début du document considéré. Les entrées sélectionnées selon l'invention forment ainsi les tables de décodage appropriées pour décoder directement la partie à accéder. Il se peut qu'aucune entrée ne soit sélectionnée et que les tables de décodage formées soient vides. C'est notamment le cas lorsque l'on accède au tout début du document codé. On accède initialement au premier champ codé de la partie à accéder, puis les tables de codage/décodage formées avec les entrées sélectionnées évoluent de façon classique au fur et à mesure du décodage des autres champs de la partie à accéder. Cette sélection peut être réalisée par simple marquage, par exemple via un drapeau binaire, des entrées sélectionnées à l'intérieur de la table initiale, l'évolution ultérieure pouvant uniquement consister en l'évolution du marquage des entrées non marquées.

On préférera cependant un mode de réalisation dans lequel ladite sélection comprend la suppression, dans ladite au moins une table initiale, des entrées dont la première occurrence indiquée a une localisation postérieure ou égale à ladite localisation déterminée de sorte à former ladite au moins une table pour le décodage. On récupère ainsi une table conforme en tout point à celle normalement manipulée à l'endroit de l'accès. En particulier, le procédé peut comprendre une étape de duplication de ladite au moins une table initiale de codage/décodage avant ladite étape de sélection. Ainsi, on conserve intactes les tables complètes/initiales qui pourront être utilisées, par de nouvelles duplications, pour les accès ultérieurs au document. Selon une caractéristique particulière de l'invention, les entrées de l'au moins une table initiale comprennent une référence de l'emplacement, dans ledit document codé, de la définition du champ codé associé. Dans cette configuration, les informations de définition du codage ne sont pas directement mémorisées au niveau des entrées des tables initiales, mais par référence à l'emplacement de leur définition dans le flux codé. Ceci permet de réduire la taille de ces tables initiales pour une transmission plus aisée. En particulier, ladite au moins une table initiale est transmise attachée audit document codé, soit directement intégrée dans le document codé, soit dans un fichier qui lui est attaché. L'accès à une partie d'un document codé selon l'invention peut ainsi être réalisé efficacement sur un site distant de celui générant le document. Particulièrement, ladite référence pointe sur ladite première occurrence. Ainsi, en une information brève, typiquement un pointeur, l'entrée de la table initiale est totalement définie, y compris, implicitement, l'indication de première occurrence utilisée dans la mise en oeuvre de l'invention. Selon une caractéristique particulière de l'invention, l'étape de formation comprend : - la sélection d'au moins une entrée de la table initiale dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation d'un premier champ codé ; - l'accès à l'emplacement référencé dans ladite entrée sélectionnée et le décodage des données codées audit emplacement pour former une entrée de la table de décodage. Ces étapes permettent de constituer les entrées de la table de décodage en récupérant, directement dans le flux codé, des informations de définition des entrées : l'item ou la valeur concerné(e). La valeur de codage associée à l'entrée (l'index) est déterminée par la position de l'entrée dans la table et le nombre courant d'entrées dans la table. En particulier, le procédé comprend une étape d'obtention d'une donnée codée de ladite partie à décoder, et la sélection, l'accès et le décodage de l'entrée associée à cette donnée codée sont réalisés suite à ladite obtention et si aucune entrée associée à ladite donnée codée n'est présente dans ladite table de décodage. Ici, on construit la ou les tables de décodage en parallèle du décodage effectif du document. Selon ces dispositions spécifiques, on crée les entrées de la table de décodage uniquement lorsqu'elles sont mises en oeuvre dans la partie de document à accéder. On évite ainsi de créer des entrées inutiles pour cet accès et on accélère le traitement selon l'invention. Particulièrement, préalablement au décodage de la partie à accéder, le procédé comprend une étape de comptabilisation du nombre d'entrées de ladite table initiale dont l'indication de première occurrence associée précède ladite localisation du premier champ codé de la partie à accéder. Cette étape de comptabilisation permet de connaître le nombre d'entrées de ladite table initiale et donc de déterminer la valeur de codage associée à chaque entrée (son index). En effet, l'index d'une entrée de la table est codé en fonction du nombre courant d'entrées de la table, pour utiliser une taille de codage optimale. Dans un mode de réalisation, ladite indication de première occurrence comprend une indication de localisation de type pointeur vers la position de la première occurrence dudit champ codé à l'intérieur du document codé. On dispose ainsi rapidement de la localisation de l'occurrence sans traitement supplémentaire. Dans le cas où les entrées référencent leurs définitions dans le document codé, ce pointeur joue une double fonction: indicateur de première occurrence et référence vers la définition de l'entrée. Il s'avère, en effet, que généralement les informations définissant l'utilisation d'un index pour le codage d'un item sont codées, dans le document, lors de la première occurrence de l'item codé.

Comme indiqué ci-dessus, on recherche une efficacité accrue de l'invention en construisant les tables initiales de codage/décodage de façon indépendante à l'accès au document. Ainsi, on envisage tout d'abord que le procédé comprend une étape de construction de l'au moins une table initiale de codage/décodage, ladite construction étant préalable à l'accès direct audit document codé. Par exemple, ladite construction est réalisée en même temps que le codage dudit document dans sa version codée. On optimise ainsi le temps d'élaboration de ces tables. Cette réalisation est envisagée en particulier lorsque c'est le même dispositif qui code le document initial et qui y accède ultérieurement. Toutefois, cette table initiale pourra être attachée au document codé, l'ensemble étant transmis ultérieurement. En variante, ledit document codé est reçu par un dispositif d'accès, ladite construction étant réalisée par ledit dispositif d'accès lors d'un accès antérieur audit document codé. On note qu'une efficacité accrue est obtenue lorsque cette construction est réalisée lors du premier accès direct audit document, car tous les accès ultérieurs pourront bénéficier de cette construction préalable. Dans un mode de réalisation, ladite au moins une table initiale est stockée en mémoire d'un dispositif d'accès, ledit stockage étant fonction d'au moins une information de priorité associée audit document. Ce stockage va de paire avec l'utilisation ultérieure de ces tables lors des accès futurs. En particulier, ladite information de priorité est l'une choisie parmi l'ensemble comprenant une information de fréquence d'utilisation dudit document, une information de localisation moyenne des accès réalisés dans ledit document, et la taille dudit document. On envisage cependant également une combinaison de ces différentes informations.

Par ailleurs, en observant les solutions de l'art antérieur, il apparaît également difficile de mettre à jour une donnée au sein du document XML Binaire. Alors que, dans un document au format XML, il suffit de modifier cette donnée directement au sein du document, dans le cas d'un format codé XML Binaire, ce n'est plus possible. En effet, le codage de la donnée initiale peut prendre plusieurs formes : codage direct ou par l'intermédiaire d'un index. De même, le codage de la donnée modifiée peut aussi prendre plusieurs formes qui dépendent de ce qui précède dans le document. En outre, la modification de la donnée peut impacter le codage de ce qui suit dans le document. Cette problématique est illustrée en référence à la figure 1. Si l'on souhaite mettre à jour le nom de famille de la première personne, pour remplacer Smith par Thompson , il faut, lors de l'utilisation d'un mécanisme d'indexation des valeurs pour le codage, recoder non seulement la première occurrence de Smith (celle qui est effectivement modifiée), mais aussi la deuxième (qui, elle, n'est pas modifiée mais dont le codage dépendait de la première occurrence). Il apparaît donc que la modification d'une donnée dans un document XML stocké dans un format XML Binaire ne peut être réalisée simplement, engendrant des traitements lourds et coûteux de décodage de tout le document en mémoire pour y effectuer les modifications souhaitées avant recodage. Dans ce dessein, l'invention a également trait à un procédé de modification d'une partie d'un document à partir d'une version codée dudit document, comprenant : - une étape d'accès à ladite partie à accéder pour modification, selon le procédé d'accès précédemment exposé ; et - ledit décodage de la partie à accéder, donc à compter de la localisation déterminée (soit généralement le début de la partie à modifier), étant suivi d'une modification de ladite partie décodée et d'un codage de ladite partie modifiée vers un document modifié codé.

Grâce à l'accès efficace directement à la partie souhaitée, on peut effectuer une modification du document sans interagir, par codage ou décodage, avec le début du document codé, correspondant à la portion avant ladite partie à modifier.

En particulier, on prévoit que le procédé comprend la détermination de la localisation, à l'intérieur du document codé, du premier champ codé de ladite partie à accéder; puis la sélection des entrées et le décodage de ladite partie à accéder comme évoqué ci-dessus. Ainsi puisqu'on accède directement à la position souhaitée de modification, on prévoit une étape de recopie du début du document codé jusqu'à ladite localisation déterminée. Cette étape de recopie est réalisée vers une version codée et modifiée du document initial. Cette étape de recopie ou le placement direct au premier champ codé de la partie à modifier contribue aux performances de l'invention, en comparaison des solutions connues qui nécessitent le décodage du début du document puis son recodage. Dans un mode de réalisation, le procédé comprend une étape de détermination de la localisation, à l'intérieur du document codé, du dernier champ codé à modifier : - ledit décodage de la partie à modifier étant poursuivi jusqu'à ladite localisation du dernier champ codé à modifier. On note que ce dernier champ codé à modifier n'est pas nécessairement dans la partie à modifier définie initialement. Il se peut en effet que le codage de ce champ identifié comme dernier doive être modifié à cause des modifications apportées en amont dans le document (par exemple par décalage des index de codage). Cette localisation du dernier champ codé à modifier permet en combinaison avec la localisation du premier champ codé de délimiter de façon efficace l'étendue des parties du document à modifier. Cette délimitation permet d'éviter des traitements inutiles de décodage/recodage des parties non impactées par la modification souhaitée. En l'absence de localisation du dernier champ codé à modifier, on décode, modifie et recode le document codé (puis modifié) jusqu'à sa fin.

Grâce à la localisation du dernier champ codé à modifier, on peut prévoir que, suite au décodage, à la modification et au codage de la partie ainsi modifiée, on recopie la fin du document codé à compter de ladite localisation du dernier champ codé à modifier.

Cette étape constitue encore une étape de gain notable en traitements par rapport aux techniques connues, puisque la fin du document codé n'a pas besoin de décodage et recodage lorsque l'on arrive à délimiter efficacement la partie à modifier. Dans un mode de réalisation, au moins une entrée de ladite au moins une table initiale de codage/décodage comprend une indication de la dernière occurrence, à l'intérieur du document codé, de l'item associé à l'entrée. On observe à ce stade que cette indication peut être de même nature que celle de première occurrence: information de localisation et/ou pointeur. Cette information est utile, comme on le verra par la suite dans la description détaillée, pour déterminer, entre autres, le plus précisément possible la localisation du dernier champ codé impacté par la modification souhaité (le dernier champ codé à modifier). En outre, elle permet d'établir aisément une table de décodage épurée en n'y intégrant pas les entrées qui ne concernent que des items dont toutes les occurrences (donc première et dernière occurrences) précèdent le début de la partie à accéder. Ainsi, pour de telles entrées, seule leur existence est indiquée dans la table de décodage épurée (afin de pouvoir calculer correctement le nombre total d'entrées dans la table et l'index correspondant à chaque entrée effectivement utilisée), mais leur contenu n'est pas renseigné.

En particulier, on prévoit dans le cas où l'on procède à la construction de l'au moins une table initiale de codage/décodage, que cette construction comprend : - une étape préliminaire de modification d'au moins une table de codage/décodage de base, par exemple obtenue lors du codage préalable dudit document dans sa version codée, par l'adjonction, pour chaque entrée, d'une indication de première occurrence prenant la valeur de la localisation de début de document et d'une indication de dernière occurrence prenant la valeur de la localisation de début de document ; et - une étape ultérieure de traitement d'au moins une item dudit document, comprenant la modification de l'indication de dernière occurrence de l'entrée correspondant audit item, en fonction de la localisation, à l'intérieur du document codé, du champ codé correspondant audit item traité. Cette réalisation permet d'obtenir par des mécanismes simples les tables d'encodage avec référence des occurrences par un traitement unique du document, par exemple lors du codage initial du document ou lors d'un premier décodage du document codé. En particulier, il arrive qu'aucune entrée associée audit item traité n'existe dans ladite table. On prévoit alors que l'étape ultérieure comprend la création d'une entrée associée audit item traité, ladite entrée comprenant des indications de première et dernière occurrences renseignant la localisation, à l'intérieur du document codé, du champ codé correspondant audit item traité. Dans ce cas, cette étape ultérieure est notamment réalisée lors du recodage de la partie modifiée afin de maintenir à jour lesdites tables initiales pour les accès et modifications ultérieurs. Afin de disposer de nouvelles tables initiales mises à jour pour l'ensemble du document codé, il convient de traiter les entrées de tables correspondant aux items postérieurs à la partie à modifier du document. Dans ce dessein, on prévoit que le procédé comprend, suite à l'étape de codage de ladite partie modifiée, la récupération, soit par copie depuis la table initiale obtenue après construction lorsque les entrées ont été supprimées, soit par démarquage des entrées sélectionnées, dans l'au moins une table comprenant lesdites entrées sélectionnées (utilisée pour le décodage ou le codage et mises à jour depuis), des entrées de l'au moins une table initiale de codage/décodage construite dont la première occurrence est localisée, à l'intérieur du document codé, à ou après ladite localisation du dernier champ codé à modifier, et si la différence entre cette dernière localisation et la localisation, à l'intérieur du document modifié codé, du dernier champ codé de la partie modifiée est non nulle, on modifie, pour les entrées récupérées, les indications de localisation (aussi bien de première que de dernière occurrence), postérieures ou égales à ladite localisation du dernier champ codé à modifier, d'une valeur égale à ladite différence, par une incrémentation ou une décrémentation selon le signe de la différence.

Ce traitement permet de récupérer toutes les entrées de la table correspondant à la fin du document codé et qui ne sont pas impactées par la modification apportée au document. Il convient donc de les récupérer et de mettre à jour leurs localisations respectives afin de tenir compte d'un éventuel décalage introduit par le rallongement ou le rétrécissement de la partie modifiée. A la fin du traitement, on obtient ainsi les tables de codage initiales modifiées correspondant au document codé après sa mise à jour. Ce sont ainsi des tables disponibles pour les accès ou modifications ultérieures de ce document.

Dans un mode de réalisation, ladite sélection des entrées comprend la suppression, dans ladite au moins une table initiale, des entrées dont la première occurrence indiquée a une localisation postérieure à ladite localisation déterminée de sorte à former ladite au moins une table pour le décodage ou codage, le procédé comprenant la duplication de l'au moins une table ainsi obtenue de sorte à disposer d'au moins une table de codage, utilisée pour ledit décodage de la partie à modifier, et au moins une table de décodage, utilisée pour le codage de ladite partie modifiée. Ainsi en une action simple, on dispose des deux tables qui permettront successivement de décoder puis recoder la partie à modifier/modifiée.

En particulier, ladite table de codage est optimisée pour la détermination d'un champ codé à partir d'un item non codé et ladite table de décodage est optimisée pour la détermination d'un item non codé à partir d'un champ codé. Dans un mode de réalisation de l'invention, ladite au moins une table initiale est stockée en mémoire d'un dispositif d'accès, ledit stockage étant fonction d'au moins une information de priorité associée audit document, ladite information de priorité étant l'une choisie parmi l'ensemble comprenant une information de fréquence d'utilisation dudit document, une information de localisation moyenne des accès réalisés dans ledit document, une estimation du temps de décodage du document codé et codage du document modifié, une mesure du temps moyen de modification du document codé, et la taille dudit document. L'invention a également trait à un procédé de modification d'une pluralité de parties d'un document à partir d'une version codée dudit document, comprenant : - la détermination, pour chacune desdites parties à accéder pour 10 modification, de la localisation, à l'intérieur du document codé, du premier champ codé de ladite partie à accéder ; - la sélection de la localisation, parmi lesdites localisations déterminées des parties à modifier, la plus proche du début dudit document codé ; 15 - la sélection des entrées d'au moins une table initiale dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation la plus proche sélectionnée, ladite au moins une table initiale de codage/décodage comprenant des entrées associant chacune un item non codé à un champ codé et au moins une entrée comprenant une 20 indication de la première occurrence, à l'intérieur du document codé, de l'item associé à ladite entrée ; - le décodage des parties à modifier à l'aide des entrées sélectionnées, suivi d'une modification des parties décodés et d'un codage des parties modifiées. 25 De façon optionnelle, le procédé de modification d'une pluralité de parties peut comprendre des étapes du procédé de modification exposé précédemment. L'invention vise également un dispositif d'accès à ou de modification d'une partie d'un document à partir d'une version codée dudit document, 30 comprenant des moyens de décodage de ladite partie à accéder à l'aide d'au moins une table de codage/décodage ayant des entrées qui associent chacune un item non codé à un champ codé, et des moyens pour former ladite au moins une table étant formée à partir : - d'au moins une table initiale de codage/décodage regroupant des entrées correspondant à une pluralité de champs codés du document et comprenant, pour au moins une entrée, une indication de la première occurrence, à l'intérieur du document codé, de l'item associé à l'entrée ; et - d'une localisation, à l'intérieur du document codé, d'un premier champ codé de ladite partie à accéder. Dans un mode de réalisation, lesdits moyens pour former comprennent : - des moyens de détermination de la localisation, à l'intérieur du document codé, du premier champ codé de ladite partie à accéder ; - des moyens de sélection des entrées de l'au moins une table initiale dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation déterminée de sorte à former ladite au moins une table de codage/décodage pour le décodage ; et les moyens de décodage étant apte à décoder ladite partie à accéder à l'aide des entrées sélectionnées. En particulier, le dispositif comprend des moyens de détermination de la localisation, à l'intérieur du document codé, du dernier champ codé à modifier, - dispositif dans lequel les moyens de décodage sont aptes à décoder ledit document codé jusqu'à ladite localisation dudit dernier champ codé à modifier, - le dispositif comprenant des moyens de modification de ladite partie décodée et des moyens de codage de ladite partie ainsi modifiée vers un document modifié codé. On prévoit également que le dispositif peut comprendre des moyens de recopie, vers le document modifié codé, du début dudit document codé à modifier jusqu'à ladite localisation du premier champ codé et de la fin dudit document codé à modifier à partir de ladite localisation du dernier champ codé à modifier.

Dans un mode de réalisation, ledit dispositif comprend des moyens de stockage d'une pluralité de tables initiales de codage/décodage associée à une pluralité de documents codés, ledit dispositif étant apte à gérer le stockage desdites tables initiales en fonction d'au moins une information de priorité associée à chaque document codé. En particulier, les moyens de stockage comprennent une pluralité de mémoires, ledit dispositif étant apte à répartir lesdites tables initiales dans la pluralité de mémoires en fonction desdites informations de priorités. On peut ainsi optimiser l'utilisation des ressources mémoires ainsi que la rapidité d'accès à certaines tables (pour les documents les plus utilisés par exemple) plutôt qu'à d'autres. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques des procédés d'accès et de modification exposés précédemment.

L'invention vise également une structure de données associée à un document codé à l'aide d'au moins une table de codage ayant des entrées qui associent chacune un item non codé à un champ codé, la structure de données comprenant, pour des entrées de l'au moins une table de codage résultant du codage dudit document, une référence de l'emplacement, dans ledit document codé, de la définition de chaque entrée, et une indication de première occurrence de l'item associé à l'entrée. On observe ici que cette structure de données n'est ni plus, ni moins que les tables initiales évoquées précédemment. En particulier, ladite référence et ladite indication sont réalisées conjointement au moyen d'un même pointeur vers ladite première occurrence. En détail, ladite structure comprend, pour chacune des tables de codage, un champ indiquant le nombre d'entrées de ladite table. L'invention est particulièrement bien adaptée au format EXI. Dans ce cas, ladite structure comprend une première section codant conjointement une table des espaces de nommage, des tables de préfixes associés aux espaces de nommage et des tables de noms locaux associés aux espaces de nommage. Ce codage conjoint permet optimise la taille de la structure (donc de la table initiale) à joindre au document codé. En particulier, la première section comprend le nombre d'entrées de la table des espaces de nommage suivi, pour chacun des espace de nommage, d'un pointeur sur la définition de l'espace de nommage correspondant dans le document codé, du nombre d'entrées de la table de préfixes associée à l'espace de nommage, du nombre d'entrées de la table de noms locaux associée à l'espace de nommage et de pointeurs sur la définition de chacune des entrées des deux tables de préfixes et de noms locaux.

Egalement, ladite structure comprend une seconde section codant conjointement des tables de valeurs et des tables de structures (grammaires) rattachées à un même item, également appelé nom qualifié. Un nom qualifié est généralement défini par deux informations: un espace de nommage (défini par son URI par exemple) et un nom dans cet espace identifiant l'item. En particulier, cette deuxième section comprend le nombre de noms qualifiés suivi d'informations relatives à chacun de ces noms qualifiés, ces informations comprenant : - une description dudit nom qualifié, - une première sous-section décrivant une table de valeurs associée audit nom qualifié, - une deuxième sous-section décrivant une ou plusieurs tables de structures associées audit nom qualifié. En particulier, les noms qualifiés sont triés à l'intérieur de ladite deuxième section. Cette disposition permet une recherche dichotomique plus efficace à l'intérieur de la section, lorsque l'on souhaite accéder aux données spécifiques d'un nom qualifié. Selon une caractéristique, les noms qualifiés sont groupés, dans ladite deuxième section, selon la nature de l'item correspondant, par exemple les noms qualifiés d'attributs d'un côté et les noms qualifiés d'éléments d'autre part. 23 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é d'accès ou de modification 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é d'accès ou de modification 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 15 lesquels : - la figure 1 représente un exemple de document XML ; - la figure 2 représente des exemples de tables créées, de façon classique, pour coder ou décoder le document XML de la figure 1 dans un format XML Binaire ; 20 - la figure 3 représente des exemples de tables créés pour accéder ou modifier le document de la figure 1 conformément à l'invention ; - la figure 4 représente, sous forme d'un logigramme, un exemple d'étapes d'accès à une partie d'un document selon l'invention ; - la figure 5 représente, sous forme d'un logigramme, un exemple 25 d'étapes de modification d'une partie d'un document selon l'invention ; - les figures 6 et 7 représentent, sous forme de logigrammes, des étapes de génération de tables de codage modifiées mises en oeuvre dans le processus des figures 4 et 5 ; - la figure 8 représente, sous forme d'un logigramme, des étapes de 30 génération de tables de codage pour une localisation précise du document traité lors des processus des figures 4 et 5 ; - la figure 9 illustre l'évolution d'une table de codage lors de son utilisation par la présente invention ; - la figure 10 représente, sous forme d'un logigramme, des étapes pour la détermination d'une localisation finale de modification du document traité lors du processus de la figure 5 ; - la figure 11 illustre, sous forme d'un logigramme, des étapes de modification du document lors du processus de la figure 5 ; - la figure 12 montre une configuration matérielle particulière d'un dispositif apte à une mise en oeuvre du procédé selon l'invention ; - les figures 13 et 14 représentent deux sections d'une structure de données représentant des tables pour un accès conforme à la présente invention ; - la figure 15 représente, sous forme d'un logigramme, un exemple d'étapes de génération de tables de codage/décodage modifiées à partir de la structure des figures 13 et 14 ; et - la figure 16 représente, sous forme d'un logigramme, un autre exemple d'étapes de génération de tables de décodage modifiées à partir de la structure des figures 13 et 14. On décrit et illustre maintenant l'invention à l'aide de l'exemple consistant à modifier le nom de famille de la première personne de la figure 1, en l'espèce "Smith" à la ligne 135, pour le remplacer par un autre nom "Thompson". La figure 3 illustre les tables de codage ou décodage utilisées pour la mise en oeuvre de l'invention. La constitution et l'évolution de ces tables sont décrites plus en détail en référence aux figures 4 à 11. La figure 3 montre les deux tables de la figure 2 telles que modifiées par l'invention. La table 300 est la table d'index pour les valeurs textuelles contenues dans le document 1. Elle reprend les informations contenues dans la table 200 et y ajoute des informations supplémentaires. Ces informations supplémentaires sont contenues dans les colonnes 320 et 325 : - dans la colonne 320 est indiquée, pour chaque entrée dans la table, la ligne de l'événement du document 1 qui est à la source de cette entrée, c'est-à-dire la première occurrence de l'événement dans le document 1 ; - dans la colonne 325 est indiquée, pour chaque entrée dans la table, la ligne du dernier événement (ou dernière occurrence) du document 1 utilisant cette entrée. Ainsi, par exemple, pour l'entrée 301, qui correspond à la valeur textuelle 220 Mary , la ligne du premier événement est la ligne 120, qui correspond à la première occurrence de cette valeur textuelle dans le document 1. Pour cette même entrée, la ligne du dernier événement est aussi la ligne 120, puisque cette valeur textuelle n'apparaît qu'une seule fois dans le document. Par contre, pour l'entrée 302, qui correspond à la valeur textuelle 220 Smith , la ligne du premier événement est la ligne 135, tandis que la ligne du dernier événement est la ligne 175. La table 310 est la grammaire pour le contenu de l'élément person . De façon similaire à la table 300, la table 310 reprend les informations contenues dans la table 210 et y ajoute des informations supplémentaires dans les colonnes 330 et 335 ; - dans la colonne 330 est indiquée, pour chaque entrée dans la table, la ligne de l'événement du document 1 qui est à la source de cette entrée ; - dans la colonne 335 est indiquée, pour chaque entrée dans la table, la ligne du dernier événement du document 1 utilisant cette entrée.

Ainsi, par exemple, pour l'entrée 312, qui correspond au début de l'élément 220 firstname au sein de l'élément person , la ligne du premier événement est la ligne 115, et la ligne du dernier événement est la ligne 155. Il est à noter que les entrées 313, 314 et 315 ont pour ligne de début 0, car ces entrées sont créées préalablement au codage et au décodage du document. En outre, la ligne 315 n'étant pas utilisée lors du codage ou du décodage du document, sa ligne de fin est aussi O.

Le passage des tables 200, 201 aux tables 300, 301, y compris le remplissage des colonnes de première et dernière occurrences est décrit plus en détail par la suite en référence aux figures 6 et 7. Les colonnes de début d'utilisation (320 et 330) et de fin d'utilisation (325 et 335) permettent de déterminer sur quelle partie du document XML porte une entrée. La colonne de début d'utilisation permet de déterminer quel est l'événement responsable de la création de l'entrée, tandis que la colonne de fin d'utilisation permet de déterminer quelle est la portée de l'entrée, c'est-à-dire l'étendue de la portion de document englobant toutes les utilisations de cette entrée. Ces informations sont utilisées par l'invention pour réaliser de manière efficace la modification du document XML, comme illustré par la suite en référence à la figure 5. La seule information de début d'utilisation (320 et 330) permet, quant à elle, un accès efficace à un événement dans le document, comme détaillé par la suite en référence à la figure 4.

De manière plus générale, la colonne de début d'utilisation contient, pour chaque entrée de la table, une indication du premier événement utilisant cette entrée, c'est-à-dire une indication de l'événement à la source de la création de cette entrée. Dans les formats binaires, c'est notamment à l'emplacement de cette première occurrence dans le fichier codé que l'on trouve la définition de cette entrée. Cette définition est utilisée par le décodeur pour constituer ses tables de décodage. La colonne de fin d'utilisation contient pour chaque entrée de la table une indication du dernier événement utilisant cette entrée. Dans la pratique, ces indications peuvent être un pointeur vers la position de l'événement correspondant au sein du document XML Binaire, ou bien une information de position de cet événement au sein du document XML Binaire. Une manière efficace de coder cette information consiste à indiquer la position de l'événement par rapport au début du fichier contenant le document XML Binaire.

Comme il a été précisé en référence à la figure 2, d'autres tables de codage peuvent être utilisées pour le codage d'un document XML. Dans ce cas, l'invention est aussi appliquée à ces autres tables de codage.

On décrit maintenant les différentes étapes d'accès direct à une partie d'un document XML Binaire 1, en référence à la figure 4. La première étape (400) consiste à créer des tables de codage (ou de décodage) 300, 310 contenant des informations de début d'utilisation (320, 330) de chacune de leurs entrées. La création des tables de codage est décrite en référence aux figures 6 et 7. On observe que les tables de codage/décodage issues de cette étape listent l'ensemble des informations utilisées pour le codage (ou le décodage) du document XML Binaire 1. Un autre exemple de tables de codage/décodage 300, 310 est illustré en référence aux figures 13 et 14. Cette étape est réalisée préalablement à l'accès direct au document XML. Elle peut être réalisée à plusieurs moments selon le scénario d'utilisation de l'invention. La présente invention est d'autant plus efficace que ces tables de codage/décodage 300, 310 sont disponibles par le dispositif de traitement lors des accès ultérieurs au document 1 auquel correspondent ces tables. On prévoit donc de sauvegarder ces tables en mémoire ou de les transmettre avec le document codé que l'on souhaite accéder partiellement. Dans un premier cas d'utilisation de l'invention, le document XML Binaire est généré par le dispositif qui va ensuite y accéder. Dans ce cas, lors de la génération du document 1, les tables de codage 300, 310 selon l'invention sont créées et mémorisées. Dans un deuxième cas d'utilisation de l'invention, le document XML Binaire 1 est reçu par le dispositif qui va y accéder. Dans un tel cas, le document XML Binaire 1 est lu pour créer les tables de codage 300, 310 selon l'invention. Ces tables sont alors mémorisées pour des utilisations futures (accès ou modifications futurs). Il est notamment avantageux de combiner cette lecture du document avec le premier accès direct à ce document. On évite ainsi de dupliquer des traitements entre la lecture du document et le premier accès au document codé XML Binaire 1.

Dans un troisième cas d'utilisation de l'invention, une structure de données représentative des tables de codage/décodage 300, 310 est associée et jointe au document codé XML Binaire 1, l'ensemble étant transmis à un dispositif distant de traitement. Quel que soit le cas d'utilisation envisagé, les tables de codage 300, 310 correspondant à chacun des documents 1 appelés à être modifiés sont conservées en mémoire. Plusieurs stratégies peuvent être mises en oeuvre pour limiter l'utilisation de la mémoire. D'une part, une gestion des tables 300, 310 en mémoire peut n'être appliquée qu'à certains documents XML. D'autre part, une autre stratégie consiste à donner des ordres de priorités aux différents documents XML afin de favoriser certains types de documents. Les tables de codage 300, 310 des documents XML les moins prioritaires peuvent être retirées de la mémoire quand la taille de la mémoire utilisée par les tables de codage devient trop importante. Cette stratégie peut être étendue à la gestion de ces tables de codage 300, 310 pour leur stockage dans plusieurs types de mémoire. On tient alors compte de la priorité des documents XML correspondant aux tables : ainsi les tables de codage correspondant aux documents XML les plus prioritaires sont conservées dans une mémoire rapide (par exemple de la mémoire vive (RAM)), tandis que les tables de codage correspondant aux documents XML les moins prioritaires sont conservées dans une mémoire moins rapide (par exemple sur un disque dur). Différentes mesures de priorité des documents XML peuvent être envisagées. Une première mesure de priorité correspond à leur degré d'utilisation. Ce degré d'utilisation peut être mesuré en fonction du temps écoulé depuis la dernière modification appliquée à ce document, en fonction de la fréquence de modification de ce document, ou en fonction d'une combinaison de ces deux mesures. Une deuxième mesure de priorité correspond à l'efficacité de l'invention sur le document XML. Cette efficacité peut être mesurée en fonction de la taille du document XML (plus le document est important, plus l'invention apporte un gain en temps de décodage-recodage). Elle peut être mesurée aussi en fonction de la localisation moyenne du contenu accédé : plus cette localisation est proche du début du document, moins l'invention est efficace. Elle peut aussi être mesurée en fonction d'une estimation du temps de décodage pour un accès classique et d'une mesure du temps de décodage pour un accès direct à l'aide de l'invention. Enfin, cette efficacité peut être mesurée par une combinaison de ces trois paramètres. Une autre mesure de priorité consiste à combiner les différentes mesures précédentes. Une fois que ces tables de codage/décodage 300, 310 sont créées, on obtient, lors de l'étape 410, un événement E correspondant au début de la partie devant être accédée. A l'étape 420, on obtient la localisation L (c'est-à-dire par exemple le numéro de ligne du document comme représenté sur la figure 1) de l'événement E à accéder au sein du document XML binaire 1. Cette localisation peut par exemple être obtenue à partir d'un index du document XML binaire. L'étape suivante (430) calcule l'état des tables de décodage 300, 310 pour cette localisation L. On parle ici de tables de décodage, car le document XML Binaire étant codé, le processus général nécessaire à l'accès d'un événement est celui de décoder l'événement codé correspondant.

Les tables de décodage 300', 310' pour la localisation L sont calculées à partir des tables de codage complètes 300, 310 créées à l'étape 400. Ce calcul est notamment réalisé en supprimant, des tables de codage 300, 310, toutes les entrées créées à compter de la localisation L. Une première réalisation de cette étape est détaillée en référence aux figures 8 et 9. Une deuxième réalisation est décrite en lien avec la figure 15. Une autre réalisation est détaillée en référence à la figure 16. Il est à noter que dans la pratique, afin de conserver les tables de codage/décodage complètes 300, 310 intactes pour de futurs accès ou modifications du document XML, cette étape 430 crée un nouveau jeu de tables 300', 310' correspondant à la localisation L à partir des tables de codage/décodage 300, 310 créées à l'étape 400.

Lorsqu'on est amené à modifier et écraser le document 1, on privilégiera alors la suppression des entrées directement dans les tables complètes initiales. De façon optionnelle, ce jeu de tables peut être spécialisé pour mieux correspondre à sa fonction de décodage. En effet, dans le cas du codage, les associations valeur-index (ou événement-index) sont utilisées pour obtenir l'index à partir de la valeur, tandis que dans le cas du décodage, ces associations sont utilisées pour obtenir la valeur à partir de l'index. Il est donc avantageux d'utiliser des représentations de ces associations optimisées pour leur sens d'utilisation. Ainsi, dans le cas du codage, il est avantageux de représenter une table par une structure de type dictionnaire (ou table de hachage, hash table en terminologie anglo-saxonne), associant à chaque valeur l'entrée correspondante. En effet, une structure de type dictionnaire est optimisée pour permettre un accès rapide à une entrée à partir d'une clé. Dans le cas du décodage, il est avantageux de représenter une table par un tableau, les entrées de la table étant ordonnées au sein du tableau en fonction de leur index, l'index d'une entrée correspondant à sa position au sein du tableau. Ainsi, l'accès à une entrée en fonction de son index est réalisé immédiatement en obtenant l'entrée du tableau correspondant à cet index. Le processus se termine à l'étape 440 où ce jeu de tables 300', 310' est utilisé pour décoder l'événement E. On réitère ce décodage pour les autres éléments de la partie à accéder du document XML Binaire à partir de la localisation L. Le décodage s'effectue de manière classique et s'arrête à la fin de la partie à accéder. On observe que les tables 300', 310' ainsi élaborées contiennent l'ensemble des renseignements nécessaires au décodage du document à compter de la localisation L. On peut donc se limiter au décodage du document uniquement à compter de cette localisation L sans avoir besoin de décoder le début du document XML Binaire 1. Si plusieurs parties doivent être accédées, on peut accéder individuellement à chacune de ces parties ou, pour éviter les calculs des tables de décodage 300', 310', on peut prévoir d'accéder initialement à la localisation L la plus en amont du document XML Binaire parmi les différentes parties et de décoder l'ensemble du document jusqu'à la localisation la plus en aval du document pour l'ensemble des parties à accéder.

On décrit maintenant les différentes étapes de modification d'une partie d'un document XML Binaire 1, en référence à la figure 5. Comme on l'observera par la suite, la modification d'un document XML binaire selon l'invention est un cas particulier de l'accès direct à une partie d'un document XML binaire à l'aide de l'invention. Dans la suite, on concentre la description sur ce cas particulier. Il est à noter que les deux utilisations de l'invention, pour l'accès direct et pour la modification de documents, sont tout à fait compatibles et qu'elles peuvent être réalisées à partir des mêmes tables de codage/décodage 300, 300', 310, 310'.

La première étape (500) pour la modification du document 1 consiste à créer des tables de codage (ou de décodage) contenant des informations de début d'utilisation et de fin d'utilisation de chacune de leurs entrées. Cette étape est similaire à l'étape 400 de la figure 4. La création des tables de codage est décrite en référence aux figures 6 et 7 ou en lien avec les figures 13 et 14.

Les deux cas d'utilisation évoquée ci-dessus à l'étape 400 sont également envisagés où, dans le deuxième cas, on tentera de combiner la lecture du document avec les autres étapes de cet algorithme de modification de document. Un autre cas d'utilisation de l'invention est également prévu pour obtenir une modification plus efficace du document XML Binaire 1 selon l'invention. Dans ce cas, le document XML Binaire 1 est régulièrement modifié par un même dispositif. Lors de l'écriture du document modifié comme on le verra plus en détail par la suite, notamment en référence à la figure 11, les tables de codage 300, 310 selon l'invention sont mises à jour et sont prêtes à être utilisées pour la modification suivante. Ainsi l'invention peut être appliquée de manière successive pour chaque modification à réaliser dans le document. 32 Les différentes stratégies de gestion évoquées en lien avec l'étape 400 pour l'accès direct au document sont applicables à cette étape 500. Néanmoins, l'efficacité de l'invention prévue dans la deuxième mesure de priorité ci-dessus est estimée en fonction de la taille du document XML (plus le document est important, plus l'invention apporte un gain en temps de décodage-recodage). Elle peut aussi être mesurée en fonction de la proportion du document XML recodée en moyenne pour chaque modification (voir la portion de document recodée lors de l'étape 560 décrite ci-après). Elle peut aussi être mesurée en fonction d'une estimation du temps de décodage- recodage pour le document complet et d'une mesure du temps de modification moyen à l'aide de l'invention. Enfin, cette efficacité peut être mesurée par une combinaison de ces trois paramètres. Une fois que ces tables de codage/décodage 300, 310 sont créées, on obtient, lors de l'étape 510, un événement E à modifier. En pratique lorsqu'une partie de document 1 doit être modifiée, on commence par le premier événement de la partie à modifier. La modification peut être l'ajout de l'événement, la suppression de l'événement, ou la modification des caractéristiques de l'événement. Comme exemple, le document XML de la figure 1 est modifié pour remplacer le nom de famille de Mary Smith par le nom Thompson . L'événement à modifier est donc la valeur textuelle Smith , pour la remplacer par Thompson . Il s'agit donc de remplacer le contenu de la ligne 135 ( Smith ) par Thompson . Lors de l'étape suivante 520, on obtient la localisation L de l'événement E à modifier au sein du document XML binaire. Cette localisation peut par exemple être obtenue à partir d'un index du document XML binaire, comme évoqué ci-dessus en lien avec l'étape 420. En reprenant l'exemple de la figure 1, la localisation de l'événement à modifier est la ligne 135.

L'étape suivante (530) calcule, de façon similaire à l'étape 430 ci-dessus, l'état des tables de codage 300, 310 pour cette localisation L d'événement à modifier. Les tables de codage 300', 310' pour cette localisation L sont calculées à partir des tables de codage complètes 300, 310 créées à l'étape 500. Ce calcul est réalisé en supprimant des tables de codage toutes les entrées créées après la localisation L, c'est-à-dire celles dont la localisation de première occurrence 320, 330 est postérieure à la localisation L. Cette étape est détaillée en référence aux figures 8 et 9, ou 15 ou 16. Il est à noter que dans la pratique, à partir des tables complètes 300, 310 créées à l'étape 500, cette étape crée un nouveau jeu de tables 300', 310' correspondant à la localisation L. Ce jeu de tables est identique à celui qui serait obtenu lors du codage (ou du décodage) du document XML juste avant de coder l'événement situé à cette localisation L. Ensuite, ce jeu de tables 300', 310' pour la localisation L est dupliqué pour créer un jeu de tables 300'(dec), 310'(dec) pour le décodage du document initial et un jeu de tables 300'(cod), 310'(cod) pour le codage du document modifié. En effet, la modification du document XML Binaire 1 nécessite à la fois le décodage d'une portion pertinente du document XML Binaire 1 initial et le codage de cette portion pertinente une fois modifiée conformément à la modification souhaitée. Une spécialisation de ces tables similaire à celle évoquée ci-dessus en lien avec l'étape 430 peut être prévue. Notamment, les tables 300'(dec), 310'(dec) peuvent optimiser le sens d'utilisation des associations {index de codage} vers {valeur ou élément XML}, alors que les tables 300'(cod), 310'(cod) peuvent optimiser le sens d'utilisation des associations {valeur ou événement XML} vers {index de codage}. En reprenant l'exemple, la localisation L est la ligne 135. Dans la table 300, les entrées 302 et 303 créées pour la localisation L ou ultérieurement sont supprimées pour obtenir la table correspondant à la localisation L. Dans la table 310, aucune entrée n'est supprimée, puisque toutes les entrées sont créées avant la localisation L. Le processus de modification se poursuit à l'étape 540 par le calcul de la localisation Lf, correspondant à la fin de la partie à modifier du document XML 1.

De par les mécanismes de codage binaire des documents XML, cette localisation Lf ne correspond pas nécessairement à la localisation de l'événement suivant l'événement E à modifier. En effet, la modification de l'événement E peut avoir des répercussions sur le codage des événements suivants en modifiant par exemple les index associés à certaines valeurs ou certains événements. Le calcul de cette localisation Lf est ainsi décrit plus loin dans la description en référence à la figure 10. En reprenant l'exemple ci-dessus, la modification de la valeur textuelle Smith de la ligne 135 pour la remplacer par Thompson affecte uniquement la table 300. L'entrée initiale correspondant à cette valeur textuelle est l'entrée 302. L'entrée modifiée correspondant à la nouvelle valeur ( Thompson ) n'existe pas dans la table et l'entrée Smith 302 doit être conservée. La modification va donc insérer une nouvelle entrée dans la table et déplacer l'entrée 302. Par conséquent, dans un tel cas la localisation Lf prend pour valeur la localisation de la fin du document. A titre d'exemple uniquement, dans un autre cas où l'on modifie le prénom Mary pour prendre la valeur Anne , la modification correspondrait à remplacer l'entrée 301 de la table par une nouvelle entrée représentant la valeur textuelle Anne . Dans ce cas, seul l'événement modifié serait à recoder et la localisation Lf serait égale à la localisation L. De retour à la figure 5, une fois les localisations de début L et de fin Lf de la partie à modifier connues, on procède au traitement à proprement parler du document XML Binaire 1. Tout d'abord, à l'étape 550, on copie le début du document XML binaire 1 dans un fichier recevant la version codée et modifiée du document. En effet, la partie du document XML binaire située avant la localisation L ne subit aucune modification et donc son codage dans le format XML binaire reste inchangé. Ce début du document XML binaire 1 est donc copié directement depuis la version initiale du document vers la version modifiée, sans effectuer d'étape de décodage ou recodage. Cette étape 550 de copie directe permet à l'invention d'effectuer une modification rapide du document : en effet la copie directe du document XML 35 Binaire 1 est beaucoup plus rapide que les opérations de décodage et recodage nécessaires dans l'art antérieur. Cette copie directe permet également de conserver le document XML Binaire initial 1 pour la suite du traitement et pour des modifications ultérieures de cette version si nécessaire. Il est toutefois possible d'effectuer la modification du document XML Binaire 1 sur place, c'est-à-dire sans en faire de copie. Dans un tel cas, cette étape revient à se placer à la localisation L dans le document XML Binaire 1. Dans ce cas, on ne conserve pas la version initiale du document 1 avant modification. En outre, il convient d'être prudent lors des étapes suivantes du traitement du document 1, et de ne pas écraser, lors de l'écriture du document modifié 1', une partie du document initial 1 non encore lue (ceci peut arriver si par exemple, la modification consiste à rajouter un événement). On peut alors prévoir de copier en mémoire la suite (ou une partie glissante de la suite) du document, à partir de laquelle on décode et recode (puis on recopie éventuellement la fin du document comme évoqué ci-après). En reprenant l'exemple, la partie du document XML Binaire correspondant aux lignes de 100 à 130 (incluses) est copiée directement. Ensuite, lors de l'étape 560, la partie du document XML Binaire 1 comprise entre la localisation L et la localisation Lf est modifiée. Cette étape consiste à lire le document XML Binaire initial 1 à partir de la localisation L à l'aide des tables de décodage 300'(dec), 310'(dec) calculées à l'étape 530, à appliquer les modifications à réaliser sur cette partie décodée, et à écrire le document XML Binaire modifié 1' en recodant cette partie modifiée à l'aide des tables de codage 300'(cod), 310'(cod) calculées à l'étape 530. Cette étape est décrite en détail en référence à la figure 11. En reprenant l'exemple, la partie du document XML Binaire 1 correspondant aux lignes de 135 à 190 (incluses) est décodée pour fournir les lignes 135 à 190 de la figure 1. Cette partie est ensuite modifiée pour inclure le nom "Thompson" à la place du nom "Smith" en ligne 135. Puis le document est recodée en tenant compte de cette modification, ce qui décale les index pour encoder les valeurs "John" (index=2) et "Smith" (index=3). Cette partie modifiée est écrite dans le document XML Binaire modifié 1'. L'algorithme de modification du document 1 se termine à l'étape 570 par la copie de la fin du document XML binaire initial 1. De manière similaire à l'étape 550, la partie du document XML binaire située après la localisation Lf ne subit aucune modification et donc son codage dans le format XML binaire reste inchangé. Cette fin du document XML binaire est donc copiée directement depuis la version initiale du document 1 vers la version modifiée 1', sans effectuer d'étape de décodage ou recodage.

Cette étape 570 de copie directe contribue, au même titre que l'étape 550, à l'efficacité de l'invention pour effectuer une modification rapide du document : en effet la copie directe du document XML Binaire 1 est beaucoup plus rapide que les opérations de décodage et recodage nécessaires dans l'art antérieur.

En reprenant l'exemple ci-dessus, la partie du document XML Binaire située après la localisation Lf est vide et donc rien n'est effectué à cette étape. Dans une version dégradée de l'invention, l'étape 540 de calcul de la localisation Lf n'est pas réalisée. Par conséquent, l'étape 570 n'est pas réalisée et seule l'étape 550 de copie directe contribue à l'efficacité de l'invention. Dans cette version, l'étape 560 décode et recode le document XML Binaire 1 depuis la localisation L jusqu'à la fin du document. Ainsi, seul le début du document XML Binaire est copié directement (au cours de l'étape 550). L'efficacité de l'invention est donc moindre, mais les traitements et calculs sont simplifiés. Si plusieurs parties du document XML Binaire 1 doivent être modifiées, on adapte le calcul des localisations L et Lf. Pour calculer la localisation L, la localisation de chacun des événements "i" à modifier L(i) est obtenue. Puis ces différentes localisations L(i) sont comparées pour retenir celle qui est la plus proche du début du fichier. Pour le calcul de la localisation Lf, la localisation de la fin de la partie à modifier Lf(i) est calculée pour chacun des événements à modifier, en utilisant l'algorithme décrit en référence à la figure 9. Puis la localisation Lf est calculée en comparant ces différentes localisations Lf(i) et en retenant celle qui est la plus proche de la fin du fichier. Le reste de l'algorithme se déroule comme décrit précédemment, l'étape 560 appliquant toutes les modifications à apporter au document au lieu d'en appliquer une seule. On décrit maintenant plus en détail, en référence aux figures 6 et 7, la création des tables de codage avec références des étapes 400 et 500. Cette opération de création comprend principalement deux sous-étapes. La première sous-étape de la génération des tables de codage (ou de décodage) modifiées est illustrée par la figure 6. Le rôle de cette étape est de modifier les tables de codage initiales, c'est-à-dire des tables de codage par défaut utilisées au début d'un processus de codage du document XML, pour y ajouter les informations de localisation nécessaires à l'invention. La première étape (600) consiste à obtenir une première table de codage (ou de décodage) initiale 300 ou 310. Puis dans cette table, toutes les entrées sont marquées, à l'étape 610, avec une localisation de première utilisation 320 ou 330 correspondant au début du fichier contenant le document XML et une localisation de dernière utilisation correspondant aussi au début du fichier. Dans la pratique, la valeur de ces deux localisations est fixée à 0. Cette localisation de début du fichier précède la localisation du premier événement contenu dans le document XML, puisque les entrées ainsi marqués sont créées avant le codage (ou le décodage) de ce premier événement. Ensuite, l'étape 620 vérifie s'il reste d'autres tables à traiter. Si c'est le cas, l'algorithme obtient une autre table (étape 630) et la traite à son tour (étape 610 et suivantes). Si ce n'est pas le cas, l'algorithme se termine à l'étape 640. Il est à noter que cette sous-étape est réalisée à chaque création d'une nouvelle table de codage ou décodage. Ainsi, si une ou plusieurs nouvelles tables sont créées durant le codage (ou décodage) du document XML, cette sous-étape est appliquée à ces nouvelles tables avant leur utilisation pour le codage.

Une fois ces tables 300, 310 pourvues de champs de première et dernière occurrences pré-remplis avec la valeur 0, on met à jour cette valeur en fonction du document XML associé, comme illustré ci-après en référence à la figure 7.

Ainsi la deuxième sous-étape de la génération des tables de codage (ou de décodage) modifiées a pour but d'ajouter les informations de localisation nécessaires à l'invention pour les entrées des différentes tables. La première étape (700) consiste à obtenir un premier événement à coder (ou à décoder) du document XML 1. Ensuite, la localisation de cet événement est obtenue (étape 710). Cette localisation est obtenue à partir de la position courante dans le document XML Binaire codé (ou décodé) 1. Puis cet événement est traité (étape 720). Dans le cas du codage, le traitement correspond à coder cet événement. Dans le cas du décodage, le traitement correspond à décoder cet événement.

L'étape suivante (730) consiste à marquer les entrées utilisées par cet événement. Deux cas se présentent: une nouvelle entrée est ajoutée dans l'une des tables 300 ou 310 (ou dans les deux), ou bien une entrée existante est utilisée lors du traitement de cet événement. Il est possible que ces deux cas coexistent pour un même événement.

Pour chaque nouvelle entrée ajoutée lors du traitement de cet événement, les localisations de première utilisation (320, 330) et de dernière utilisation (325, 335) prennent la valeur de la localisation de l'événement traité. Pour chaque entrée déjà existante et utilisée lors du traitement de cet événement, la localisation de dernière utilisation (325, 335) prend la valeur de la localisation de cet événement. Ensuite, à l'étape 740, on vérifie s'il reste d'autres événements à traiter. Si c'est le cas, l'algorithme obtient l'événement suivant (étape 750) puis le traite (étape 710 à 730). Si ce n'est pas le cas, l'algorithme se termine à l'étape 760.

Dans la pratique, il est efficace de combiner les étapes 720 et 730 : durant le traitement de l'événement, lors de chaque accès à une table, les localisations correspondant à l'entrée accédée sont mises à jour.

On envisage également de maintenir à jour les tables de codage modifiées 300', 310' lorsque le document XML Binaire est modifié. Pour ce faire, ce processus d'ajout des informations de localisation peut être réalisé au cours du codage du document modifié 1' lors de l'étape 560, afin d'obtenir à la fin de l'algorithme de la figure 5 des tables de codage modifiées 300', 310' correspondant au document XML Binaire 1' après modification. Dans ce cas, on prévoit que l'étape 730 ne modifie pas une localisation de fin si cette localisation de fin se situe après Lf. Ensuite, à l'étape 570, les entrées des tables de codage 300', 310' doivent être complétées. Toutes les entrées des tables de codage 300 et 310 dont la localisation de première utilisation est postérieure ou égale à Lf sont copiées dans les tables de codage modifiées 300' et 310'. Ceci permet d'ajouter aux tables de codage 300' et 310' les entrées correspondant à la fin du document.

Ensuite, la localisation courante dans le document XML Binaire modifié 1' est comparée à Lf (qui est alors la localisation courante dans le document XML Binaire initial 1). Si ces deux localisations sont différentes, alors la taille de la partie recodée lors de l'étape 560 a été modifiée et il convient de modifier, dans les tables 300' et 310', les localisations se situant après Lf ou égales à Lf. Pour cela, la différence entre la localisation courante dans le document XML Binaire modifié 1' et la localisation Lf est ajoutée à chacune de ces localisations, de première ou de dernière utilisation (320, 325, 330, 335), se situant après Lf ou égales à Lf. On obtient ainsi les tables de codage/décodage 300' et 310' dont les localisations de première et dernière occurrences sont correctement renseignées en vue des accès et modifications ultérieurs du document XML Binaire 1 associé. On décrit maintenant plus en détail, en référence aux figures 8 et 9, les étapes 430 et 530 de calcul des états des tables de codage/décodage 300, 310 du document XML Binaire 1 pour la localisation L spécifique. Ce calcul est réalisé à partir des tables de codage modifiées 300, 310 créées lors de l'une des étapes 400 ou 500, ou lors de l'étape 560 lorsqu'on réalise plusieurs modifications successives sur un document. On traite chacune des tables de codage/décodage. La première étape (800) consiste à obtenir une première table de codage modifiée 300, 310 et à la copier en table copiée 300', 310'.

Ensuite, à l'étape 810, la première entrée E de cette table copiée 300', 310' est obtenue, ainsi que la localisation Ld(E) de première utilisation qui lui est associée. Il est à noter que l'ordonnancement des entrées dans la table dépend de la manière d'ajouter des entrées à la table. Si les nouvelles entrées sont ajoutées à la fin de la table (comme c'est le cas pour la table de valeurs textuelles 300), les entrées sont ordonnancées du début à la fin de la table. Si au contraire les entrées sont ajoutées au début de la table (comme c'est le cas pour la table de grammaire 310), les entrées sont ordonnancées de la fin au début de la table.

A l'étape 820, on vérifie si Ld(E) précède la localisation L déterminée à l'étape 420 ou 520. Si c'est le cas, alors cette entrée E doit être conservée. Dans ce cas, l'algorithme vérifie s'il reste d'autres entrées dans la table (étape 830) et si c'est le cas obtient l'entrée suivante et sa localisation de première utilisation Ld(E) (étape 840) pour se poursuivre à l'étape 820. Si à l'étape 830, il ne reste plus d'entrée dans la table 300', 310', l'algorithme se poursuit à l'étape 880. Si Ld(E) ne précède pas L (ou si Ld(E) est égale à L), alors cette entrée et toutes les suivantes doivent être supprimées de la table 300', 310'. Pour cela, l'algorithme se poursuit à l'étape 850 où l'entrée est supprimée de la table. Puis l'étape 860 vérifie s'il reste d'autres entrées dans la table et si c'est le cas, l'entrée suivante est obtenue à l'étape 870 et supprimée à son tour (étape 850). Cette suppression rapide sans test sur Ld(E) est prévue si l'on traite une table dont les entrées sont ordonnancées selon leur ordre de création/insertion dans la table (donc selon Ld(E)), et si l'on accède à la table par l'entrée première dans cet ordre. Si à l'étape 860, il ne reste plus d'entrée dans la table de codage/décodage 300', 310', l'algorithme se poursuit à l'étape 880.

L'étape 880 vérifie s'il reste d'autres tables de codage/décodage à traiter. Si c'est le cas, l'algorithme obtient la table suivante (étape 885), puis la traite (étape 810 et suivantes). Si ce n'est pas le cas, l'algorithme se termine à l'étape 890.

On obtient ainsi les tables de codage ou décodage 300', 310' correspondant à celles qui seraient obtenues lors du codage (décodage) classique du document juste avant de traiter l'événement à la localisation L. La seule différence est que les tables de codage ou décodage 300', 310' contiennent en plus des informations de localisation de première et dernière utilisation. La figure 9 illustre les différents états d'une table de codage modifiée lors de son utilisation par l'invention. La table 900 est celle créée à l'une des étapes 400 ou 500 en appliquant les algorithmes décrits par exemple en référence aux figures 6 et 7.

Cette table de codage comprend un ensemble d'entrées, avec pour chaque entrée une indication de la localisation de la première utilisation dans le document XML et (de façon optionnelle) une indication de la localisation de la dernière utilisation dans le document XML Binaire. Des exemples de telles tables modifiées sont donnés en référence à la figure 3.

Lors de l'une des étapes 430 ou 530, une nouvelle table 910 est créée à partir de cette table 900. Cette table 910 correspond à l'état de la table de codage à une localisation L dans le document XML Binaire. Cette nouvelle table est créée en appliquant l'algorithme décrit par exemple en référence à la figure 8 à la table 900.

Le point de localisation L (912) permet de séparer la table de codage en deux parties : le début (911) qui correspond à l'état de la table lors du codage (ou du décodage) avant de coder l'événement situé à la localisation L, et la fin (913) qui correspond aux entrées ajoutées à la table après cette localisation L. Le début de la table doit donc être conservé, tandis que la fin de la table doit être supprimée. A partir de cette table 910, deux tables sont construites. La table 920 est celle utilisée pour le décodage du document XML Binaire initial 1. Sa construction consiste à copier la table 910. En variante, la table 920 peut être optimisée pour être rendue plus efficace pour le décodage. La table 930 est celle utilisée pour le codage du document XML Binaire modifié 1'. Sa construction consiste à copier le début 911 de la table 910. En variante, la table 930 peut être optimisée pour être rendue plus efficace pour le codage. Ces deux tables sont toujours construites lors de l'étape 530. En revanche, puisque seule la table de décodage est utilisée pour l'accès direct au document, seule la table 920 est construite à l'étape 430.

Il est à noter que dans un souci d'efficacité, il est inutile de créer effectivement la table 910 : seules les deux tables 920 et 930 doivent être créées. On note ici que ces deux tables correspondent par exemple aux tables 300'(dec) et 300'(cod) établies à partir de la table 300, comme évoqué ci-dessus. En variante, pour optimiser l'algorithme, la construction des tables peut être modifiée. Lors de la création de la table 910, les entrées contenues dans la fin (913) de la table ne sont pas supprimées, mais seulement marquées comme ultérieures au point de localisation L. Ceci revient à déterminer quelle est la dernière entrée de la table 900 créée avant le point de localisation L. La table 920 de décodage est alors créée en comprenant toutes les entrées de la table 900. Mais sa fin est positionnée après la dernière entrée créée avant le point de localisation L. Ensuite, lors du décodage du document, quand une entrée devra être ajoutée à la table, elle y sera déjà présente à la bonne position et il suffira de changer la position de la fin de la table pour inclure cette entrée. Ce mécanisme permet d'éviter de supprimer puis d'ajouter à nouveau des entrées à la table et accélère donc le traitement effectué par l'algorithme. En revanche, la table 930 de codage est créée à partir uniquement des entrées du début 911 de la table 910: en effet, comme cette table 930 va servir au codage du document modifié, ses entrées ultérieures au point de localisation L vont différer de celles de la table initiale 900. En autre variante, pour limiter la mémoire nécessaire à l'algorithme, le début 911 de la table 910 peut être partagé par les deux tables 920 et 930.

Ceci permet de réduire la mémoire utilisée, mais au détriment du temps de traitement puisque d'une part l'accès aux tables 920 et 930 est rendu plus complexe et que d'autre part les tables 920 et 930 ne peuvent plus être optimisées pour le codage ou le décodage.

On décrit maintenant, en référence à la figure 10, l'étape 540 de calcul de la localisation Lf de la fin de la partie du document XML Binaire initial 1 à modifier et à recoder. A l'étape 1000, on initialise la variable Lf à la valeur de la localisation L calculée à l'étape 520.

A l'étape 1010, une première table de codage (ou de décodage) complète et modifiée 300, 310 est obtenue. L'algorithme vérifie alors, à l'étape 1020 si cette table 300, 310 est affectée par la modification à réaliser. Pour cela, l'algorithme détermine le type de l'événement XML modifié et la caractéristique de cet événement modifiée.

En fonction de cela, l'algorithme peut déterminer quelles sont les tables prenant part au codage de cette caractéristique et étant donc affectée par la modification. Si la table n'est pas affectée, l'algorithme se poursuit à l'étape 1060. Dans notre exemple, la modification d'une seule valeur textuelle n'impacte que la table 300 et non pas la table 310 des grammaires.

Si la table est affectée, l'algorithme détermine, à l'étape 1030, l'entrée initiale I correspondant à l'entrée de la table utilisée lors du codage de l'événement initial Ei, celui à modifier. Il détermine aussi l'entrée modifiée M correspondant à l'entrée de la table utilisée pour le codage de l'événement modifié Em. Cette entrée modifiée M n'est pas nécessairement présente dans la table. Deux cas particuliers sont à prendre en compte. Si la modification correspond à une insertion d'un nouvel événement, alors l'entrée initiale I est nulle. Si, au contraire, la modification correspond à une suppression d'un événement, alors l'entrée modifiée M est nulle.

Lors de l'étape suivante (1040), l'algorithme détermine la localisation LfT correspondant à la fin de la partie du document XML Binaire initial 1 à recoder pour cette table 300, 310 uniquement. Ce calcul est réalisé de la manière suivante, en fonction de l'existence de I et de M et de la localisation Ld(l) de première utilisation de l'entrée initiale I dans le document XML Binaire initial 1. i) Si I et M sont identiques, ce qui correspond à la modification d'une caractéristique de l'événement dont le codage n'utilise pas la table considérée, alors la localisation LfT prend pour valeur la localisation L. ii) Sinon et, si I et M ne sont pas nulles, et si la localisation Ld(l) est antérieure à la localisation L, trois cas peuvent se présenter. Le premier cas correspond à celui où l'entrée modifiée M n'est pas présente dans la table. Dans ce cas par défaut, la localisation LfT prend pour valeur la fin du document XML Binaire initial 1, du fait de l'ajout de M qui vient décaler les index pour toute la fin du document. Dans les deux autres cas, la localisation Ld(M) de première utilisation de l'entrée modifiée M est évaluée, et - si Ld(M) est antérieure à la localisation L, alors le codage de la modification revient à changer un index (au niveau de cette table) et la localisation LfT prend la valeur de la localisation L ; - si Ld(M) est postérieure à la localisation L, deux sous-cas peuvent se présenter : • si la première entrée P ajoutée après la localisation L est l'entrée modifiée M, alors la localisation LfT prend la valeur de la localisation L, puisqu'au final le codage de Em sollicite le même index de M (plus tôt cependant dans le traitement du document) ; • sinon, la localisation LfT prend la valeur de la localisation de dernière utilisation, dans la table, la plus grande pour l'ensemble des entrées comprises entre cette première entrée P et l'entrée modifiée M (en incluant ces deux entrées), car il s'agit ici d'une permutation circulaire entre les index des entrées entre P et M. En variante, pour simplifier ce sous-cas, il est possible de considérer que LfT prend pour valeur la localisation de fin de document. iii) Si I et M ne sont pas nulles, et si la localisation Ld(l) est égale à la localisation L, deux cas peuvent se présenter en fonction de la localisation Lf(l) de dernière utilisation de l'entrée 1 : - si la localisation Lf(I) est égale à la localisation L, deux sous-cas se présentent : • tout d'abord, si l'entrée modifiée M n'existe pas dans la table, alors la localisation LfT prend la valeur de la localisation L, résultant d'une simple substitution de Ei par Em ; • sinon, si l'entrée modifiée M existe dans la table, alors la localisation LfT prend pour valeur la fin du document XML Binaire initial, car Ei disparaît du document et n'est donc désormais plus codé. - si la localisation Lf(I) est postérieure à la localisation L, alors la localisation LfT prend pour valeur la fin du document XML Binaire initial. iv) Si I est nulle, deux sous-cas se présentent : - si l'entrée modifiée M est présente dans la table et si la localisation Ld(M) de première utilisation de l'entrée modifiée M est antérieure à la localisation L, alors LfT prend la valeur de la localisation L, car il s'agit d'une simple insertion d'un nouvel élément Em dont l'index est déjà existant ; - sinon, LfT prend pour valeur la fin du document XML Binaire initial, car l'insertion de Em provoque un décalage des index. v) Si M est nulle, deux sous-cas se présentent : - si la localisation Ld(I) de première utilisation de l'entrée initiale I est antérieure à la localisation L, alors LfT prend la valeur de la localisation L, - sinon, LfT prend pour valeur la fin du document XML Binaire initial. Il est à noter que ces règles peuvent être précisées pour distinguer d'autres cas particuliers où la valeur de LfT est proche de L. Les règles de calcul présentées ici visent à obtenir un bon compromis entre la complexité de ces règles et l'efficacité de la mise en oeuvre de l'invention. En sortie d'étape 1040, on obtient ainsi la localisation LfT correspondant à la fin de la partie du document XML Binaire initial 1 à recoder en considérant uniquement la table 300, 310 traitée. A l'étape 1050, on mémorise comme localisation de fin de modification la localisation la plus lointaine dans le document XML Binaire 1 entre celle déterminée pour les autres tables déjà traitées (Lf) et celle déterminée pour la table présentement traitée (LfT). Ainsi, si la localisation LfT est postérieure à la localisation Lf, la localisation Lf prend pour valeur la localisation LfT. Il est à noter que la modification de l'événement XML peut éventuellement affecter plusieurs entrées de la table. Dans un tel cas, les étapes 1030 à 1050 sont répétées pour chacune des entrées de la table. Puis, à l'étape 1060, l'algorithme vérifie s'il reste une autre table à traiter. Si c'est le cas, cette table est obtenue (étape 1070) puis traitée (étape 1020 et suivantes). Si ce n'est pas le cas, l'algorithme se termine à l'étape 1080.

La valeur Lf correspond ainsi à la localisation la plus proche de la fin du document XML 1 qui est impactée par les modifications envisagées. On décrit enfin, en référence à la figure 11, la modification à proprement parler du document XML Binaire 1 correspondant à l'étape 560. L'algorithme suit successivement chacune des localisations des événements composant la partie à modifier. La première étape (1100) consiste à décoder le premier événement depuis le document XML Binaire initial 1, à l'aide des tables (grammaires et valeurs) de décodage 300'(dec), 310'(dec) calculées à l'étape 530. Cette étape est similaire à l'étape de décodage 440 dans le cas de l'accès direct à une partie du document XML Binaire 1. Puis, à l'étape 1110, l'algorithme modifie l'événement si nécessaire. Pour cela, il vérifie si l'événement correspond à celui devant être modifié. Si c'est le cas, il applique la modification à l'événement. Ensuite, à l'étape 1120, l'événement (éventuellement modifié précédemment) est codé dans le document XML Binaire modifiée 1', à l'aide des tables (grammaires et valeurs) de codage 300'(cod), 310'(cod) calculées à l'étape 530. L'algorithme vérifie alors, à l'étape 1130, si la localisation Lf de fin de partie à modifier est atteinte en comparant la localisation de l'événement traité dans le document XML initial 1. Si ce n'est pas le cas, il décode l'événement suivant depuis le document XML Binaire initial (étape 1140), puis le traite à son tour (étape 1110 et suivantes).

Si la localisation Lf de fin de partie à modifier est atteinte, l'algorithme se termine à l'étape 1150. Il est à noter que si l'étape 540 de calcul de la localisation Lf n'est pas réalisée, la vérification de l'étape 1130 consiste à vérifier si la fin du document est atteinte. On décrit maintenant en références aux figures 13 à 16 une autre mise en oeuvre de l'invention. Celle-ci se distingue principalement par la constitution des tables initiales, référencées 300, 310 ci-dessus. On propose dans cette mise en oeuvre une solution permettant de mémoriser aisément ces tables initiales avec les informations supplémentaires de localisation de première occurrence, dans le document XML Binaire ou dans un document annexe qui lui est attaché. On illustre cette mise en oeuvre à l'aide du format EXI. Les figures 13 et 14 montrent deux sections 1300, 1400 constituant une structure de données représentative des tables de codage/décodage initiales (300, 310). C'est cette structure de données, particulièrement légère comme on le verra par la suite, qui est jointe au document XML Binaire lors de sa transmission. Le format EXI prévoit les tables de codage ou décodage suivantes : - table des identifiants d'espace de nommage URI ; - tables de préfixes associés à une URI. Il y a une table de préfixes par URI ; - tables de noms locaux (ou "local name") associés, chacune, à une URI. Il y a une table de noms locaux par URI ; - tables locales des valeurs de contenu textuel et d'attributs. Il y a une table locale de valeurs pour chaque élément et pour chaque attribut ; - grammaires ou tables de structures permettant de décrire la structure du contenu d'un élément. Il y a généralement plusieurs tables de structures pour chaque élément ; - table globale de valeurs, listant les valeurs contenues dans les tables locales de valeurs. La section 1300 code le contenu des trois premiers types de tables.

La section 1400 code le contenu des deux types suivants. Le cas de la dernière table est abordé plus loin. On notera que certaines tables contiennent des entrées prédéfinies par la spécification EXI. Dans ce cas, ces entrées prédéfinies ne sont pas mémorisées dans la structure de données, puisqu'elles peuvent être reconstruites, au niveau du décodeur ou d'un autre encodeur, à partir de la spécification EXI et éventuellement d'options de codage. La figure 13 détaille le codage des tables des identifiants URI d'espace de nommage, des préfixes et des noms locaux. Afin d'optimiser la taille nécessaire au stockage de ces tables, et puisque les tables des préfixes et des noms locaux sont liées aux identifiants URI (donc à la table des URI), toutes ces tables sont codées conjointement dans la section 1300. Cette dernière se présente sous forme d'un tableau et contient l'ensemble des identifiants URI, ainsi que, pour chaque identifiant d'espace de nommage, les préfixes et noms locaux qui lui sont associés. La première valeur 1301 de ce tableau est le nombre d'identifiants URI contenus dans la table des URI. Ensuite, le tableau contient, pour chaque URI, un ensemble de valeurs définissant cet identifiant URI et les préfixes et noms locaux qui lui sont associés. Ainsi, la sous-section 1310 regroupe l'ensemble des valeurs définissant un premier identifiant 'URI 1' avec les préfixes et noms locaux qui lui sont associés, et l'ensemble des valeurs 1320 définit un deuxième identifiant 'URI 2' et les préfixes et noms locaux qui lui sont associés.

La description 1310 du premier identifiant URI commence par un pointeur informatique 1311 vers l'emplacement, au sein du document XML Binaire codé, où ce URI est défini ; généralement en début de document et à tout le moins lors de sa première occurrence dans le document. Dans le cas où le codage utilisé dans le document XML n'aligne pas les valeurs codées sur les limites d'octet (cas appelé "bit-packed"), les pointeurs utilisés sont précis au bit près. C'est-à-dire qu'ils indiquent, à l'intérieur de l'octet pointé, sur quel bit commence la valeur référencée. Dans le cas aligné sur les octets ("byte-aligned", chaque nouvelle valeur codée recommence sur un nouvel octet), seul l'octet est pointé. Plus généralement, le format des pointeurs dépend du mode ou des options d'encodage choisi. Suivent ensuite le nombre 1312 de préfixes associés à cet identifiant 'URI 1' et le nombre 1313 de noms locaux associés à ce même URI. Ensuite, si le nombre 1312 de préfixes associés à cet URI n'est pas nul, la sous-section 1310 comprend la liste des préfixes, chaque préfixe étant décrit par un pointeur 1314 vers la position de sa définition au sein du document XML Binaire, c'est-à-dire généralement sa première occurrence.

Ainsi, le premier préfixe associé à la première URI est décrit par son pointeur (1314). Après la liste des préfixes, la liste des noms locaux associés à l'URI 1 est codée, chaque nom local étant décrit par un pointeur 1315 pointant vers sa première occurrence dans le document binaire codé (position de sa définition). Ainsi le premier nom local associé à la première URI est décrit par son pointeur (1315). La sous-section 1320 de description du deuxième identifiant 'URI 2' est construite de façon similaire. On voit ici que les pointeurs 1314, 1315, 1324, 1325 utilisés jouent un double rôle: d'une part, celui renseignant l'indication de première occurrence utilisée pour la mise en oeuvre de l'invention, et d'autre part, celui indiquant où trouver les informations suffisantes pour créer une entrée complète de table de codage/décodage selon le format EXI. En effet, comme une table de codage doit pouvoir être reconstruite au cours du décodage, toutes les entrées de celle-ci, qui ne sont pas prédéfinies dans la spécification ou à partir des options de codage (comme par exemple dans le cas du codage à l'aide d'une description de type schéma XML), doivent être codées dans le document XML lui-même. On utilise donc cette contrainte pour décrire chaque entrée (non prédéfinie) d'une table en utilisant un pointeur (ou plusieurs, suivant la complexité de l'entrée) vers le codage de cette entrée dans le document XML.

Ainsi, grâce à ce deuxième rôle, la structure de données comprend une faible quantité d'informations comparée aux tables complètes de la figure 3. La transmission ultérieure de cette structure avec le document codé est donc faiblement pénalisée.

Un point important pour l'invention est l'utilisation de pointeurs vers des valeurs du document codé. En effet, comme un dictionnaire de codage doit pouvoir être reconstruit au cours du décodage, toutes les entrées de ce dictionnaire qui ne sont pas prédéfinies doivent être codées dans le document XML binaire. Ainsi, l'invention décrit chaque entrée (non prédéfinie) d'un dictionnaire en utilisant un pointeur (ou plusieurs, suivant la complexité de l'entrée) vers le codage de cette entrée. On note que cette structure peut être construite au fur et à mesure du codage/décodage d'un premier document; à chaque création d'une nouvelle entrée dans une des tables de codage/décodage 300, 310, on ajoute le pointeur correspondant dans cette structure et on incrémente les compteurs (1301, 1312, 1313, 1322, 1323, etc.) qui vont bien. En variante, cette structure peut être construite à partir des tables de codage/décodage 300, 310 déjà complétée avec les informations de première et dernière occurrence.

A ce titre, il est également envisagé de pourvoir, dans les sections 1300 et 1400 et au niveau des pointeurs de première occurrence des entrées, un pointeur complémentaire de dernière occurrence, correspondant aux colonnes 325 et 353 de la figure 3. La figure 14 détaille le codage des tables locales de valeurs et des tables de structures. Ces tables sont notamment associées à des noms qualifiés, c'est-à-dire des noms définis par un espace de nommage et un nom dans cet espace. Grâce au regroupement que l'on peut réaliser sur la base de ces noms qualifiés, on code conjointement ces tables dans la section 1400, sous forme de tableau.

La section 1400 contient la description de l'ensemble de ces tables de valeurs/structure.

Une première sous-section 1410 décrit l'ensemble des noms qualifiés QName ayant au moins une table de valeur ou une table de structure associée. Cette première sous-section 1410 débute par le nombre 1411 de noms qualifiés concernés par les différentes tables de valeurs/structure.

Ensuite, pour chaque nom qualifié présent, trois valeurs sont décrites. Ainsi, pour le premier nom qualifié 'QName 1', ces trois valeurs sont stockées dans les champs 1412, 1413 et 1414. La première valeur 1412 correspond à la description de ce nom qualifié. Cette description est réalisée en codant l'index de codage de l'URI et l'index de codage du nom local de ce nom qualifié. Ces index correspondent à ceux prévus dans les tables de codage/décodage associées à la section 1300. Ils seront notamment réassociés aux URI et nom local correspondant, par le décodeur, lorsque ce dernier aura reconstitué les tables de décodage à l'aide de la section 1300. Ces index sont de préférence codés avec une taille de codage constante, pour permettre une recherche rapide d'un nom qualifié au sein de cette table, comme expliqué ci-après. La deuxième valeur 1413 est un pointeur sur la description de la table de valeurs associée à ce nom qualifié. Ainsi, pour le premier nom qualifié 'QName 1', cette valeur indique la position, dans la section 1400, de la valeur 1431 décrite plus bas. La troisième valeur 1414 est un pointeur sur la description des tables de structures associée à ce nom qualifié. Ainsi, pour le premier nom qualifié 'QName 1', cette valeur indique la position, dans la section 1400, de la valeur 1421 décrite plus bas.

Le deuxième nom qualifié 'QName 2' est ensuite codé à l'aide des valeurs 1415, 1416 et 1417 comme représentées sur la figure 14. Pour un décodeur, l'accès aux tables associées à un nom qualifié peut ainsi se faire en parcourant la sous-section 1410 de ce tableau 1400 et en vérifiant, pour chaque description de nom qualifié, si elle correspond au nom qualifié recherché.

Cet accès peut être optimisé en triant les noms qualifiés (par exemple par ordre d'index d'URI, puis par ordre d'index de nom local), ce qui permet une recherche dichotomique plus efficace dans la sous-section 1410. A la suite de 1410, la deuxième sous-section 1420 décrit l'ensemble des tables de valeurs et de structures pour les noms qualifiés qui ont été listés dans la première sous-section, chaque nom qualifié l'un après l'autre. A l'intérieur de 1420, la troisième sous-section 1430 comprend l'ensemble des informations de description de la table des valeurs pour un nom qualifié, ici le premier nom qualifié 'QName 1'.

Ainsi, la première valeur 1431 renseigne le nombre de valeurs associées à ce premier nom qualifié, c'est-à-dire le nombre d'entrées dans la table locale des valeurs associée à ce nom qualifié. Ensuite, chaque valeur est définie par un pointeur 1432 pointant vers sa description dans le document XML codé, c'est-à-dire par la position de la première occurrence dans le flux EXI codé. A la suite de 1430, les entrées de la sous-section 1420 décrivent les tables de structures associées au premier nom qualifié 'QName 1'. Ainsi, la première valeur 1421 décrit le nombre de tables de structures (grammaires) associées au premier nom qualifié 'QName 1'.

Puis chaque table de structures est décrite. Ainsi, la première table de structures 'Grammar 1' du premier nom qualifié 'QName 1' est décrite par la sous-partie 1440. Cette sous-partie 1440 contient une première valeur 1441 qui correspond au nombre d'entrées (appelées productions dans le format EXI) de cette première table de structures. Chaque entrée/production est décrite par trois valeurs. Ainsi, la première entrée 'Production 1' de cette première table de structures 'Grammar 1' est décrite par la sous-partie 1450. La première valeur 1451 de cette sous-partie décrit le type de structure correspondant à cette entrée, par exemple ce type peut correspondre à un début d'élément (production de type SE selon la spécification EXI), à un attribut (production de type AT), à un commentaire, etc. 53 La deuxième valeur 1452 de cette sous-partie est un pointeur sur la première occurrence de cette structure dans le document EXI codé. Cette référence 1452 à l'aide d'un pointeur permet de définir à la fois la première occurrence pour cette entrée/production, et aussi de préciser la valeur de l'entrée/production dans certains cas. Ainsi, pour un début d'élément, cette valeur permet de définir la première occurrence de ce début d'élément ainsi que le nom qualifié de cet élément. De la même manière, pour un attribut, cette valeur permet de définir la première occurrence de cet attribut ainsi que le nom qualifié de cet attribut.

La troisième valeur 1453 de cette sous-partie est une indication de la table de structures suivante à utiliser, conformément à ce que prescrit la spécification EXI. Cette valeur peut être, par exemple, un index dans l'ensemble des tables de structures associées à ce nom qualifié. La structure de données peut être optimisée notamment pour accélérer son parcourt. Dans un mode de réalisation, on regroupe alors les noms qualifiés selon la nature de l'item XML correspondant. Sachant par exemple que selon la spécification EXI distingue les éléments des attributs et que les attributs n'ont pas de tables de structures (grammaires) associées, on peut prévoir de diviser la sous-section 1410 en une première sous-partie contenant les noms qualifiés associés à un élément, et en une deuxième sous-partie contenant les noms qualifiés associés à un attribut. Pour cette deuxième sous-partie, seules les deux premières valeurs 1412 et 1413 (la description du nom qualifié et le pointeur sur la description de la table de valeurs associées) sont présentes.

On fait alors de même pour la sous-section 1420, et aucune information sur les tables de structures n'est codée pour les noms qualifiés correspondant à des attributs. Il est à noter que la table globale des valeurs n'est pas mémorisée dans la description ci-dessus.

En effet, la reconstruction de cette table globale peut être réalisée à partir de la description des tables locales des valeurs. En effet, la spécification EXI définit la table globale comme étant constituée de la réunion des valeurs contenues dans les tables locales. Toutefois, pour obtenir une table globale conforme aux tables initiales, et notamment au regard des index de codage affectés automatiquement par la spécification EXI, il convient, lors de la reconstruction de cette table globale, d'ordonner les valeurs selon l'ordre décrit dans la spécification, c'est-à-dire l'ordre d'apparition de ces valeurs dans le document XML codé. Pour cela, il suffit de trier l'ensemble des valeurs en fonction de leur position dans le document XML codé et de générer les index de codage correspondants. Toutefois, comme cette méthode rend coûteuse une reconstruction partielle de la table globale des valeurs, un compromis entre compression et efficacité est obtenu en codant la table globale des valeurs. Ceci peut être réalisé en codant par exemple dans une nouvelle section, le nombre de valeurs contenues dans cette table, ainsi que, pour chaque valeur, le pointeur sur la description de cette valeur dans le flux EXI.

La structure de données constituée des sections 1300 et 1400 (et éventuellement de la section pour la table globale) peut être soit codée dans le document XML Binaire lui-même, par exemple en ajoutant ces tables en fin de document, soit codée dans un document annexe joint au document XML codé. Pour faire en sorte qu'un décodeur puisse accéder aisément à ces sections, deux pointeurs indiquant la position de celles-ci sont aussi ajoutés. Si ces sections sont codées dans le document XML codé lui-même, ces pointeurs sont ajoutés en fin de document; ainsi, ils sont directement accessibles à partir de la fin du document. Si ces sections sont codées dans un document annexe, les pointeurs sont ajoutés de préférence en début de ce document annexe.

On décrit maintenant l'exploitation de cette structure de données par un codeur/décodeur pour accéder à une partie du document XML codé, en référence aux figures 15 et 16. Bien que l'on ne décrive ci-dessous que la génération d'une table de codage/décodage, celle-ci est appliquée à l'ensemble des tables décrites dans les sections de la structure de données. La figure 15 détaille l'algorithme de décodage d'une table initiale de codage ou décodage selon l'invention, en vue de reconstruire une table de codage ou décodage correspondant à l'état de cette table pour une localisation L spécifique dans le document XML codé. Cet algorithme peut être mis en oeuvre lors des étapes 420/430 ou 520/530 précitées, notamment appliquées à la structure des figures 13 et 14.

Comme exposé précédemment en lien avec les figures 4 et 5, une telle table de décodage reconstruite permet de décoder directement le document XML codé à partir de cette localisation L. La reconstruction d'une table de codage est utile en particulier dans le cas où l'on souhaite modifier une partie du document XML codé.

Lors de la première étape 1500, on obtient la position de décodage dans le document XML codé, c'est-à-dire la localisation L du début de la partie à accéder dans le flux EXI. L'étape suivante 1505 consiste à ajouter l'ensemble des entrées prédéfinies par la spécification EXI dans cette table de décodage en cours de reconstruction, par exemple des productions par défaut dans le cas des grammaires. On poursuit à l'étape 1510 où l'on décode le nombre d'entrées de la table de décodage à décoder, en récupérant l'un des nombres 1301, 1312, 1313, 1322, 1323, 1411, 1431, 1421, 1441, etc selon la table traitée.

Ainsi, par exemple, dans le cas de la table des URI, ce nombre est récupéré du champ 1301. Dans le cas de la table des noms locaux de la première URI, ce nombre est dans le champ 1313. Dans le cas de la table des valeurs du premier nom qualifié 'QName 1', ce nombre est dans le champ 1431. Dans le cas de la première table de structure du premier nom qualifié, ce nombre est dans le champ 1441. Puis à l'étape suivante 1520, si le nombre d'entrées de la table à décoder est non nul, on décode une première entrée de cette table de décodage. Par exemple, dans le cas de la table des URI, cette entrée est la valeur 1311. Dans le cas de la table des noms locaux de la première URI, cette entrée est la valeur 1315. Dans le cas de la table des valeurs du premier nom qualifié, cette entrée est la valeur 1432. Dans le cas de la première table de structure du premier nom qualifié, cette entrée est composée par les valeurs 1451, 1452 et 1453. A l'étape suivante 1530, on vérifie si cette entrée doit être conservée. Pour cela, le pointeur de première occurrence de l'entrée dans le document codé est comparé au pointeur définissant la position L de décodage obtenue à l'étape 1500 (donc le début de la partie à accéder). Par exemple, dans le cas de la table des URI, on récupère le pointeur 1311. Dans le cas de la table des noms locaux de la première URI, on récupère le pointeur 1315. Dans le cas de la table des valeurs du premier nom qualifié, on récupère le pointeur 1432. Dans le cas de la première table de structure du premier nom qualifié, on récupère le pointeur 1452. Si le pointeur de première occurrence de l'entrée est supérieur à la position L de décodage, cela signifie que cette entrée a été créée après la position de début de décodage. Cette entrée ne doit donc pas être incluse dans la table en reconstruction. Ainsi, si à l'étape 1530, l'entrée ne doit pas être conservée, cette entrée n'est pas ajoutée à la table, et l'algorithme se termine à l'étape 1540. Dans le cas contraire, l'entrée est ajoutée à la table, en récupérant toutes les informations de l'entrée dans le document EXI à l'emplacement défini par le pointeur. Ces informations renseignent notamment le nom de l'item concerné et l'index de codage associé. L'algorithme se poursuit alors à l'étape 1550. L'étape 1550 consiste à considérer l'entrée suivante. S'il n'y a pas d'entrée suivante, l'algorithme se termine à l'étape 1540. Sinon, l'entrée 25 suivante est lue (étape 1520) et traitée à son tour. Pour déterminer s'il y a une entrée suivante à considérer, l'algorithme compare le nombre d'entrées lues lors d'une itération de l'étape 1520 avec le nombre total d'entrées de la table lu à l'étape 1510. Si le nombre d'entrées lues lors de l'étape 1520 est inférieur au nombre total d'entrées de la 30 table, alors il y a une entrée suivante à considérer. Sinon, il n'y a pas d'entrée suivante à considérer.

La table de décodage (resp. codage) se trouve ainsi prête à aider le décodeur (resp. codeur) EXI à décoder de document XML codé (resp. à encoder de nouveau le document XML dans un flux EXI) à partir de la position spécifiée en 1500.

On peut noter ici que les entrées sont codées généralement dans leur ordre d'addition à la table. Cet ordre de codage permet de coder implicitement, au sein de la structure de données 1300+1400, l'ordre des entrées dans la table. Ainsi, quand une entrée est vérifiée comme étant créée pour une position ultérieure à la position de décodage courante, toutes les entrées suivantes le sont aussi et il n'est donc pas nécessaire de les considérer, ce qui réduit les traitements effectués. Toutefois, dans le cas où cet ordre implicite n'est pas conservé au sein de la structure de données, par exemple parce qu'un ré-ordonnancement lexical a été opéré, on utilise le nombre d'entrées déterminé à l'étape 1510 pour tester, dans une boucle, toutes les entrées de la structure. En variante, la figure 16 détaille un algorithme de décodage partiel d'une table initiale de codage ou décodage selon l'invention, en vue de reconstruire une table de codage ou décodage correspondant à l'état de cette table pour une localisation spécifique dans le document XML codé. Par rapport à l'algorithme décrit ci-dessus, cette solution consiste à ne reconstruire que la partie de la table de décodage nécessaire au décodage d'une information du document XML codé. Ainsi le temps de calcul nécessaire à la reconstruction des tables de décodage est diminué. En particulier, on ne réalise le décodage des entrées d'une table de décodage que lorsqu'il est nécessaire. En détail, lors d'une première étape 1600, on obtient la position L de décodage dans le document XML codé, soit généralement le début de la partie à accéder. A l'étape suivante 1610, on ajoute l'ensemble des entrées prédéfinies par la spécification EXI dans cette table de décodage. Ensuite, les étapes suivantes consistent à calculer le nombre d'entrées présentes dans la table correspondant à la localisation courante dans le document, c'est-à-dire pour la localisation de la partie du document XML codé en cours de décodage. Ce nombre d'entrées présentes dans la table correspondant à la localisation courante dans le document est nécessaire pour pouvoir décoder l'index de codage d'une entrée de cette table. En effet, l'index de codage d'une entrée de cette table est codé en fonction du nombre d'entrées présentes dans la table. Pour cela, à l'étape 1620, le nombre d'entrées de la table de décodage est décodé de façon similaire à l'étape 1510.

Puis, à l'étape 1630, pour une première entrée de cette table de décodage, l'information de localisation de première occurrence de l'entrée est décodée, à l'aide des pointeurs prévus dans la structure de données 1300+1400. A l'étape 1640, on vérifie si cette entrée doit être comptée, c'est-à- dire si sa localisation de première utilisation est antérieure à la localisation L courante dans le document. Si c'est le cas, l'algorithme vérifie s'il existe une entrée suivante (étape 1650) et si oui, la traite (i.e. retour à l'étape 1630). A l'issu des deux cas négatifs (sorties NON des étapes 1640 et 1650), le nombre d'entrées comptées est le nombre d'entrées dans la table de décodage courante, étant entendu que si les entrées sont réordonnées dans la structure de données, on traite toutes les entrées à l'aide d'une boucle établie sur la base du nombre d'entrées récupéré à l'étape 1620. Les étapes 1620 à 1650 sont similaires aux étapes 1510 à 1540, à la différence que les premières se contentent de comptabiliser les entrées présentes dans la table, alors que les secondes créent effectivement ces entrées à la table. Dans ces deux cas négatifs, l'algorithme se poursuit à l'étape 1660 où l'on décode l'index de codage de l'entrée à utiliser pour le décodage de la partie du document XML codé courante. Cet index est décodé directement dans le flux EXI codé en prenant tout d'abord le premier item codé dans la partie à accéder. Le décodage de cet index utilise l'information du nombre d'entrées présentes dans la table, comptabilisées par les étapes 1620 à 1650. A l'étape 1670, on vérifie alors si cette entrée a déjà été lue. Si c'est le cas, l'algorithme se termine en 1690.

Si ce n'est pas le cas, l'entrée est lue à l'étape 1680 et sa définition est récupérée depuis le document XML codé à l'aide du pointeur de l'entrée contenu dans la structure de données. Les traitements réalisés lors de cette sont similaires à ceux de l'étape 1530. L'algorithme se termine ensuite à l'étape 1690 : l'entrée nécessaire au décodage ayant elle-même été décodée, le décodage de la partie courante du document XML codé peut se poursuivre par le décodage de la partie suivante. Lors d'une utilisation ultérieure de cette même table de décodage, on peut reboucler directement sur l'étape 1660 pour obtenir l'index de l'entrée 15 correspondant à une nouvelle partie du document XML à codé. Ainsi, le décodage se poursuit en obtenant la partie suivante du document XML, et ce jusqu'à parcours total de la partie à décoder. Par conséquence, les étapes 1600 à 1650 ne sont réalisées, pour une table de décodage, qu'une seule fois, notamment lors de sa première 20 utilisation. Dans cette réalisation de l'invention, on constate donc que seuls les entrées dont les index correspondants sont présents dans la partie à décoder, sont effectivement décodées et ajoutées à la table utilisée pour le décodage. On a présenté ci-dessus, en lien avec la figure 13, une réalisation 25 pour le codage des identifiants URI et tables associées. Cette réalisation ne permet pas un accès direct à chaque identifiant URI comme on l'obtient sur la figure 14 pour les autres tables. Toutefois, cette réalisation présente l'intérêt de requérir un espace mémoire réduit et l'accès indirect n'est pas pénalisant puisque en général le 30 nombre d'URI utilisés dans un document XML est limité et on est donc généralement amené à reconstruire entièrement la table des URI.

Selon une alternative, on peut utiliser une organisation légèrement différente de la section 1300 pour pouvoir accéder directement à chaque URI, par exemple une organisation inspirée de la section 1400, avec notamment une première sous-section listant les différents identifiants URI et leur associant un ou plusieurs pointeurs vers des tables d'une deuxième sous-section. Cette configuration facilite la reconstruction partielle des tables de préfixes ou de noms locaux associées à une URI. Une première solution est d'associer, à chaque URI, un pointeur sur la description de cet URI. Ainsi pour la première URI de la figure 13, ce pointeur indiquerait la valeur 1311 qui serait contenue dans la deuxième sous-section. Une deuxième solution est d'associer, à chaque URI, un pointeur pour la table de préfixes et un pointeur pour la table de noms locaux. Ainsi pour la première URI de la figure 13, le pointeur pour la table de préfixes indiquerait la valeur 1312, tandis que le pointeur pour la table des noms locaux indiquerait la valeur 1313, ces deux valeurs étant dans des champs de la deuxième sous-section. Ainsi grâce à la structure de données et les traitements associés, on peut transmettre à moindre coût le document XML Binaire accompagné des tables initiales, et permettre son exploitation par la mise en oeuvre de l'invention sur tout dispositif de traitement destinataire. En référence à la figure 12, il est maintenant décrit à titre d'exemple une configuration matérielle particulière d'un dispositif d'accès ou de modification d'un document XML Binaire apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau.

Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, relié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 10 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 15 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 tables 300, 310 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 20 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 25 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 30 - 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 40 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50.

Les disquettes 52 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif d'accès ou de modification d'un document XML Binaire, é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 d'accès ou de modification 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 48 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 3 à 11, pour mettre en oeuvre le procédé objet de la présente invention et constituer le dispositif objet de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. En particulier, l'invention s'applique également dans le cas où des éléments du document sont codés de manière indépendante, comme par exemple les éléments codés en utilisant l'option EXI self-contained . Avec cette option, on peut réaliser un encodage indépendant de un ou plusieurs événements XML, chaque événement est auto-descriptif. Dans ce cas, plusieurs ensembles de tables sont codés : un premier ensemble pour la partie principale du document, et un ensemble pour chaque élément codé de manière indépendante.

Claims

REVENDICATIONS1. Procédé d'accès à une partie d'un document (1) à partir d'une version codée dudit document, comprenant le décodage de la partie à accéder à l'aide d'au moins une table de décodage (300', 310') ayant des entrées (301, 302, 303, 311, 312, 313, 314, 315) qui associent chacune un item non codé (220) à un champ codé (225), caractérisé en ce que le procédé comprend une étape de formation (420, 430, 520, 530) de ladite au moins une table pour le décodage à partir : - d'au moins une table initiale (300, 310, 1300; 1400) de codage/décodage regroupant des entrées correspondant à une pluralité de champs codés du document et comprenant, pour au moins une entrée, une indication de la première occurrence (320, 330), à l'intérieur du document codé, de l'item associé à l'entrée ; et - d'une localisation (L), à l'intérieur du document codé, d'un premier champ codé de ladite partie à accéder.
2. Procédé selon la revendication précédente, dans lequel ladite étape de formation comprend : - la détermination de ladite localisation (420, 520), à l'intérieur du document codé, du premier champ codé de ladite partie à accéder ; et - la sélection (850) des entrées de l'au moins une table initiale dont la première occurrence indiquée (320, 330) est localisée, à l'intérieur du document codé, avant ladite localisation déterminée, de sorte à former ladite au moins une table de codage/décodage ; ledit décodage (440, 1100) de ladite partie à accéder étant réalisé à l'aide des entrées sélectionnées.
3. Procédé selon l'une des revendications précédentes, dans lequel les entrées de l'au moins une table initiale (1300, 1400) comprennent une référence (1311, 1314, 1315, 1321, 1324, 1325, 1432, 1452) de l'emplacement, dans ledit document codé, de la définition du champ codé associé.
4. Procédé selon la revendication précédente, dans lequel ladite au moins une table initiale (1300, 1400) est transmise attachée audit document codé.
5. Procédé selon l'un des revendications 3 et 4, dans lequel ladite référence (1311, 1314, 1315, 1321, 1324, 1325, 1432, 1452) pointe sur ladite première occurrence.
6. Procédé selon l'une des revendications 3 à 5, dans lequel l'étape de formation comprend : - la sélection d'au moins une entrée de la table initiale (1300, 1400) dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation (L) d'un premier champ codé ; - l'accès (1530, 1680) à l'emplacement référencé dans ladite entrée sélectionnée et le décodage des données codées audit emplacement pour former une entrée de la table de décodage.
7. Procédé selon la revendication précédente, comprenant une étape d'obtention (1660) d'une donnée codée de ladite partie à décoder, et la sélection, l'accès et le décodage (1680) de l'entrée associée à cette donnée codée sont réalisés suite à ladite obtention (1660) et si aucune entrée associée à ladite donnée codée n'est présente (1670) dans ladite table de décodage.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite indication de première occurrence comprend une indication de localisation de type pointeur vers la position de la première occurrence dudit champ codé à l'intérieur du document codé.
9. Procédé selon l'une des revendications précédentes, comprenant une étape de construction (400, 500) de l'au moins une table initiale (300, 310) de codage/décodage préalable à l'accès direct (410, 510) audit document codé.
10. Procédé de modification d'une partie d'un document à partir d'une version codée dudit document, comprenant : - une étape d'accès à ladite partie à accéder pour modification, selon le procédé de l'une quelconque des revendications précédentes ; et- ledit décodage (1100) de la partie à accéder étant suivi d'une modification (1100) de ladite partie décodée et d'un codage (1120) de ladite partie modifiée vers un document modifié codé.
11. Procédé selon la revendication 10, dans lequel l'étape d'accès comprend la détermination (520) de la localisation du premier champ codé de ladite partie à accéder, le procédé de modification comprenant une étape de recopie (550) du début du document codé jusqu'à ladite localisation du premier champ codé déterminée.
12. Procédé selon la revendication précédente, comprenant une étape de détermination (540) de la localisation, à l'intérieur du document codé, du dernier champ codé à modifier (Lf) ; - ledit décodage (1100) de la partie à modifier étant poursuivi jusqu'à ladite localisation du dernier champ codé à modifier.
13. Procédé selon la revendication précédente, dans lequel, suite au décodage, à la modification et au codage de la partie alors modifiée, on recopie (570) la fin du document codé à compter de ladite localisation du dernier champ codé à modifier (Lf).
14. Procédé selon l'une des revendications 10 à 13, dans lequel au moins une entrée de ladite au moins une table initiale (300, 310) de codage/décodage comprend une indication de la dernière occurrence (325, 335), à l'intérieur du document codé, de l'item associé à l'entrée.
15. Procédé selon l'une des revendication 10 à 14 lorsque le procédé d'accès est dépendant de la revendication 2, dans lequel ladite sélection des entrées comprend la suppression (850), dans ladite au moins une table initiale (300, 310), des entrées dont la première occurrence indiquée a une localisation postérieure à ladite localisation déterminée de sorte à former ladite au moins une table pour le décodage ou codage (300', 310'), le procédé comprenant la duplication de l'au moins une table ainsi obtenue de sorte à disposer d'au moins une table de codage et au moins une table de décodage.
16. Structure de données (1300, 1400) associée à un document codé (1) à l'aide d'au moins une table de codage (300, 310) ayant des entrées qui associent chacune un item non codé à un champ codé, la structure dedonnées comprenant, pour des entrées (301...303, 311...315) de l'au moins une table de codage résultant du codage dudit document, une référence (1311, 1314, 1315, 1321, 1324, 1325, 1432, 1452) de l'emplacement, dans ledit document codé, de la définition de chaque entrée, et une indication de première occurrence de l'item associé à l'entrée.
17. Structure selon la revendication précédente, dans laquelle ladite référence et ladite indication sont réalisées conjointement au moyen d'un même pointeur (1311, 1314, 1315, 1321, 1324, 1325, 1432, 1452) vers ladite première occurrence.
18. Structure selon l'une des revendications 16 et 17, dans laquelle une première section code (1300) conjointement une table des espaces de nommage, des tables de préfixes associés aux espaces de nommage et des tables de noms locaux associés aux espaces de nommage.
19. Structure selon l'une des revendications 16 à 18, dans laquelle une seconde section (1400) code conjointement des tables de valeurs et des tables de structures rattachées à un même item qualifié, dit "nom qualifié".
20. Dispositif d'accès à ou de modification d'une partie d'un document (1) à partir d'une version codée dudit document, comprenant des moyens de décodage de ladite partie à accéder à l'aide d'au moins une table de codage/décodage (300', 310') ayant des entrées (301, 302, 303, 311, 312, 313, 314, 315) qui associent chacune un item non codé (220) à un champ codé (225), caractérisé en ce qu'il comprend des moyens pour former ladite au moins une table à partir : - d'au moins une table initiale de codage/décodage (300, 310) regroupant des entrées correspondant à une pluralité de champs codés du document et comprenant, pour au moins une entrée, une indication de la première occurrence (320, 330), à l'intérieur du document codé, de l'item associé à l'entrée ; et - d'une localisation (L), à l'intérieur du document codé, d'un premier champ codé de ladite partie à accéder.
21. Dispositif selon la revendication précédente, dans lequel lesdits moyens pour former comprennent :- des moyens de détermination de la localisation, à l'intérieur du document codé, du premier champ codé de ladite partie à accéder ; - des moyens de sélection des entrées de l'au moins une table initiale dont la première occurrence indiquée est localisée, à l'intérieur du document codé, avant ladite localisation déterminée de sorte à former ladite au moins une table de codage/décodage pour le décodage ; et les moyens de décodage étant apte à décoder ladite partie à accéder à l'aide des entrées sélectionnées.
22. Dispositif selon la revendication précédente, comprenant des moyens de détermination de la localisation, à l'intérieur du document codé, du dernier champ codé à modifier, - dispositif dans lequel les moyens de décodage sont aptes à décoder ledit document codé jusqu'à ladite localisation dudit dernier champ codé à modifier, - le dispositif comprenant des moyens de modification de ladite partie décodée et des moyens de codage de ladite partie ainsi modifiée vers un document modifié codé.
23. Dispositif selon la revendication précédente, comprenant des moyens de recopie, vers le document modifié codé, du début dudit document codé à modifier jusqu'à ladite localisation du premier champ codé et de la fin dudit document codé à modifier à partir de ladite localisation du dernier champ codé à modifier.
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é d'accès ou de modification conforme à l'une quelconque des revendications 1 à 15, lorsque le programme est chargé et exécuté par le système informatique.
25. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé d'accès ou de modification selon l'une quelconque des revendications 1 à 15, lorsqu'il est chargé et exécuté par le microprocesseur.