FR2959080A1 - Procede et dispositif de codage de donnees structurees a l'aide d'une expression xpath - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif de codage de données structurées composées d'items, notamment d'un document XML. Un item étant codé à l'aide d'une entrée d'un dictionnaire de codage, le procédé consiste à : - obtenir (E130, E430) un ensemble d'items similaires devant être codés à l'aide d'une même entrée (PROD) d'un dictionnaire de codage (GRAM), en utilisant par exemple une instruction de type expression XPath ; et - procéder au codage (E140, E450) desdits items de cet ensemble en accédant une seule fois à ladite entrée. Selon l'invention, des parties identiques d'items similaires répartis en divers emplacements du document à coder sont ainsi codées simultanément en une action. Là où classiquement on répète plusieurs fois une même action, l'invention permet de rechercher et d'accéder une seule fois une dite entrée du dictionnaire. Un grand nombre d'étapes classiquement répétées pour coder chacun de ces items est ainsi évité.

Description

La présente invention concerne un procédé et un dispositif de codage de données structurées composées d'items, notamment d'un document structuré. Elle s'applique en particulier aux documents structurés de type XML (acronyme de "eXtensible Markup Language" pour langage de balisage extensible) destinés à être codés sous la forme d'un flux binaire type EXI ("Efficient XML Interchange") ou Fast Infoset. 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. Dans le cas où un élément contient d'autres éléments, on parlera d"'élément parent" qui contient des "éléments enfants". D'autre part, un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple: <balise attribut="valeur">). De façon connue en soi, la syntaxe XML permet aussi de définir des commentaires, des instructions de traitement et des sections d'échappement.

On considère dans la suite que des données XML sont décrites en terme d"'items" ou "événements", chaque item ou événement pouvant être un début d'élément (par exemple <balise>), une fin d'élément (par exemple </balise>), un attribut (par exemple attribut="valeur"), un contenu textuel, un commentaire, une instruction de traitement ou une section d'échappement.

Le langage XML présente de nombreux avantages et est devenu un langage de référence pour stocker des données dans un fichier ou pour échanger des données. Le langage XML permet en particulier de disposer de nombreux outils pour traiter les fichiers générés. En particulier, un document XML peut être édité manuellement avec un simple éditeur de texte. En outre, comme un document XML contient sa structure intégrée aux données, ce document est très lisible même sans en connaître la spécification.

Le principal inconvénient de la syntaxe XML est d'être très prolixe. Ainsi la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi un temps de traitement important lors de la génération et de la lecture de documents XML. Elle induit aussi un temps de transmission important.

Pour remédier à ces inconvénients, des méthodes de compression et d'encodage d'un document XML ont été recherchées. Le but de ces méthodes est de coder le contenu du document XML sous une forme plus efficace, tout en permettant de reconstruire facilement le document XML. C'est notamment le cas des formats binaires tels que EXI (format utilisé comme base pour la standardisation d'un format XML binaire par le groupe de travail EXI du W3C - "World Wide Web Consortium", organisation produisant des standards pour le Web) ou Fast Infoset spécifié par la norme ITU-T Rec. X.891 1 ISO/IEC 24824-1. Ces formats ont pour caractéristique de prendre en compte un nombre important d'informations structurelles du document afin de compresser davantage les données. Par exemple, la recommandation EXI, disponible au travers du document "Efficient XML Interchange (EXI) Format 1.0 - W3C Candidate Recommendation 08 December 2009", prend en compte l'ordre d'apparition des différents items ou événements au sein d'un document structuré pour construire une ou plusieurs grammaires qui permettent d'encoder les événements les plus fréquents sur un faible nombre de bits. Une grammaire est composée d'un ensemble de productions, chaque production comprenant une description d'événement XML, une valeur de codage associée et l'indication de la grammaire suivante à utiliser. Pour coder un événement XML à l'aide d'une grammaire, la production contenant la description la plus précise de l'événement XML est utilisée. La valeur de codage contenue dans cette production est utilisée pour représenter l'événement dans le flux binaire codé, et les informations contenues dans l'événement et non décrites dans la production sont codées à la suite. Une même production peut donc servir au codage de plusieurs occurrences d'un même type d'événement XML.

Une grammaire selon Efficient XML est évolutive. Dans un certain nombre de cas, après l'occurrence d'un événement XML déjà décrit par une production de la grammaire (s'il n'est pas décrit par une production, il ne peut être encodé par la grammaire), la grammaire est modifiée pour inclure une nouvelle production plus efficace correspondant à cet événement XML. Cette production peut soit contenir une description plus précise de l'événement, diminuant le nombre d'informations à coder pour représenter l'événement, soit avoir une valeur de codage plus compacte. Les valeurs de codage, ou "codes", sont exprimées sous forme de "priorités" ayant, généralement, entre 1 et 3 niveaux. Coder une valeur de codage revient à coder les valeurs de sa priorité. Ces valeurs sont généralement exprimées sur un octet (8 bits) et manipulées ainsi par l'encodeur. Toutefois, chaque niveau peut être codé sur le nombre de bits minimum pour pouvoir coder la plus grande valeur de ce niveau associée à une production de la grammaire. Aussi, pour un niveau prenant des valeurs de 0 à 6, on utilise trois bits de codage. Pour coder un document XML, un ensemble de grammaires est utilisé. Quelques grammaires servent à coder la structure propre au document XML. En outre, pour chaque type d'événement XML présent dans le document (un type d'élément XML étant un ensemble d'événements ayant le même nom), un ensemble de grammaires est utilisé pour coder les événements XML de ce type. L'indication de la grammaire suivante au niveau des productions permet de naviguer de grammaire en grammaire. Ainsi, au fur et à mesure du codage, on empile les grammaires lorsque l'on s'enfonce dans la structure du document, et on dépile ces mêmes grammaires dès que l'on finit d'encoder les événements XML correspondant à ces grammaires.

