FR2941803A1 - Procede de transcodage d'un document code, et dispositif associe - Google Patents

Procede de transcodage d'un document code, et dispositif associe Download PDF

Info

Publication number
FR2941803A1
FR2941803A1 FR0900436A FR0900436A FR2941803A1 FR 2941803 A1 FR2941803 A1 FR 2941803A1 FR 0900436 A FR0900436 A FR 0900436A FR 0900436 A FR0900436 A FR 0900436A FR 2941803 A1 FR2941803 A1 FR 2941803A1
Authority
FR
France
Prior art keywords
input
dictionary
coding
document
transcoding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0900436A
Other languages
English (en)
Other versions
FR2941803B1 (fr
Inventor
Herve Ruellan
Youenn Fablet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0900436A priority Critical patent/FR2941803B1/fr
Publication of FR2941803A1 publication Critical patent/FR2941803A1/fr
Application granted granted Critical
Publication of FR2941803B1 publication Critical patent/FR2941803B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84Mapping; Conversion
    • G06F16/88Mark-up to mark-up conversion
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database

Abstract

La présente invention concerne un procédé et un dispositif associé de traitement pour le transcodage d'un document codé (100), notamment d'un document structuré, par exemple de type XML (acronyme de "Extensible Markup Language" pour langage de balisage extensible). Le procédé comprenant les étapes suivantes : - l'identification (E210, E510), dans un dictionnaire de décodage (300, 400), d'une première entrée (301...305, 401...404) correspondant à une donnée codée, - l'identification (E220, E540), dans un dictionnaire de codage (310, 410), d'une deuxième entrée (311...315, 411) afin d'obtenir une valeur de codage (140) pour transcoder (E230, E550) ladite donnée codée, procédé dans lequel ladite deuxième entrée (311...315, 411 ) est directement déterminée depuis ladite première entrée (301...305, 401...404) à partir d'une indication (350) reliant lesdites deux entrées. L'invention s'applique en particulier aux formats binaires, type EXI ou Fast Infoset, pour passer d'un premier jeu d'options de codage à un second jeu d'options de codage.

Description

La présente invention concerne un procédé et un dispositif associé de traitement pour le transcodage d'un document codé, notamment d'un document structuré, par exemple de type XML (acronyme de "Extensible Markup Language" pour langage de balisage extensible). Le langage XML est une syntaxe pour définir des langages informatiques. XML permet ainsi de créer des langages adaptés à des utilisations différentes mais pouvant être traités par les mêmes outils. Un document XML est composé d'éléments, chaque élément commençant par une balise ouvrante comportant le nom de l'élément (par exemple: <balise>) et se terminant par une balise fermante comportant, elle aussi, le nom de l'élément (par exemple: </balise>). Chaque élément peut contenir d'autres éléments de façon hiérarchique, constituant une structure hiérarchique de données, ou des données textuelles. D'autre part, un élément peut être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple : <balise attribut="valeur">). La syntaxe XML permet aussi de définir des commentaires (par exemple: <!-- Commentaire-->) et des instructions de traitement, qui peuvent préciser à une application informatique les traitements à appliquer au document XML (par exemple : <?montraitement?> ), ainsi que des sections d'échappement qui permettent d'éviter qu'une section de texte soit interprétée comme une balise lorsqu'elle en a la forme (par exemple : <![CDATA[<texte>Echappement</texte>]]> où <texte> est reconnu comme une chaîne de caractère et non pas une balise).
Dans la terminologie XML, l'ensemble des termes élément (identifié par une balise ouvrante et une balise fermante), attribut , donnée textuelle , commentaire , instruction de traitement et section d'échappement définissant les données XML sont regroupés sous le nom générique de item . Pour permettre l'utilisation de plusieurs langages différents basés sur la syntaxe XML et pouvant contenir des éléments de même nom, un ajout a été effectué à la syntaxe XML pour définir des espaces de nommage ( Namespace selon la terminologie anglo-saxonne). Un espace de nommage est défini par une URI (acronyme de Uniform Resource Identifier , pour Identifiant uniforme de ressource) auquel on associe un préfixe, ce dernier précédent chaque itération d'un élément issu de cet espace de nommage: par exemple, <ml:balise ml:attribut="valeur"> indique que l'élément balise appartient à l'espace de nommage ml et qu'il en est de même pour l'attribut attribut. Le format XML présente de nombreux avantages et est devenu un standard pour stocker des données dans un fichier ou pour échanger des données. XML permet en particulier de disposer de nombreux outils pour traiter les fichiers générés. Par ailleurs, un document XML peut être édité manuellement avec un simple éditeur de texte. En outre, comme un document XML contient sa structure intégrée aux données, ce document est très lisible même sans en connaître la spécification.
Toutefois, le principal inconvénient de la syntaxe XML est d'être très prolixe, amenant parfois la taille d'un document XML à être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi un temps de traitement important lors de la génération et surtout de la lecture de documents XML.
Pour remédier à cet inconvénient, de nouvelles méthodes pour encoder un document XML ont été recherchées. Le but de ces méthodes est de coder le contenu du document XML sous une forme plus compacte, mais permettant de reconstruire facilement le document XML. Une méthode simple consiste par exemple à remplacer les items 30 XML par des symboles. D'autres méthodes plus évoluées existent, notamment les formats XML Binaire, parmi lequel on connaît le format EXI ("Efficient XML lnterchange") ou le format Fast Infoset, permettant de conserver nombre d'avantages du format XML malgré le codage. Ainsi, par exemple, le format EXI, en cours de standardisation au sein du W3C, permet de coder un document XML sous une forme binaire. Ce format utilise des dictionnaires pour coder les différentes parties d'un document XML. Certains de ces dictionnaires sont dits "globaux" en ce qu'ils concernent le codage de l'ensemble du document, par exemple le dictionnaire de vocabulaire pour le codage des URI.
D'autres dictionnaires sont dits "locaux" : par exemple, à chaque URI est associé un dictionnaire de vocabulaire pour les noms locaux d'éléments ("element local name"). De manière similaire, à chaque nom qualifié d'attribut ("attribute qualified name") est associé un dictionnaire de valeurs. Un dictionnaire local est ainsi utilisé uniquement lorsque l'URI, le nom qualifié d'attribut, etc. associé au dictionnaire concerne la portion de document XML à coder. Ce dictionnaire local utilisé est, à cet instant d'utilisation, le dictionnaire courant de valeurs. Enfin, des dictionnaires de structures locaux sont aussi utilisés pour coder la structure du document XML. Ces dictionnaires permettent de coder le type de chaque item du document XML: attribut, balise ouvrante d'élément, etc. Ces dictionnaires de structures dépendent de l'élément parent de l'item à coder et peuvent dépendre des items précédant l'item à coder au sein de cet élément parent. Ces dictionnaires de structures sont généralement appelés "grammaires" dans la spécification EXI. Toujours selon cette dernière, les grammaires sont composées d'un ensemble de productions, chaque production comprenant une description d'événement XML, une valeur de codage associée et l'indication de la grammaire suivante à utiliser (pour le codage de l'événement suivant). Puisqu'on passe d'une grammaire à une autre grâce à cette indication, à un instant donné, on a généralement une seule grammaire courante. Dans la suite de la description, le terme de "dictionnaire" est utilisé pour désigner de manière générique les différents dictionnaires mis en oeuvre lors du codage ou décodage d'un document: dictionnaire de vocabulaire, dictionnaire de valeurs ou dictionnaire de structures. Bien que la suite de la description se concentre sur le format EXI, comme ci-dessus, car l'invention lui est particulièrement bien adaptée, l'invention n'est pas limitée à ce format de codage. L'invention peut également s'appliquer à d'autres formats XML binaires, ou être utilisée entre plusieurs formats XML binaires. A titre d'exemple, le format Fast Infoset, format binaire ITU-T et ISO, utilise en particulier des indicateurs binaires pour décrire les différents noeuds contenus dans le document XML, ainsi que des tables d'index (dictionnaires selon la terminologie adoptée ci-dessus) pour les noms d'éléments, les noms d'attributs, les valeurs d'attributs et les valeurs textuelles. Pour pouvoir s'adapter à différents scénarios, les formats de codage, et notamment le format EXI, proposent plusieurs options de codage.
Ainsi par exemple, les dictionnaires locaux de structure peuvent être créés, soit dynamiquement lors du codage du document (ou lors de son décodage), soit au préalable à partir d'un fichier de description structurelle de documents, par exemple à partir d'un Schéma XML ("XML Schema"). ll en va de même pour les dictionnaires de noms locaux d'éléments qui peuvent être, soit créés dynamiquement lors du codage du document, soit préalablement remplis à partir d'un Schéma XML. Selon qu'ils sont créés dynamiquement ou à partir d'un Schéma XML, les dictionnaires locaux sont différents : ils peuvent ne pas comporter les mêmes entrées, ou les contenir dans des ordres différents, et dans le cas des dictionnaires de structure, le nombre de dictionnaires (grammaires) correspondant à un élément XML donné peut être différent. Ces exemples d'options de codage ne sont pas limitatifs. Par exemple, le format EXI propose un mode de compression qui permet d'appliquer une compression de type ZIP au contenu codé. Afin d'améliorer l'efficacité de la compression, les données ne sont pas codées de la même manière, ni dans le même ordre, que pour un simple codage dynamique sans compression ou à partir d'un Schéma XML. Ceci a pour conséquence que suivant que ce mode de compression est utilisé ou non, les dictionnaires de valeurs peuvent contenir des entrées ordonnées différemment. De façon générale, on observe donc que, selon les options de codage choisies, les dictionnaires utilisés pour le codage et/ou pour le 5 décodage ne sont pas les mêmes. Dans un certain nombre d'applications, il peut être intéressant de recoder un document déjà codé avec un premier jeu d'options en un autre document encodé mais avec un deuxième jeu d'options, par exemple un document XML déjà codé avec le format EXI en un second document XML 10 utilisant ce même format mais avec des options différentes. Ce passage d'un document codé en un autre document codé différemment est ci-après dénommé transcodage. A titre d'exemple d'application, dans le cas d'un serveur de fichiers, les documents XML peuvent être mémorisés en utilisant le format EXI avec des 15 dictionnaires générés à partir d'un Schéma XML afin d'obtenir des documents compacts pour un stockage efficace. Cependant, pour répondre à certaines requêtes d'utilisateurs, le serveur doit pouvoir fournir aussi ces documents XML en utilisant le format EXI mais avec des dictionnaires non générés à partir d'un Schéma XML. Dans ce 20 cas, le serveur doit recoder ces documents XML codés lors de leur stockage. Or, comme, suivant les options de codage mises en oeuvre, les dictionnaires utilisés et leurs valeurs de codage sont différents, la méthode classique pour recoder ces documents XML consiste à décoder entièrement le document XML puis à le recoder avec de nouvelles options. 25 Cette solution de transcodage nécessite une représentation sous une forme totalement décodée (au format XML) d'une première donnée avant de la ré-encoder selon le deuxième jeu d'options de codage. Cela pose un problème de performance, car le codage et le décodage d'un document XML selon le format EXI peuvent être relativement 30 coûteux.
La présente invention a pour but de pallier cet inconvénient en évitant de décoder entièrement le document initialement codé, en particulier en évitant l'étape de représentation sous une forme décodée. A cet effet, l'invention vise notamment un procédé de traitement pour le transcodage d'un document codé à l'aide de dictionnaires, comprenant les étapes suivantes : - l'identification, dans un dictionnaire de décodage, d'une première entrée correspondant à une donnée codée, - l'identification, dans un dictionnaire de codage, d'une deuxième entrée afin d'obtenir une valeur de codage pour transcoder ladite donnée codée, procédé dans lequel ladite deuxième entrée est directement déterminée depuis ladite première entrée à partir d'une indication reliant lesdites deux entrées.
L'invention permet notamment le transcodage de documents XML utilisant le format EXI, en transformant efficacement un document XML utilisant le format EXI avec un premier jeu d'options en une nouvelle version utilisant le format EXI avec un second jeu d'options. Selon l'invention, des liens créés pour associer les entrées des dictionnaires de codage aux entrées des dictionnaires de décodage sont utilisés afin d'effectuer une conversion plus directe entre les données du document codé initial et celles du document transcodé. Deux entrées (l'une dans un dictionnaire de décodage et l'autre dans un dictionnaire de codage) représentant notamment la même structure ou la même valeur dans un contexte similaire sont liées ensemble. Ainsi, lorsque le décodeur, à partir du contenu codé, sélectionne une entrée dans un dictionnaire de décodage, il peut, grâce aux liens créés précédemment, indiquer directement au codeur quelle entrée utiliser dans le dictionnaire de codage.
Cette détermination directe de l'entrée à utiliser dans le dictionnaire de codage supprime l'étape de représentation de l'item XML au cours du décodage de l'art antérieur à partir du dictionnaire de décodage. En outre, le procédé selon l'invention évite l'étape de recherche, dans le dictionnaire de codage, (coûteuse en temps de calcul) de l'entrée correspondante à la représentation. L'invention permet ainsi de diminuer le temps de calcul nécessaire 5 par rapport aux décodage et recodage complets d'un document XML, comme dans l'art antérieur. En évitant la représentation de l'item XML, la présente invention réduit également la mémoire utilisée lors du transcodage de documents. Dans un mode de réalisation, le procédé comprend une étape de 10 constitution d'au moins une indication, ladite étape de constitution comprenant, lorsque aucune deuxième entrée d'un dictionnaire de codage n'est reliée à ladite première entrée : - une étape de décodage de ladite donnée codée à l'aide de la première entrée pour générer une représentation décodée de la donnée, 15 - une étape d'identification, dans le dictionnaire de codage, d'une troisième entrée à l'aide de ladite représentation décodée afin d'obtenir une valeur de transcodage de ladite donnée codée, une étape d'indication d'un lien entre lesdites première et troisième entrées. 20 Dans cette configuration, le transcodage est effectué de manière classique lorsqu'aucun lien ne permet d'indiquer directement, à l'encodeur, l'entrée pertinente du dictionnaire de codage. De plus, l'étape d'indication d'un lien spécifique à l'invention permet d'éviter d'avoir à régénérer ultérieurement une représentation de l'item XML lorsque la même première entrée du 25 dictionnaire de décodage est utilisée. L'invention est donc compatible avec les méthodes classiques. Cette configuration permet notamment de démarrer la mise en oeuvre de l'invention à partir du procédé classique de décodage et de ré-encodage. 30 En particulier, lorsque aucune entrée n'est identifiée dans le dictionnaire de codage à l'aide de la représentation décodée, on crée, dans ledit dictionnaire de codage, une nouvelle entrée comprenant une valeur de codage de ladite représentation décodée et on renseigne une indication reliant la nouvelle entrée à ladite première entrée. Cette disposition permet de démarrer la mise en oeuvre de l'invention dans le cas où l'entrée dans le dictionnaire de codage doit être créée (évolution dynamique des dictionnaires).
Dans un mode de réalisation, si ladite première entrée est plus générique que la troisième entrée ou la nouvelle entrée, ladite indication d'un lien entre les entrées n'est pas réalisée. Cela est notamment le cas lorsque le premier jeu d'options (celui pour le document initialement codé) vise des entrées génériques, alors que le deuxième jeu d'options concerne des dictionnaires disposant d'entrées plus précises. Dans ce cas, une même valeur de codage initiale renvoie vers plusieurs entrées des dictionnaires de décodage. Par conséquent, il convient d'en éviter une association. On entend ici par "générique" le fait que l'élément, XML par exemple, auquel se rapporte une entrée, ne décrit que partiellement l'élément correspondant à l'autre entrée. Par exemple, une production EXI par défaut de début d'élément, notée "SE(*)", peut être utilisée pour décrire tout type de début d'élément et est donc générique par rapport à une production spécifique associée à un nom qualifié, par exemple une production "SE(first-name)" comme on le verra par la suite.
Dans un mode de réalisation, préalablement aux opérations de transcodage du document codé, on génère des dictionnaires de codage et de décodage, et on renseigne des indications reliant des première et deuxième entrées. On utilise notamment des Schémas XML pour ce paramétrage préalable d'un dispositif de l'invention. Ainsi, l'invention peut être mise en oeuvre directement dès les premières données du document codé. II se peut que certains items, initialement codés avec une même valeur, correspondent à plusieurs entrées possibles des dictionnaires de codage, notamment parce que l'encodage de l'item dépend du contexte dans lequel il se situe. Dans ce cas, on prévoit de sélectionner successivement plusieurs dictionnaires de codage en fonction des données parcoures dans ledit document, définissant de la sorte un dictionnaire courant pour une donnée du document, et on prévoit que ladite étape d'identification d'une deuxième entrée comprend l'identification d'une pluralité d'entrées de dictionnaires de codage et la sélection de l'entrée, parmi ladite pluralité, appartenant au dictionnaire de codage courant.
En effet, la gestion des contextes est généralement menée en indiquant successivement les divers dictionnaires à utiliser (souvent les dictionnaires locaux en ce sens qu'ils sont spécifiques à un élément précédent, définissant le contexte). Dans ce cadre, l'invention prévoir de choisir uniquement l'entrée correspondant au dictionnaire "actif'. On réduit ainsi les traitements nécessaires à la détermination de l'entrée pertinente. Selon une configuration de l'invention, ladite indication de lien comprend un pointeur sur ladite deuxième entrée, prévu au niveau de ladite première entrée. En variante, ladite indication de lien comprend au moins une table référençant au moins une deuxième entrée.
Afin de réduire l'espace mémoire pour le stockage des dictionnaires, des données constitutives des dictionnaires de codage et de décodage sont partagées. Cette disposition est originale en ce qu'elle mutualise certaines données des dictionnaires alors même qu'ils visent deux étapes totalement distinctes (ici, codage d'une part, et décodage d'autre part). Cette mutualisation est rendue efficace en raison des indications de lien qui permettent d'identifier des candidats sérieux à celle-ci. En particulier, des entrées desdits dictionnaires de codage et de décodage sont identiques de sorte que ladite indication est implicite. Notamment l'ensemble des dictionnaires peut être identique. Cette configuration peut être mise en oeuvre lorsque les jeux d'options de codage ne modifient pas directement les dictionnaires, mais portent, par exemple, sur la façon dont les valeurs codées sont alignées: alignement sur un bit ("bitpacked") ou sur un octet ("byte-aligned", chaque nouvelle valeur codée recommence sur un nouvel octet).
Selon une caractéristique particulière, on recopie ladite donnée codée en tant que donnée transcodée. Les temps de traitements sont réduits grâce à cette recopie. Cette configuration s'applique notamment aux cas où le changement opéré par le transcodage ne porte pas sur la représentation en donnée codée des valeurs de codage (la donnée codée est identique à la donnée transcodée). C'est le cas notamment lorsqu'il porte sur un changement de typage de données (par exemple, une chaîne de caractères devient un entier) : dans un tel cas, seules certaines données sont modifiées lors du transcodage, les autres données restant codées de manière identique. Une indication de recopie peut notamment être indiquée au niveau de la première entrée de décodage, lors d'une première itération de l'invention, afin de procéder, ultérieurement, directement à la recopie de la donnée codée.
Dans un mode de réalisation, le procédé comprend la détermination d'une indication de transcodage associée auxdites premières entrées, et en fonction de cette indication, soit on procède à l'identification dans le dictionnaire de codage, soit on passe à une donnée codée suivante dudit document. Ladite indication de transcodage peut être prévue pour indiquer que le codage est implicite (par exemple, lorsque la donnée se déduit directement de la donnée transcodée précédente, notamment en raison du contexte local) ou que la donnée correspondante dans le document est supprimée (par exemple, des commentaires supprimés). Cette disposition accélère le traitement de transcodage.
Dans un mode de réalisation de l'invention, on mémorise les premières entrées pour une pluralité de données codées dudit document à transcoder, avant de transcoder la pluralité de données. En mémorisant les premières entrées, on mémorise indirectement les données à recoder. Cela permet d'appliquer efficacement le transcodage lorsque le deuxième jeu d'options de codage nécessite par exemple d'ordonner un ensemble de données avant d'appliquer l'algorithme de ré-encodage. C'est notamment le cas pour l'option de "compression" du format EXI ou lorsqu'un ordre d'attributs doit être respecté. En variante, on récupère, associées audit document codé, des 30 informations décrivant l'ordre de données codées à l'intérieur dudit document. Cette disposition permet notamment d'éviter cette mémorisation temporaire lorsqu'un ordre est requis. En effet, on peut déduire directement cet ordre à partir des informations prévues ici. Dans un mode de réalisation de l'invention, lesdits documents sont des fichiers XML codés au format EXI, ledit transcodage permettant de passer d'un ensemble d'options de codage EXI à un autre ensemble d'options. Selon une caractéristique de l'invention, le procédé est mis en oeuvre dans un serveur informatique stockant des données codées selon un premier format de codage, pour fournir, sur requête, les données stockées codées selon un deuxième format de codage. On peut ainsi passer du format EXI au format Fast Infoset, ou vice et versa. Egalement, lesdits dictionnaires de décodage et de codage correspondent respectivement à deux versions différentes d'un fichier de description structurelle de documents XML. Corrélativement, l'invention vise également un dispositif de traitement pour le transcodage d'un document codé à l'aide de dictionnaires, comprenant : - un premier moyen d'identification, dans un dictionnaire de décodage, d'une première entrée correspondant à une donnée codée, - un deuxième moyen d'identification, dans un dictionnaire de codage, d'une deuxième entrée afin d'obtenir une valeur de codage pour transcoder ladite donnée codée, et dans lequel ledit deuxième moyen d'identification est apte à déterminer directement ladite deuxième entrée depuis ladite première entrée à partir d'une indication reliant lesdites deux entrées. De façon optionnelle, le dispositif peut comprendre des moyens se 25 rapportant aux caractéristiques du procédé de configuration exposé précédemment. Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le 30 procédé de traitement 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 traitement 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 un exemple de document XML pour la mise en oeuvre de l'invention ; - la figure 2 représente un exemple de schéma XML pour illustrer la mise en oeuvre de l'invention sur le document de la figure 1 ; - la figure 3 représente, de façon schématique, un processus de transcodage selon l'art antérieur ; - la figure 4 illustre, de façon schématique, la présente invention en comparaison avec le processus de l'art antérieur de la figure 3 ; - la figure 5 représente, sous forme de logigramme, des étapes générales du procédé selon l'invention ; - la figure 6 illustre un premier exemple de traitement de transcodage selon l'invention ; - la figure 7 illustre un deuxième exemple de traitement de transcodage selon l'invention ; - la figure 8 représente, sous forme de logigramme, des étapes détaillées du procédé selon l'invention ; et - la figure 9 montre une configuration matérielle particulière d'un dispositif de traitement d'information apte à une mise en oeuvre des procédés selon l'invention.
On décrit ci-après un exemple de procédé selon l'invention en référence au document XML 10 représenté sur la figure 1 et décrivant des personnes, et au Schéma XML 20 correspondant représenté sur la figure 2.
Ce schéma XML signifie qu'un élément list est composé d'un nombre indéterminé d'éléments person , et qu'un élément person est lui-même composé de trois éléments : un élément first-name , un élément middle-name optionnel et un élément last-name .
Pour la suite de la description, on considère que le document XML 10 de la figure 1 a été encodé à l'aide du format EXI, sans l'utilisation du schéma associé, selon les mécanismes classiques de codage EXI. Ce document codé 100 est le document initial. A titre d'illustration de l'invention, on ré-encode ce même document XML 10 toujours à l'aide du format EXI, mais en utilisant le schéma associé. Le fichier ré-encodé 140 ainsi obtenu est également appelé document transcodé. Pour le document initial 100, le jeu initial d'options de codage EXI correspond aux options classiques EXI. Le jeu d'options du document transcodé 140, également appelé jeu cible d'options, précise que le codage doit être réalisé avec la connaissance initiale du Schéma XML. L'utilisation ou non du schéma associé va déterminer quels sont les dictionnaires utilisés pour le codage et le décodage de ce document et quel est le contenu de ces dictionnaires. La notion d'options de codage n'est pas limitative et peut recouvrir plusieurs aspects mis en oeuvre lors du codage. A titre d'exemples complémentaires ou alternatifs à l'utilisation ou non d'un Schéma XML : - une option peut être la façon d'aligner ou non les valeurs codées sur des limites d'octets (modes bit-packed ou byte-aligned du format EXI); - une option peut correspondre au support ou non de certains noeuds XML (ainsi une option peut spécifier si les commentaires XML sont ou non codés) ; - une option peut préciser si une compression des données codées est effectuée ou non, généralement à l'aide d'un algorithme de type Deflate ou ZIP ; - une option peut prévoir de coder conjointement plusieurs événements XML, par exemple sur la base de données statistiques (prédiction univoque des éléments). Ces différentes options peuvent être combinées entre elles.
La figure 3 représente schématiquement un processus général de transcodage de l'art antérieur. Tout d'abord, le fichier codé 100 est décodé par le décodeur 110, qui génère une représentation XML 120 du contenu de ce document XML 10. Cette représentation XML 120 est généralement similaire au document XML 10 lui-même. Il peut s'agit d'une représentation complète, par exemple une représentation DOM ( Document Object Mode! en anglais, ou Modèle Objet de Documents en français) du document XML. Cette dernière représente le document 10 sous forme d'arbre mais nécessite un espace mémoire important.
Alternativement, il peut s'agir d'une représentation partielle à l'aide d'événements de type SAX ( Simple API for XML en anglais, ou Interface de programmation simple pour XML en français) ou StAX ( Streaming API for XML en anglais, ou Interface de programmation au fur et à mesure pour XML en français). Ces méthodes représentent chaque noeud du document XML par un ou plusieurs événements. L'intégralité du document XML est alors décrite par la succession de ces événements. Ces méthodes de représentation permettent de traiter un document XML au fur et à mesure de sa lecture et nécessitent donc peut d'espace mémoire. Grâce à ces méthodes, dès qu'une partie suffisante du document est décodée par le décodeur 110 pour pouvoir générer un événement, cet événement est utilisé par l'encodeur 130 pour coder cette partie du document. Ainsi, il n'est pas nécessaire d'avoir l'intégralité du document XML en mémoire pour effectuer le transcodage, mais seule une fraction minimale du document a besoin de résider en mémoire, à un instant donné.
Toujours en référence à la figure 3, l'encodeur 130 utilise ensuite la représentation XML 120 pour coder, de façon classique, le document transcodé dans un nouveau fichier 140.
Le processus selon l'art antérieur est représenté par les flèches 150. On rappelle ici que les encodages classiques, type EXI ou Fast Infoset, font appels à des dictionnaires. La figure 4 représente le même schéma général de transcodage illustrant la présente invention. Dans le cadre de la présente invention, certaines informations sont transmises directement depuis le décodeur 110 vers l'encodeur 130, sans passer par une représentation XML 120. Ces informations permettent notamment de déterminer les valeurs de codage à utiliser pour le transcodage.
Ce processus spécifique à l'invention est représenté par la flèche 160. On notera que la transmission directe de ces informations, et donc l'absence de traitement de la représentation XML 120, permet d'accélérer le processus général de transcodage d'un document, et, dans certains cas, de diminuer la taille mémoire nécessaire à la mise en oeuvre du transcodage.
En référence à la figure 5, on décrit maintenant les principales étapes du procédé mis en oeuvre par l'invention. Dans une première étape E200, des données du document codé 100 sont lues. Lors de l'étape E210, à partir de ces données, le décodeur 110 obtient une entrée dans un dictionnaire de décodage courant. Le dictionnaire de décodage courant est déterminé par les règles de décodage définies par le format de codage du document codé 100. En particulier, il peut s'agir de dictionnaires locaux tenant compte du contexte courant (défini par un élément parent) ou de la grammaire active en fonction du parcours dans la structure du document XML. On poursuit, à l'étape E220, en cherchant si une entrée dans le dictionnaire de codage courant est liée à cette entrée du dictionnaire de décodage. Si c'est le cas, lors de l'étape E230, l'encodeur 130 utilise cette entrée pour obtenir la valeur de transcodage correspondante et générer une partie du document transcodé 140. On observe ici que l'on n'est pas passé par l'étape de représentation XML 120.
Si aucune entrée n'est trouvée, un procédé classique selon l'invention peut être mis en oeuvre (étape E240) pour le transcodage de la donnée courante, passant notamment par la représentation XML 120. On comprendra ici que ces différentes étapes sont itérées sur l'ensemble des données du document XML 100 à transcoder. La figure 6 illustre un exemple de l'invention appliquée au transcodage d'un nom local d'élément. Selon la spécification EXI, un nom local d'élément est codé à l'aide d'un index. Cet index est déterminé par le dictionnaire de codage ou de 10 décodage, généralement un dictionnaire local. Le dictionnaire de décodage 300 représenté sur la figure correspond à celui généré à la fin du décodage lorsque l'on utilise le format EXI sans schéma XML. Le dictionnaire de codage 310 correspond, quant à lui, à celui généré directement à partir du schéma XML 20 de la figure 2 pour le format 15 EXI. Quand le schéma XML 20 n'est pas utilisé, le dictionnaire 300 contenant les noms locaux des éléments est construit dynamiquement à chaque fois qu'un nouvel élément est rencontré. Ce dictionnaire est donc constitué par les entrées suivantes : 20 0 list 1 person 2 first-name 3 last-name 4 middle-name 25 Les nombres précédant chaque entrée correspondent à l'index (ou valeur de codage) utilisé pour le codage. Quand le schéma XML 20 est utilisé, le dictionnaire 310 est pré- peuplé à l'aide des noms locaux d'éléments décrits dans le schéma, ordonnés selon leur ordre d'apparition dans le schéma. Ainsi ce dictionnaire est constitué 30 par les entrées suivantes : 0 list 1 person 2 first-name 3 middle-name 4 last-name On observe donc que ces deux dictionnaires sont différents de deux manières. Tout d'abord le dictionnaire 300 est créé dynamiquement au fur et à mesure du décodage (ou du codage), alors qu'au contraire, le dictionnaire 310 est créé avant le début du codage (ou du décodage). D'autre part si ces deux dictionnaires contiennent au final les mêmes 10 entrées, l'ordre de ces entrées et donc les indexes associés à chacune des valeurs sont différents. Dans certains cas, il est possible que ces dictionnaires aient des ensembles d'entrées différents : par exemple, si le deuxième élément person de l'exemple ne contenait pas de sous-élément middle-name . 15 Dans ce cas, le dictionnaire 300 ne contiendrait à aucun moment l'entrée middle-name . La figure 6 montre également les liens 350 entre les entrées du dictionnaire 300 et celles du dictionnaire 310. Ainsi l'entrée 301, 0 list , du dictionnaire 300 est liée à l'entrée 311, 0 list , du dictionnaire 310. 20 L'inversion des deux dernières entrées entre le dictionnaire 300 et le dictionnaire 310 est représentée par les flèches croisées. Les liens sont notamment des pointeurs prévus dans le dictionnaire de décodage 300, et "pointant", pour chaque entrée de celui-ci, vers l'entrée correspondante du dictionnaire de codage 310. Comme on le verra par la suite, 25 ces liens 350 peuvent être créés soit préalablement au transcodage (à partir d'un Schéma XML par exemple), soit au cours dudit transcodage par apprentissage à partir d'occurrences antérieures du document déjà transcodées. Comme expliqué en lien avec la figure 5, lors du transcodage selon 30 l'invention, l'index du nom local est lu dans le document codé 100, puis est recherché dans le dictionnaire 300. Ceci permet d'obtenir une entrée dans ce dictionnaire 300. On recherche alors un lien 350 vers une entrée du dictionnaire 310 et on obtient directement cette dernière. L'entrée obtenue du dictionnaire 310 permet de coder le nom local à l'aide de l'index qu'elle contient. En comparaison, en l'absence de l'invention, les étapes sont les suivantes. A partir de l'entrée obtenue dans le dictionnaire 300, la chaîne représentant le nom local est générée par le décodeur comme représentation 120 de cette partie du document XML (et éventuellement intégrée à un événement de type SAX ou StAX). Ensuite, l'encodeur 130 utilise cette chaîne de caractères pour trouver, selon les mécanismes classiques de recherche, l'entrée correspondante dans le dictionnaire de codage 310. Cette étape de recherche est coûteuse, puisqu'elle implique la recherche d'une chaîne de caractères dans une liste de chaînes de caractères. Même avec des algorithmes adaptés (comme par exemple une table de hachage), le coût en temps de calcul de cette recherche est beaucoup plus important que l'obtention directe du lien entre les entrées tel qu'il est réalisé dans l'invention.
On illustre encore l'invention à l'aide d'un deuxième exemple ayant trait au traitement des informations de structure du document XML codé 100, comme illustré par la figure 7. On se place ici lors du traitement pour le transcodage du début d'un élément first-name au sein d'un élément person se trouvant après l'élément person de l'exemple correspondant à John Peter Miller . En d'autres termes, l'ensemble des éléments XML de la figure 1 a été transcodé, donc les dictionnaires de codage/décodage correspondants sont déjà remplis, et on souhaite transcoder un nouvel élément person consécutif à cet ensemble d'éléments. On se situe précisément au moment du transcodage de l'élément first-name . Puisque le document 100 a été encodé sans utiliser le schéma XML 20, le dictionnaire 400 (également appelé "grammaire" selon la norme EXI) contient l'ensemble de la description structurelle de l'élément person , à savoir le début des éléments first-name , middle-name et fast-name .
En outre, le dictionnaire étant évolutif, une entrée générique SE(*) permet de décoder tout nouveau début d'élément non défini par les autres entrées. Dans ce cas, une entrée spécifique à ce nouveau début d'élément sera créée sur le même modèle que les trois entrées listées ci-dessus. Il est à noter que la description du dictionnaire est simplifiée par rapport à la spécification EXI pour faciliter la compréhension de l'invention.
Ce dictionnaire 400 a été créé durant le décodage du début du document XML 100 et comporte donc des entrées ordonnées selon leur ordre d'occurrence (la dernière entrée créée se trouve au début du dictionnaire, car les entrées créées sont ajoutées en début de dictionnaire). Le jeu d'options cible utilise, quant à lui, le schéma XML 20. Ainsi, le dictionnaire 410 ne comporte qu'une seule entrée correspondant au début de l'élément first-name . En effet, le schéma décrivant précisément la structure des documents XML, la description de la structure d'un élément est optimisée et peut utiliser plusieurs dictionnaires, comme dans le cas présent. La structure d'un élément "person" est décrite par les dictionnaires (grammaires EXI) suivants : Grammaire Person 1 0 SE (first-name) Person 2 Grammaire Person 2 0 SE (middle-name) Person_3 1 SE (last-name) Person_4 Grammaire Person 3 0 SE (last-name) Person_4 Grammaire Person_4 0 EE Chaque entrée d'un dictionnaire (grammaire) est une production indiquant un index de codage (valeur de codage), l'événement XML associé (par exemple début SE d'élément "first-name") et le dictionnaire suivant à utiliser. Lors du codage (ou du décodage), en parcourant les différents dictionnaires à l'aide des indications de "dictionnaire suivant', on peut définir le "dictionnaire courant", c'est-à-dire celui "actif" pour coder/décoder l'événement en cours de traitement.
Le dictionnaire 410 représenté sur la figure 7 correspond au dictionnaire Person 1, qui est le premier dictionnaire à utiliser pour coder la structure d'un élément person . Dans l'exemple de la figure 7, seule l'entrée 403 du dictionnaire de décodage 400 est liée à une entrée du dictionnaire d'encodage courant 410. Par contre, l'entrée 402 de ce dictionnaire de décodage 400 est liée à deux entrées : la deuxième entrée du dictionnaire Person_2 et la première entrée du dictionnaire Person_3 . Ainsi, lors du transcodage selon l'invention, quand l'entrée du dictionnaire de décodage a été déterminée à partir des données extraites du document codé, le procédé recherche l'entrée liée du dictionnaire d'encodage. Pour cela, il parcourt l'ensemble des entrées liées à l'entrée du dictionnaire de décodage et sélectionne celle qui est contenue dans le dictionnaire d'encodage courant.
Dans le cas présent, seule l'entrée 411 est liée à l'entrée 403. II n'y a pas de difficulté. Dans le cas de l'entrée 402, si l'élément "last-name" fait suite directement à un élément "first-name", le dictionnaire courant est "Person_2". Dans ce cas, l'entrée sélectionnée est la deuxième entrée de ce dictionnaire et non l'entrée du dictionnaire "Person 3". On décrit maintenant plus en détail le procédé selon l'invention en référence à la figure 8, et en particulier des mécanismes de création des liens 350 entre les entrées des dictionnaires. Dans une première étape E500, des données du document XML 25 codé 100 sont lues. Lors de l'étape E510, à partir de ces données, le décodeur 130 obtient une entrée (par exemple 403 sur la figure 7) dans un dictionnaire de décodage courant (400 sur la figure 7). Le dictionnaire de décodage courant 400 est déterminé par les 30 règles de décodage définies par le format de codage du document codé 100, en particulier selon la spécification EXI. Cette entrée obtenue peut soit être déjà existante dans le dictionnaire de décodage courant, soit être créée dans le dictionnaire de décodage courant selon les principes d'évolution dynamique des dictionnaires. En tout état de cause, l'entrée obtenue est celle qui sera utilisée lors de la prochaine instance de données similaires dans le document codé 100.
Puis, à l'étape E520, le procédé obtient l'ensemble des entrées liées à cette entrée du dictionnaire de décodage. On note ici que chaque entrée d'un dictionnaire de décodage peut être liée à 0, 1 ou plusieurs entrées des dictionnaires de codage. A titre d'exemple, les liens 350 entre les entrées des dictionnaires de 10 décodage et les entrées des dictionnaires de codage peuvent être représentés par des pointeurs informatiques. Pour certains dictionnaires (comme par exemple un dictionnaire des noms locaux), une entrée peut avoir au plus un lien 350. Dans ce cas, ce lien 350 peut être représenté directement par un pointeur au niveau de cette entrée. 15 Pour d'autres dictionnaires (comme par exemple un dictionnaire de structure), une entrée peut avoir plusieurs liens 350. Dans ce cas, l'ensemble des liens d'une entrée peut être représenté sous forme de tableau, ou par une structure de type table de hachage, ou encore pour tout autre type de structure adaptée. De manière générale, le type d'association entre un dictionnaire de 20 décodage et un dictionnaire de codage correspond au nombre maximal de liens associés à une entrée du dictionnaire de décodage. On définit deux types d'associations principaux : celui où chaque entrée du dictionnaire de décodage possède au plus un lien et celui où chaque entrée du dictionnaire de décodage peut posséder un nombre indéterminé de liens. Si pour certains types de 25 dictionnaires (comme par exemple un dictionnaire des noms locaux) le type d'association entre le dictionnaire de codage et le dictionnaire de décodage est constant, pour d'autres dictionnaires (comme par exemple les dictionnaires de structures), le type d'association entre le dictionnaire de codage et le dictionnaire de décodage peut varier en fonction des options utilisées. De 30 manière préférée, la représentation des liens pour chaque entrée d'un dictionnaire de décodage est adaptée au type d'association entre les deux dictionnaires. Si une entrée d'un dictionnaire de décodage ne peut avoir au plus qu'un seul lien, alors ce lien est représenté par un pointeur. Si une entrée d'un dictionnaire de décodage peut avoir plusieurs liens, alors ce lien est représenté par un ensemble de pointeurs. On poursuit à l'étape E530 en vérifiant si l'une des entrées liées ainsi obtenues à l'étape E520 est contenue dans le dictionnaire de codage courant. Dans l'affirmative, le procédé continue à l'étape E540 par l'obtention de cette entrée liée et utilise cette entrée à l'étape E550 pour (trans)coder l'information correspondant à cette entrée. On constitue ainsi progressivement le document transcodé 140.
Dans la négative, ou si l'entrée du dictionnaire de décodage ne possède aucune entrée liée, alors le procédé continue à l'étape E560. Les deux premières étapes (E560, E570) de la suite du procédé correspondent à des étapes classiques de transcodage. Durant l'étape E560, une représentation 120 des données XML correspondant à cette entrée est créée. Cette représentation 120 peut être un événement SAX ou un événement StAX comme évoqué précédemment. Dans ce cas, il convient de mémoriser le résultat du décodage de plusieurs données codées consécutives (en effet, un événement SAX est généralement codé par le format EXI en plusieurs parties/fractions).
La représentation XML 120 peut aussi avoir une granularité plus fine correspondant à une fraction du document XML encodée en une seule fois. On poursuit à l'étape E570 en utilisant cette représentation 120 pour obtenir une entrée dans le dictionnaire de codage courant. Pour ce faire, on utilise les mécanismes classiques de recherche d'entrées dans un dictionnaire, comme par exemple une recherche réalisée en parcourant les entrées du dictionnaire, ou une recherche réalisée à l'aide d'une table de hachage. Cette entrée du dictionnaire de codage courant peut être déjà existante ou peut être créée à partir de cette représentation XML 120 le cas échéant. L'obtention de cette entrée et son éventuelle création sont régies par les règles définissant le format EXI.
Ensuite, à l'étape E580, spécifique à la présente invention, un lien 350 est créé entre l'entrée du dictionnaire de décodage obtenue à l'étape E510 et l'entrée du dictionnaire de codage obtenue à l'étape E570. Ainsi, par la suite (itération de transcodage selon l'invention sur d'autres données du document XML codé 100), si l'entrée du dictionnaire de décodage est de nouveau utilisée, l'entrée liée du dictionnaire de codage pourra être directement obtenue par l'intermédiaire de ce lien 350 au cours des étapes E520 et E540. Il faut cependant noter que la création de ce lien 350 n'est pas réalisée systématiquement. Dans certains cas, les deux entrées ne 10 correspondent pas au sens où elles ne visent pas un événement XML avec le même degré de précision. Par exemple, si une entrée correspondant au début d'un élément non précisé est utilisée lors du décodage (entrée de type SE (*) ), tandis que l'entrée de codage précise le nom de l'élément (par exemple une entrée de type 15 SE (first-name) ), alors ces entrées ne sont pas liées. Dans un autre exemple relatif aux dictionnaires structurels dynamiques, c'est-à-dire évoluant durant le codage ou le décodage, la création d'un lien 350 n'est réalisée que si les entrées sont stables : une entrée, qu'elle serve pour le décodage ou le codage, ne sera liée que si l'instance suivante 20 des données codées ou décodées utilisera cette même entrée. Ainsi, une entrée de type SE (*) n'est jamais liée car elle ne concerne que les premières occurrences d'un début d'élément et non les occurrences suivantes de ce même début d'élément. Par contre, une entrée de type SE (tirstname) peut être liée. 25 Toujours en exemple, pour les entrées de type CH (production chaîne de caractères selon le format EXI) dans le cas d'utilisation du format EXI sans utilisation de Schéma XML, lors de la première occurrence d'un contenu textuel codé à l'aide d'une telle entrée, une nouvelle entrée est créée avec une représentation codée plus compacte. Ainsi, dans un tel cas, l'entrée de type 30 CH initiale (qui est générique au même titre que SE (*) ) n'est pas liée, mais l'entrée nouvellement créée l'est.
Suite à l'étape E580, on continue à l'étape E550 durant laquelle la représentation XML 120 est codée à l'aide de l'entrée obtenue à l'étape E570. Les étapes ci-dessus illustrent le transcodage d'une donnée codée du document 100. On envisage ainsi d'itérer ces différentes étapes sur l'ensemble des données codées constitutives du document XML codé 100 ou d'une portion de celui-ci que l'on souhaite transcoder. Dans un mode de réalisation optimisant l'invention, des liens 350 peuvent être créés avant de commencer le transcodage. En particulier, les entrées prédéfinies dans des dictionnaires (également prédéfinis) peuvent être liées dès leur création. Dans le cas général, les entrées prédéfinies dans les dictionnaires de vocabulaire sont liées avant le début du transcodage. Dans le cas d'utilisation d'un Schéma XML 20 pour le document initial 100 et pour le document final 140, les entrées prédéfinies dans les dictionnaires de vocabulaire et les dictionnaires de structures peuvent être liées avant le début du transcodage. Ceci s'applique aussi bien au cas où le même Schéma est utilisé pour le document initial et pour le document final que pour le cas où deux Schémas différents sont utilisés (par exemple dans le cas d'utilisation d'une nouvelle version d'un Schéma).
On décrit maintenant quelques adaptations de l'invention à des spécificités d'options de codage. Selon une première adaptation, on mémorise les entrées obtenues lors d'itérations successives de l'étape E510. Dans le cas de l'option de "compression", type Deflate ou ZIP, déjà 25 évoqué, il est important d'ordonner les données afin d'obtenir une compression plus efficace. Il convient dès lors de mémoriser, lors du transcodage, certaines données décodées avant de pouvoir les encoder de nouveau. Pour pouvoir appliquer l'invention quand l'option de compression est utilisée au codage ou au décodage, les données mémorisées ne sont pas 30 mémorisées sous la représentation XML 120, mais à l'aide des entrées des dictionnaires de décodage. Ainsi quand des données mémorisées peuvent être codées (l'ordonnancement a été réalisé), les entrées des dictionnaires de décodage qui leur sont associées sont toujours disponibles et l'invention peut être appliquée pour déterminer directement les entrées des dictionnaires de codage, et encoder les valeurs de codage correspondantes selon cette option de compression EXI.
Toujours selon cette première adaptation, selon les options utilisées par le format EXI, les attributs d'un élément peuvent ou non être ordonnés (l'ordre imposé par certaines options du format EXI est l'ordre lexical). Si dans le document initial les attributs ne sont pas ordonnés, mais qu'ils doivent l'être dans le document final, on procède à la mémorisation de l'ensemble des attributs d'un élément, comme évoqué ci-dessus, avant de les encoder de nouveau. De façon similaire au cas de la "compression", la mémorisation de ces attributs n'est pas réalisée par une représentation XML 120, mais à l'aide des entrées des dictionnaires de décodage. Selon une autre adaptation qui propose une solution alternative à la mémorisation précédente, on prévoit de décrire l'ordre des éléments dans des données liées au document codé 100 afin de faciliter les opérations de tri et d'ordonnancement par le décodeur 110/codeur 130. Par exemple, lors de l'encodage initial, quelles que soient les contraintes imposées par le format choisi, les attributs sont encodés dans un ordre spécifique, notamment celui imposé par le format EXI pour certaines options. Lors du transcodage, les attributs sont déjà ordonnés correctement et peuvent parfois être encodés de nouveau sans qu'il soit nécessaire de les mémoriser. Afin que l'entité chargée du transcodage connaisse l'ordre utilisé lors du codage initial, des métadonnées décrivant cet ordre sont liées au document initial lors du codage initial. Cette adaptation s'applique notamment lorsque l'encodage initial et le transcodage sont contrôlés par une même entité (par exemple un serveur de fichiers XML), ou lorsque l'encodage initial est contrôlé par une entité compatible avec l'invention. Selon une autre adaptation, on prévoit que les espaces mémoire pour la représentation des dictionnaires de décodage et de codage sont partagés. Cette adaptation vise à réduire l'espace mémoire nécessaire à la mise en oeuvre de l'invention et s'applique particulièrement bien lorsque ces dictionnaires comportent des informations communes. Par exemple, les dictionnaires de valeurs représentés sur la figure 6 comportent les mêmes entrées, mais dans un ordre différent. Pour économiser la mémoire, le dictionnaire de décodage et le dictionnaire de codage utilisent la même chaîne de caractères (en mémoire) pour représenter un même nom local. En particulier, il arrive que le dictionnaire de décodage soit identique à celui de codage, par exemple si le document à décoder 100 utilise l'option d'alignement des données (chaque donnée du document à décoder commence sur un début d'octet), tandis que le document transcodé 140 ne l'utilise pas (chaque donnée du document à coder commence dès la fin de la donnée suivante). Dans ce cas, les dictionnaires de décodage et de codage sont identiques, seule la manière de coder les index correspondant aux entrées de ces dictionnaires change. Selon cette adaptation particulière de l'invention, on utilise la même représentation pour le dictionnaire de décodage et pour le dictionnaire de codage (l'espace mémoire est totalement partagé). Dans ce cas, les liens 350 entre les entrées sont implicites puisqu'une entrée de codage a la même représentation que l'entrée de décodage à laquelle elle est liée. En particulier, il arrive que non seulement le dictionnaire de décodage est identique au dictionnaire de codage, mais également que les données qu'ils servent à coder sont représentées de façon identique dans le fichier à décoder et dans le fichier à transcoder. Cette situation est rencontrée lorsque, par exemple, le changement opéré par le transcodage est l'utilisation d'un codage différent pour certaines valeurs typées (par exemple dans le document à décoder les entiers sont codés sous forme de chaîne de caractères, tandis que dans le document à transcoder, les entiers sont codés directement sous forme d'entiers). Dans un tel cas, seul le codage de ces valeurs typées change. Pour les autres valeurs, et pour les informations structurelles, on prévoit de copier directement les données codées à l'aide de ces dictionnaires, sans même chercher l'entrée correspondante.
De façon plus générale, si une entrée du dictionnaire de codage présente une même valeur de codage que celle de l'entrée liée du dictionnaire de décodage, et que la représentation de ces valeurs de codage est la même, alors on effectue la copie. Si toutes les entrées des dictionnaires ne sont pas identiques, on précise (par exemple avec un drapeau binaire) au niveau de chaque entrée du dictionnaire de décodage s'il est possible de procéder à cette recopie. Dans ce cas, l'identification de l'entrée dans le dictionnaire de codage est implicite. Les autres entrées sont traitées conformément aux étapes E500 à E580 décrites précédemment.
Selon une autre adaptation, on tient compte du fait que certaines différences entre les options de codage et de décodage conduisent à supprimer certaines informations lors du transcodage. Par exemple, si des commentaires XML sont présents dans le document initial 10 (et sous forme codée dans le document 100) mais ne doivent pas être présents dans le document final 140, ils doivent être supprimés lors du transcodage. Dans un tel cas, les entrées des dictionnaires de décodage correspondant à un commentaire XML sont marquées, au fur et à mesure (étape E580 par exemple), de manière spécifique pour indiquer que la partie décodée ne doit pas être encodée et peut donc être ignorée. On accélère ainsi le processus de transcodage. Dans un autre exemple, on peut enlever la préservation des préfixes associés aux espaces de nommage, lors des opérations de transcodage. Ainsi, dans le document initial, des préfixes sont associés aux différents espaces de nommage, permettant une lecture plus facile du document, puisque chaque préfixe est une abréviation intelligible de l'espace de nommage. Par contre, dans le document final, ces préfixes sont supprimés dans un souci de gain de place. Aussi, les préfixes de nommage sont ignorés de façon similaire. Encore un autre exemple impliquant un traitement similaire concerne la suppression, dans un document, des attributs ou des éléments qui ne sont pas valides par rapport à un Schéma XML donné 20. De façon proche, une autre adaptation a trait aux données dont le codage est implicite (c'est-à-dire qu'elles sont totalement prédictibles eu égard aux données/contexte qui les précèdent, et ne nécessitent donc pas d'être codées). C'est par exemple le cas en utilisant pour le document final des options de codage où les dictionnaires de structure sont générés à partir d'un Schéma XML 20 et où le mode de codage est strict, c'est-à-dire n'autorisant aucune déviation par rapport au Schéma XML. Dans un tel cas, le Schéma XML permet de définir de manière unique certaines structures et il n'est donc pas nécessaire d'encoder d'information pour définir ces structures (c'est le cas par exemple de l'unique production dans les grammaires "Person_l" et "Person_3" ci-dessus).
Dans un tel cas, une entrée d'une table de décodage liée à des entrées de tables de codage toutes codées implicitement peut être marquée (par exemple lors de l'étape E580) de manière spécifique pour indiquer que la partie décodée est codée implicitement. Ceci permet d'accélérer le processus de transcodage.
On envisage une autre adaptation pour le cas où, lors du codage initial, on code une partie du document XML à l'aide d'une simple indication de "conformité" lorsque cette partie peut être prédite de manière univoque à partir du dictionnaire courant. Cette autre adaptation vise également le cas où, de façon assez similaire lors du codage initial du document 10, on prédit plusieurs événements XML successifs et on encode, à la place d'une donnée codée correspondante à chacun de ces événements, le nombre de prédictions exactes successives. Au niveau du décodeur, les prédictions sont menées pour déduire les événements XML.
De telles options de codages permettent de grouper plusieurs événements XML pour produire des données codées réduites. Cette autre adaptation met ainsi en oeuvre, lorsque plusieurs parties d'un document XML sont codées en une seule fois en utilisant des informations statistiques sur le contenu du document XML, une optimisation du transcodage en liant, au niveau du dictionnaire de décodage, chaque symbole correspondant à un ensemble de parties codées conjointement avec un ensemble d'entrées de dictionnaire de codage permettant le ré-encodage de ces parties codées conjointement. Comme il ressort de ce qui précède, la présente invention permet de diminuer de façon substantielle le nombre de calculs nécessaires pour le transcodage par rapport aux décodage et ré-encodage complets d'un document XML. De nombreuses applications de la présente invention sont envisagées. On décrit ci-après, à titre d'exemples, les spécificités relatives à certaines applications.
Selon un premier scénario, l'invention est appliquée à un serveur de fichiers. Le serveur de fichiers mémorise des fichiers XML dans un format codé EXI en utilisant un jeu d'options. Lorsqu'un client sollicite un fichier XML sous le format EXI avec un autre jeu d'options, ou sous un autre format XML binaire, on applique les enseignements de l'invention pour transcoder le document et le fournir à l'utilisateur demandeur. Notamment, dans un tel scénario, on prévoit que le serveur de fichiers XML choisit le jeu d'options le plus adéquat pour mémoriser les documents XML; par exemple le jeu d'options offrant la meilleure compacité, ou le jeu d'options le plus demandé par les clients. Le jeu d'options cible pour le transcodage est spécifique, au cas par cas, à la demande de l'utilisateur. Selon un deuxième scénario, l'invention est mise en oeuvre dans le cas d'une transmission de documents XML signés. Pour calculer la signature d'un document XML, ce dernier est mis sous une forme canonique (c'est-à-dire reproductible sans ambiguïté). Pour cela, il existe des normes définissant des formes canoniques pour XML mais dont la conversion depuis un document XML est coûteuse. Dans ce deuxième scénario, on utilise le format EXI avec un jeu d'option bien défini comme forme canonique.
Ainsi, le procédé selon l'invention peut être appliqué pour la création ou la vérification de la signature d'un document XML codé à l'aide du format EXI : si le document codé n'utilise pas les options du format EXI correspondant à la forme canonique utilisée pour le calcul de la signature, le document est transcodé afin d'obtenir la forme canonique et d'effectuer le calcul de la signature. L'invention permet alors de choisir le format le plus adapté pour le 5 traitement du document XML signé, tout en permettant de calculer avec un faible coût en temps de calcul la forme canonique de ce document XML et donc sa signature. Selon un troisième scénario, l'invention est utilisée lorsqu'un Schéma XML utilisé pour coder le document initial est changé. 10 Un exemple de tel changement est le cas où une nouvelle version d'un Schéma définissant un type de document est publiée. Dans un tel cas, il est intéressant de pouvoir coder un document, soit par rapport à l'ancienne version, soit par rapport à la nouvelle. Ainsi, le transcodage selon l'invention offre une solution efficace pour passer facilement de l'un de ces codages à 15 l'autre. Un autre exemple de tel changement est l'utilisation d'un Schéma générique couvrant l'intégralité d'un ensemble de documents ou d'un Schéma plus précis ne couvrant qu'une portion de ce même ensemble de documents. Le Schéma générique a l'avantage d'être commun à tous les 20 documents et donc de faciliter un codage initial de tous les documents, tandis que le Schéma précis permet une compression plus importante des documents auxquels il s'applique. La présente invention permet de passer efficacement de l'un à l'autre. Selon un quatrième scénario, la présente invention est mise en 25 oeuvre lorsque l'on souhaite passer d'un mode édition de document, dans lequel des commentaires, des préfixes et éventuellement certains éléments ou attributs aidant l'édition sont présents, vers un mode de traitement (par exemple un mode d'impression) dans lequel tous les noeuds XML spécifiques à l'édition sont supprimés. Ce passage permet de diminuer la taille du document, ainsi 30 que d'accélérer sa transmission et son traitement. En outre, le mode édition peut utiliser les Schémas dans un mode non strict, autorisant les déviations par rapport au Schéma définissant le document, tandis que le mode traitement peut les utiliser dans un mode strict, n'autorisant aucune déviation. Encore une fois, l'invention permet ici de passer d'un mode à l'autre. En référence à la figure 9, il est maintenant décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de traitement apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau. Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, reliée à une carte d'entrée/sortie (non représentée) et fournissant au dispositif de traitement d'information des données multimédia, éventuellement sous forme de documents XML. Le dispositif 50 comporte un bus de communication 51 auquel sont reliés : - une unité centrale de traitement CPU 52 se présentant par exemple sous la forme d'un microprocesseur ; - une mémoire morte 53 dans laquelle peuvent être contenus les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention ; - une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention et enregistre les dictionnaires de codage/décodage prévus aux figures 6 et 7 ; - un écran 55 permettant de visualiser des données et/ou de servir 30 d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - un lecteur de disquette 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 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. Dans le cas de données audio, le dispositif 50 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 62. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 50 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50. Les disquettes 63 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de traitement d'information, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Le code exécutable permettant au dispositif de traitement la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 58 par exemple) avant d'être exécuté.
L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC). Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 4 à 8, pour mettre en oeuvre le procédé objet de la présente invention et constituer le dispositif objet de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (20)

  1. REVENDICATIONS1. Procédé de traitement pour le transcodage d'un document codé (100) à l'aide de dictionnaires, comprenant les étapes suivantes : - l'identification (E210, E510), dans un dictionnaire de décodage (300, 400), d'une première entrée (301...305, 401...404) correspondant à une donnée codée, - l'identification (E220, E540), dans un dictionnaire de codage (310, 410), d'une deuxième entrée (311...315, 411) afin d'obtenir une valeur de codage (140) pour transcoder (E230, E550) ladite donnée codée, caractérisé en ce que ladite deuxième entrée (311...315, 411) est directement déterminée depuis ladite première entrée (301...305, 401...404) à partir d'une indication (350) reliant lesdites deux entrées.
  2. 2. Procédé selon la revendication 1, comprenant une étape de constitution d'au moins une indication (350), ladite étape de constitution comprenant, lorsque aucune deuxième entrée (311...315, 411) d'un dictionnaire de codage n'est reliée à ladite première entrée : - une étape de décodage (E560) de ladite donnée codée à l'aide de la première entrée (301...305, 401...404) pour générer une représentation 20 décodée (120) de la donnée, - une étape d'identification (E570), dans le dictionnaire de codage (310, 410), d'une troisième entrée (311...315, 411) à l'aide de ladite représentation décodée (120) afin d'obtenir une valeur de transcodage de ladite donnée codée, 25 - une étape d'indication (E580) d'un lien (350) entre lesdites première et troisième entrées.
  3. 3. Procédé selon la revendication précédente, dans lequel, lorsque aucune entrée n'est identifiée dans le dictionnaire de codage (310, 410) à l'aide de la représentation décodée (120), on crée, dans ledit dictionnaire de 30 codage, une nouvelle entrée comprenant une valeur de codage de ladite représentation décodée et on renseigne (E580) une indication (350) reliant la nouvelle entrée à ladite première entrée (301...305, 401...404).
  4. 4. Procédé selon la revendication 2 ou 3, dans lequel, si ladite première entrée (301...305, 401...404) est plus générique que la troisième entrée ou la nouvelle entrée, ladite indication d'un lien (350) entre les entrées n'est pas réalisée.
  5. 5. Procédé selon l'une des revendications précédentes, dans lequel, préalablement aux opérations de transcodage du document codé, on génère des dictionnaires de codage (310, 410) et de décodage (300, 400), et on renseigne des indications (350) reliant des première et deuxième entrées.
  6. 6. Procédé selon l'une des revendications précédentes, dans lequel on sélectionne successivement plusieurs dictionnaires de codage (310, 410) en fonction des données parcoures dans ledit document, définissant de la sorte un dictionnaire courant pour une donnée du document, et ladite étape d'identification (E220, E540) d'une deuxième entrée (311...315, 411) comprend l'identification d'une pluralité d'entrées de dictionnaires de codage et la sélection de l'entrée, parmi ladite pluralité, appartenant au dictionnaire de codage courant.
  7. 7. Procédé selon l'une des revendications précédentes, dans lequel ladite indication de lien (350) comprend un pointeur sur ladite deuxième entrée (311...315, 411), prévu au niveau de ladite première entrée (301...305, 401...404).
  8. 8. Procédé selon l'une des revendications précédentes, dans lequel ladite indication de lien (350) comprend au moins une table référençant au moins une deuxième entrée (311...315, 411).
  9. 9. Procédé selon l'une des revendications précédentes, dans lequel des données constitutives des dictionnaires de codage (310, 410) et de décodage (300, 400) sont partagées.
  10. 10. Procédé selon la revendication précédente, dans lequel des entrées desdits dictionnaires de codage et de décodage sont identiques de sorte que ladite indication (350) est implicite.
  11. 11. Procédé selon l'une des revendications précédentes, dans lequel on recopie ladite donnée codée en tant que donnée transcodée.
  12. 12. Procédé selon l'une des revendications précédentes, comprenant la détermination d'une indication de transcodage associée auxdites premières entrées, et en fonction de cette indication, soit on procède à l'identification dans le dictionnaire de codage, soit on passe à une donnée codée suivante dudit document.
  13. 13. Procédé selon l'une des revendications 1 à 12, dans lequel on mémorise les premières entrées (301...305, 401...404) pour une pluralité de données codées dudit document à transcoder (100), avant de transcoder (E230, E550) la pluralité de données.
  14. 14. Procédé selon l'une des revendications 1 à 12, dans lequel on récupère, associées audit document codé, des informations décrivant l'ordre de données codées à l'intérieur dudit document.
  15. 15. Procédé selon l'une des revendications précédentes, dans lequel lesdits documents sont des fichiers XML codés au format EXI, ledit transcodage permettant de passer d'un ensemble d'options de codage EXI à un autre ensemble d'options.
  16. 16. Procédé selon l'une des revendications 1 à 14, mis en oeuvre dans un serveur informatique stockant des données codées selon un premier format de codage, pour fournir, sur requête, les données stockées codées selon un deuxième format de codage.
  17. 17. Procédé selon l'une des revendications 1 à 14, dans lequel lesdits dictionnaires de décodage et de codage correspondent respectivement à deux versions différentes d'un fichier de description structurelle de documents XML.
  18. 18. Dispositif de traitement pour le transcodage d'un document codé (100) à l'aide de dictionnaires, comprenant: - un premier moyen d'identification, dans un dictionnaire de décodage (300, 400), d'une première entrée (301...305, 401...404) 30 correspondant à une donnée codée,- un deuxième moyen d'identification, dans un dictionnaire de codage (310, 410), d'une deuxième entrée (311...315, 411) afin d'obtenir une valeur de codage (140) pour transcoder ladite donnée codée, caractérisé en ce que ledit deuxième moyen d'identification est apte à déterminer directement ladite deuxième entrée (311...315, 411) depuis ladite première entrée (301...305, 401...404) à partir d'une indication (350) reliant lesdites deux entrées.
  19. 19. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé conforme à l'une quelconque des revendications 1 à 17, lorsque le programme est chargé et exécuté par le système informatique.
  20. 20. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 17, lorsqu'il est chargé et exécuté par le microprocesseur.
FR0900436A 2009-02-02 2009-02-02 Procede de transcodage d'un document code, et dispositif associe Expired - Fee Related FR2941803B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0900436A FR2941803B1 (fr) 2009-02-02 2009-02-02 Procede de transcodage d'un document code, et dispositif associe

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0900436A FR2941803B1 (fr) 2009-02-02 2009-02-02 Procede de transcodage d'un document code, et dispositif associe

Publications (2)

Publication Number Publication Date
FR2941803A1 true FR2941803A1 (fr) 2010-08-06
FR2941803B1 FR2941803B1 (fr) 2016-02-05

Family

ID=41168715

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0900436A Expired - Fee Related FR2941803B1 (fr) 2009-02-02 2009-02-02 Procede de transcodage d'un document code, et dispositif associe

Country Status (1)

Country Link
FR (1) FR2941803B1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010056504A1 (en) * 1999-12-21 2001-12-27 Eugene Kuznetsov Method and apparatus of data exchange using runtime code generator and translator

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010056504A1 (en) * 1999-12-21 2001-12-27 Eugene Kuznetsov Method and apparatus of data exchange using runtime code generator and translator

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MICHELE VALLISNERI ET AL: "Python and XML for Agile Scientific Computing", COMPUTING IN SCIENCE AND ENGINEERING, IEEE SERVICE CENTER, LOS ALAMITOS, CA, US, vol. 9, no. 1, 1 January 2008 (2008-01-01), pages 80 - 87, XP011199629, ISSN: 1521-9615 *
SCHNEIDER J ET AL: "Efficient XML Interchange (EXi) Format 1.0 - W3C Working Draft", W3C WORKING DRAFT, XX, XX, 26 March 2008 (2008-03-26), pages 1 - 100, XP002515320, Retrieved from the Internet <URL:http://www.w3.org/TR/2008/WD-exi-20080326/> [retrieved on 20090216] *

Also Published As

Publication number Publication date
FR2941803B1 (fr) 2016-02-05

Similar Documents

Publication Publication Date Title
FR2926378A1 (fr) Procede et dispositif de traitement pour l&#39;encodage d&#39;un document de donnees hierarchisees
US10095694B2 (en) Embedding content-based searchable indexes in multimedia files
FR2924244A1 (fr) Procede et dispositif d&#39;encodage et de decodage d&#39;information
FR2933793A1 (fr) Procedes de codage et de decodage, par referencement, de valeurs dans un document structure, et systemes associes.
FR2936623A1 (fr) Procede de codage d&#39;un document structure et de decodage, dispositifs correspondants
FR2907567A1 (fr) Procede et dispositif de generation de motifs de reference a partir d&#39;un document ecrit en langage de balisage et procedes et dispositifs de codage et de decodage associes.
FR2914759A1 (fr) Procede et dispositif de codage d&#39;un document hierarchise
FR2939535A1 (fr) Procede et systeme de traitement pour la configuration d&#39;un processseur exi
FR2963841A1 (fr) Systeme de traduction combinant des modeles hierarchiques et bases sur des phases
US8949207B2 (en) Method and apparatus for decoding encoded structured data from a bit-stream
FR2927712A1 (fr) Procede et dispositif d&#39;acces a une production d&#39;une grammaire pour le traitement d&#39;un document de donnees hierarchisees.
FR2906383A1 (fr) Referentiel semantique de services web et procede utilisant ce referentiel
EP1358583A1 (fr) Procede de codage et de decodage d&#39;un chemin dans l&#39;arborescence d&#39;un document structure
FR2930661A1 (fr) Procede d&#39;acces a une partie ou de modification d&#39;une partie d&#39;un document xml binaire, dispositifs associes
FR2943441A1 (fr) Procede de codage ou decodage d&#39;un document structure a l&#39;aide d&#39;un schema xml, dispositif et structure de donnees associes
FR2919400A1 (fr) Procede et dispositif d&#39;encodage d&#39;un document structure et procede et dispositif de decodage d&#39;un document ainsi encode.
FR2913274A1 (fr) Procede et dispositif de codage de document et procede et dispositif de decodage de document.
FR2901037A1 (fr) Procede et dispositif de generation de motifs structurels de reference aptes a representer des donnees hierarchisees
FR2941803A1 (fr) Procede de transcodage d&#39;un document code, et dispositif associe
EP1194868B1 (fr) Methode et systeme de creation de documents electroniques - auto-publiants et adaptatifs
FR2954983A1 (fr) Procede et dispositif de codage d&#39;un document structure memorise sous forme d&#39;arbre dom
FR2911200A1 (fr) Procede et dispositif de traitement de documents a partir de schemas enrichis et procede et dispositif de decodage correspondants
FR2941071A1 (fr) Procede et systeme de configuration d&#39;un processeur exi
EP1713243A1 (fr) Procédé et système de génération automatique de composants logiciels pour la conception de services vocaux
FR2913275A1 (fr) Procede et dispositif de codage d&#39;un document et procede et dispositif de decodage d&#39;un document.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

ST Notification of lapse

Effective date: 20171031