FR 2941071 A1 20100716 FR 0950163 A 20090113 La présente invention concerne un procédé et un système de configuration d'un processeur de codage/décodage de données structurées. Elle s'applique, en particulier, aux documents de type XML (acronyme de "Extensible Markup Language" pour langage de balisage extensible) et aux processeur de type EXI ("Efficient XML Interchange") 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: ) et se terminant par une balise fermante comportant, elle aussi, le nom de l'élément (par exemple: ). 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 : ). La syntaxe XML permet aussi de définir des commentaires (par exemple: ) et des instructions de traitement, qui peuvent préciser à une application informatique les traitements à appliquer au document XML (par exemple : � �), 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 : � Echappement ]]> � où 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 �. Plusieurs langages différents basés sur le XML peuvent contenir des 5 éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage (� Namespace � selon la terminologie anglo-saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI 10 (acronyme de � Uniform Resource Identifier �, pour Identifiant uniforme de ressource), par exemple � http://canon.crf.fr/xml/monlangage �. L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: l'attribut 15 � xmlns:ml="http://canon.crf.fr/xml/monlangage" � associe le préfixe � ml � à l'URI � http://canon.crf.fr/xml/monlangage �). Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de � : � (par exemple: � � indique que l'élément balise découle de 20 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é 25 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 30 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, des méthodes pour encoder un document XML ont été recherchées. Le but de ces méthodes est de coder le contenu du document XML sous une forme plus compacte, permettant de reconstruire facilement le document XML. Une méthode simple consiste par exemple à remplacer les items 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 Interchange") ou Fast Infoset, permettant de conserver nombre d'avantages du format XML malgré le codage. EXI est un format XML Binaire actuellement standardisé par le W3C qui utilise un ensemble de grammaires ainsi que des tables de vocabulaire (ou "dictionnaires de valeurs") pour décrire et coder un document XML. Les grammaires permettent de coder efficacement la structure du document, alors que les tables de vocabulaire, qui recensent le vocabulaire rencontré, permettent de coder efficacement des chaînes de caractères qui se répètent, par l'utilisation d'un identifiant numérique à partir de la deuxième apparition d'une chaîne donnée. Pour la suite du document on définit le � contexte de codage � comme étant l'ensemble des grammaires et des tables de vocabulaire utilisées pour encoder ou décoder un document. Pour pouvoir coder les items compris dans un document XML, la spécification Efficient XML divise chacun des éléments rencontrés dans le document à coder, en parties élémentaires appelées événements, par exemple une balise ouvrante ou un attribut. 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 le codage de l'événement suivant). 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, et les informations contenues dans l'événement et non décrites dans la production sont codées. Une grammaire selon Efficient XML (et donc le contexte de codage) 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 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 numériques �, 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é. Selon le mode de codage le plus avantageux en termes de compression, chaque niveau est codé sur un nombre de bit minimum pour pouvoir coder la plus grande valeur de ce niveau associée à une production de la grammaire. Par exemple, pour un niveau prenant des valeurs de 0 à 6, on utilise 3 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'élément XML présent dans le document (un type d'élément XML étant un ensemble d'éléments ayant le même nom, éventuellement dans un même contexte [lequel tient compte des types d'éléments parents de l'élément considéré]), un même ensemble de grammaires est utilisé pour coder les éléments XML de ce type. Les règles de grammaires utilisées peuvent être des règles génériques, communes à tous les documents XML et construites à partir de la syntaxe XML. Mais elles peuvent aussi être des règles spécifiques à un type de document lorsqu'elles sont construites au préalable. Cela permet d'obtenir un codage (ou décodage) plus efficace en termes de compression. Lors du décodage, le processus inverse est utilisé : la valeur de codage est extraite et permet d'identifier l'événement XML codé, ainsi que les informations complémentaires à décoder à partir des productions. 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 et de productions identique à celui qui était utilisé lors du codage. Deux types d'alignement sont fournis par le format EXI pour représenter les valeurs de codage : un format en octets alignés (en anglais, "byte-aligned ), pour lequel les données encodées sont alignées au niveau des octets, c'est-à-dire que chaque nouvelle chaîne de caractères débute sur un nouvel octet, par exemple, et un format en bits groupés (en anglais, "bitpacked ), pour lequel les données sont encodées sur le plus petit nombre de bits possibles. Dans ce dernier mode, les chaînes de caractères ne commencent donc pas nécessairement sur un nouvel octet. Le premier mode peut être décodé plus efficacement, tandis que le second produit des fichiers davantage compressés. La norme EXI introduit également un mode dit "EXI Schéma" qui se base sur les schémas XML. Ces derniers décrivent des modèles de données représentatifs de structures, et à ce titre il est possible de construire des grammaires représentant ce modèle, et donc un contexte de codage spécifique pour le processeur EXI. Dans le mode EXI Schéma, on utilise un tel schéma afin de créer des grammaires, et on utilise ensuite ces grammaires pour coder ou décoder un document. Le mode EXI Schéma permet d'obtenir une meilleure compression que lorsque les grammaires sont apprises depuis le document. En effet, considérons l'exemple simplifié suivant de données structurées, dans lequel un élément comprend trois éléments successifs , et dans cet ordre : . Selon la spécification EXI, si aucun schéma n'est utilisé, les éléments , et figurent dans la même grammaire, celle qui décrit le contenu de l'élément . En revanche, avec un schéma XML, il devient possible de savoir que les éléments , et se produisent toujours dans le même ordre, par l'indication de la propriété "séquence" définie par la norme. Cette précision permet de créer davantage de grammaires pour ces éléments, chaque grammaire contenant une seule production: une grammaire pour le passage de vers , une autre pour le passage de vers , etc. En réduisant le nombre de productions par grammaire, on réduit le nombre de bits nécessaires pour coder les priorités, et dans l'exemple ici, puisqu'une seule production demeure par grammaire, il n'y a même plus lieu de coder la production associée (qui est toujours choisie lorsque la grammaire est appelée). La création des grammaires à partir d'un schéma XML est décrite dans la spécification EXI. Comme il arrive que les documents instanciant un schéma ne respectent pas parfaitement le modèle défini, il est possible de choisir un sous-mode autorisant les déviations par rapport au schéma. Dans ce cas, on insère des productions supplémentaires dans les grammaires afin de pouvoir encoder les parties qui ne respectent pas strictement le schéma. De cette manière, on profite de la connaissance du schéma sans pour autant nécessiter des documents parfaitement conformes. Néanmoins, du fait des productions supplémentaires, la compression est moins importante que dans le cas où l'on n'autorise pas les déviations. La norme EXI propose également une gestion particulière du contexte de codage dans le cas d'événements dits "auto-contenus". La propriété "auto-contenu" permet d'indiquer que le contenu d'un élément XML peut-être décodé indépendamment du reste du document dans lequel cet élément apparaît. Lorsqu'un tel événement est rencontré, le contexte de codage courant est sauvegardé, et le contexte de codage initial obtenu pour le décodage du document considéré est rétabli pour le codage de l'événement auto-contenu. Cela signifie que l'on mène le décodage (ou le codage) comme si le contenu de l'élément auto-contenu figurait au début du document. On décode alors le contenu de l'élément auto-contenu, et lorsque l'on arrive à la fin de cet élément, on rétablit le contexte sauvegardé pour poursuivre le décodage du reste du document. Comme on le voit ci-dessus, la norme EXI permet de configurer un contexte de codage d'un processeur EXI à partir de données externes de configuration, en l'espèce des schémas XML, afin d'améliorer la compression des données structurées et des documents correspondants. Toutefois, ces schémas doivent être traités quand on encode ou décode un document afin de construire des grammaires et des tables de vocabulaire. Ce traitement qui comprend, entre autres, la lecture et l'analyse des schémas, ainsi que la création du contexte de codage, est assez coûteux, en particulier pour traiter des fichiers courts. En effet, le traitement des schémas XML, même s'il n'y en a qu'un seul, représente un coût fixe, qui prend donc une part d'autant plus importante dans le traitement que le fichier traité est court. Pour réduire ce temps de traitement, certaines bibliothèques de programmes implémentant la norme EXI (par exemple Efficient XML) proposent de produire une version compilée du schéma XML, version à partir de laquelle la construction du contexte de codage est réalisée plus rapidement. L'intérêt de cette version compilée vient du fait qu'il n'est plus nécessaire d'analyser un schéma XML à chaque fois que l'on en a besoin. Cependant, le besoin de lire des données externes de configuration (schéma XML ou équivalent) puis de créer le contexte de codage demeure. Dans certains cas de traitements, les fichiers à traiter appartiennent à un ensemble limité de types et connu. Dans ce cas, les contextes utilisés pour le traitement de ces fichiers présentent généralement de fortes similitudes. A titre d'exemple, dans un appareil photo, on peut être amené à traiter uniquement deux types différents de fichiers: des fichiers SVG ("Scalable Vector Graphics", format de description d'objets graphiques vectoriels) pour l'interface graphique, et des fichiers XML pour décrire les photos. Les mécanismes de l'art antérieur pour configurer le contexte de codage du processeur EXI présentent tous l'inconvénient de devoir, pour le codage d'un nouveau fichier, lire à nouveau les données externes de configuration (schéma XML compilé ou non) et générer intégralement le contexte de codage initial correspondant. La présente invention vise à résoudre cet inconvénient de l'art antérieur et donc à rendre la configuration du contexte de codage du processeur EXI plus efficace. Dans ce dessein, l'invention vise notamment un procédé de configuration d'un processeur de codage/décodage pour le codage/décodage de nouvelles données structurées, ledit processeur comprenant en mémoire un contexte de codage/décodage relatif au traitement d'anciennes données structurées, le contexte étant composé d'une pluralité de sous-contextes, le procédé comprenant les étapes suivantes : - la détermination d'un ensemble de sous-contextes définissant un contexte de codage/décodage desdites nouvelles données structurées ; - l'identification et la suppression, dans le contexte de codage/décodage en mémoire du processeur, d'au moins un sous-contexte non compris dans l'ensemble déterminé de sorte à conserver les sous-contextes appartenant audit ensemble. On considère ici les contextes de codage comme des ensembles de sous-contextes. L'invention permet de gérer efficacement le passage d'un contexte de codage d'un premier document (ou fragment de document) à celui d'un second document (ou fragment de document). En effet, lors du changement de contexte de codage, on conserve les sous-contextes communs aux deux contextes de codage se succédant. On tire profit des similitudes entre les contextes de codage successifs. De la sorte, on réduit les opérations de traitement et de lecture de données externes de configuration nécessaires au chargement des sous-contextes pour procéder au codage/décodage ultérieur. A l'opposé des solutions connues de l'art antérieur où les contextes étaient, à chaque fois, intégralement rechargés, l'invention accélère la configuration du processeur de codage/décodage. Les gains apportés par l'invention sont d'autant plus importants que les fichiers à traiter sont fréquents (par exemple parce qu'ils sont courts) et qu'ils présentent plusieurs sous- contextes similaires (par exemple parce qu'ils mettent en oeuvre des types d'élément identiques). L'invention s'applique particulièrement bien à la reconfiguration du processeur EXI pour le codage/décodage d'un nouveau document mais également pour la gestion des éléments auto-contenus au sens de la norme EXI. Dans ce cas, on utilise des informations spécifiques pour améliorer la compression d'un élément auto-contenu. En plus du contexte initial de codage (qui est rétabli lorsque l'on arrive sur un élément auto-contenu), on peut prendre en compte un profil de configuration (un schéma XML par exemple) dédié à ce type d'élément spécifique, afin de charger un sous-contexte spécifique comprenant des grammaires décrivant l'élément et/ou un vocabulaire contenant des valeurs apparaissant fréquemment dans son contenu. De cette manière, on améliore la compression de cet élément auto-contenu, sans pour autant pénaliser la compression du reste du document, puisque les valeurs spécifiques, par exemple, ne sont prises en compte qu'à l'intérieur de l'élément auto-contenu. Dans un mode de réalisation, ledit contexte de codage/décodage comprend un sous-contexte dynamique comprenant des informations de codage/décodage apprises par le processeur pendant le traitement (codage/décodage) desdites anciennes données, et au moins un sous-contexte statique comprenant des informations de codage/décodage créées par le processeur à partir de données de configuration externes. Le cas où l'on a un seul sous-contexte statique représente la situation la plus simple. Dans ce cas, le sous-contexte dynamique est généralement supprimé et on conserve le sous-contexte statique pour le traitement d'un nouveau document. Les processeurs EXI de l'état de l'art nécessitent, eux, le rechargement intégral de ce sous-contexte statique, notamment du fait qu'ils ne font aucune différence entre les deux sous-contextes statique et dynamique évoqués ici. Ainsi, en particulier, ladite suppression comprend celle du sous-contexte dynamique. Dans un mode de réalisation, ladite suppression dans le contexte comprend l'enregistrement en mémoire dudit au moins un sous-contexte supprimé. Cette configuration permet, dans le cas où l'on doit réutiliser ultérieurement des sous-contextes statiques supprimés antérieurement, d'éviter de relire les profils de configuration à partir desquels ils ont été construits la première fois. Une simple copie depuis la mémoire de stockage des sous- contextes supprimés suffit. On réalise ainsi un gain de temps, bien qu'il soit nécessaire de disposer de davantage de mémoire. Dans ce dessein, on prévoit que la mémoire stockant le sous-contexte supprimé a une taille limitée, et on supprime le sous-contexte en mémoire le moins utilisé lorsque la taille mémoire encore disponible est inférieure à la taille du sous-contexte supprimé à enregistrer. D'autres politiques sont possibles comme celle qui consiste à conserver un ensemble de M sous-contextes au maximum (M étant par exemple défini en fonction de contraintes de mémoire), et à éliminer, si l'on atteint cette limite, le sous-contexte le moins fréquemment utilisé, ou bien celui dont la dernière utilisation remonte le plus loin dans le temps. De façon proche, dans le cas où le fait de ne pas supprimer un sous-contexte de codage n'a pas d'impact sur le flux encodé ou décodé (autrement dit, si la suppression du sous-contexte est possible mais pas nécessaire), au lieu de supprimer ce sous-contexte, on peut simplement le marquer comme facultatif et le supprimer de la mémoire uniquement si l'on atteint une certaine limite de mémoire. Dans un mode de réalisation, le procédé comprend le chargement d'un sous-contexte non présent dans ledit contexte en mémoire du processeur et appartenant audit ensemble déterminé. Cette opération permet de configurer le contexte du processeur en fonction du document ou des données à traiter. On itère notamment ce chargement pour l'ensemble des sous-contextes non présents dans le contexte initialement en mémoire et appartenant à l'ensemble déterminé. En particulier, ledit chargement comprend la copie dudit sous-contexte depuis une mémoire stockant des sous-contextes inactifs vers ledit contexte en mémoire du processeur. Cette disposition est à rapprocher de la sauvegarde des sous-contextes en mémoire et présente donc le même intérêt: éviter un nouveau traitement des données externes de configuration type schéma XML. Dans un mode de réalisation, les sous-contextes sont disjoints deux à deux, notamment au sens où les sous-contextes ne concernent que des éléments structurés distincts. Dans ce cas, la gestion du contexte de codage, donc des grammaires et autres partitions de dictionnaires, est simplifiée. On obtient ainsi un gain notable d'efficacité et de rapidité lors du changement de contexte de codage/décodage. Selon une caractéristique de l'invention, le procédé comprend l'ordonnancement des sous-contextes conservés et chargés. Cet ordonnancement permet de garantir que les informations de codage (priorités et identifiants) sont les mêmes pour un même contexte bien que ce dernier ait été constitué à partir de contextes antérieurs distincts. On prévoit alors que le procédé comprend une étape de (re)calcul de valeurs de codage (priorités pour les productions, identifiants pour les valeurs de dictionnaires) pour les sous-contextes ordonnés. Dans un mode de réalisation de l'invention, les sous-contextes sont issus d'un ensemble de sous-contextes comprenant un sous-contexte général décrivant des éléments communs à plusieurs ensembles de données structurées (en pratique à plusieurs documents) et des sous-contextes spécialisés décrivant des éléments spécifiques à chacun desdits ensembles de données. Cette configuration est particulièrement adaptée pour traiter efficacement une famille de documents présentant des variations significatives dans leurs contenus. En variante, les sous-contextes sont issus d'un ensemble de sous-contextes hiérarchiques. En variante encore, lesdits contextes sont répartis en deux parties disjointes de sous-contextes, l'une décrivant des informations de structure, et l'autre partie décrivant des informations de contenus. Cette configuration permet de rendre efficace la compression successive de documents ayant par exemple des contenus variables mais des structures fortement similaires (ou vice et versa). Dans un mode de réalisation, lors du chargement, on indique, pour chaque information d'un sous-contexte chargé dans ledit contexte en mémoire du processeur, le sous-contexte auquel elle est attachée. De la sorte, l'étape d'identification des informations à supprimer en vue de la suppression d'un sous-contexte peut être menée efficacement. En particulier, le contexte est formé de grammaires associant des productions à des valeurs de codage, et de dictionnaires (ou tables de vocabulaire) dont les entrées associent des chaînes de caractères à des identifiants de codage, et ladite indication de sous-contexte est renseignée au niveau des productions et des entrées des dictionnaires. Cette indication portée sur les entrées des grammaires et dictionnaires permet de distinguer explicitement celles-ci en fonction des sous-contextes, alors que plusieurs sous-contextes peuvent influer sur une même grammaire ou sur un même dictionnaire. L'identification des informations à supprimer peut être menée plus efficacement qu'en signalant par exemple les dépendances uniquement au niveau des grammaires et dictionnaires. Selon une caractéristique particulière, le contexte est formé de grammaires et de dictionnaires présentant des partitions, et on associe, à chaque grammaire et partition, un compteur du nombre de sous-contextes qui lui sont liés. En pratique, on incrémente et décrémente les compteurs adéquats lors, respectivement, du chargement et de la suppression d'un sous-contexte qui était lié à la grammaire/partition correspondante. Les partitions sont à entendre, ici, au sens de la norme EXI, c'est-à-dire des parties de dictionnaires qui sont dédiées au codage des valeurs ou chaînes de caractères associées à un élément structuré spécifique. Elles permettent d'utiliser des identifiants de codage plus courts. Dans cette configuration, l'état du compteur permet de savoir rapidement si l'on peut traiter (notamment lors de l'étape de suppression) la grammaire ou la partition dans son ensemble ou bien si l'on doit effectuer les opérations de suppression/ajout au niveau des productions de la grammaire et des entrées de la partition. Différentes utilisations de l'invention peuvent être envisagées. Selon l'une d'elle, les anciennes et nouvelles données structurées sont chacune un document structuré différent. Ainsi, on passe du traitement (codage ou décodage) d'un premier document au traitement d'un deuxième document. La suppression suivie du chargement permet la configuration initiale du processeur. Selon une autre, les anciennes et nouvelles données structurées appartiennent à un même document. Ici, les étapes d'identification, suppression et chargement sont mises en oeuvre lors du codage/décodage d'un même document et mettent à jour le contexte de codage/décodage pour le traitement d'une nouvelle donnée structurée à l'intérieur du document. L'art antérieur connu n'envisage pas de modifier ainsi le contexte en cours de traitement du document. En particulier, les nouvelles données structurées comprennent un élément auto-contenu au sens de la norme EXI. Dans un mode de réalisation, ladite détermination comprend la détermination d'un type représentatif desdites nouvelles données structurées, et ledit ensemble des sous-contextes est déterminé à partir dudit type. L'utilisation d'une unique information (le type) entre les données à traiter et les sous-contextes qui leurs sont liés procure une efficacité importante dans les opérations de détermination, car ces opérations sont simples. En particulier, ledit type est déterminé à partir desdites nouvelles données. En variante, ledit type est déterminé à partir d'une règle de correspondance liant le nom d'un fichier comprenant les nouvelles données structurées à un type. Dans un mode de réalisation, ledit chargement d'un sous-contexte est réalisé à partir d'un fichier de configuration de type Schéma XML. En effet, un tel schéma est adapté à décrire des données structurées et donc à fournir les informations nécessaires à les coder/décoder (c'est-à-dire les informations des grammaires et dictionnaires). Corrélativement, l'invention vise également un dispositif de configuration d'un processeur de codage/décodage pour le codage de nouvelles données structurées, ledit processeur comprenant en mémoire un contexte de codage/décodage relatif au traitement d'anciennes données structurées, le contexte étant composé d'une pluralité de sous-contextes, le dispositif comprenant : - un moyen de détermination d'un ensemble de sous-contextes définissant un contexte de codage/décodage desdites nouvelles données structurées ; - un moyen d'identification et de suppression, dans le contexte de codage/décodage en mémoire du processeur, d'au moins un sous-contexte non compris dans l'ensemble déterminé de sorte à conserver les sous-contextes appartenant audit ensemble. De façon optionnelle, le dispositif peut comprendre des moyens se 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 procédé de configuration 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 configuration 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 schématiquement un processeur EXI pour la mise en oeuvre de l'invention ; - les figures 2a à 2e illustrent la formation de contexte de codage pour la mise en oeuvre de l'invention ; - la figure 3 représente, sous forme de logigramme, des étapes du procédé selon l'invention ; - la figure 4 représente, sous forme de logigramme, des étapes pour la détermination de sous-contextes mise en oeuvre dans le procédé de la figure 2 ; - la figure 5 représente, sous forme de logigramme, des étapes pour la suppression de sous-contextes dans le procédé de la figure 2 ; - la figure 6 représente, sous forme de logigramme, des étapes pour l'ajout de sous-contextes dans le procédé de la figure 2 ; et - la figure 7 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 illustre maintenant l'invention par un exemple de décodage de fichiers SVG par un processeur EXI. Les fichiers SVG sont préalablement encodés à l'aide de plusieurs modèles, typiquement des Schémas XML, décrivant les données contenues dans ces fichiers, afin d'améliorer leur taux de compression. Ces modèles permettent de paramétrer la configuration initiale du processeur EXI de façon similaire au mode Schéma EXI de l'art antérieur. Ici, on distingue deux types de fichiers SVG : un premier type dit "Image", qui décrit des images fixes, et un deuxième type dit "Animation", qui décrit des animations. Comme représenté sur la figure 1, un processeur EXI 1 utilisé pour le codage ou le décodage de documents structurés tels que le XML, comprend une mémoire vive 10 mémorisant un contexte de codage 12 pour le codage/décodage d'un document, ici un fichier SVG. Ce contexte 12 correspond à l'ensemble des informations qui permettent de savoir comment encoder ou décoder un événement XML. Il comprend typiquement deux types d'objets : les grammaires GRAM telles que prévues par la norme EXI, qui décrivent la structure des données XML, et les tables de vocabulaire VOCA, également prévues par la norme EXI sous le terme de "string tables", qui contiennent des chaînes de caractères. Cinq tables de vocabulaire sont distinguées dans la spécification EXI : - trois concernent des informations sur les noms qualifiés (un nom "qualifié" comprend un nom local [par exemple � balise �], une URI [par exemple � xmlns:ml="http://canon.crf.fr/xml/monlangage �], et éventuellement un préfixe [par exemple � ml �]) et les espaces de nommage (une pour les URI, une pour les préfixes, une pour les noms locaux), et - deux concernent des informations sur les valeurs textuelles, qui apparaissent pour un attribut ou pour un événement de contenu textuel (une table locale et une table globale). Ces grammaires et tables de vocabulaire sont largement documentées dans la norme EXI et ne sont pas décrites plus en détail ici. Sur la figure 1, le contexte de codage 12 est composé de plusieurs sous-contextes 14 et 16, chacun définissant une partie du contexte 12. Si l'on traite un document XML, on a toujours au moins deux sous-contextes : au moins un sous-contexte statique 14, qui correspond aux données présentes dans le contexte de codage au début du traitement des données, et un sous-contexte dynamique 16, qui correspond aux données apprises durant le traitement des données du document XML par le processeur EXI. Le sous- contexte statique peut être réduit à sa plus simple expression: des grammaires par défaut au sens EXI, lorsque aucune donnée initiale de configuration n'est utilisée. Pour l'invention, on considérera généralement que le contexte initial contient des informations autres que les grammaires par défaut. Comme on le verra par la suite, plusieurs sous-contextes statiques 141, 14; peuvent être utilisés. Le but de la division du contexte 12 en sous-contextes 14, 16 est de pouvoir effectuer des opérations sur ces sous-contextes. Un sous-contexte de codage 14, 16 comprend des informations relatives à des grammaires GRAM et à des tables de vocabulaire VOCA. On définit donc un sous-contexte 14, 16 comme un ensemble de références vers des éléments du contexte de codage, c'est-à-dire des références vers des grammaires GRAM, et des entrées des tables de vocabulaire VOCA, typiquement des partitions. On distingue deux types de tables de vocabulaire VOCA : celles qui sont simplement constituées de valeurs, par exemple la liste des valeurs globales qui recense des valeurs pouvant apparaître n'importe où dans un document, et celles qui sont constituées de partitions, par exemple la liste des valeurs locales attachées à un type d'élément XML précis (par exemple toutes les valeurs que prend un élément "enfant"). Comme définie par la spécification EXI, une partition des tables VOCA est une sous-table, cette sous-table contenant un certain nombre d'entrées. Dans le cas des valeurs locales, l'information locale (le nom de l'attribut ou de l'élément dans lequel on rencontre la valeur textuelle) donne un critère de distinction des valeurs rencontrées et donc différentes partitions. En séparant les valeurs suivant ce critère, on constitue les partitions, on minimise le nombre de valeurs possibles dans un contexte donné (le contexte étant ici le fait d'être à l'intérieur d'un attribut ou d'un élément donné, i.e. une partition), et le code numérique utilisé pour l'identifiant correspondant à la valeur à coder est alors plus court. La compression en devient plus efficace. La table VOCA des valeurs locales contient donc, pour chaque attribut ou élément dans lequel on rencontre une valeur textuelle, une partition, cette partition contenant des entrées, chaque entrée consistant en un identifiant et une valeur textuelle. Pour la mise en oeuvre de l'invention, on indique, au niveau de chaque production et de chaque entrée d'une partition, la liste des sous- contextes auxquels elle (production ou entrée) est liée. Cette indication peut être un simple champ additionnel référençant un numéro de sous-contexte. Comme on le verra par la suite, cette indication permet une gestion efficace lorsque une grammaire ou une partition est liée à plusieurs sous-contextes 14, 16. En effet, dans ce cas les références vers les grammaires et partitions ne permettent pas de distinguer les productions et entrées associées à tel ou tel sous-contexte 14, 16. Pour l'invention, un sous-contexte statique 14 est appris par le processeur EXI via des données de configuration externes, par exemple un schéma XML, ou plus généralement un profil 20. Cet apprentissage est par exemple conforme au mode Schéma EXI déjà évoqué. On prévoit donc un ensemble de profils externes 201, 202, 20n associés chacun à sous-contexte statique 14;. Par profil 20, on entend la description externe d'un modèle de données, comprenant des indications de structure et/ou de contenu, qui permet de créer des grammaires et/ou des tables de vocabulaire pour un processeur EXI. Les schémas XML répondent à cette définition. Toutefois, tout modèle décrit dans un langage structuré, ainsi que les descriptions compactes de grammaires dans un format dédié peuvent être envisagés. On assimile parfois, dans la suite du document, les termes "profil" et "sous-contexte" pour désigner les informations de codage spécifiques à la structure et au contenu décrit. Toutefois, le terme "profil" aura vocation principalement à désigner de telles informations lorsqu'elles sont considérées comme une connaissance externe pour configurer le processeur, et le terme "sous-contexte" pour désigner ces informations lorsqu'elles constituent une structure interne au processeur. Dans certains cas, quand on considère un ensemble de documents structurés, ces documents présentent des structures et des contenus proches, et l'on peut alors les modéliser efficacement avec un seul profil 20. En revanche, dans d'autres cas, une même famille de documents peut présenter des variations significatives, et il peut alors être intéressant de définir plusieurs profils 20 pour modéliser ces données, avec par exemple un profil général 201 décrivant les informations communes à tous les documents, et des profils spécialisés 202, 20n, décrivant chacun une variante spécifique aux différents documents. De retour à notre exemple des fichiers SVG "Image" et "Animation", on dispose de trois profils 201, 202 et 203. Ces profils au format Schéma XML et/ou sous forme de description compacte de grammaires et contenus au format XML sont générés par des mécanismes classiques de génération, par exemple de fichiers XML, que l'on ne décrit pas plus en détail ici pour cette raison. Les trois profils comprennent : - un profil Général 201, valable pour les deux types de fichiers car regroupant des informations communes ; - un profil Image 202, utilisé en complément du profil Général dans le cas des images fixes ; et - un profil Animation 203 utilisé en complément du profil Général dans le cas des animations. Ces trois profils 201, 202 et 203 sont représentés sur la figure 2a. Chaque profil décrit une liste d'éléments XML, les attributs et les enfants possibles pour ces éléments. Par exemple, pour le profil 201, l'élément "SVG" (qui est l'élément racine du document) comprend deux attributs "height" et "width", et un élément enfant "path" dont les composantes attributs sont également listées. Dans ces profils, les valeurs entre parenthèses sont des valeurs fréquentes pour les attributs considérés, par exemple l'attribut "height" prend fréquemment la valeur "100%". Ces valeurs constituent un vocabulaire initial pour le processeur EXI lorsqu'il se configure avec ce profil, comme on le verra par la suite. D'une façon générale, il est préférable de disposer d'un maximum d'informations pour décrire des modèles destinés à paramétrer un processeur EXI (notamment les transitions possibles entre attributs et entre enfants). Dans notre exemple, on se limite cependant à des informations limitées et essentielles afin de rendre les explications plus facilement compréhensibles. Dans notre exemple, on crée un processeur EXI afin de décoder un des fichiers SVG préalablement encodés, par exemple le fichier "image.svg.exi" représentant un fichier de type "Image". Il s'agit du premier fichier à décoder, le contexte de codage 12 est donc vide. Pour le configurer correctement, on détermine tout d'abord quels ont été les profils 20 utilisés pour encoder ce fichier. L'information permettant cette détermination peut être contenue dans le fichier lui-même, par exemple en utilisant un champ d'en-tête destiné à spécifier des données externes utilisées lors de l'encodage (notamment un schéma XML), ou bien par exemple grâce à une table associant chaque fichier à différents profils. Dans l'exemple, on tire du nom du fichier le type auquel il correspond: "Image"; et on déduit que l'on doit utiliser les profils Général 201 et Image 202. On utilise ces deux profils de façon classique pour initialiser le processeur EXI, c'est-à-dire pour créer un contexte initial de codage 12, composé de grammaires GRAM et de tables de vocabulaire VOCA. La figure 2b présente les grammaires obtenues à partir du profil Général 201. Dans certains cas (par exemple celui de l'élément "svg"), il existe deux grammaires par élément, une grammaire � StartTag � destinée à modéliser le début de l'élément (notamment les attributs), et une grammaire � ElementContent � destinée à représenter les enfants de l'élément. Cette distinction est spécifique au format EXI dont elle contribue à l'efficacité. La grammaire � StartTag svg � comprend ainsi une production pour coder un nouvel élément "path" : production SE path; et des productions pour coder les attributs: productions ATT. On note ici que l'on n'a pas représenté les valeurs des priorités utilisées pour coder ces productions, mais qu'elles peuvent être déterminées de façon classique conformément à la spécification EXI, par exemple en attribuant une valeur de priorité sur un seul niveau pour chaque production. En revanche on indique pour chaque production le sous-contexte SC1 (associé au profil 201) auquel elle est liée. Une grammaire � StartTag path � permet de façon similaire de coder le contenu d'un élément "path". Cette grammaire comprend les productions SE path et EE (fin d'élément) associées au sous-contexte SC1. Chacune des grammaires GRAM renseigne également du contexte auquel elle est liée (par au moins une production), ici uniquement le contexte SC1 (voir en-tête des grammaires sur la figure 2b). Le traitement du profil Image 202 amène l'ajout de nouvelles grammaires au contexte de codage 12, ainsi que l'ajout de nouvelles productions à certaines grammaires existantes (� StartTag svg � et � ElementContent svg �). En effet, le profil Image 202 apporte des informations complémentaires sur l'élément � svg � défini dans le profil Général 201, dont il faut tenir compte pour le décodage des fichiers svg. Les grammaires du contexte de codage 12 ainsi obtenues sont représentées en figure 2c, les valeurs de priorités n'étant pas représentées. Au sein des grammaires GRAM, on distingue les productions liées à tel ou tel sous-contexte statique 14;, grâce à l'indication 24 du profil SC; correspondant. On visualise également de façon globale, à l'aide des références aux grammaires, à quels contextes chaque grammaire est liée: par exemple les références 22 permettent de lire rapidement que la grammaire � StartTag svg � est liée aux contextes SC1 et SC2. On peut cependant aisément s'affranchir de cette référence 22 dans la mesure où les indications au niveau de chaque production permettent de déduire ces dépendances. Concernant l'autre partie du contexte de codage 12, à savoir les tables de vocabulaire, on décrit ici uniquement la table recensant les valeurs rencontrées pour les différents attributs. La figure 2d représente cette table. Pour chaque nom d'attribut, on utilise, selon la terminologie EXI, une partition P distincte d'une table de vocabulaire. Cette partition associe des identifiants et des valeurs. Ici, on aura par exemple une partition pour l'attribut � width �, cette partition associant les identifiants 0 et 1 aux valeurs � 100% � et � 250 � (valeurs fréquentes de l'attribut � width � selon les profils Général et Image). On indique également à quel sous-contexte SC; (à l'aide du profil 20 correspondant) chacune des entrées correspond: l'entrée "100%" de la partition "width" est notamment liée au profil 201 et donc au sous-contexte associé référencé SC1. Suivant l'ordre dans lequel on ajoute les sous-contextes, les identifiants 0 et 1 ne désigneront pas les mêmes valeurs, c'est pourquoi, dans le cas général, on ordonne les sous-contextes SC; et donc les profils associés 20;. Les profils/sous-contextes sont par exemple ordonnés en fonction de l'indice correspondant: SC1 avant SC2, ou si l'on nomme les profils, en utilisant l'ordre alphabétique. L'ordre peut être défini soit dans les profils eux-mêmes, soit via une autre ressource, par exemple un fichier complémentaire décrivant l'ordre des profils et leurs éventuelles dépendances, suivant le type de profils considérés. Dans notre exemple, le profil Général 201 étant commun et indexé "1", on le considère comme prioritaire par rapport au profil Image 202, et l'identifiant 0 de la partition � width � désigne donc � 100% � sans ambiguïté. On note ici qu'une variante des références 22 et des indications 24 dans les grammaires et tables de vocabulaire consiste à utiliser une ou plusieurs listes 18 d'entrées décrivant chaque sous-contexte SC;/14;. Ces listes 18 sont stockées en mémoire 10 du processeur EXI. Pour les grammaires GRAM, on conserve une référence vers chaque grammaire ajoutée pour le sous-contexte SC; considéré ainsi qu'une référence vers chaque production ajoutée pour ce sous-contexte. Pour les tables de vocabulaire, on conserve une référence vers chaque partition ajoutée pour le sous-contexte SC; considéré, ainsi que le nombre de valeurs ajoutées à cette partition pour ce sous-contexte. Dans le cas des grammaires, il arrive qu'une même grammaire soit utilisée par deux sous-contextes, c'est pourquoi il faut garder aussi une information concernant chaque production. De manière identique, il arrive qu'une partition soit utilisée par deux sous-contextes, et il faut donc conserver le nombre de valeurs ajoutées pour chaque sous-contexte. Dans notre exemple, on considère que les sous-contextes sont ordonnés, et qu'il suffit alors de connaître ce nombre de valeurs ajoutées pour chaque sous-contexte SC; afin de déterminer les valeurs associées à un sous-contexte donné. Les listes d'entrées associées au sous-contexte Général SC1 et au sous-contexte Image SC2 sont représentées sur la figure 2e. Maintenant que le processeur EXI est configuré avec son contexte de codage 12 initial, on procède au décodage du fichier "image.svg.exi". Ce décodage est conforme aux mécanismes connus, et modifie donc le contexte de codage 12 (qui est évolutif) au fur et à mesure du traitement des éléments XML du fichier. Ainsi, peuvent être ajoutées de nouvelles valeurs dans les tables de vocabulaire, de nouvelles grammaires ou bien de nouvelles productions à l'intérieur des grammaires. Comme on l'a déjà évoqué précédemment, tous ces éléments ajoutés au contexte 12 pendant ce décodage constituent le sous-contexte dynamique 16. Ce sous-contexte est structurellement similaire aux sous-contextes statiques SC;/14; précédemment décrits. L'invention s'applique lorsque, le décodage étant terminé, on demande au processeur EXI de décoder un autre fichier, en l'occurrence le fichier "anim.svg.exi" de type "Animation". Dans les techniques de l'art antérieur, le processeur fait appel à une fonction de réinitialisation afin de supprimer les objets du contexte 12 créés pour le décodage précédent, notamment les grammaires et les tables de vocabulaire dans le cas d'un processeur EXI. Selon un exemple de l'invention, on cherche d'abord à déterminer le type associé au fichier à traiter, en l'occurrence le type "Animation". On détermine les profils ou sous-contextes nécessaires à ce type de fichier: ici les sous-contextes Général SC1 et Animation SC3. Par rapport au décodage du fichier précédent "image.svg.exi", il existe un profil partagé (Général 201), un profil en moins (Image 202) et un profil en plus (Animation 203). De plus, il existe le sous-contexte dynamique 16, qui contient des informations propres au document décodé et qui ne sont donc pas nécessaires pour le document "anim.svg.exi". En manipulant le contexte de codage 12 au travers de sous- contextes 14, 16, SC, l'invention permet d'enlever les éléments du contexte de codage 12 relatifs au sous-contexte Image SC2 et au sous-contexte dynamique 16, et d'ajouter ceux relatifs au sous-contexte Animation SC3. Ainsi, on ne procède pas à nouveau au chargement du sous-contexte Général SC1 en mémoire à partir du profil correspondant. En pratique, pour supprimer les éléments liés au sous-contexte Image SC2, on parcourt la liste 18 des grammaires et des partitions liées à ce sous-contexte Image. Si la grammaire ou la partition étudiée n'est liée qu'à ce sous-contexte (c'est-à-dire qu'elle n'est pas listée dans une autre liste 18 associée à un autre sous-contexte), alors on peut la supprimer d'un seul coup. En revanche, si elle est liée à un autre sous-contexte, il faut supprimer uniquement les productions liées au sous-contexte Image, de même que si une partition est liée à un autre sous-contexte, il faut supprimer uniquement les valeurs de cette partition liées au sous-contexte. Pour notre exemple et le sous-contexte Image SC2, on supprime la grammaire � StartTag rect � qui lui est propre, ainsi que seulement les productions ajoutées dans les grammaires � StartTag svg � et � ElementContent svg �. En ce qui concerne les tables de vocabulaire VOCA, on supprime simplement les valeurs � 100 � et � 250 � des partitions � height � et � width �, et non les partitions � height � et � width � dans leur totalité car il existe des valeurs liées au sous-contexte Général pour chacune de ces partitions. Une fois tous les sous-contextes statiques concernés supprimés, ici seulement le sous-contexte Image SC2 supprimé, on dispose, dans le contexte de codage, du sous-contexte Général SC1 (similaire à la figure 2b) ainsi que du sous-contexte dynamique 16. On supprime le sous-contexte dynamique de la même manière que l'on a supprimé le sous-contexte Image. On ajoute alors le sous-contexte SC3 correspondant au profil Animation 203 de manière similaire à l'ajout des sous-contextes Général et Image tel que décrit précédemment. A ce stade, on dispose du contexte de codage 12 pour procéder ensuite au décodage du fichier cible. Ainsi, grâce à l'invention, plutôt que de reconstruire tout le contexte de codage 12, on a donc pu conserver les éléments qui existaient déjà et éviter de traiter une nouvelle fois des données déjà traitées (ici le profil Général 201). L'invention permet ainsi un gain en termes de temps de configuration du processeur. On décrit maintenant de façon générale un exemple d'étapes de l'invention, en référence aux figures 3 à 6. La figure 3 présente les étapes générales. On débute, à l'étape E100, par la réception, par un processeur EXI, d'une requête pour le traitement de données. Ce traitement peut consister à encoder des données XML au format EXI, ou bien à décoder des données encodées dans le format EXI. Les données considérées peuvent être de deux sortes : soit un document, soit un fragment de document (typiquement, un élément XML et son contenu, au sein d'un document, notamment un élément auto-contenu). A l'étape E110, on détermine le type des données à traiter. Dans le cas où les données à traiter sont un document, ce type peut être déterminé à partir du document, par lecture de l'en-tête du document ou en utilisant son nom par exemple. En particulier, dans le cas où le traitement à effectuer est le décodage d'un flux EXI, il se peut que l'on lise le type des données dans le champ d'identifiant de schéma de l'en-tête du flux EXI, ce champ étant destiné à indiquer le schéma utilisé pour compresser les données. Dans le cas où l'on traite un élément XML et son contenu, le type peut être le nom qualifié de l'élément. Enfin, si l'on dispose d'une interface avec le processeur EXI permettant de spécifier un document et son type (ceci peut notamment être le cas lorsqu'on encode un document et que l'on spécifie un schéma à utiliser pour l'encoder), alors le type est trivialement déterminé par transmission de cette information via l'interface. Une fois le type connu, on détermine, à l'étape E115, les profils 20 associés, desquels on déduit les sous-contextes SC/14 à considérer. On en déduit également, à l'étape E120, par différence avec le contexte de codage 12 courant, les sous-contextes à supprimer et les sous- contextes à ajouter. Cette étape est notamment détaillée ci-après en référence à la figure 4. Les ensembles de sous-contextes à supprimer et à ajouter étant connus, il est alors possible de supprimer, lors de l'étape E130, les sous- contextes qui doivent l'être, puis d'ajouter, lors de l'étape E140, les sous-contextes manquants. Ces étapes de suppression et d'ajout sont décrites plus en détail après en référence, respectivement, à la figure 5 et à la figure 6. Ces opérations de suppression/ajout effectuées, le traitement des données peut avoir lieu lors de l'étape E150, notamment encodage ou décodage classique par le processeur EXI. Dans le cas où l'on traite non pas un document mais un fragment de document, il convient, une fois les données traitées, de supprimer les contextes qui ont été ajoutés, afin de revenir à la configuration du contexte de codage telle qu'elle était avant d'entrer dans le fragment. C'est le cas notamment pour les éléments auto-contenus. A moins que le fragment suivant appelle une nouvelle configuration du processeur EXI, laquelle configuration pouvant être réalisée conformément à l'invention. On peut ainsi poursuivre le traitement de la suite du fragment. Le traitement prend alors fin à l'étape E160. En référence à la figure 4, on décrit maintenant la détermination des sous-contextes à considérer pour suppression ou ajout. On commence, à l'étape E200, par obtenir l'ensemble ER des sous-contextes statiques 14 requis pour le traitement souhaité. Cet ensemble est connu à partir des profils 20 associés au type de données, déterminés à l'étape E115 de la figure 1. On poursuit à l'étape E210 par l'obtention de l'ensemble EC des sous-contextes statiques courants (ceux qui sont déjà dans le contexte de codage 12 courant). Cet ensemble peut se lire directement de la liste 18 conservée en mémoire 10 du processeur EXI. A l'étape E220, on construit alors l'ensemble des sous-contextes à supprimer, constitué des sous-contextes de EC privés des sous-contextes appartenant aussi à ER. De même, à l'étape E230, on construit l'ensemble des sous- contextes à ajouter, constitués des sous-contextes de ER privés des sous- contextes appartenant aussi à EC. A la suite de ces deux étapes E220 et E230, les listes de sous-contextes à supprimer et à ajouter contiennent uniquement des sous-contextes statiques 14. Il reste à déterminer ce qu'il convient de faire du ou des sous-contextes dynamiques 16. Pour cela, on évalue à l'étape E240 si les données à traiter sont un document. Dans l'affirmative (sortie OUI de l'étape E240), les sous-contextes dynamiques 16 ne sont plus nécessaires puisque l'on va décoder un autre document. A l'étape E250, on les ajoute donc à la liste des sous-contextes à supprimer. En revanche, si les données à traiter ne sont pas un document (sortie NON de l'étape E240), on détermine, à l'étape E260, s'il s'agit d'un élément auto-contenu. En effet, dans le cas d'un élément auto-contenu, il faut traiter les données indépendamment des informations de contexte apprises dynamiquement ; de plus, les informations de contexte apprises à l'intérieur de l'élément auto-contenu ne doivent pas être prises en compte une fois la fin de cet élément atteinte. Dans l'affirmative de l'étape E260, on procède donc à l'ajout d'un nouveau sous-contexte dynamique 16 à l'ensemble des sous-contextes à ajouter (étape E270), puis l'on ajoute les sous-contextes dynamiques courants à l'ensemble des sous-contextes à supprimer (étape 250). Bien sûr les sous-contextes à supprimer ne sont pas à supprimer dans l'absolu, mais à supprimer du contexte de codage 12 du processeur. C'est notamment le cas pour les sous-contextes dynamiques, qui dans le cas d'un élément auto-contenu seront ajoutés à la liste des sous-contextes à ajouter une fois la fin de l'élément atteinte. Comme expliqué plus haut, dans le cas d'un élément auto-contenu, les sous-contextes ajoutés sont supprimés lorsque l'on arrive à la fin du contenu de cet élément ; on rétablit aussi alors les sous-contextes qui avaient été supprimés à l'entrée dans cet élément. On restaure, de la sorte, le contexte de codage 12 pour traiter la suite du document. Suite à l'étape E250, ou bien dans la négative de l'étape E260, le traitement prend fin. On décrit maintenant l'étape de suppression E130 en référence à la figure 5. On rappelle que cette suppression ne signifie pas nécessairement qu'on efface entièrement les sous-contextes, mais signifie qu'on les ôte du contexte de codage 12. On peut ainsi les enregistrer dans une autre partie de la mémoire 10 du processeur, ou tout simplement les dé-référencer du contexte 12 courant. La figure 1 illustre ces sous-contextes "désactivés" 26 comprenant les grammaires et le vocabulaire définis par ce sous-contexte. Ainsi, si l'on doit réutiliser ces sous-contextes ultérieurement, on évite de relire les profils 20 à partir desquels ils ont été construits la première fois, et on ne fait que lire en local ces sous-contextes déjà prétraités. On réalise ainsi un gain de temps et on prévoit davantage de mémoire 10 pour le stockage correspondant. Afin de limiter le taille de mémoire supplémentaire, on conserve un ensemble de M sous-contextes au maximum (M étant par exemple défini en fonction de contraintes de mémoire), et si l'on atteint cette limite, on élimine le sous-contexte le moins fréquemment utilisé, ou bien celui dont la dernière utilisation remonte le plus loin dans le temps. Signalons aussi que dans le cas où le fait de ne pas supprimer un sous-contexte de codage n'a pas d'impact sur le flux encodé ou décodé (autrement dit, si la suppression du contexte est possible mais pas nécessaire), au lieu de supprimer ce sous-contexte, on peut simplement le marquer comme facultatif et le supprimer uniquement si l'on atteint une certaine limite de mémoire. Ce peut-être notamment le cas lorsque le sous-contexte de codage "à supprimer" se rapporte à des éléments non concernés par les sous-contextes de codage "actifs" pour le codage/décodage courant (par exemple des grammaires totalement distinctes). Le processus de suppression début à l'étape E300 par l'obtention des sous-contextes à supprimer, déterminés lors de l'étape E120 (résultat du processus de la figure 4). A l'étape E310, on vérifie s'il reste un sous-contexte SC à supprimer non traité. Dans l'affirmative, on obtient, à l'étape E320, la liste 18 des grammaires et des entrées (partitions) de tables de vocabulaire liés au sous- contexte SC (liste qui peut être établies à l'aide des références 22 et 24 lorsque la liste 18 n'est pas directement envisagée). Ces listes 18 étant construites (étapes E451, E452, E471 et E472 ci-dessous) lors de l'ajout de chaque sous-contexte au contexte de codage, aucun calcul n'est nécessaire à l'obtention de ces listes. A l'étape E330, on détermine alors s'il reste une grammaire GRAM ainsi listée non traitée. Dans l'affirmative, on détermine, à l'étape E340, si GRAM est liée uniquement à SC. Si oui, alors on supprime la grammaire GRAM à l'étape E341. Sinon, on supprime uniquement les productions de GRAM liées à SC, lors de l'étape E342. Suite aux étapes E341 et E342, on retourne à l'étape E330 pour évaluer s'il reste une grammaire GRAM listée non traitée parmi les grammaires liées au sous-contexte SC. Dans la négative de l'étape E330, on passe au traitement du vocabulaire, à l'étape E350, où l'on détermine s'il reste une partition P listée non traitée. Si c'est le cas, on vérifie à l'étape E360 si P est liée uniquement à SC. Si oui, on peut supprimer la partition P lors de l'étape E361. Sinon, on supprime uniquement les valeurs de P qui sont liées à SC lors de l'étape E362. Suite aux étapes E361 et E362, on retourne à l'étape E350 afin de déterminer s'il reste une partition P listée à traiter. Dans la négative, on passe à l'étape E370 où l'on supprime le vocabulaire hors partition, c'est-à-dire le vocabulaire qui appartient à des listes de valeurs (par exemple la liste des valeurs globales). On retourne ensuite à l'étape E310, où l'on détermine s'il reste un sous-contexte à supprimer non traité. Quand tous les sous-contextes à supprimer ont été traités, le traitement prend fin à l'étape E390. On décrit maintenant l'étape d'ajout E140 en référence à la figure 6. A l'étape E400, on obtient l'ensemble des sous-contextes courants (connu du processeur) et de l'ensemble des sous-contextes à ajouter (déterminé à l'étape E120). On poursuit à l'étape E410, en ordonnant les sous-contextes obtenus à l'étape E400 comme expliqué précédemment. A l'étape E420, on évalue s'il reste un sous-contexte SC à ajouter. Dans l'affirmative, on obtient, à l'étape E430, les grammaires GRAM et les tables de vocabulaire VOCA définies dans le sous-contexte SC à ajouter. Pour obtenir ces informations, on envisage plusieurs alternatives. On peut lire le profil 20 décrivant le sous-contexte SC (un schéma XML par exemple), et construire les grammaires et les partitions qui en découlent. Dans le cas où l'on conserve les sous-contextes "inactifs" en mémoire 26 du processeur, on vérifie si le sous-contexte SC recherché appartient aux sous-contextes conservés. Si ce n'est pas le cas, on lit le profil 20 correspondant pour générer grammaires et partitions correspondantes. Si c'est le cas, on récupère les grammaires et partitions correspondantes. On procède alors à l'ajout du sous-contexte SC au contexte de codage 12. Pour cela, on évalue, à l'étape E440, s'il reste une grammaire GRAM non traitée parmi les grammaires définies pour SC. Si c'est le cas (sortie OUI de l'étape E440), on détermine, à l'étape E450, si une telle grammaire existe déjà dans le contexte de codage du processeur, c'est-à-dire s'il existe une grammaire GRAM' décrivant le même type d'élément que GRAM. Si oui, alors il ne faut pas créer GRAM mais ajouter (étape E451) les productions de GRAM, propres au sous-contexte SC, à la grammaire GRAM', et marquer chaque production ajoutée comme liée à SC. En revanche, si une telle grammaire GRAM' n'existe pas, alors on ajoute (étape E452) GRAM au contexte de codage 12. Dans les deux cas, on marque la grammaire traitée (GRAM' dans le premier cas, GRAM dans le second) comme liée au sous-contexte SC. A l'issue des étapes E451 et E452, on retourne à l'étape E440 pour évaluer s'il reste encore une grammaire à ajouter non traitée. Dans la négative de l'étape E440 (sortie NON), on passe au traitement du vocabulaire et on détermine d'abord, à l'étape E460, s'il reste une 10 partition P à ajouter non traitée. Si oui, on détermine, à l'étape E470, si P est déjà définie dans le contexte de codage. Dans l'affirmative, on ajoute uniquement les valeurs propres au sous-contexte SC pour la partition P (étape E471), et l'on marque ces valeurs comme liées au sous-contexte SC. Dans la négative, on ajoute la 15 partition P avec ses valeurs au contexte de codage (étape E472). Dans les deux cas, on ajoute la partition P à la liste des partitions liées à SC. Suite aux étapes E471 et E472, on retourne à l'étape E460 pour déterminer s'il reste une partition à traiter. 20 Si ce n'est pas le cas, on passe à l'étape E480 où l'on ajoute le vocabulaire hors partition, c'est-à-dire le vocabulaire qui appartient à des listes de valeurs (par exemple le vocabulaire appartenant à la liste des valeurs globales). On retourne alors à l'étape E420, où l'on détermine s'il reste un 25 sous-contexte SC à ajouter, et dans la négative, quand tous les sous-contextes ont été ajoutés, le traitement prend fin à l'étape E490. Suivant le type de profils 20 considéré, on peut, à l'issue des ajouts, recalculer les codes de priorités des productions pour certaines grammaires ainsi que les identifiants associés aux valeurs de vocabulaire ; ainsi, si l'on a 30 par exemple une grammaire contenant cinq productions, chaque production ayant un code de priorité à un seul niveau comprise entre 1 et 5, et que l'on supprime la productions ayant pour valeur de priorité 3, cela signifie que l'on doit mettre à jour les codes de priorités des productions ayant précédemment les codes de priorité 4 et 5 avec les codes 3 et 4. A cet effet, il est avantageux de conserver une liste des grammaires mises à jour par ajout ou suppression de productions lors de la configuration du contexte de codage, ainsi qu'une liste des tables de vocabulaire (une liste des partitions dans le cas des tables qui contiennent des partitions) mises à jour par ajout ou suppression d'entrées lors de la configuration du contexte de codage. Pour les objets qui existaient avant la configuration et qui n'ont pas été modifiés, de même que pour les objets ajoutés, aucun calcul supplémentaire n'est nécessaire. L'invention ci-dessus décrite simplifie les traitements effectués au niveau d'un processeur pour sa reconfiguration en vue du codage/décodage de nouvelles données structurées. En effet, une partie du contexte de codage peut être conservée, là où les solutions connues de l'art antérieur menaient une reconfiguration complète du processeur. L'invention peut s'appliquer au traitement de documents successifs, pour gérer efficacement le passage du contexte de codage d'un premier document à celui d'un second document. Le cas le plus simple est entièrement conforme à la spécification EXI et permet cependant d'obtenir des gains significatifs lors du traitement des documents. Ainsi, dans le mode EXI Schéma, où l'on utilise un schéma XML pour compresser davantage les données, lorsque l'on traite le deuxième document, au lieu de réinitialiser le contexte de codage, on commence par déterminer le schéma à utiliser. En particulier, lors du décodage, cela signifie qu'on commence à lire le fichier encodé en conservant le contexte de codage résultant du décodage du document précédent, ce qui va à l'encontre du mécanisme classique selon lequel le traitement d'un nouveau document s'accompagne de la réinitialisation du contexte de codage. Si le schéma à utiliser est le même que pour le document précédent, alors on procède à la réinitialisation du contexte par suppression du sous-contexte dynamique ; si en revanche il est différent, on supprime le contexte. Un cas plus complexe et préféré concerne l'utilisation de plusieurs profils pour un seul document, cas qui peut se révéler intéressant pour des documents SVG par exemple. En effet, le modèle général des données SVG est particulièrement riche, et construire un contexte de codage à partir de ce modèle est coûteux et peu efficace en termes de compression du fait que l'on couvre un spectre extrêmement large de documents. De ce fait, il est plus avantageux de construire des profils à partir des documents que l'on souhaite encoder. Dans ce cas, chaque profil correspond à un sous-contexte de codage, et le passage d'un document à un autre va consister, en fonction des sous-contextes courants (utilisés pour le premier document) et des sous-contextes suivants (utilisés pour le deuxième document) à supprimer les sous-contextes courants qui ne figurent pas dans les suivants et à ajouter aux sous-contextes courants les suivants qui ne figurent pas dans les courants. L'invention peut également s'appliquer à la prise en compte de nouvelles informations externes pour le traitement d'un élément XML au sein d'un même document traité. Notamment, cela est le cas lorsque l'étape E100 est réalisée au cours de l'étape E150, présentées ci-dessus. Ici, contrairement au cas des documents successifs, on met à jour le contexte de codage au cours du traitement d'un document, par exemple suite au traitement d'un élément XML donné. En fonction de cet élément XML, on détermine un type, et on ajoute au contexte de codage le ou les sous-contextes correspondant à ce type. Ainsi, dans le cas où l'on traite des documents SOAP, plusieurs schémas sont généralement nécessaires : le schéma SOAP d'abord, mais aussi d'autres schémas susceptibles d'intervenir dans le corps des documents. Lorsque l'on encode l'un de ces documents, on ne sait pas a priori quels schémas vont être réellement utilisés dans le corps du document, et on encode donc dans l'en-tête une référence désignant l'ensemble des schémas. Comme le traitement de tous ces schémas dans le but de construire le contexte de codage est coûteux et peut requérir une quantité importante de mémoire, on distingue un ou plusieurs sous-contextes par schéma et on ne les ajoute au contexte de codage du processeur que lorsque l'on rencontre des données qui leur correspondent, par exemple à la détection du type d'élément concerné. En référence à la figure 7, 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 le contexte de codage 12 et les sous-contextes "désactivés" 26 de la figure 1 ; - un écran 55 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention ; - un lecteur de disquette 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 70 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données. Dans le cas de données audio, le dispositif 50 est équipé de préférence d'une carte d'entrée/sortie (non représentée) qui est reliée à un microphone 62. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 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 1 à 6, pour mettre en oeuvre le procédé objet de la présente invention et constituer le système objet de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation 20 de l'invention qui ne s'y limite pas. En particulier, on a présenté les profils 20 comme structurés autour d'un profil Général 201 commun et de profils spécialisés 202 et 203. En variante, on prévoit une hiérarchie de profils, chaque document correspondant à un profil particulier dans chaque niveau hiérarchique (par 25 exemple Général / Image / Icône pour une hiérarchie à trois niveaux). Selon une autre variante, on prévoit des profils décrivant la structure, et d'autres décrivant le contenu Enfin, on peut prévoir des profils modulables, chaque document pouvant correspondre à différents modules, indépendamment de toute 30 hiérarchie. On peut aussi séparer la description de documents XML (obtenus à partir d'un schéma XML ou d'une autre source) en différentes parties, chaque partie représentant un sous-contexte SC. Ces différentes parties rassemblent des éléments/attributs très généralement utilisés conjointement. Cette séparation permet par exemple de ne charger qu'une partie du schéma/profil pour le codage/décodage d'un document et non l'ensemble du schéma. Dans ce cas, on n'effectue pas la décomposition en profils selon un critère de compression mais selon un critère de minimisation de la consommation mémoire et de temps de traitement nécessaires à l'utilisation d'un mode EXI avec information externe. On peut citer deux exemples de cas où l'on divise la description en différentes parties. Premièrement, celui où l'on doit supporter un modèle (par exemple un schéma, ou un ensemble de schémas), mais où l'on sait que dans une majorité de cas, on se restreindra à une sous-partie du modèle : alors, il est intéressant de créer un profil dédié à cette sous-partie du modèle, ce profil définissant un sous-contexte, et un ou plusieurs autres profils définissant autant de sous-contextes complémentaires pour décrire le reste du modèle. Deuxièmement, dans le cas où l'on doit supporter un modèle et où l'on dispose d'un ensemble de documents instanciant ce modèle, on peut chercher à restreindre le modèle à partir des instances : ainsi, on peut déterminer des parties du modèle plus fréquentes que d'autres, et dans ce cas les définir dans un profil dédié. Dans les deux cas, la division du modèle de départ n'affecte pas le flux EXI, l'ensemble du modèle restant supporté. Soulignons enfin, pour conclure sur cet aspect, que la division du modèle en profils peut-être améliorée grâce aux traitements successifs des documents instanciant le modèle par un algorithme d'apprentissage. Suivant le type de profils choisi, les contraintes imposées à l'invention sont différentes. En effet, plus les profils sont indépendants les uns des autres, plus il est facile d'ajouter ou de supprimer un sous-contexte ; en revanche, si les profils sont très liés (si par exemple plusieurs profils donnent différentes définitions d'un élément XML), alors les grammaires ou les tables de vocabulaires résultantes auront de fortes chances de contenir des informations liées à différents sous-contextes, et l'ajout ou la suppression d'un sous-contexte demandera donc davantage de calculs. Par conséquent, si l'invention ne requiert pas l'utilisation d'un type de profil particulier, il est cependant préférable d'utiliser des profils disjoints (c'est-à-dire concernant des grammaires et des partitions différentes) si l'on souhaite obtenir les meilleurs gains d'efficacité. On a vu également plus haut qu'il est important de mémoriser les liens entre sous-contexte et production/entrée de partition. Dans ce contexte, un cas particulier intéressant est celui où l'on construit les profils 20 en s'assurant que chaque valeur d'une partition ne peut appartenir qu'à un seul sous-contexte. Concrètement, cela signifie par exemple que l'attribut � width � avec la valeur � 100 � (voir figures 2) n'apparaît pas dans deux profils. Dans ce cas, en ordonnant les sous-contextes comme évoqué ci-dessus, il suffit de connaître le nombre d'entrées pour chaque sous-contexte afin de déterminer entièrement les entrées liées à un sous-contexte donné. En effet, si l'on nomme Ni le nombre de valeurs liées au i-ème sous-contexte pour une partition donnée, alors les valeurs pour le premier sous-contexte sont les NO premières, celles pour le deuxième sous-contexte sont les N1 suivantes, etc. Par ailleurs, pour vérifier si une grammaire ou une partition est liée à un ou plusieurs sous-contextes (information qui permet de savoir si l'on peut traiter la grammaire ou la partition dans son ensemble ou bien si l'on doit travailler au niveau des productions et des entrées û étapes E340, E360), il peut être intéressant de conserver, pour chaque grammaire et chaque partition, un compteur du nombre de sous-contextes auxquelles celle-ci est liée. De cette manière, quand on traite un sous-contexte à partir des listes de référence, on peut déterminer aisément s'il faut considérer d'autres sous-contextes (compteur supérieur à 1) ou pas (compteur égal à 1).30 REVENDICATIONS1. Procédé de configuration d'un processeur (1) de codage/décodage pour le codage/décodage de nouvelles données structurées, ledit processeur comprenant en mémoire (10) un contexte de codage/décodage (12) relatif au traitement (E105) d'anciennes données structurées, caractérisé en ce que le contexte est composé d'une pluralité de sous-contextes (14, 16, SC), et le procédé comprend les étapes suivantes : - la détermination (E120) d'un ensemble de sous-contextes 10 définissant un contexte de codage/décodage (12) desdites nouvelles données structurées ; - l'identification et la suppression (E130, E220), dans le contexte de codage/décodage (12) en mémoire (10) du processeur (1), d'au moins un sous-contexte (14, SC) non compris dans l'ensemble déterminé de sorte à conserver 15 les sous-contextes appartenant audit ensemble. 2. Procédé selon la revendication 1, dans lequel ledit contexte de codage/décodage (12) comprend un sous-contexte dynamique (16) comprenant des informations de codage/décodage apprises par le processeur (1) pendant le traitement (E150) desdites anciennes données, et au moins un sous-contexte 20 statique (14;) comprenant des informations de codage/décodage créées par le processeur (1) à partir de données de configuration externes (20;). 3. Procédé selon la revendication précédente, dans lequel ladite suppression (E130) comprend celle du sous-contexte dynamique (16). 4. Procédé selon l'une des revendications précédentes, dans 25 lequel ladite suppression (E130) dans le contexte comprend l'enregistrement en mémoire (26) dudit au moins un sous-contexte supprimé. 5. Procédé selon la revendication précédente, dans lequel la mémoire (26) stockant le sous-contexte supprimé a une taille limitée, et on supprime le sous-contexte en mémoire le moins utilisé lorsque la taille mémoire 30 encore disponible est inférieure à la taille du sous-contexte supprimé à enregistrer. 6. Procédé selon l'une des revendications précédentes, comprenant le chargement (E140) d'un sous-contexte (14, SC) non présent dans ledit contexte (12) en mémoire (10) du processeur (1) et appartenant audit ensemble déterminé. 7. Procédé selon la revendication 6, dans lequel ledit chargement (E140) comprend la copie dudit sous-contexte depuis une mémoire (26) stockant des sous-contextes inactifs vers ledit contexte (12) en mémoire (10) du processeur. 8. Procédé selon la revendication 6 ou 7, dans lequel, lors du chargement (E140), on indique (E451, E452, E471, E472), pour chaque information d'un sous-contexte chargé dans ledit contexte (12) en mémoire (10) du processeur, le sous-contexte (14, SC) auquel elle est attachée. 9. Procédé selon la revendication précédente, dans lequel le contexte (12) est formé de grammaires (GRAM) associant des productions à des valeurs de codage, et de dictionnaires (VOCA) dont les entrées associent des chaînes de caractères à des identifiants de codage, et ladite indication (22, 24) de sous-contexte (14, SC) est renseignée au niveau des productions et des entrées des dictionnaires. 10. Procédé selon la revendication 8 ou 9, dans lequel le contexte (12) est formé de grammaires (GRAM) et de dictionnaires (VOCA) présentant des partitions (P), et on associe, à chaque grammaire (GRAM) et partition (P), un compteur du nombre de sous-contextes (14, SC) qui lui sont liés. 11. Procédé selon l'une des revendications 6 à 10, dans lequel les anciennes et nouvelles données structurées sont chacune un document structuré différent. 12. Procédé selon l'une des revendications 6 à 11, dans lequel les anciennes et nouvelles données structurées appartiennent à un même document. 13. Procédé selon la revendication précédente, dans lequel les nouvelles données structurées comprennent un élément auto-contenu au sens de la norme EXI. 14. Procédé selon l'une des revendications 6 à 13, dans lequel ledit chargement (E140) d'un sous-contexte (14i, SC;) est réalisé à partir d'un fichier (20;) de configuration de type Schéma XML. 15. Procédé selon l'une des revendications précédentes, dans lequel ladite détermination (E120) comprend la détermination (E110) d'un type représentatif desdites nouvelles données structurées, et ledit ensemble des sous-contextes (14, SC) est déterminé (E120) à partir dudit type. 16. Procédé selon la revendication précédente, dans lequel ledit type est déterminé à partir desdites nouvelles données. 17. Procédé selon l'une des revendications précédentes, dans lequel les sous-contextes (14, SC) sont disjoints deux à deux. 18. Procédé selon l'une des revendications précédentes, comprenant l'ordonnancement des sous-contextes (14, SC) conservés et chargés. 19. Dispositif de configuration d'un processeur (1) de codage/décodage pour le codage de nouvelles données structurées, ledit processeur comprenant en mémoire (10) un contexte de codage/décodage (12) relatif au traitement (E150) d'anciennes données structurées, caractérisé en ce que le contexte est composé d'une pluralité de sous-contextes (14, 16, SC), et le dispositif comprend : - un moyen de détermination (E120) d'un ensemble de sous-contextes définissant un contexte de codage/décodage (12) desdites nouvelles données structurées ; - un moyen d'identification et de suppression (E130, E220), dans le contexte de codage/décodage (12) en mémoire (10) du processeur (1), d'au moins un sous-contexte (14, SC) non compris dans l'ensemble déterminé de sorte à conserver les sous-contextes appartenant audit ensemble. 20. 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 à 18, lorsque le programme est chargé et exécuté par le système informatique. 21. 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 à 18, lorsqu'il est chargé et exécuté par le microprocesseur.5