Les règles de grammaires utilisées peuvent soit être des règles génériques, communes à tous les documents XML et construites à partir de la syntaxe XML, soit être des règles spécifiques à un type de document, construites à partir d'un Schéma XML décrivant la structure de ce type de document. Ces grammaires constituent des dictionnaires de codage. Lors du décodage, le processus inverse est utilisé : la valeur de codage correspondant à un événement EXI est extraite du flux binaire EXI, et permet d'identifier l'événement XML codé ainsi que les informations complémentaires à décoder. En outre, lors du décodage, les mêmes règles d'évolution des grammaires sont utilisées, permettant d'avoir à tout moment un ensemble de règles de grammaires identique à celui qui était utilisé lors du codage. A titre d'exemple, le fragment XML suivant est utilisé pour décrire le codage d'un document XML à l'aide de la spécification EXI: <person> <firstname>John</firstname> <middlename>P.</middlename> <lastname>Smith</lastname> </person> Dans la suite des explications, il sera également fait référence à un élément <st> correspondant à une liste contenant plusieurs éléments <person>. Au début de l'encodage de ce fragment, puisque l'encodeur n'a pas encore rencontré d'élément <person>, une grammaire par défaut est créée pour cet élément. Il s'agit d'une grammaire ne contenant que des productions génériques. Durant l'encodage de l'élément "person", de nouvelles productions seront créées et insérées pour rendre la grammaire liée à cet élément plus efficace. La grammaire par défaut utilisée pour coder le contenu de l'élément "person" est la suivante (de manière simplifiée par rapport à la spécification Efficient XML, notamment en utilisant une seule grammaire pour coder l'élément "person") : ElementContent : EE 0 SE (*) ElementContent 1.0 CH ElementContent 1.1 Les événements EE, SE, CH représentés ici (d'autres événements sont prévus dans la recommandation EXI) utilisés pour décrire les événements XML sont appelés événements EXI et sont directement associés aux valeurs de codage (ou "priorités") du flux EXI binaire. En particulier, "EE" correspond à l'événement de fin d'élément, "SE (*)" correspond un événement de début d'élément quelconque (générique, le nom n'est donc pas précisé), et "CH" correspond à un événement de contenu textuel. Lors de l'encodage, après avoir reçu l'événement correspondant au début d'élément "person" (SE (person)), et l'avoir codé par exemple de façon littérale (ou à l'aide d'une grammaire appropriée de plus haut niveau), l'encodeur sélectionne la grammaire de codage du contenu de l'élément "person", décrite ci-dessus. Ensuite, l'encodeur reçoit l'événement de début d'élément "firstname" (<firstname> correspondant à un événement EXI SE (firstname)). La production la plus précise qui correspond à cet événement dans la grammaire ci-dessus est la deuxième : SE (*) ElementContent 1.0 L'encodeur code donc cet événement en insérant la priorité "1.0" dans le flux EXI binaire. Comme le premier niveau de priorité comprend deux valeurs distinctes ("0" et "1") parmi les productions de la grammaire, ce niveau peut être codé sur un bit, avec la valeur "1". De même, le deuxième niveau de priorité comprend deux valeurs distinctes et peut être codé sur un bit, avec la valeur "0". La priorité "1.0" est donc codée ici avec les deux bits "10". Cette donnée codée est ainsi générée initialement sur un ou plusieurs octets.

Ensuite, comme la production ne précise pas le nom de l'élément, "firstname" est codé par exemple de façon littérale à l'aide d'un format spécifique à la spécification Efficient XML (similaire au format UTF8). 5 On poursuit ensuite l'encodage du contenu de "firstname". Dans ce dessein, on recherche la production associée à cet élément. Comme aucun élément "firstname" n'a encore été rencontré, on crée une grammaire "firstname" à partir de la grammaire par défaut évoquée précédemment.

L'élément "firstname" contient un noeud texte pour unique enfant. On encode ce noeud texte, par exemple littéralement. Une fois ce noeud texte encodé, on met à jour la grammaire de "firstname" en insérant une production texte CH. Grammaire "firstname" ElementContent : Une fois le contenu de "firstname" codé, l'encodeur modifie la grammaire associée à l'élément "person" pour adapter la grammaire aux données XML rencontrées. Pour cela, une nouvelle production est ajoutée à la grammaire, cette production correspondant au début d'élément "firstname". A cette production est associée la priorité "0", et les autres priorités sont décalées pour conserver l'unicité des priorités. On rappelle ici que le décodeur agissant de façon symétrique sera en mesure de réaliser des décalages de priorités (ou index) similaires au fur et à mesure du décodage des données reçues. Ainsi la grammaire "person" devient :

L'événement suivant du fragment XML à coder est le début de l'élément "middlename". Comme pour "firstname", cet élément est codé à l'aide de la production : SE (*) ElementContent 2.0 CH 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 Grammaire "person" ElementContent : SE (firstname) ElementContent 0 EE 1 SE (*) ElementContent 2.0 CH ElementContent 2.1 puisque aucune production correspondant à l'élément "middlename" n'est trouvée. Le premier niveau de priorité ayant maintenant trois valeurs possibles, il est codé sur deux bits, avec la valeur "2". Le deuxième niveau de priorité est toujours codé sur un seul bit. La priorité "2.0" est donc codée ici avec les trois bits "100". Le nom de l'élément, "middlename", est ensuite codé, par exemple littéralement. Puis le contenu de "middlename" est codé à l'aide d'une grammaire associée à l'élément "middlename", à créer si nécessaire lors de la première occurrence d'un item "middlename", de façon similaire à ce qui est décrit ci-dessus pour la grammaire "firstname". On procède de même pour l'élément "lastname". Après l'encodage de l'élément "lastname", la grammaire "person" a été modifiée pour y ajouter une production correspondant au début de chaque élément "middlename" et "lastname" (avec décalage des priorités), et elle devient alors : 25 Ensuite, l'événement de fin d'élément, correspondant à la fin de l'élément "person" est codé, en utilisant la production : EE 3 Si, par la suite, dans le document XML, le codeur rencontre un autre élément "person" similaire, cet élément va être codé à partir de cette 30 grammaire. Ainsi le premier événement correspondant au contenu de l'élément "person" est l'événement de début de l'élément "firstname". Cet élément est codé avec la production: Grammaire "person" ElementContent : SE (lastname) ElementContent 0 SE (middlename) ElementContent 1 SE (firstname) ElementContent 2 EE 3 SE (*) ElementContent 4.0 CH ElementContent 4.1 SE (firstname) ElementContent 2 On note que la production 4.0 SE (*) ElementContent correspond aussi à cet événement, mais est moins précise (elle ne précise pas le nom "firstname" de l'élément). C'est donc la première production qui est utilisée pour une efficacité de codage accrue. L'encodeur code donc la priorité de cette production, à savoir la valeur "2", qui est codée sur trois bits (car prenant des valeurs de 0 à 4), soit "010". Il n'y a pas besoin de coder le nom de l'élément, puisque celui-ci est précisé par la production et ressort du codage littéral initial lorsque l'élément "firstname" a été rencontré pour la première fois. L'encodeur code ensuite le contenu de l'élément "firstname". Comme une production spécifique à l'événement de début de l'élément "firstname" existe déjà dans la grammaire, il n'est pas nécessaire d'ajouter une nouvelle production à la grammaire. L'encodeur code ensuite, de manière similaire, les événements de début de l'élément "middlename" et "lastname", en codant uniquement les priorités "1" puis "0" avec les bits "001" et "000". Ainsi, pour le codage du deuxième élément "person" similaire au premier, le code généré est plus compact, puisqu'il n'est plus nécessaire de coder le nom des éléments contenus dans "person", ni littéralement (en codant l'intégralité de la chaîne de caractères), ni même à l'aide d'un index. On observe ainsi, tout au long du codage d'un document XML, que l'on navigue d'une grammaire à l'autre pour trouver les productions adaptées au codage des événements XML. Cette navigation est fonction de l'événement XML qui vient d'être codé, et qui peut indiquer implicitement la nouvelle grammaire à utilise (après SE(firstname) on bascule sur la grammaire liée à "firstname") ou dont la production associée indique la grammaire suivante à utiliser (la production CH indique la grammaire qu'il faut charger pour la suite en remplacement de la grammaire courante). La recommandation EXI prévoit par ailleurs des mécanismes pour préparer, avant le codage ou le décodage, les grammaires en tout ou partie, à partir d'un fichier de description structurelle de documents, dit Schéma XML ("XML Schema"). Si un tel schéma XML est disponible pour décrire le contenu de l'élément "person", à savoir un élément "firstname", un élément "middlename" et un élément "lastname", il est possible de construire dès le départ la grammaire générée après la fin du codage du premier élément "person". Cependant, si le schéma précise en outre que les éléments "firstname", "middlename" et "lastname" doivent être ordonnés, dans cet ordre, à l'intérieur de l'élément "person", il est possible de générer les grammaires suivantes pour décrire le contenu de l'élément "person" (toujours de manière simplifiée par rapport à la spécification Efficient XML). ElementContentl : 0 SE (firstname) ElementContent2 EE 1.0 SE (*) ElementContentl 1.1 CH ElementContentl 1.2 ElementContent2 : 0 SE (middlename) ElementContent3 EE 1.0 SE (*) ElementContent2 1.1 CH ElementContent2 1.2 ElementContent3 : 0 SE (lastname) ElementContent4 EE 1.0 SE (*) ElementContent3 1.1 CH ElementContent3 1.2 ElementContent4 : EE 0 SE (*) ElementContent4 1.0 10 CH ElementContent4 1.1

Cette notion d'ordre des éléments est connue sous le nom de structure dite "séquence", certains des éléments pouvant être optionnels. Par ailleurs une séquence peut être répétée. A l'inverse des séquences, si l'élément "person" est composé des éléments "firstname", "middlename" et "lastname" sans ordre précis, on parlera d'une structure dite "choix". Les éléments d'un choix peuvent être optionnels et répétés, et le choix peut être répétitif ou non.

Les informations de choix/séquence, d'optionalité et de répétitivité sont en particulier renseignées à l'intérieur du Schéma XML. Les grammaires de l'exemple ci-dessus se servent de l'ordre connu d'apparition des éléments "firstname", "middlename" et "lastname" pour séparer les productions en plusieurs grammaires et diminuer le nombre de productions par grammaire, et par conséquent le nombre de bits nécessaires pour coder une priorité. Ces grammaires peuvent même être réduites si l'on n'accepte pas les déviations par rapport au schéma. Une déviation correspond à la présence d'un événement XML non décrit par le schéma. Ce peut être la présence d'un élément XML autre que ceux décrits par le schéma, ou la présence d'un élément XML décrit par le schéma, mais à un endroit non prévu par le schéma. Lors de l'utilisation d'un schéma pour construire les grammaires EXI, un premier mode, le mode déviation, permet de prendre en compte ces déviations et de les coder en faisant évoluer les grammaires.

Un autre mode, le mode strict, n'autorise pas ces déviations et ne permet pas de coder un document contenant une telle déviation. Dans ce dernier mode, il est ainsi possible de s'affranchir des productions dites "génériques" (telles que SE(*)) utiles pour traiter des événements inattendus) et celles qui ne se réaliseront pas.

Aussi, dans le mode strict, les grammaires deviennent, pour notre exemple: ElementContentl : 11 SE (firstname) ElementContent2 0

ElementContent2 : SE (middlename) ElementContent3 0 ElementContent3 : SE (lastname) ElementContent4 0

ElementContent4 : 10 EE 0

Dans ce cas, chaque grammaire ne contenant qu'une seule priorité, cette priorité n'a pas besoin d'être codée. Ainsi, l'ensemble des événements décrivant le contenu de l'élément "person" tel que décrit ci-dessus est codé en 15 zéro bit (tous les événements peuvent être prédits de façon sûre) et peut être décodé rapidement par prédiction. Dans le cas où l'élément "middlename" est optionnel, ces grammaires deviennent: ElementContentl : SE (firstname) ElementContent2 0

ElementContent2 : SE (middlename) ElementContent3 0 SE (lastname) ElementContent4 1 ElementContent3 : SE (lastname) ElementContent4 0

ElementContent4 : 20 25 30 EE 0 Seule la présence ou non de l'élément "middlename" doit être codée. En effet, l'élément "firstname" peut être suivi soit de l'élément "middlename", soit de l'élément "lastname", d'où les deux entrées dans la grammaire ElementContent2 faisant suite immédiatement après le codage d'un élément "firstname". Comme il ressort de ce qui précède, le codage de chaque élément d'un document XML vers le format EXI nécessite a minima la réalisation des étapes suivantes: rechercher la production correspondant au début de cet élément, coder cette production à l'aide de la priorité associée, obtenir le contenu de l'élément, rechercher la production correspondante pour le contenu (notamment du texte), coder cette dernière, coder le contenu, rechercher la production correspondant à la fin de l'élément puis coder cette dernière. Par ailleurs, le codage d'un document XML consiste à coder successivement chacun des items ou éléments du document dans l'ordre de ce dernier, notamment en les récupérant au travers d'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) ou en parcourant verticalement un arbre de représentation, type arbre DOM (pour "Document Object Modef'), stockant le document XML. Or, de façon générale, il est fréquent qu'un document structuré contienne un grand nombre d'items similaires, c'est-à-dire faisant notamment appel aux mêmes entrées des dictionnaires de codage (aux mêmes productions dans notre exemple). Les inventeurs ont pu constater, dans ce cas, qu'un grand nombre des étapes listées ci-dessus est répété à l'identique un grand nombre de fois et donc inutilement reproduit. La présente invention vise ainsi à pallier ces inconvénients, notamment pour permettre un encodage plus efficace et plus rapide. On connaît par ailleurs, de la publication US 2005/228811, une méthode de codage d'un document XML en cartographiant les éléments XML dans un espace résultant d'une décomposition des chemins XPath identifiant chacun des éléments XML. La carte obtenue, l'espace de décomposition et les grammaires sont alors codés pour permettre à un décodeur de reconstituer le document XML d'origine. L'inconvénient principal de cette méthode est que le flux codé obtenu n'est plus du tout compatible avec les formats de codage classiques, tels que l'EXI ou Fast Infoset, notamment car les éléments XML ne sont pas individuellement codés. La présente invention vise également à être compatible avec les formats de codage existants pour permettre un décodage des flux binaires obtenus par des décodeurs classiques.

Dans ce dessein, l'invention concerne notamment un procédé de codage de données structurées composées d'items, au moins un item étant codé à l'aide d'une entrée d'un dictionnaire de codage, le procédé étant caractérisé en ce qu'il comprend les étapes consistant à : - obtenir un ensemble d'items devant être codés à l'aide d'une 15 même entrée d'un dictionnaire de codage ; et - procéder au codage desdits items de l'ensemble obtenu en accédant une seule fois à ladite entrée, de sorte à obtenir des items codés. L'invention offre un procédé de codage plus rapide que les procédés classiques. Cette efficacité accrue résulte de la réduction du nombre d'accès à 20 une entrée du dictionnaire de codage, en prévoyant d'identifier les items "similaires" qui doivent être codés à l'aide de cette entrée, puis en y accédant une seule fois pour obtenir une valeur de codage (par exemple les priorités) servant à encoder "simultanément" ces items "similaires". A titre illustratif, dans le cas du codage EXI, les ensembles d'items 25 dits "similaires" correspondent aux items ayant un même type d'item (attribut, élément, texte, etc.) et éventuellement le même nom qualifié (ou "qualified name" ou "qname"), car chaque production correspond à un tel type d'élément possiblement complété d'un nom qualifié (comme montré ci-dessus entre la production SE(*) et la production SE(firstname)). 30 Par conséquent, selon l'invention on factorise des étapes identiques pour coder des items similaires. Par exemple on recherche et accède une seule fois cette entrée du dictionnaire. Un grand nombre d'étapes classiquement répétées pour coder chacun de ces items est ainsi évité. On modifie donc par l'invention, l'ordre de codage des items par rapport à l'ordre classiquement adopté. Par exemple, dans une représentation arborescente, type arbre DOM, le codage selon l'invention revient à, lorsque l'on rencontre un élément XML, parcourir la structure de données en largeur pour déterminer et coder les éléments similaires. Le parcours de l'arbre DOM n'est donc plus uniquement réalisé verticalement, dans le sens uniquement de la profondeur (cas classique).

