FR2930660A1

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

Info

Publication number: FR2930660A1
Application number: FR0852827A
Authority: FR
Inventors: Herve Ruellan
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-04-25
Filing date: 2008-04-25
Publication date: 2009-10-30
Also published as: US20090271695A1; FR2930661B1; FR2930661A1

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') dont les entrées 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 les 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. L'utilisation de formats XML Binaire permet ainsi, 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 Iastname ) 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 ( Iastname ) : 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. 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 à un index (le même que celui associé à cette valeur lors du codage). Ainsi, lors de l'occurrence ultérieure de cet index dans le document à décoder, cet index indique que la valeur contenue dans le document à cet emplacement est Smith . Ce codage par index 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 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 à 20 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 25 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. 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 30 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 15 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 dont les entrées associent chacune un item non codé à un 20 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 les 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 25 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 30 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 représentant 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 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. 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.

Comme indiqué ci-dessus, on recherche une efficacité accrue de l'invention en construisant les tables 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. 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, 20 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é. 25 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 30 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 10 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 15 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 20 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. 25 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 30 traitement 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 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 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é ; - 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 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 10 parties modifiées. 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 15 d'une partie d'un document à 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 dont les entrées associent chacune un item non codé à un champ codé, et des moyens pour former ladite au moins une table étant formée à partir : 20 - d'au moins une table initiale de codage/décodage regroupant les 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 25 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 ; 30 - 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.

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 ; et - la figure 12 montre une configuration matérielle particulière d'un dispositif apte à une mise en oeuvre du procédé selon l'invention.

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. 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. 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.

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. Quel que soit le cas d'utilisation envisagé, les tables de codage 300, 310 correspondant à chacun des documents 1 appelés à être modifiés doivent être 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. Cette étape est détaillée en référence aux figures 8 et 9. 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 10 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 15 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 20 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 25 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 d'accès à une partie du document se termine à l'étape 30 440 où ce jeu de tables 300', 310' est utilisé pour décoder le 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 focalise 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. 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.

Un troisième 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. 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, on prévoit que l'efficacité de l'invention prévue dans la deuxième mesure est 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 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. 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 5 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 10 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 15 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 20 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 25 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 30 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 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 10 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 15 modification. En outre, il convient d'être prudent lors des étapes suivantes du traitement du document 1. Notamment, il convient 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 20 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 25 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 30 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 "Smith" (index=2) et "John" (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écrit 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 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(I) 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(I) est égale à la localisation L, deux cas peuvent se présenter en fonction de la localisation Lf(I) de dernière utilisation de l'entrée I : - 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(l) 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'(ood), 310'(ood) 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.

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 exemple sous la forme d'un microprocesseur ; - Une mémoire morte 53 dans laquelle peuvent être contenus les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention ; - Une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en oeuvre de l'invention, notamment les 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 programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - Un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - Un lecteur de disquette 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 70 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - Une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données.

Dans le cas de données audio, le dispositif 50 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 62. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 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.

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') dont les entrées (301, 302, 303, 311, 312, 313, 314, 315) 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) de codage/décodage regroupant les 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 la revendication 2, dans lequel ladite sélection comprend la suppression (850), dans ladite au moins une table initiale (300, 310), des entrées dont la première occurrence indiquée (320, 330) a une localisation postérieure ou égale à ladite localisation déterminée de sorte à former ladite au moins une table pour le décodage (300', 310').
4. Procédé selon la revendication précédente, comprenant une étape de duplication de ladite au moins une table initiale de codage/décodage avant ladite étape de sélection.
5. 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é.
6. 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é.
7. Procédé selon la revendication 6, dans lequel ladite construction (400, 500) est réalisée en même temps que le codage dudit document (1) dans sa version codée.
8. Procédé selon la revendication 6, dans lequel ledit document codé est reçu par un dispositif d'accès (50), ladite construction étant réalisée par ledit dispositif d'accès lors d'un accès antérieur audit document codé.
9. 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é.
10. Procédé selon la revendication 9, 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.
11. 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.
12. 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).
13. Procédé selon l'une des revendications 9 à 12, 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.
14. Procédé selon la revendication précédente, comprenant une étape de construction (500) de l'au moins une table initiale de codage/décodage, ladite construction comprenant: - une étape préliminaire de modification (610) d'au moins une table de codage/décodage de base (200, 210) par l'adjonction, pour chaque entrée, d'une indication de première occurrence (320, 330) prenant la valeur de la localisation de début de document et d'une indication de dernière occurrence (325, 335) prenant la valeur de la localisation de début de document; et - une étape ultérieure de traitement (720) d'au moins un item dudit document (1), comprenant la modification (730) 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é. 17. Procédé selon la revendication précédente, dans lequel, 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 (320, 325, 330, 335) renseignant la localisation, à l'intérieur du document codé, du champ codé correspondant audit item traité. 18. Procédé selon l'une des revendication 9 à 15 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 moinsune 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. 17. Procédé selon l'une des revendications 9 à 16, dans lequel ladite au moins une table initiale (300, 310) est stockée en mémoire (53, 54, 63) d'un dispositif d'accès (50), ledit stockage étant fonction d'au moins une information de priorité associée audit document (1), ladite information de priorité étant au moins 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. 18. 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') dont les entrées (301, 302, 303, 311, 312, 313, 314, 315) 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 les 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. 19. 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 dudocument 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. 20. 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é. 21. 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. 22. Dispositif selon l'une des revendications 18 à 21, dans lequel 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é. 23. Dispositif selon la revendication précédente, dans lequel 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. 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 desrevendications 1 à 17, 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 à 17, lorsqu'il est chargé et exécuté par le microprocesseur.