Dans un mode de réalisation de l'invention, l'étape d'obtenir un ensemble d'items comprend les étapes consistant à : - obtenir une représentation desdites données structurées, en mémoire d'un encodeur ; - utiliser au moins une instruction de sélection dans ladite représentation hiérarchique de sorte à sélectionner ledit ensemble d'items. Comme introduit précédemment, la représentation peut être de type arbre DOM facilitant la navigation à l'intérieur des données structurées. Grâce à des instructions adaptées, la sélection des items dans la représentation est aisée et conduit à un codage accéléré.

En particulier, ladite au moins une instruction de sélection est une expression XPath. La simplicité d'utilisation des expressions XPath assure un traitement de codage plus efficace, en temps de traitement et en mémoire nécessaire au stockage des instructions de sélection. En variante, ladite représentation est hiérarchique et repose sur une technologie offrant des commandes de navigation au sein de ladite représentation hiérarchique, et ladite au moins une instruction de sélection comprend au moins une dite commande de navigation. La représentation par arbre DOM est typiquement hiérarchique. Cette disposition permet une mise en oeuvre logicielle ou matérielle simple des mécanismes de sélection des items au niveau de l'encodeur, car reposant sur une seule technologie. Selon une caractéristique particulière, ladite instruction de sélection est formée à partir d'un fichier de description de structure de document, type Schéma XML, préalablement au codage des données structurées. Cette disposition permet de constituer à l'avance les instructions de sélection, pour une efficacité accrue du codage effectif. Cette constitution préalable permet également une réutilisation aisée de ces instructions pour différents documents satisfaisant une même définition de structure et étant codés successivement. En variante, ladite instruction de sélection est créée lors de l'encodage de la première occurrence des items devant être codés à l'aide de ladite entrée de dictionnaire de codage. Dans ce cas, la constitution des instructions peut être menée à partir des dictionnaires de codage en cours de création. Dans le cas de l'utilisation d'un Schéma XML notamment, on peut prévoir une étape consistant à associer, en mémoire, ladite instruction de sélection d'item à ladite entrée codant ces items. A titre illustratif, dans le cas du codage EXI, cela correspond à mémoriser la requête XPath de sélection d'un élément, par exemple <person>, au niveau de la production codant cet élément, dans l'exemple SE(person). Cette production est contenue dans la grammaire courante, dans notre exemple la grammaire liée à l'élément "list" qui comprend les occurrences de l'élément "person". Cette disposition permet d'accéder et d'obtenir rapidement cette instruction de sélection, lorsqu'il s'agit de procéder au codage des données structurées. En particulier, on associe, en mémoire, ladite instruction de sélection d'items à d'autres entrées d'autres dictionnaires de codage, ces autres entrées codant le même type d'items que ladite entrée, par exemple ceux ayant le même nom qualifié au sens de la recommandation EXI. Cette disposition permet de couvrir le cas des éléments optionnels évoqués précédemment qui apparaissent dans plusieurs grammaires EXI par exemple. On s'assure ainsi que tous les dictionnaires susceptibles de coder un type d'élément XML (selon la réalisation ou non d'éléments optionnels avant un tel type d'élément) disposent de l'instruction de sélection lorsque l'on accède à l'entrée correspondante pour procéder au codage. Dans un mode de réalisation, ladite au moins une instruction de sélection se substitue, lors de sa formation, à ladite entrée du dictionnaire de codage, et on associe, à ladite instruction de sélection, des informations de codage. En particulier, le procédé met en oeuvre une pluralité d'instructions de sélection se substituant à une pluralité d'entrées de dictionnaire de codage, la pluralité d'entrées formant initialement une structure ordonnée, et lesdites instructions de sélection après substitution sont reliées entre elles en conservant ladite structure ordonnée. Ces dispositions permettent d'éviter le stockage simultané des grammaires EXI et des instructions de sélection type expressions XPath utilisées pour la mise en oeuvre de l'invention. En accédant directement aux expressions XPath et aux informations de codage associées, les recherches de grammaire/production EXI sont simplifiées par rapport aux mécanismes classiques de codage. On accélère ainsi le codage (surtout lorsque les expressions XPath sont préparées préalablement au codage, à l'aide des schémas XML) et on permet celui-ci par des codeurs munis de ressources mémoire limitées. Dans un mode de réalisation de l'invention, le procédé comprend une étape consistant à concaténer des items codés selon leur ordre au sein des données structurées. Cette disposition permet de constituer progressivement les données codées, en plusieurs endroits du document à coder (résultant donc d'un codage parallèle selon l'invention), au fur et à mesure que l'on code les items similaires à ceux que l'on rencontre. En particulier, un contexte de codage est associé à un item parent, ledit contexte de codage étant configuré pour recevoir au moins les données correspondant à l'item parent codé, et le procédé comprend : - une étape d'exécution d'une instruction de sélection d'un item enfant à l'intérieur de l'item parent, et - si l'instruction de sélection retourne plusieurs items enfants, une étape de construction d'un contexte de codage propre pour chacun des items enfants, le codage de chaque item enfant remplissant le contexte de codage correspondant avec les données correspondant à l'item enfant codé.

Cette disposition assure une réalisation parallèle du codage des différents items obtenus par l'instruction de sélection. En effet, les valeurs communes pour le codage de ces items peuvent être directement copiées dans les contextes de ceux-ci, permettant le parallélisme d'un codage selon l'invention. Ainsi, ledit codage en accédant une seule fois à ladite entrée comprend la recopie, dans chacun des contextes de codage propres aux items enfants, d'une même donnée codée obtenue au niveau de ladite entrée. Selon une caractéristique particulière, le procédé comprend, lorsque lesdits items enfants sont codés, une étape consistant à concaténer le contexte de codage associé à l'item parent avec les contextes de codage associés aux items enfants, en fonction de l'ordre desdits items enfants au sein des données structurées. De la sorte, on constitue progressivement les morceaux codés des données structurées. Selon une caractéristique particulière de l'invention, si un item enfant est susceptible d'être répété dans la structure d'un item parent, ce qui est déterminable par exemple à l'aide d'un Schéma XML, le procédé comprend : - une étape de décomposition de l'item enfant susceptible d'être répété en une séquence d'items enfants identiques, - une étape d'association d'une instruction de sélection d'items au premier des items enfants identiques dans ladite séquence et d'au moins une instruction de sélection d'items aux autres items enfants identiques, - si l'exécution de l'au moins une instruction de sélection associée aux autres items enfants identiques retourne plusieurs items enfants, une étape de propagation d'un contexte de codage associé audit premier item enfant en l'associant successivement à chaque item enfant retourné en respectant l'ordre desdits items enfants dans les données structurées De la sorte, dans ce cas particulier des éléments répétables, on évite de créer un contexte de codage propre à chaque élément répété, en effectuant une propagation du contexte de codage courant. Il en résulte un codage encore plus efficace. Cette disposition s'applique notamment lorsque l'on prévoit d'associer une même instruction de sélection d'items à plusieurs dits autres items enfants identiques. De la sorte, on groupe cette sélection en effectuant une seule opération, tout en évitant une démultiplication des contextes de codage puisque ces éléments répétés sont consécutifs et peuvent être codés consécutivement dans le même contexte de codage sans surcoût.

Selon une autre caractéristique, le procédé comprend, si l'instruction de sélection retourne un seul item enfant, une étape de propagation dudit contexte de codage associé à l'item parent en l'associant à l'item enfant retourné. Cette association à l'item enfant est temporaire le temps que celui-ci soit codé. Après, le contexte de codage peut être à nouveau associé à l'item parent pour continuer son codage. Cette disposition contribue également au codage progressif des données structurées. Bien entendu, cette opération de propagation peut être menée plusieurs fois en parallèle pour plusieurs occurrences d'éléments parent similaires ayant chacun un seul élément enfant. Dans un mode de réalisation, un contexte de codage comprend une indication du dernier item codé qu'il code. Cette disposition contribue à simplifier les opérations lorsqu'il s'agit de concaténer entre eux les contextes de codage. Dans un autre mode de réalisation, ledit ensemble des items obtenus et codés en accédant une seule fois à ladite entrée comprend des items provenant de plusieurs documents structurés. En effet, la présente invention trouve une application particulièrement intéressante au codage simultané de plusieurs documents, notamment dès lors qu'ils respectent un même schéma XML à partir duquel les instructions de sélection évoquées précédemment peuvent être établies.

Corrélativement, l'invention concerne un dispositif de codage de données structurées composées d'items, au moins un item étant codé à l'aide d'une entrée d'un dictionnaire de codage, caractérisé en ce qu'il comprend : - un moyen pour obtenir un ensemble d'items devant être codés à l'aide d'une même entrée d'un dictionnaire de codage ; et - un moyen de codage configuré pour coder lesdits items de l'ensemble obtenu en accédant une seule fois à ladite entrée, de sorte à obtenir des items codés.

Le dispositif de codage présente des caractéristiques et avantages analogues au procédé de codage selon l'invention. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de codage exposé précédemment.

En particulier, ledit dispositif de codage comprend des dictionnaires de codage composés d'entrées codant chacune un type d'items, une instruction de sélection, par exemple de type expression XPath, étant associée à chacune des entrées pour sélectionner des items dudit type correspondant à l'entrée. Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de codage conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. Un programme d'ordinateur lisible par un microprocesseur, comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de codage conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente, sous forme d'ordinogramme, des étapes générales de codage selon la présente invention ; - la figure 2 représente, sous forme d'ordinogramme, des étapes pour la création d'instructions de sélection type expressions XPath pour la mise en oeuvre de l'invention ; - la figure 3 représente, sous forme d'ordinogramme, des étapes pour la création d'un ensemble d'expressions relatives à une séquence d'éléments à l'intérieur d'un élément XML courant, mise en oeuvre lors des traitements de la figure 2 ; - la figure 4 représente, sous forme d'ordinogramme, des étapes de codage d'un élément XML à partir d'instructions de sélection ; et - la figure 5 montre une configuration matérielle particulière d'un dispositif de codage apte à une mise en oeuvre du procédé selon l'invention.

L'invention concerne notamment un procédé et un dispositif de codage de données structurées composées d'items. Par exemple, de telles données structurées peuvent être tout ou partie d'un document XML. Les items, par exemple des éléments XML ou événements XML, sont prévus pour être codés à l'aide d'entrées de dictionnaires de codage. Ces dictionnaires sont notamment des grammaires dont les entrées sont des productions dans le cadre du codage EXI, des tables d'index dans le cadre du codage Fast Infoset ou tout dictionnaire selon une norme de codage. Pour les besoins d'illustration uniquement, on se concentrera dans la suite sur le codage EXI.

Selon l'invention, on obtient tout d'abord un ensemble d'items devant être codés à l'aide d'une même entrée de dictionnaire de codage; puis on procède au codage desdits items de l'ensemble obtenu en accédant une seule fois à ladite entrée, de sorte à obtenir des items codés. Ce codage de plusieurs items qui peut donc être menée de façon simultanée, consiste à calculer une seule fois la partie commune du codage de chacun des items "similaires" obtenus, et à dupliquer cette partie commune dans l'espace mémoire mémorisant les données codées de chacun de ces items similaires. Ce codage simultané peut toutefois inclure le calcul particulier, pour chaque item, de la partie spécifique de son codage. La façon de coder chacun des items peut cependant rester classique, par exemple conforme au format EXI, de telle sorte que le document codé généré par l'invention peut être lu et exploité par un décodeur classique, par exemple un décodeur EXI. En particulier, pour obtenir les items, on obtient tout d'abord une représentation desdites données structurées, en mémoire d'un encodeur; puis on utilise au moins une instruction de sélection dans ladite représentation hiérarchique de sorte à sélectionner ledit ensemble d'items.

L'obtention d'items similaires, au sens où ils sont destinés à être codés à l'aide de la même entrée de dictionnaire, peut notamment être mise en oeuvre à l'aide de requêtes XPath, bien connues de l'homme de l'art. D'autres langages de requêtes peuvent toutefois être utilisés.

C'est par exemple le cas du langage inhérent à une technologie de représentation des données structurées. Par exemple, lorsqu'une représentation hiérarchique de type arbre DOM est utilisée pour mémoriser les données structurées, il peut s'avérer très efficace d'utiliser les fonctions de navigation au sein de l'arbre DOM. Bien entendu, d'autres types de représentation, par exemple au travers d'une base de données, peuvent être adoptés. Egalement, lorsque le document XML est manipulé par un navigateur Web, on peut utiliser des sélecteurs CSS (pour "Cascading Style Sheets") pour former les instructions de sélection. Ces sélecteurs CSS offrent des fonctionnalités proches de celles offertes par XPath. De plus, comme ceux-ci sont largement utilisés dans les applications Web, leur mise en oeuvre en JavaScript au sein des navigateurs Web est fortement optimisée, garantissant un codage efficace. Dans la suite de la description, on se concentrera plus particulièrement sur l'utilisation des requêtes XPath. Ainsi, dans un mode principal de réalisation de l'invention décrit par la suite, l'obtention des ensembles d'items similaires d'un document XML est réalisée à l'aide d'expressions XPath créées à partir des grammaires EXI. Ces expressions XPath peuvent notamment être formulées de façon absolue. Par exemple, dans le cas de l'élément "firstname", cet item peut être recherché à partir de la racine, à l'aide d'une expression de la forme "//firstname". Cette recherche est toutefois coûteuse à réaliser, puisqu'elle parcourt tout le document XML. Ainsi, pour faciliter l'évaluation des expressions XPath, ces expressions peuvent notamment être formulées de façon relative, c'est-à-dire en permettant de trouver un item à partir de l'item précédent. Par exemple, si l'ensemble des items "person" est déjà obtenu, il est possible d'écrire une requête beaucoup plus simple partant de chacun des ces items, ayant la forme "./firstname". Pour la suite, on adoptera de préférence la forme relative, plus efficace en termes de rapidité de recherche. L'invention s'applique toutefois également lorsque l'on utilise la formulation absolue.

On a représenté sur la figure 1 les étapes principales d'un exemple de codage selon l'invention. Une première partie consiste à obtenir une expression XPath pour sélectionner un ensemble d'items similaires, et une deuxième partie est relative au codage de ces items. On décrira par la suite la création d'une telle expression XPath en lien avec les figures 2 et 3, puis le codage des items en lien avec la figure 4. Selon une première approche possible, ces deux parties peuvent être réalisées lors d'opérations bien distinctes. C'est le cas par exemple lorsque les grammaires EXI sont créées au préalable à partir d'un fichier Schéma EXI. Dans ce cas, on peut créer les expressions XPath nécessaires à l'invention, dès cette phase préalable. Le codage des items consiste ensuite à utiliser ces grammaires pré-établies lorsque l'on code un document structuré. On voit, dans ce cas, que ces grammaires et expressions XPath pré-établies peuvent être utilisées de façon répétée pour le codage de plusieurs documents XML compatibles avec le même fichier Schéma XML. Comme il ressortira de la description ci-après, dans un mode de réalisation de l'invention, au lieu d'effectuer les recherches d'items "similaires" sur un seul document, ces recherches peuvent être réalisées simultanément sur l'ensemble des documents. Ainsi, tous les items similaires des différents documents peuvent être codés simultanément.

Dans ce cas, on veillera toutefois à assurer que chaque item codé est mémorisé dans un flux ou une structure de données correspondant au document auquel il appartient. En variante de la première approche, la construction des expressions XPath et leur utilisation peuvent être réalisées au fur et à mesure du codage du document XML et de la constitution évolutive des grammaires. Cette approche est toutefois moins efficace mais réalisable en l'absence notamment de fichier Schéma XML.

Ces deux approches peuvent également être combinées, par exemple pour un codage EXI en mode déviation permettant aux grammaires pré-établies d'évoluer avec les déviations contenues dans le document XML. Les expressions XPath pré-établies peuvent ainsi être complétées d'autres expressions XPath correspondant aux productions créées lors de l'évolution des grammaires. Pour les besoins d'illustration, on se concentrera plus particulièrement sur la première approche à l'aide de Schémas XML, qui reprend toutefois les mêmes mécanismes que pour les autres approches.

La première étape E100 consiste à obtenir le document XML à coder. Ce document est obtenu, de façon non limitative, sous forme d'arbre DOM. Si le document n'est pas sous forme d'arbre DOM, il est possible d'utiliser un parseur XML pour en créer aisément une représentation sous 15 forme d'arbre DOM. A l'étape E110, une grammaire EXI, notée GRAM, est obtenue; puis l'une des productions, notée PROD, de cette grammaire EXI est obtenue. A noter que cette étape peut comprendre la création de ces grammaires et productions, par exemple à partir d'une description de type Schéma XML du 20 document XML. Ces grammaires et productions peuvent toutefois avoir déjà été générées au préalable à partir de ce fichier Schéma XML. L'étape suivante, E120, consiste alors à constituer et/ou obtenir une instruction de sélection IS sous forme d'expression XPath correspondant à la production obtenue à l'étape E110. L'expression XPath est créée à partir de la 25 production obtenue. L'obtention de cette expression est utile pour réaliser la sélection puis le codage des items similaires correspondant à la production associée. Cette expression XPath a donc pour vocation de permettre la sélection de l'ensemble des items codés par cette production. Ces différents 30 items sont dits "similaires" et présents sous un même item parent ou sous des items parents similaires. Ils présentent également un même type d'item (par exemple 'attribut' AT, 'début d'élément' SE, 'chaîne de caractères' CH, etc.) et éventuellement un même nom qualifié, comme prévu dans le format EXI: par exemple la production SE(firstname) détermine tous les items "firstname" à l'intérieur d'un élément "person", alors que la production SE(*) peut déterminer tous les éléments XML à l'intérieur de l'élément "person".

La création des expressions XPath notamment lors d'un établissement préalable à partir d'un schéma XML, est décrite plus en détail, ci-après en référence aux figures 2 et 3. Il est à noter que les deux étapes E110 et E120 peuvent être réalisées dans un ordre différent.

En particulier, dans un mode préféré, ces deux étapes sont réalisées simultanément : les expressions XPath sont créées préalablement à l'encodage (à partir d'un schéma XML ou d'autres informations renseignant la structure du document) et associées aux grammaires et productions. Ainsi lors de l'obtention d'une production, l'expression XPath associée est obtenue simultanément grâce à cette association préalable. Dans un mode optimisé, les structures correspondant aux grammaires et productions EXI peuvent être remplacées par des structures comportant les expressions XPath associées et des informations nécessaires au codage (par exemple les codes de priorité de la production, les informations nécessaires au codage d'un contenu textuel, etc.). Lors de ce remplacement, les expressions XPath obtenues sont reliées entre-elles en conservant la même structure que celle reliant initialement les grammaires et les productions entre elles. Ainsi dans un tel mode optimisé, l'étape E110 d'obtention de la grammaire/production disparaît au profit d'une simple étape d'obtention d'informations de codage associées à l'expression XPath choisie. Enfin, dans un mode dégradé de l'invention, les expressions XPath sont créées durant le codage à partir des grammaires et des productions. Dans ce mode, l'étape E120 correspond alors à la création de l'expression XPath à partir de la grammaire et de la production courante.

Le traitement de codage se poursuit à l'étape E130 par la recherche effective des items "similaires" en utilisant l'expression XPath obtenue à l'étape E120. Par exemple, on recherche tous les items "firstname" à l'intérieur d'un item "person" courant en utilisant l'expression XPath: "./firstname". A noter que pour une efficacité accrue de l'invention, cette recherche n'est pas limitée à l'item courant, mais est réalisée au niveau de tous les items "similaires" à celui-ci. Dans notre exemple, on recherche donc tous les items "firstname" se réalisant dans n'importe quelle occurrence "person". En d'autres termes, on réalise cette recherche de façon récursive au niveau des items "similaires" obtenus lors d'une ou de plusieurs itérations précédentes. Au sortir de l'étape E130, on dispose donc d'un ensemble d'items "similaires" qui, selon la recommandation EXI, seront codés à l'aide de la même production. Ainsi, à l'étape E140 qui suit, ces items "similaires" obtenus à l'étape E130 sont codés. Dans un premier temps, la priorité correspondant à la production est codée. Ce codage est simultané en ce qu'il est réalisé en accédant une seule fois à la production pour l'ensemble de ces items similaires. Le code renseigné au niveau de cette production est copié dans un espace mémoire alloué à chaque item, également appelé contexte de codage tel que précisé par la suite, mémorisant les données codées de chacun des items.

Puis dans un deuxième temps, si nécessaire, la valeur ou le contenu propre à chaque item est codé dans chaque contexte de codage propre correspondant. On notera qu'il est fréquent que des contenus de plusieurs items soient identiques. Dans ce cas, ce codage simultané des items permet également de déterminer une seule fois les valeurs de codage correspondant à ce contenu identique après avoir identifié toutes les occurrences de chaque contenu. Puis à l'étape E150, les données codées de chacun des items sont intégrées dans le document codé, par concaténation de celles-ci dans l'ordre correspondant des items respectifs à l'intérieur du document. On peut notamment observer que parfois certains autres items du document (situés par exemple entre deux items "similaires") devront être codés avant de pouvoir concaténer l'intégralité des items "similaires" codés à l'étape E140.

Comme on le verra par la suite, cette opération de concaténation consiste sensiblement à concaténer les contextes de codage mémorisant les données codées de chaque item. Afin de traiter l'ensemble des items composant le document XML à coder, on reboucle à l'étape E110 en obtenant une production suivante, non encore traitée. Lorsque l'intégralité des productions de toutes les grammaires a été traitée, l'ensemble des éléments XML du document a été codé et les données codées correspondantes ont été concaténées ensemble pour former le document codé. On décrit maintenant en référence à la figure 2, la création des instructions de sélection IS type expressions XPath. Comme indiqué supra, cette création peut être menée au préalable à partir d'un Schéma XML ou lors de l'étape El 20 au cas par cas lorsqu'elles sont requises.

Cette opération est réalisée pour toutes les entrées (productions) des dictionnaires de codage ou pour tous les types d'items à coder. Pour les besoins d'illustration, on se concentrera sur la création d'expression XPath relatives à des éléments XML. Toutefois, de mêmes traitements pourront être réalisés, si nécessaire avec des adaptations mineures, pour les autres types d'items, par exemple les attributs, les contenus textuels, les commentaires ou les instructions de traitement. Notamment les attributs d'un élément parent XML peuvent être considérés comme une séquence d'éléments particuliers, placée avant le reste du contenu de l'élément parent XML. Par conséquent, ils peuvent être pris en compte en utilisant l'algorithme décrit par la suite en référence à la figure 3 et en insérant les expressions XPath ainsi créées ("./@attribut") aux emplacements idoines avant celles servant à obtenir les éléments enfants contenus dans l'élément parent XML considéré. Plus particulièrement, en ce qui concerne les éléments XML, on obtient, à l'étape E200, un élément XML ou une sous-partie de cet élément courant. En effet, certains éléments XML peuvent avoir des structures relativement complexes, de telle sorte que le présent traitement est récursivement appliqué aux sous-parties successives composant ledit élément XML. Dans un souci de simplification, on se concentrera pour la suite au seul cas d'un élément XML. A l'étape E210, on obtient la structure de l'élément XML courant obtenu à l'étape E200. On entend par structure, l'ensemble des informations, autres que le contenu, relatives aux items composant ledit élément XML courant. Cette structure est, de préférence, obtenue à partir du schéma XML décrivant le document auquel appartient cet élément XML, car cette obtention est rapide et aisée. En variante, elle peut être obtenue à partir des grammaires permettant de coder cet élément XML. Toutefois, cette variante requiert plus de calculs car il est alors nécessaire d'analyser les grammaires correspondant à l'élément XML en utilisant les règles de construction de ces grammaires décrites dans la spécification EXI. Cela revient à reconstruire en partie le schéma XML à partir des grammaires EXI. Une fois ces informations de structure obtenues, on teste (E220), si la structure de l'élément XML courant comprend une répétition d'un ensemble d'éléments enfants ou non. A titre d'exemple, cette information de répétitivité est notamment renseignée dans le Schéma XML, au niveau de la séquence ou du choix décrivant la structure de l'élément XML courant. Dans l'affirmative, le traitement vérifie, à l'étape E230, le type de structure affectée par la répétition, à savoir s'il s'agit d'un "choix" ou d'une "séquence". A noter que le cas où un unique élément enfant est répété est assimilé à une séquence d'un seul élément. Dans le cas d'une séquence, le traitement crée alors une expression XPath permettant d'obtenir l'ensemble des éléments enfants correspondant à celui situé en première position de cette séquence répétée, lors de l'étape E235. Cette expression est associée avec le début de l'élément XML courant considéré, par exemple au niveau de la production codant le premier élément enfant. En outre, un indicateur "multiple" (drapeau binaire par exemple) est associé à cette expression pour indiquer que plusieurs résultats sont susceptibles d'être retournés par cette expression et qu'ils doivent être traités en parallèle. Ainsi, dans le cas d'un élément courant <person>, l'expression XPath est de la forme : "./firstname", pour obtenir l'ensemble des éléments enfants <firstname> (premier élément enfant) contenus dans un quelconque élément <person>. Cette expression est associée avec la production SE(firstname) de la grammaire "person". Dans le cas d'une séquence, le traitement se poursuit à l'étape E240 par la création d'un ensemble d'expressions XPath pour obtenir la suite des éléments enfants composant la séquence. Dans notre exemple, il s'agit par exemple des expressions "./middlename" et "./lastname" permettant de sélection l'élément enfant suivant l'élément enfant courant. Cet ensemble d'expressions est créé comme décrit ci-après en référence à la figure 3. Cet ensemble est notamment associé à l'élément XML considéré à la suite de l'expression créée à l'étape E235. Notamment cette association est réalisée en mémorisant chacune de ces expressions au niveau de la ou des productions correspondantes (tenant compte d'une éventuelle optionalité). On respecte ainsi l'ordre de la séquence. Dans notre exemple, "./middlename" est associé à la ou les productions SE(middlename) et "./lastname" à SE(lastname). Dans le cas d'un "choix" lors de l'étape E230, on poursuit à l'étape E245 par la création d'un ensemble d'expressions XPath pour obtenir tous les éléments enfants contenus dans ce choix. Cette étape est relativement similaire à l'étape E240 décrite en lien avec la figure 3, moyennant quelques adaptations comme décrites ci-après. À chacune de ces expressions créées lors de cette étape E245 est associé un indicateur "multiple" pour indiquer que plusieurs résultats sont susceptibles d'être retournés par chaque expression (en raison de la répétition du choix) et qu'ils doivent être traités en parallèle.

En outre, si l'un des éléments du choix peut être répété, il est traité comme une séquence d'éléments identiques et les expressions XPath correspondant à cet élément sont créées comme décrit ci-après en référence à la figure 3. On réalise ainsi une décomposition de l'élément susceptible d'être répété en une séquence d'éléments identiques. Il est à noter que dans ce cas, seule la première expression XPath se voit associer l'indicateur "multiple". On peut donc noter que l'indicateur "multiple" est renseigné au niveau de toute expression XPath correspondant à un élément susceptible d'être le premier survenant dans une structure (choix ou séquence) répétable. A l'étape E235, on marque le premier élément des séquences répétées; à l'étape E245, on marque tous les éléments d'un choix répété, car chacun d'entre eux est susceptible d'être le premier élément d'une nouvelle occurrence du choix, en notant que si un élément d'un choix peut être répété, seule la première expression XPath le décomposant est marquée. En effet, cette situation de "premier élément" fait que l'expression XPath utilisée va retourner, dans le cas de structures répétées, toutes les occurrences de l'élément visé par cette expression qui constituent le premier élément des structures répétées.

Il y aura donc lieu de traiter ces occurrences de première position de façon séparée, notamment en utilisant des contextes de codage propres comme évoqué par la suite. L'ensemble des expressions XPath obtenues est associé à l'élément XML considéré, par exemple chacune au niveau de la production correspondante dans la grammaire courante. Dans notre exemple, pour l'élément courant <person>, on crée en même temps les expressions "./firstname", "./middlename" et "./Iastname". Dans le cas d'un choix avec un ou des éléments répétés, la première expression XPath obtenue pour le début d'un élément répété est stockée au niveau de la production permettant de coder cet élément en tant que fils du choix, c'est-à-dire au niveau du premier élément de la séquence constitutive de cet élément répété. Les autres expressions XPath sont stockées au niveau des productions correspondant aux autres éléments identiques de la séquence constitutive de l'élément répété.

Ensuite, le traitement se poursuit à l'étape E250 au cours de laquelle on active un indicateur "fusion" au niveau de l'élément XML considéré (notamment au niveau de la grammaire codant cet élément). Cet indicateur permet d'indiquer que, lors du codage, il y aura lieu de fusionner l'ensemble des codages des éléments enfants contenus dans l'élément XML considéré. Cette étape de fusion est rendue nécessaire notamment du fait de la répétition de la structure de l'élément XML considéré et du codage en parallèle, selon l'invention, des différents éléments contenus dans cet élément. En revanche, dans le cas où le contenu de l'élément XML courant ne comprend pas de répétition (sortie "non" du test E220), le traitement vérifie, à l'étape E260, de façon similaire à l'étape E230, le type de structure du contenu de cet élément XML.

Dans le cas d'une séquence, on crée un ensemble d'expressions (étape E265) pour obtenir tous les éléments contenus dans cette séquence, comme décrit par la suite en référence à la figure 3. Cet ensemble de productions est associé à l'élément XML considéré, par exemple chacune au niveau de la ou des productions correspondantes.

Dans le cas d'un choix, on crée un ensemble d'expressions (étape E270 similaire à l'étape E245) pour obtenir tous les éléments contenus dans ce choix. Cet ensemble d'expressions est associé à l'élément XML considéré, par exemple chacune au niveau de la production correspondante. À la différence de l'étape E245, aucun indicateur "multiple" n'est associé à ces expressions.

A noter également que si l'un des éléments du choix ou de la séquence peut être répété, il est traité comme une séquence d'éléments identiques et les expressions XPath correspondant à cet élément sont créées comme décrit ci-après en référence à la figure 3. Comme décrit ci-dessus, l'association d'une ou plusieurs expressions XPath à un élément XML est réalisée de préférence en associant chaque expression XPath à l'une des grammaires décrivant le contenu de l'élément XML, au niveau de la production correspondant à cette expression XPath. Ainsi, l'expression XPath "./firstname" est notamment associée à la production SE (firstname) de la grammaire de l'élément <person>.

En variante toutefois, les expressions XPath peuvent être reliées entre elles dans l'ordre logique de leur enchaînement (c'est-à-dire qu'elles forment une structure similaire à celle des grammaires et des productions auxquelles elles sont associées dans la réalisation préférée décrite précédemment). Puis, à chaque expression XPath sont ajoutées les informations nécessaires au codage des éléments qu'elles sélectionnent. Ces informations sont en particulier le code de la priorité de la production correspondante, les informations nécessaires au codage d'un contenu textuel, etc. En conservant l'ordre logique de leur enchaînement et en ayant les informations de codage, on peut désormais s'affranchir de l'utilisation des grammaires et productions pour coder les éléments XML. Dans ce cas, ces expressions XPath et les informations de codage se substituent aux grammaires et productions créées au préalable. En référence à la figure 3, on décrit maintenant la création d'un ensemble d'expressions relatives à une séquence d'éléments à l'intérieur d'un élément XML courant (ou une sous-partie courante d'élément XML). Il s'agit notamment des étapes E240 et E265.

Puisqu'il s'agit d'une séquence, ce traitement vise à créer une chaîne d'expressions XPath, notée SEQ, permettant de sélectionner tour à tour, dans l'ordre, chacun des éléments XML constituant la séquence. Cette chaîne SEQ d'expressions XPath est liée aux grammaires et productions permettant de coder le contenu de la séquence considérée. Ainsi, chaque expression XPath peut être reliée à une ou plusieurs productions selon que l'élément XML qu'elle vise est optionnel ou non (et donc présent au travers de productions dans plusieurs grammaires). La chaîne SEQ est initialement vide. La première étape E300 consiste à obtenir la séquence d'éléments XML pour laquelle l'ensemble d'expressions XPath est à créer. En même temps, la liste des grammaires utilisées pour le codage de cette séquence est obtenue. Puis, à l'étape E310, le premier élément non traité de la séquence d'éléments XML est obtenu. Bien entendu, on traite les éléments de la séquence dans l'ordre de cette dernière, à savoir que lors de la première itération de cette étape E310, on va traiter le premier élément prévu dans la séquence.

Par ailleurs, la grammaire courante GRAM est obtenue. Lors de la première itération de cette étape, cette grammaire GRAM est la première grammaire utilisée pour le codage de la séquence. Lors des itérations suivantes de l'étape E310, cette grammaire est la grammaire à utiliser après avoir codé l'élément considéré auparavant. Le traitement se poursuit en créant l'expression XPath correspondant à l'élément courant, lors de l'étape E320. Cette expression a pour but de sélectionner l'élément courant à partir par exemple de l'élément qui le précède dans un document XML à coder.

Ainsi dans notre exemple, l'expression XPath créée pour l'élément <firstname> (premier élément enfant de la séquence <person>) est de la forme : "./firstname[) ]". Pour un élément <middlename> après un élément <firstname>, l'expression XPath créée est de la forme : "./following-sibling::middlename[l]".

A noter que "[i]" vise à préciser que l'on souhaite voir retourner la i- ème occurrence de l'élément recherché.. En revanche, dans le cas où la séquence peut être répétée, la création des expressions XPath reste très proche : seule la première expression XPath est modifiée, pour retourner l'ensemble des éléments recherchés. Ainsi, dans l'exemple précédent, l'expression devient : "./firstname", laquelle va permettre d'obtenir tous les débuts de répétition de la séquence de sorte à créer un contexte de codage propre à chacune de ces répétitions. L'expression ainsi créée est alors ajoutée (toujours lors de l'étape E320) à l'ensemble SEQ d'expressions XPath créées pour traiter la séquence d'éléments XML considérée. Cette expression XPath est en outre reliée à la grammaire courante GRAM, au niveau de la production correspondant à l'élément courant: par exemple "./firstname[l]" est reliée à SE(firstname) de la grammaire courante.

En outre, cette expression XPath est aussi reliée à l'ensemble des grammaires utilisées pour le codage de la séquence et qui ont été mémorisées comme points d'option lors d'une étape E350 exécutée au préalable et décrite ci-après. Ce lien est également réalisé au niveau de la production correspondant à l'élément courant, soit SE(firstname) pour une expression du type "./firstname". Cette approche permet de relier cette expression XPath à l'ensemble des contextes dans lesquels l'élément qu'elle sélectionne peut survenir. En effet, un élément XML pouvant être optionnel, il en découle, pour un même élément suivant, plusieurs productions dans plusieurs grammaires. En poursuivant le traitement, on teste à l'étape E330 si l'élément courant est optionnel ou non. Dans la négative, l'ensemble des grammaires mémorisées comme points d'option est réinitialisé à l'ensemble vide, lors de l'étape E340. Ceci permet, lors de l'exécution suivante de l'étape E320, d'indiquer qu'il n'existe pas d'autre production (outre celle de la grammaire courante) à laquelle il convient d'associer également l'expression XPath, pour tenir compte de l'optionalité de l'élément XML.

Dans la négative, la grammaire courante est ajoutée à la liste des grammaires mémorisées comme points d'option, lors de l'étape E350. En effet, comme l'élément courant est optionnel, d'autres éléments que lui-même peuvent survenir dans le contexte de la grammaire courante. Cela signifie que la grammaire courante comprend plusieurs productions représentant les différents éléments pouvant survenir. Il est alors utile d'associer à chacun de ces éléments une expression XPath permettant de le sélectionner. Suite aux étapes E340 et E350, on poursuit en vérifiant (test E360) s'il reste des éléments à traiter dans la séquence. Si c'est le cas, on traite l'élément suivant en retournant à l'étape E310.

Il est à noter que si un élément de la séquence peut être répété, il est considéré comme autant d'éléments distincts de cette séquence (tenant compte du nombre maximum de répétitions autorisées), certaines occurrences de cet élément pouvant être optionnelles (celles au-delà du nombre minimum de répétitions autorisées).

Ainsi, pour un élément ayant au minimum 3 occurrences et au maximum 5 occurrences, la séquence est traitée comme ayant 5 occurrences de cet élément, les deux dernières étant optionnelles.

Lors du traitement d'un élément répété, une même expression XPath n'est pas associée plusieurs fois à une même production. Lors de l'étape E320, on vérifie que c'est le cas. Dans un souci d'optimisation, un élément répété peut être traité de manière particulière. En considérant un élément "elem" répété au minimum rmin fois et au maximum rmax fois, l'algorithme est modifié de la façon suivante. Lors du parcours de la séquence, l'algorithme considère d'abord la première occurrence de l'élément. Cette occurrence est traitée normalement et permet d'obtenir une expression XPath retournant, dans le cas de structures répétées, toutes les occurrences de l'élément visé par cette expression qui constituent le premier élément des structures répétées. Puis l'algorithme considère les occurrences de 2 à rmin de l'élément. Il crée pour ces occurrences une expression XPath particulière : "./followingsibling::elem[position()>=1 and position()<rmin]". Cette expression XPath permet de sélectionner toutes les occurrences de 2 à rmin en partant d'un premier élément "elem" courant sélectionné à l'aide de l'expression XPath pour la première occurrence de l'élément. Cependant, ces occurrences correspondent à des productions dans des grammaires différentes. L'expression XPath est associée à la production correspondant à l'occurrence rmin de cet élément.

D'autre part, la production correspondant à l'occurrence 1 de cet élément est modifiée pour indiquer comme grammaire suivante celle correspondant à l'occurrence rmin. Cela permet en effet de réduire le nombre d'expressions XPath utilisées, et donc d'éviter l'exécution répétée d'une même expression XPath.

Il est à noter que si rmin vaut 1, cette étape n'est pas réalisée. Enfin, l'algorithme considère les occurrences de rmin+1 à rmax de l'élément. Il crée pour ces occurrences une expression XPath particulière : "./following-sibling::elem[position()>=1 and position()<rmax-rmin]". Cette expression XPath permet de sélectionner toutes les occurrences de rmin+1 à rmax de l'élément en s'assurant que l'on n'a pas plus d'occurrences que le maximum rmax autorisé. Comme pour l'étape précédente, ces occurrences correspondent à des productions dans des grammaires différentes.

L'expression XPath est associée à la production correspondant à l'occurrence rmin+l de l'élément et cette production est modifiée pour indiquer comme grammaire suivante celle correspondant à l'occurrence rmax. Il est à noter que si rmax est infini, il y a une seule production pour toutes les occurrences à partir de rmin+l. Dans le cas où les expressions XPath sont associées aux grammaires, le traitement optimisé des éléments répétés dans une séquence nécessite de modifier les grammaires. Cependant, dans la variante de mise en oeuvre où les expressions XPath sont reliées entre elles directement, cette optimisation se met en place sans changement additionnel. Enfin, s'il ne reste pas d'élément à traiter, le traitement se termine en E370. Pour illustrer ces traitements à l'aide de notre exemple précédent portant sur la séquence <person> avec l'élément <middlename> optionel, les 15 expressions XPath créées et associées à ces grammaires sont les suivantes : ElementContentl : SE (firstname) ElementContent2 0 "./firstname[l]"

ElementContent2 : 20 SE (middlename) ElementContent3 0 "./following-sibling::middlename[1]" SE (lastname) ElementContent4 1 "./following-sibling::lastname[1 ]"

ElementContent3 : SE (lastname) ElementContent4 0 "./following-sibling::lastname[1 ]" ElementContent4 : EE 0

La création des expressions XPath et leur association aux 30 grammaires et productions, dans le cas d'un "choix" d'éléments, sont notamment simplifiées comparé au traitement de la figure 3. Pour rappel, cela concerne les étapes E245 et E270. 25 L'adaptation prévue sur ce traitement consiste à ce qu'une expression XPath est créée pour chaque élément du choix et est ensuite associée à la production représentant cet élément dans la grammaire représentant le choix. En effet, le choix n'entraînant la création que d'une seule grammaire, il n'y a pas lieu de traiter, à ce stade, la notion d'optionalité. Par contre, le traitement d'un élément répété à l'intérieur de ce choix, est traité par l'algorithme de la figure 3, comme indiqué en référence à l'étape E245. L'optimisation décrite ci-dessus pour les éléments répétés peut lui être appliquée.

Enfin, si l'un des sous-éléments d'une séquence ou d'un choix et lui-même une séquence ou un choix, il est traité récursivement par l'algorithme de la figure 2. On décrit maintenant, en référence à la figure 4, le codage d'un élément XML, par exemple <person>, à partir des expressions XPath créées comme décrit ci-dessus. On commence, à l'étape E400, par l'obtention d'une grammaire permettant le codage d'une partie de l'élément XML. Pour des raisons de concision, une seule grammaire est considérée dans la suite de la description. Toutefois, dans la pratique, plusieurs grammaires sont utilisées pour le codage de l'ensemble de l'élément XML et sont donc considérées tour à tour, dans l'ordre du document XML. Comme déjà introduit précédemment, on associe, à l'élément XML courant ou à la grammaire servant à coder cet élément, un "contexte de codage" destiné à recevoir les données codées de cet élément. Ainsi, le contexte de codage associé à un élément et le contexte de codage associé à une grammaire visent un même contexte de codage si la grammaire sert à coder cet élément. Ce contexte de codage comprend notamment une localisation dans le document XML à coder, qui correspond au dernier élément codé dans ce contexte, et à un espace mémoire contenant l'ensemble des données déjà codées dans ce contexte.

Lors du démarrage du codage du document, un nouveau contexte est créé, dont la localisation est le début du document et ne contenant aucune donnée codée. De façon optionnelle, ce contexte initial peut contenir les données codées correspondant à l'en-tête du document codé. Lors du codage de l'élément XML, ce contexte peut contenir l'ensemble des données codées des éléments XML le précédant dans le document. A noter également, comme on le verra ci-après que si plusieurs éléments XML "similaires" existent, alors chacun dispose de son propre contexte de codage.

Dans le présent traitement, à l'étape E410, le ou les contextes de codage associés à cette grammaire courante sont obtenus. Comme il s'agit de la grammaire codant l'élément <person>, les contextes de codage obtenus sont ceux associés aux items <person> similaires, c'est-à-dire aux différentes occurrences de cet élément <person>.

A l'étape E420, une production PROD de la grammaire courante GRAM et l'expression XPath associée sont obtenues. La production décrit notamment un élément enfant de l'élément XML à coder. A l'étape E430, l'expression XPath obtenue à l'étape E420 est exécutée pour chacun des contextes de codage, c'est-à-dire en prenant comme élément de base pour l'évaluation de l'expression en mode relatif, chacun des items similaires correspondants. Ceci permet d'obtenir, pour chaque contexte de codage (dans notre exemple pour chaque occurrence d'un élément <person> similaire), les éléments enfants similaires codés par la production considérée.

Il est à noter que si l'expression XPath ne retourne aucun résultat, l'algorithme se poursuit directement à l'étape E460. On teste alors (E440) si, pour la requête XPath, plusieurs résultats sont retournés, ce qui signifierait que plusieurs éléments enfants similaires sont identifiés.

Dans l'affirmative, un nouveau contexte de codage (vide à cet instant) est créé pour chacun de ces résultats ou éléments similaires identifiés (étape E445).

Ce test sert à vérifier si l'expression XPath correspond à un élément enfant unique ou à une séquence d'éléments enfants pouvant être répétée. On dispose ainsi d'un contexte de codage associé à l'élément parent (contexte de codage parent) et un contexte de codage associé à chacun des éléments enfants similaires (contextes de codage enfants). En outre, chacun de ces nouveaux contextes de codage a pour parent le contexte de codage de l'élément parent, c'est-à-dire celui dans lequel l'expression XPath a été exécutée. Dans cette configuration, chaque nouveau contexte de codage permet de mémoriser de façon temporaire une partie du codage qui sera intégré au final dans le contexte de codage parent. Ainsi, dans l'exemple précédent, lors de l'exécution de la requête permettant d'obtenir les éléments <person> appartenant à un élément <list>, chaque nouveau contexte de codage sert à coder un unique élément <person> et l'ensemble de ces nouveaux contextes de codage est rattaché au contexte de codage de l'élément <list> pour permettre la fusion finale du codage de tous les éléments <person> au sein du codage de l'élément <st>. A noter que s'il existe plusieurs éléments <st>, chacun de ces éléments <st> a son propre contexte de codage. Lors de la création des contextes de codage enfants pour les éléments <person>, chaque contexte de codage enfant est rattaché au contexte de codage de l'élément <list> qui contient l'élément <person> correspondant. Dans la négative du test E440, le contexte de codage parent peut être propagé à l'élément enfant retourné, notamment si cet élément enfant est l'élément suivant à coder (déterminable par la localisation indiquée dans le contexte de codage parent). Cette propagation peut simplement consister à désormais associer ce contexte de codage à l'élément enfant retourné. En variante, un contexte de codage propre à l'élément enfant retourné peut également être créé, auquel cas il conviendra également de prévoir une fusion des contextes de codage parent et enfant.

Le traitement se poursuit alors à l'étape E450 où l'on procède au codage effectif de chaque élément retourné par la requête XPath. Le codage des éléments enfants peut être simple comme décrit ci-après ou mettre en oeuvre récursivement les traitements de la figure 4, si ces éléments enfants sont eux-mêmes constitués de sous-éléments. Notamment, les éléments retournés comprennent des informations communes qui sont codées de la même façon, et des informations particulières.

S'agissant des informations communes, le codage selon l'invention peut être réalisé simultanément pour le ou les éléments similaires retournés, par exemple en inscrivant directement, dans chacun des contextes de codage associés à ces éléments similaires, la priorité correspondant de la production considérée. Bien entendu, d'autres valeurs de codage communes peuvent être mémorisées simultanément dans l'ensemble des contextes de codage enfants. L'information de localisation est alors mise à jour. La partie du codage commune à l'ensemble des éléments retournés est donc réalisée une seule fois; le codage est ainsi optimisé. Par ailleurs, on code chaque information particulière dans le contexte de codage correspondant, en utilisant les techniques classiques de codage, par exemple conformément à la recommandation EXI. On note toutefois que, si deux éléments similaires ont le même contenu, on procède simultanément au codage de ce dernier pour ces deux éléments, en accédant aux dictionnaires de codage ou en calculant les données de codage qu'une seule fois pour ces deux éléments. Dans le cas où l'indicateur "multiple" n'est pas associé à l'expression XPath utilisée, et si plusieurs contextes de codages ont été créés à l'étape E445, ces contextes sont fusionnés dans leur contexte parent. Ceci correspond en effet au cas d'un élément répété au sein d'une séquence ou d'un choix, à l'exclusion du premier élément répété qui dispose, lui, d'une expression XPath dédiée soit marquée "multiple" (cas du choix répété) soit ne retournant qu'un seul résultat (autres cas). Dans une variante, pour optimiser le codage, si l'indicateur "multiple" n'est pas associé à l'expression XPath utilisée, l'étape E445 n'est pas réalisée et le codage des différents éléments est mémorisé directement dans le contexte courant, en respectant l'ordre de codage des éléments répétés. Cette mémorisation peut être réalisée en propageant le contexte courant entre ces différents éléments en respectant ledit ordre de codage. Après le codage effectif, on vérifie, à l'étape E460, s'il reste une production non traitée dans la grammaire. Dans l'affirmative, la production suivante est traitée en retournant à l'étape E420. L'ordre de parcours des productions dépend du type de structure de l'élément XML (ou de sa sous-partie courante). Dans le cas d'un choix, toutes les productions sont parcourues de manière séquentielle. Dans le cas d'une séquence, les productions correspondant à des éléments optionnels sont parcourues en premier. Dans la négative de l'étape E460, on passe à l'étape E470 consistant à vérifier si une fusion des contextes de codage est requise, c'est-à-dire si l'indicateur "fusion" renseigné lors de l'étape E250 est actif au niveau de l'élément XML à coder ou de la grammaire codant celui-ci. A noter qu'une étape de fusion correspond à la fin d'une séquence répétée ou d'un choix répété. En cas de vérification positive (fusion requise), on fusionne (étape E475) les contextes de codage enfants ainsi obtenus pour la grammaire avec leurs contextes de codage parents. Pour cela, pour chaque contexte de codage parent, l'ensemble de ses contextes de codage enfants est considéré. Les données de codage contenues dans ces contextes de codage enfants sont concaténés, dans l'ordre du document s'ils sont consécutifs, et le résultat concaténé est ajouté au contexte de codage parent. Puis, la localisation renseignée dans le contexte de codage parent devient celle du dernier contexte de codage enfant ajouté, dans l'ordre du document. Après cette étape de fusion ou en cas de vérification négative, les contextes de codage sont mis à jour (étape E480), d'une part en mettant à jour leur localisation qui devient celle du dernier élément codé qu'ils contiennent, et d'autre part, en les propageant à l'élément suivant par association à la grammaire suivante. Cette grammaire suivante dépend de la production correspondant au dernier élément codé dans le contexte de codage.

Cette mise à jour permet de propager les contextes de codage d'élément en élément (voire d'élément enfant en élément enfant) et ainsi de constituer progressivement et par morceaux le document EXI codé. Dans le cas d'une séquence non répétée, le contexte de codage parent est ainsi propagé successivement à chacun des éléments enfants codés. Pareillement, à la fin du codage d'une séquence ou d'un choix, le contexte de codage parent (contenant alors l'ensemble des données de codage de cette séquence ou de ce choix) est propagé vers l'élément XML faisant suite à celui qui vient d'être codé par la séquence ou le choix. Le traitement de la figure 4 est alors répété pour la grammaire courante suivante, et ainsi de suite. Comme illustré par cet exemple, l'invention permet ainsi de conduire un codage parallèle d'items similaires. On constitue ainsi des morceaux codés du document à coder pour diverses portions de ce document, puis progressivement ces morceaux codés sont concaténés pour former au final le document codé. Une information localisant ces portions dans le document permet d'assurer une concaténation efficace en respectant l'ordre des items dans le document.

On peut notamment utiliser l'invention dans tous les cas où un document XML est contenu entièrement en mémoire et doit être codé au format EXI. C'est par exemple le cas pour un éditeur de document XML, ou un éditeur spécialisé pour un langage XML particulier comme XHTML ou SVG. Dans un tel cas, si l'éditeur n'utilise qu'une partie du langage XML particulier, l'ensemble des grammaires et des expressions XPath utilisées lors de la mise en oeuvre de l'invention peut être simplifié en ne conservant que celles correspondant à la partie du langage XML mise en oeuvre dans l'éditeur. Ceci est particulièrement utile pour un éditeur SVG qui généralement n'utilisera qu'une seule représentation pour une forme graphique particulière parmi toutes celles offertes par SVG. Cette optimisation s'applique plus facilement dans la variante de mise en oeuvre où les grammaires sont supprimées et les expressions XPath sont reliées entre elles : il suffit alors de ne conserver que les expressions XPath correspondant à la partie du langage XML mise en oeuvre. Cette optimisation peut être mise en oeuvre dans d'autres cas d'utilisation où seule une partie d'un langage XML est utilisée.

Un autre exemple est le cas d'un serveur web qui génère des données XML comme par exemple des flux ATOM, RSS ou FeedSync. Dans ce dernier cas, il est possible de considérer chaque entrée du flux comme un document indépendant et de coder, à l'aide de la présente invention, plusieurs entrées comme plusieurs documents.

C'est uniquement lors de la génération même du flux que les entrées codées sont fusionnées. Ainsi, il est facile de générer plusieurs flux différents à partir des mêmes entrées. Cela permet d'optimiser la génération de flux différents encodés au format EXI au niveau du serveur de flux. Par exemple dans le cas d'un serveur de nouvelles proposant plusieurs catégories de nouvelles, un premier flux peut contenir toutes les nouvelles, un autre flux les nouvelles sportives, un troisième les nouvelles politiques, un autre encore les nouvelles internationales, etc. Ainsi, une nouvelle, représentée par une entrée dans un flux, est présente dans au moins deux flux sinon plus.

Dans un tel cas, l'utilisation de l'invention pour coder chaque entrée (c'est-à-dire chaque nouvelle) séparément permet non seulement d'optimiser le codage en codant plusieurs entrées simultanément, mais aussi d'éviter de coder plusieurs fois une même nouvelle. Une application privilégiée de l'invention est celle du codage d'un document présentant une même structure régulièrement répétée: à titre d'exemple, un document dans lequel un élément <person> a une structure régulière qui est répétée au sein d'un élément <st>. Toutefois, dans le cas où seule une partie d'un document XML présente une structure régulière, il est possible de n'appliquer l'invention qu'à cette partie du document XML. Ainsi, pour chaque partie du document XML, la méthode de codage la plus efficace peut être utilisée. Par exemple, si l'élément <st> est précédé d'un en-tête décrivant à quoi correspond cette liste, il peut s'avérer efficace de coder cet en-tête de manière classique, et de n'appliquer l'invention qu'au contenu de l'élément <st>. La présente invention peut également être mise en oeuvre en combinaison avec des techniques de codage améliorée qui mémorisent directement et de façon temporaire, dans l'arbre DOM stockant le document XML à coder, des informations de codage ou d'indexation de tout ou partie des éléments XML. En effet, dans ce cas, l'invention permet de coder efficacement les éléments répétés dans le document XML, alors que les autres éléments sont 10 codés de manière classique. La cohabitation des deux méthodes de codage est possible du fait que le codage de chaque élément n'est pas mémorisé directement dans le document EXI, mais de façon temporaire au niveau de chaque élément dans l'arbre DOM. 15 C'est par exemple le cas pour le codage d'un document SVG dont la structure est généralement irrégulière car dépendant du contenu graphique qu'il représente. Toutefois, comme un tel document SVG contient souvent de nombreuses occurrences d'un même élément (en effet les primitives graphiques utilisées sont représentées par des éléments), il s'avère intéressant 20 d'utiliser la présente invention pour coder simultanément une partie de toutes ces occurrences : les expressions XPath permettent d'obtenir directement les éléments fréquents contenus dans le document SVG; ces éléments sont alors codés simultanément comme décrit dans l'invention, et leur codage est mémorisé au niveau de l'arbre DOM du document SVG. 25 Pour générer le document codé EXI, il suffit alors de parcourir l'arbre DOM, en codant si nécessaire les éléments non codés au niveau de l'arbre. Enfin, la présente invention peut également tirer profit du mode compression (type DEFLATE) proposé par la recommandation EXI. Pour rappel, dans ce mode, les valeurs de contenu (texte, etc.) sont codées 30 séparément de la structure du document pour obtenir un meilleur taux de compression. En particulier, le codage de ces valeurs propose un regroupement de celles-ci en canaux de valeurs en fonction du nom qualifié de l'élément auquel elles se rapportent. Lors du codage, tel que décrit en référence à la figure 4, seule la structure est codée.

On peut prévoir alors de créer une expression XPath définie pour obtenir l'ensemble des contenus des éléments similaires (donc rattachés à un même nom qualifié notamment) : il suffit de construire cette expression XPath à partir de celle ayant permis d'obtenir l'élément considéré et en la généralisant pour qu'elle obtienne l'ensemble des éléments et non plus un seul élément. Ces expressions XPath sont ensuite mémorisées. Quand l'ensemble de la structure du document est codé, ces expressions XPath sont alors utilisées pour obtenir les valeurs à coder. Puis, ces valeurs sont codées comme décrit par la spécification EXI. L'ordre à respecter pour le codage de ces valeurs est aisé à mettre en oeuvre en ordonnançant les expressions XPath en fonction de cet ordre de codage (notamment selon l'ordre d'apparition des noms qualifiés au sein du document à coder). Par cette adaptation, on évite, lors de la mise en oeuvre du mode compression, de mémoriser l'ensemble du codage des valeurs et on obtient ainsi directement les valeurs dans l'ordre dans lequel elles doivent être codées. En référence maintenant à la figure 5, il est décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de traitement apte à une mise en oeuvre du procédé de codage 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 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 selon l'invention comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, relié à une carte d'entrée/sortie (non représentée) et fournissant au dispositif des données multimédia, éventuellement sous forme de documents XML ou SVG. 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. Il peut s'agir d'une mémoire flash ou EEPROM ; - une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention nécessaires à la mise en oeuvre de l'invention. Cette mémoire vive 54 est de type RAM (à accès aléatoire), ce qui offre des accès rapide comparés à la mémoire morte 53 ; - un écran 55 permettant de visualiser des données notamment vidéo et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - un lecteur de disquettes 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 63 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 50 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50. Les disquettes 63 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de traitement, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

Le code exécutable permettant, au dispositif de traitement, la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 58 par exemple) avant d'être exécuté. L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC).

Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 1 à 4, pour mettre en oeuvre les procédés objets de la présente invention et constituer les dispositifs objets 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 (22)

1. REVENDICATIONS1. Procédé de codage de données structurées composées d'items, au moins un item étant codé à l'aide d'une entrée d'un dictionnaire de codage, le procédé étant caractérisé en ce qu'il comprend les étapes consistant à : - obtenir (E130, E430) un ensemble d'items devant être codés à l'aide d'une même entrée (PROD) d'un dictionnaire de codage (GRAM) ; et - procéder au codage (E140, E450) desdits items de l'ensemble obtenu en accédant une seule fois à ladite entrée, de sorte à obtenir des items codés.
2. 2. Procédé de codage selon la revendication 1, dans lequel l'étape d'obtenir un ensemble d'items comprend les étapes consistant à : - obtenir (E100) une représentation desdites données structurées, 15 en mémoire ; - utiliser au moins une instruction de sélection (IS) dans ladite représentation hiérarchique de sorte à sélectionner ledit ensemble d'items.
3. 3. Procédé de codage selon la revendication 2, dans lequel ladite au moins une instruction de sélection est une expression XPath. 20
4. 4. Procédé de codage selon la revendication 2, dans lequel ladite représentation est hiérarchique et repose sur une technologie offrant des commandes de navigation au sein de ladite représentation hiérarchique, et ladite au moins une instruction de sélection comprend au moins une dite commande de navigation. 25
5. 5. Procédé de codage selon l'une des revendications 2 à 4, dans lequel ladite instruction de sélection (IS) est formée à partir d'un fichier de description de structure de document, préalablement au codage des données structurées.
6. 6. Procédé de codage selon la revendication 5, comprenant une 30 étape consistant à associer, en mémoire, ladite instruction de sélection d'items à ladite entrée codant ces items.
7. 7. Procédé de codage selon la revendication 6, dans lequel on associe, en mémoire, ladite instruction de sélection d'items à d'autres entrées d'autres dictionnaires de codage, ces autres entrées codant le même type d'item que ladite entrée.
8. 8. Procédé de codage selon l'une des revendications 2 à 4, dans lequel ladite instruction de sélection est créée lors de l'encodage de la première occurrence des items devant être codés à l'aide de ladite entrée de dictionnaire de codage.
9. 9. Procédé de codage selon l'une des revendications 2 à 8, dans lequel ladite au moins une instruction de sélection (IS) se substitue, lors de sa formation, à ladite entrée (PROD) du dictionnaire de codage (GRAM), et on associe, à ladite instruction de sélection, des informations de codage.
10. 10. Procédé de codage selon la revendication 9, dans lequel le procédé met en oeuvre une pluralité d'instructions de sélection se substituant à une pluralité d'entrées de dictionnaire de codage, la pluralité d'entrées formant initialement une structure ordonnée, et lesdites instructions de sélection après substitution sont reliées entre elles en conservant ladite structure ordonnée.
11. 11. Procédé de codage selon l'une des revendications précédentes, comprenant une étape consistant à concaténer (E150, E475) des items codés selon leur ordre au sein des données structurées.
12. 12. Procédé de codage selon la revendication 11 en dépendance de la revendication 2, dans lequel un contexte de codage est associé à un item parent, ledit contexte de codage étant configuré pour recevoir au moins les données correspondant à l'item parent codé, et le procédé comprend : - une étape d'exécution (E430) d'une instruction de sélection (IS) d'un item enfant à l'intérieur de l'item parent, et - si l'instruction de sélection retourne plusieurs items enfants (E440), une étape de construction (E445) d'un contexte de codage propre pour chacun des items enfants, le codage de chaque item enfant remplissant le contexte de codage correspondant avec les données correspondant à l'item enfant codé.
13. 13. Procédé de codage selon la revendication 12, dans lequel ledit codage en accédant une seule fois à ladite entrée (E140, E450) comprend la recopie, dans chacun des contextes de codage propres aux items enfants, d'une même donnée codée obtenue au niveau de ladite entrée.
14. 14. Procédé de codage selon la revendication 12 ou 13, comprenant, lorsque lesdits items enfants sont codés, une étape consistant à concaténer (E475) le contexte de codage associé à l'item parent avec les contextes de codage associés aux items enfants, en fonction de l'ordre desdits items enfants au sein des données structurées.
15. 15. Procédé de codage selon l'une des revendications 12 à 14, dans lequel si un item enfant est susceptible d'être répété dans la structure d'un item parent, le procédé comprend : - une étape de décomposition de l'item enfant susceptible d'être répété en une séquence d'items enfants identiques, - une étape d'association d'une instruction de sélection d'items (IS) au premier des items enfants identiques dans ladite séquence et d'au moins une instruction de sélection d'items aux autres items enfants identiques, - si l'exécution (E430) de l'au moins une instruction de sélection associée aux autres items enfants identiques retourne plusieurs items enfants (E440), une étape de propagation d'un contexte de codage associé audit premier item enfant en l'associant successivement à chaque item enfant retourné en respectant l'ordre desdits items enfants dans les données structurées.
16. 16. Procédé de codage selon l'une des revendications 12 à 15, comprenant, si l'instruction de sélection retourne un seul item enfant, une étape de propagation dudit contexte de codage associé à l'item parent en l'associant à l'item enfant retourné.
17. 17. Procédé de codage selon l'une des revendications 12 à 16, dans lequel un contexte de codage comprend une indication du dernier item codé qu'il code.
18. 18. Procédé de codage selon l'une des revendications précédentes, dans lequel ledit ensemble des items obtenus et codés enaccédant une seule fois à ladite entrée comprend des items provenant de plusieurs documents structurés.
19. 19. Dispositif de codage de données structurées composées d'items, au moins un item étant codé à l'aide d'une entrée d'un dictionnaire de 5 codage, caractérisé en ce qu'il comprend : - un moyen pour obtenir un ensemble d'items devant être codés à l'aide d'une même entrée (PROD) d'un dictionnaire de codage (GRAM) ; et - un moyen de codage configuré pour coder lesdits items de l'ensemble obtenu en accédant une seule fois à ladite entrée, de sorte à obtenir 10 des items codés.
20. 20. Dispositif selon la revendication 19, comprenant des dictionnaires de codage composés d'entrées codant chacune un type d'items, une instruction de sélection étant associée à chacune des entrées pour sélectionner des items dudit type correspondant à l'entrée. 15
21. 21. Moyen de stockage d'informations, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de codage conforme à l'une quelconque des revendications 1 à 18 lorsque le programme est chargé et exécuté par le système informatique. 20
22. 22. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de codage selon l'une quelconque des revendications 1 à 18, lorsqu'il est chargé et exécuté par le microprocesseur.