FR2941071A1 - Processor i.e. Efficient XML Interchange processor, configuring method for encoding or decoding XML document in information processing device, involves suppressing sub-context that is not comprised in set of sub-contexts, in context - Google Patents

Abstract

The method involves determining a set of sub-contexts defining an encoding and decoding context of a data structure, where the data structure includes a self-container element conforming to Efficient XML Interchange standard. A sub-context not comprised in the determined set of sub-contexts is identified and suppressed in the encoding and decoding context in a memory of a processor to conserve the sub-contexts belonging to the set of sub-contexts. The respective sub-context is suppressed by storing the suppressed sub-context in another memory. Independent claims are also included for the following: (1) a device for configuring a processor for encoding or decoding a data structure (2) an information storage medium comprising instructions to perform a method for configuring a processor for encoding or decoding a data structure (3) a computer program product comprising instructions to perform a method for configuring a processor for encoding or decoding a data structure.

Description

The present invention relates to a method and system for configuring a structured data encoding / decoding processor. It applies, in particular, to documents of the XML type (acronym for Extensible Markup Language) and EXI (Efficient XML Interchange) type processors. XML is a syntax for defining languages. computer. XML makes it possible to create languages adapted to different uses but which can be processed by the same tools. An XML document is composed of elements, each element starting with an opening tag with the name of the element (for example: <tag>) and ending with a closing tag that also contains the name of the element ( for example: </ tag>). Each element can contain other elements hierarchically, constituting a hierarchical structure of data, or textual data. On the other hand, an element can be specified by attributes, each attribute being defined by a name and having a value. The attributes are placed in the opening tag of the element they specify (for example: <attribute tag = "value">). The XML syntax also allows you to define comments (for example: <! - Comment ->) and processing instructions, which can specify to a computer application the processing to apply to the XML document (for example: <? Myprocessing? >), as well as escape sections that prevent a section of text from being interpreted as a tag when it has the form (for example: <! [CDATA [<text> Escape </ text> ]]> where <text> is recognized as a string and not a tag). In XML terminology, the set of element terms (identified by an opening tag and a closing tag), attribute, textual data, comment, processing instruction, and escape section defining the XML data are grouped under the generic name of the item. . Several different XML-based languages may contain 5 elements of the same name. To be able to mix several different languages, an addition has been made to the XML syntax for defining namespace (namespace according to the English terminology). Two elements are identical only if they have the same name and are in the same namespace. A namespace is defined by a URI 10 (acronym for Uniform Resource Identifier), for example http://canon.crf.fr/xml/monlangage. Using a namespace in an XML document requires defining a prefix that is a shortcut to the URI for that namespace. This prefix is defined using a specific attribute (for example: attribute 15 xmlns: ml = "http://canon.crf.fr/xml/monlanguage" associates the prefix ml with the http URI: //canon.crf.fr/xml/monlanguage). Then, the namespace of an element or attribute is specified by prefixing its name with the prefix associated with the namespace followed by: (for example: <ml: ml tag: attribute = "value "> indicates that the tag element is from the ml namespace and so is the attribute attribute. The XML format has many advantages and has become a standard for storing data in a file or exchanging data. XML allows in particular to have many tools to process the generated files. In addition, an XML document can be edited manually with a simple text editor. In addition, as an XML document contains its built-in data structure, this document is very readable even without knowing the specification. However, the main disadvantage of the XML syntax is that it is very verbose, sometimes causing the size of an XML document to be several times larger than the intrinsic size of the data. This large size of the XML documents also induces an important processing time during the generation and especially the reading of XML documents.

To remedy this drawback, methods for encoding an XML document have been searched. The purpose of these methods is to encode the contents of the XML document into a more compact form, making it easy to reconstruct the XML document. For example, a simple method is to replace XML items with symbols. Other more advanced methods exist, including Binary XML formats, among which we know the EXI format ("Efficient XML Interchange") or Fast Infoset, to retain many advantages of XML despite coding. EXI is a Binary XML format currently standardized by W3C that uses a set of grammars as well as vocabulary tables (or "value dictionaries") to describe and encode an XML document. Grammars make it possible to efficiently code the structure of the document, whereas the vocabulary tables, which list the vocabulary encountered, make it possible to efficiently code repeated strings of characters by using a numerical identifier from the second. appearance of a given chain. For the rest of the document, the coding context is defined as being the set of grammars and vocabulary tables used to encode or decode a document.

In order to be able to code the items included in an XML document, the Efficient XML specification divides each element encountered in the document to be encoded, into elementary parts called events, for example an opening tag or an attribute. A grammar is composed of a set of productions, each production including an XML event description, an associated coding value, and the indication of the next grammar to use (for coding the next event). To code an XML event using a grammar, the output containing the most accurate description of the XML event is used. The encoding value contained in this output is used to represent the event, and the information contained in the event and not described in the output is encoded.

A grammar according to Efficient XML (and thus the coding context) is scalable. In a certain number of cases, after the occurrence of an XML event already described by a grammar production (if it is not described by a production, it can not be encoded by the grammar), the grammar is modified to include a new production corresponding to this XML event. This output can either contain a more accurate description of the event, decreasing the amount of information to be encoded to represent the event, or have a more compact encoding value. Coding values, or numerical codes, are expressed as priorities, usually between 1 and 3 levels. Coding an encoding value amounts to coding the values of its priority. According to the most advantageous coding mode in terms of compression, each level is coded on a minimum number of bits in order to be able to code the greatest value of this level associated with a production of the grammar. For example, for a level taking values from 0 to 6, 3 coding bits are used. To encode an XML document, a set of grammars is used. Some grammars are used to code the structure of the XML document. In addition, for each type of XML element present in the document (an XML element type being a set of elements with the same name, possibly in the same context [which takes into account the parent element types of the item considered]), the same set of grammars is used to encode XML elements of this type. The grammar rules used can be generic rules, common to all XML documents and built from the XML syntax. But they can also be rules specific to a type of document when they are built beforehand. This provides a more efficient encoding (or decoding) in terms of compression. During decoding, the reverse process is used: the encoding value is extracted and identifies the coded XML event, as well as the additional information to be decoded from the productions. In addition, during decoding, the same rules of evolution of grammars are used, allowing to have at any time a set of rules of grammars and productions identical to that which was used during the coding. Two types of alignment are provided by the EXI format to represent the encoding values: a format in byte-aligned, for which the encoded data are aligned at the byte level, that is, that is, each new character string starts on a new byte, for example, and a bitpacked format, for which the data is encoded on the smallest possible number of bits. In the latter mode, character strings do not necessarily begin on a new byte. The first mode can be decoded more efficiently, while the second produces more compressed files. The EXI standard also introduces a mode called "EXI Schema" which is based on XML schemas. The latter describe representative data models of structures, and as such it is possible to construct grammars representing this model, and therefore a specific encoding context for the EXI processor. In the EXI Schema mode, such a schema is used to create grammars, and then these grammars are used to code or decode a document. The EXI Schema mode provides better compression than when grammars are learned from the document. Indeed, consider the following simplified example of structured data, in which an <element> element has three successive elements <childl>, <child2>, and <child3> in this order: <element> <childl /> <child2 /> <child3 /> </ element>.

According to the EXI specification, if no schema is used, the <childl>, <child2>, and <child3> elements are in the same grammar, the one that describes the contents of the <element> element. On the other hand, with an XML schema, it becomes possible to know that the <childl>, <child2> and <child3> elements always occur in the same order, by the indication of the "sequence" property defined by the norm. This precision makes it possible to create more grammars for these elements, each grammar containing a single production: a grammar for the passage from <element> to <enfantl>, another for the passage from <enfantl> to <enfant2>, etc. By reducing the number of productions per grammar, we reduce the number of bits needed to code the priorities, and in the example here, since only one production remains per grammar, there is no longer any need to code the associated production. (which is always chosen when the grammar is called). The creation of grammars from an XML schema is described in the EXI specification. As it happens that the documents instantiating a schema do not perfectly respect the defined model, it is possible to choose a sub-mode allowing deviations from the schema. In this case, additional productions are inserted in the grammars in order to be able to encode the parts which do not strictly respect the diagram. In this way, we take advantage of the knowledge of the schema without requiring perfectly compliant documents. Nevertheless, due to the additional productions, the compression is less important than in the case where one does not allow the deviations. The EXI standard also offers special management of the coding context in the case of so-called "self-contained" events. The "self-contained" property is used to indicate that the content of an XML element can be decoded independently of the rest of the document in which this element appears. When such an event is encountered, the current encoding context is saved, and the initial encoding context obtained for the decoding of the relevant document is restored for the encoding of the self-contained event. This means that the decoding (or coding) is carried out as if the content of the self-contained element appeared at the beginning of the document. Then we decode the content of the self-contained element, and when we reach the end of this element, we restore the context saved to continue decoding the rest of the document. As seen above, the EXI standard makes it possible to configure an encoding context of an EXI processor from external configuration data, in this case XML schemas, in order to improve the compression of the structured data and the data. corresponding documents.

However, these schemas must be handled when encoding or decoding a document to build grammars and vocabulary tables. This processing which includes, among other things, the reading and analysis of schemas, as well as the creation of the coding context, is quite expensive, in particular for processing short files. In fact, the processing of XML schemas, even if there is only one, represents a fixed cost, which therefore takes on an even greater share in the processing that the processed file is short. To reduce this processing time, some program libraries implementing the EXI standard (for example Efficient XML) propose to produce a compiled version of the XML schema, from which the construction of the coding context is carried out more quickly. The advantage of this compiled version comes from the fact that it is no longer necessary to analyze an XML schema whenever it is needed. However, the need to read external configuration data (XML schema or equivalent) and then to create the encoding context remains. In some processing cases, the files to be processed belong to a limited set of types and known. In this case, the contexts used to process these files generally have strong similarities. For example, in a camera, it may be necessary to treat only two different types of files: SVG files ("Scalable Vector Graphics" format for vector graphic objects) for the graphical interface, and XML files to describe the photos. The mechanisms of the prior art for configuring the encoding context of the EXI processor all have the disadvantage that, for the coding of a new file, it is necessary to read again the external configuration data (compiled or uncomplicated XML schema) and to generate integrally the corresponding initial coding context. The present invention aims to solve this drawback of the prior art and thus to make the configuration of the coding context of the EXI processor more efficient. For this purpose, the invention aims in particular at a method for configuring an encoding / decoding processor for encoding / decoding new structured data, said processor comprising in memory a coding / decoding context relating to the processing of old structured data. , the context being composed of a plurality of subcontexts, the method comprising the following steps: determining a set of subcontexts defining a coding / decoding context of said new structured data; the identification and deletion, in the context of coding / decoding in the memory of the processor, of at least one subcontext not included in the set determined so as to preserve the sub-contexts belonging to said set. Here we consider the coding contexts as sets of subcontexts. The invention makes it possible to effectively manage the transition from an encoding context of a first document (or document fragment) to that of a second document (or fragment of document). Indeed, during the change of coding context, we keep the sub-contexts common to the two successive coding contexts. The similarities between the successive coding contexts are used. In this way, it reduces the processing and read operations of external configuration data needed to load the subcontexts for subsequent coding / decoding.

In contrast to the known solutions of the prior art where the contexts were, each time, fully reloaded, the invention accelerates the configuration of the coding / decoding processor. The gains brought by the invention are all the more important that the files to be processed are frequent (for example because they are short) and that they present several similar sub-contexts (for example because they implement identical element types). The invention applies particularly well to the reconfiguration of the EXI processor for the coding / decoding of a new document but also for the management of self-contained elements in the sense of the EXI standard. In this case, specific information is used to improve the compression of a self-contained element. In addition to the initial context of coding (which is restored when one arrives at a self-contained element), one can take into account a configuration profile (an XML schema for example) dedicated to this type of specific element, so to load a specific sub-context including grammars describing the element and / or a vocabulary containing values appearing frequently in its content. In this way, the compression of this self-contained element is improved, without penalizing the compression of the remainder of the document, since the specific values, for example, are taken into account only inside the auto element. -content.

In one embodiment, said coding / decoding context comprises a dynamic sub-context including coding / decoding information learned by the processor during the processing (coding / decoding) of said old data, and at least one static sub-context including encoding / decoding information created by the processor from external configuration data. The case where we have a single static sub-context represents the simplest situation. In this case, the dynamic sub-context is usually deleted and the static sub-context is retained for processing a new document. The EXI processors of the state of the art require, them, the full reloading of this static sub-context, in particular because they make no difference between the two static and dynamic sub-contexts mentioned here. Thus, in particular, said deletion includes that of the dynamic sub-context.

In one embodiment, said deletion in the context includes storing in memory said at least one deleted sub-context. This configuration makes it possible, in the case where one must later reuse static sub-contexts previously deleted, to avoid re-reading the configuration profiles from which they were first constructed. A simple copy from the storage memory of deleted sub-contexts is sufficient. This saves time, although it is necessary to have more memory. For this purpose, it is expected that the memory storing the deleted sub-context has a limited size, and the sub-context in the least used memory is deleted when the memory size still available is less than the size of the deleted sub-context to be recorded. . Other policies are possible, such as keeping a set of M subcontexts at a maximum (M being defined for example according to memory constraints), and eliminating, if this limit is reached, the sub-contexts. context the least frequently used, or the one whose last use goes back further in time. In a close way, in the case where the fact of not deleting a coding sub-context has no impact on the encoded or decoded stream (in other words, if the deletion of the sub-context is possible but not necessary) instead of deleting this sub-context, you can simply mark it as optional and delete it from memory only if you reach a certain memory limit. In one embodiment, the method includes loading a sub-context not present in said context in memory of the processor and belonging to said determined set. This operation makes it possible to configure the context of the processor according to the document or the data to be processed. In particular, this loading is iterated for all the sub-contexts that are not present in the context initially in memory and belonging to the determined set.

In particular, said loading comprises copying said sub-context from a memory storing inactive sub-contexts to said context in memory of the processor. This arrangement is to be compared with the backup of the subcontexts in memory and therefore has the same interest: to avoid a new processing of external configuration XML schema type data. In one embodiment, the subcontexts are disjoint two by two, especially in the sense that the subcontexts relate only to distinct structured elements. In this case, the management of the coding context, and thus grammars and other dictionary partitions, is simplified. This gives a significant gain in efficiency and speed during the change of coding / decoding context.

According to one characteristic of the invention, the method comprises the scheduling of the conserved and loaded subcontexts. This scheduling makes it possible to guarantee that the coding information (priorities and identifiers) are the same for the same context even though the latter has been constituted from different prior contexts. It is then expected that the method comprises a step of (re) calculation of coding values (priorities for productions, identifiers for the dictionary values) for the ordered subcontexts. In one embodiment of the invention, the subcontexts come from a set of sub-contexts comprising a general sub-context describing elements common to several structured data sets (in practice to several documents) and sub-contexts. specialized contexts describing elements specific to each of said sets of data. This configuration is particularly adapted to effectively handle a family of documents with significant variations in their contents. Alternatively, the subcontexts come from a set of hierarchical subcontexts. As a further variant, said contexts are divided into two disjoint parts of subcontexts, one describing structure information, and the other part describing content information. This configuration makes it possible to make successive compression of documents having, for example, variable contents but structures that are very similar (or vice versa) efficient. In one embodiment, during loading, for each piece of information of a sub-context loaded in said context in memory of the processor, is indicated the sub-context to which it is attached. In this way, the step of identifying the information to be deleted for the purpose of deleting a sub-context can be conducted efficiently. In particular, the context consists of grammars associating productions with coding values, and dictionaries (or vocabulary tables) whose entries associate strings of characters with coding identifiers, and said indication of sub-context is indicated. at the level of the productions and the entries of the dictionaries. This indication on the entries of grammars and dictionaries makes it possible to distinguish them explicitly according to the sub-contexts, whereas several sub-contexts can influence the same grammar or the same dictionary. The identification of information to be deleted can be carried out more efficiently than, for example, reporting dependencies only at the level of grammars and dictionaries. According to a particular characteristic, the context is formed of grammars and dictionaries presenting partitions, and we associate, with each grammar and partition, a counter of the number of subcontexts linked to it. In practice, the appropriate counters are incremented and decremented, respectively, for the loading and deletion of a sub-context that was related to the corresponding grammar / partition. The partitions are to be understood here, in the sense of the EXI standard, that is to say parts of dictionaries which are dedicated to the coding of the values or strings of characters associated with a specific structured element. They allow to use shorter coding identifiers. In this configuration, the state of the counter makes it possible to quickly know if it is possible to treat (in particular during the step of deletion) the grammar or the partition as a whole or if one must carry out the operations of suppression / added at the level of the productions of the grammar and the entries of the partition. Different uses of the invention can be envisaged.

According to one of them, the old and new structured data are each a different structured document. Thus, one goes from the processing (encoding or decoding) of a first document to the processing of a second document. Deleting followed by loading allows the initial configuration of the processor. According to another, old and new structured data belong to the same document. Here, the identification, deletion and loading steps are implemented during the coding / decoding of the same document and update the coding / decoding context for the processing of a new structured data inside the document. . The known prior art does not intend to modify the context in the process of processing the document.

In particular, the new structured data includes a self-contained element in the sense of the EXI standard. In one embodiment, said determination comprises determining a representative type of said new structured data, and said set of subcontexts is determined from said type.

The use of a single piece of information (the type) between the data to be processed and the sub-contexts related to them provides a great efficiency in the determination operations, because these operations are simple. In particular, said type is determined from said new data.

In a variant, said type is determined from a correspondence rule linking the name of a file comprising the new structured data to a type. In one embodiment, said loading of a sub-context is performed from an XML Schema configuration file. Indeed, such a scheme is adapted to describe structured data and thus to provide the information necessary to code / decode (that is to say the information of grammars and dictionaries). Correlatively, the invention also provides a device for configuring a coding / decoding processor for coding new structured data, said processor comprising in memory a coding / decoding context relating to the processing of old structured data, the context being composed of a plurality of subcontexts, the device comprising: means for determining a set of subcontexts defining a coding / decoding context of said new structured data; means for identifying and deleting, in the context of coding / decoding in the processor's memory, at least one sub-context not included in the set determined so as to retain the sub-contexts belonging to said set.

Optionally, the device may comprise means relating to the characteristics of the configuration method described above. An information storage medium, possibly totally or partially removable, readable by a computer system, comprises instructions for a computer program adapted to implement the configuration method according to the invention when this program is loaded and executed by the computer system. A microprocessor-readable computer program comprises portions of software code adapted to implement the configuration method according to the invention, when loaded and executed by the microprocessor. The information storage means and computer program have characteristics and advantages similar to the processes they implement.

Other features and advantages of the invention will become apparent in the description below, illustrated by the accompanying drawings, in which: - Figure 1 schematically shows an EXI processor for the implementation of the invention; FIGS. 2a to 2e illustrate the formation of coding context for the implementation of the invention; FIG. 3 represents, in the form of a logic diagram, steps of the method according to the invention; FIG. 4 represents, in the form of a logic diagram, steps for the determination of subcontexts implemented in the method of FIG. 2; FIG. 5 represents, in the form of a logic diagram, steps for the deletion of subcontexts in the method of FIG. 2; FIG. 6 represents, in the form of a logic diagram, steps for the addition of subcontexts in the method of FIG. 2; and FIG. 7 shows a particular hardware configuration of an information processing device suitable for implementing the methods according to the invention. The invention is now illustrated by an example of decoding SVG files by an EXI processor.

SVG files are previously encoded using several models, typically XML Schemas, describing the data contained in these files, in order to improve their compression ratio. These models make it possible to parameterize the initial configuration of the EXI processor in a similar way to the EXI Schematic mode of the prior art.

Here, there are two types of SVG files: a first type called "Image", which describes still images, and a second type called "Animation", which describes animations. As represented in FIG. 1, an EXI processor 1 used for encoding or decoding structured documents such as XML, comprises a random access memory 10 storing a coding context 12 for encoding / decoding a document, here a file SVG. This context 12 corresponds to the set of information that makes it possible to know how to encode or decode an XML event. It typically includes two types of objects: GRAM grammars as provided by the EXI standard, which describe the XML data structure, and VOCA vocabulary tables, also provided by the EXI standard under the term "string tables", which contain strings.

Five vocabulary tables are distinguished in the EXI specification: - three relate to information on qualified names (a "qualified" name includes a local name [eg tag], a URI [eg xmlns: ml = "http: // canon.crf.fr/xml/monlangage], and possibly a prefix [eg ml]) and namespaces (one for URIs, one for prefixes, one for local names), and - two relate to information on textual values, which appear for an attribute or for a textual content event (a local table and a global table) These grammars and vocabulary tables are extensively documented in the EXI standard and are not described in more detail here. In FIG. 1, the coding context 12 is composed of several sub-contexts 14 and 16, each defining part of the context 12.

If we treat an XML document, we always have at least two sub-contexts: at least one static sub-context 14, which corresponds to the data present in the coding context at the beginning of the data processing, and a sub-context dynamic 16, which corresponds to the data learned during the processing of the data of the XML document by the processor EXI. The static sub-context can be reduced to its simplest expression: default grammars in the EXI sense, when no initial configuration data is used. For the invention, it will generally be assumed that the initial context contains information other than the default grammars. As will be seen later, several static subcontexts 141, 14; can be used. The purpose of the division of context 12 into sub-contexts 14, 16 is to be able to perform operations on these subcontexts. A coding sub-context 14, 16 includes information relating to GRAM grammars and VOCA vocabulary tables. Thus, a sub-context 14, 16 is defined as a set of references to elements of the coding context, that is to say references to GRAM grammars, and entries in the VOCA vocabulary tables, typically partitions. There are two types of VOCA vocabulary tables: those that simply consist of values, for example the list of global values that lists values that can appear anywhere in a document, and those that consist of partitions, for example the list of local values attached to a specific XML element type (for example, all values that a child element takes). As defined by the EXI specification, a VOCA table partition is a sub-table, this sub-table containing a number of entries. In the case of local values, local information (the name of the attribute or element in which the textual value is found) gives a criterion for distinguishing the values encountered and therefore different partitions. By separating the values according to this criterion, the partitions are constituted, the number of possible values in a given context is minimized (the context here being the fact of being within an attribute or a given element, ie a partition), and the numerical code used for the identifier corresponding to the value to be encoded is then shorter. Compression becomes more efficient. The VOCA table of local values therefore contains, for each attribute or element in which a textual value is encountered, a partition, this partition containing entries, each entry consisting of an identifier and a textual value. For the implementation of the invention, at the level of each production and each entry of a partition, the list of subcontexts to which it (production or input) is linked is indicated. This indication may be a simple additional field referencing a sub-context number. As will be seen later, this indication allows efficient management when a grammar or a partition is linked to several sub-contexts 14, 16. Indeed, in this case the references to grammars and partitions do not make it possible to distinguish productions and inputs associated with this or that sub-context 14, 16.

For the invention, a static sub-context 14 is learned by the EXI processor via external configuration data, for example an XML schema, or more generally a profile 20. This learning is for example in accordance with the EXI Schema mode already mentioned. A set of external profiles 201, 202, 20n each associated with static sub-context 14 is therefore provided. By profile 20 is meant the external description of a data model, including structure and / or content indications, which makes it possible to create grammars and / or vocabulary tables for an EXI processor. XML schemas meet this definition. However, any model described in a structured language, as well as compact descriptions of grammars in a dedicated format can be considered. The terms "profile" and "sub-context" are sometimes used throughout the document to denote the coding information specific to the structure and content described. However, the term "profile" will be primarily intended to designate such information when it is considered an external knowledge to configure the processor, and the term "sub-context" to designate this information when they constitute a structure internal to the processor .

In some cases, when we consider a set of structured documents, these documents present structures and similar contents, and we can then model them effectively with only one profile. In contrast, in other cases, the same family of documents can have significant variations, and it may be interesting to define several profiles 20 to model these data, with for example a general profile 201 describing the information common to all the documents, and specialized profiles 202, 20n, describing each a specific variant to the different documents. Back to our example of the SVG "Image" and "Animation" files, we have three profiles 201, 202 and 203. These profiles in XML Schema format and / or in the form of a compact description of grammars and contents in XML format are generated. by conventional generation mechanisms, for example XML files, which are not described in more detail here for this reason. The three profiles comprise: - a General 201 profile, valid for the two types of files because gathering common information; an image profile 202, used in addition to the general profile in the case of still images; and an animation profile 203 used in addition to the General profile in the case of animations.

These three profiles 201, 202 and 203 are represented in FIG. 2a. Each profile describes a list of XML elements, attributes, and possible children for those elements. For example, for profile 201, the "SVG" element (which is the root element of the document) includes two "height" and "width" attributes, and a "path" child element whose attribute components are also listed. In these profiles, the values in parentheses are frequent values for the attributes considered, for example the attribute "height" frequently takes the value "100%". These values constitute an initial vocabulary for the EXI processor when it is configured with this profile, as will be seen later. In general, it is preferable to have as much information as possible to describe models intended to parameterize an EXI processor (notably the possible transitions between attributes and between children). In our example, however, we limit ourselves to limited and essential information in order to make the explanations more easily understood. In our example, we create an EXI processor to decode a previously encoded SVG file, for example the file "image.svg.exi" representing a file of type "Image". This is the first file to decode, coding context 12 is empty. To configure it correctly, it is first determined which profiles were used to encode this file.

The information enabling this determination can be contained in the file itself, for example by using a header field intended to specify external data used during the encoding (in particular an XML schema), or for example thanks to a table associating each file with different profiles. In the example, we take from the name of the file the type to which it corresponds: "Image"; and we deduce that we must use the profiles General 201 and Image 202. We use these two profiles in a conventional way to initialize the processor EXI, that is to say, to create an initial coding context 12, composed of grammars GRAM and VOCA vocabulary tables. Figure 2b presents the grammars obtained from the General 201 profile. In some cases (for example that of the "svg" element), there are two grammars per element, a StartTag grammar intended to model the beginning of the element ( including attributes), and an ElementContent grammar to represent the children of the element. This distinction is specific to the EXI format and contributes to its effectiveness. The grammar StartTag svg thus includes a production to encode a new element "path": production SE path; and productions to code the attributes: ATT productions. It is noted here that the values of the priorities used to code these productions have not been represented, but that they can be conventionally determined in accordance with the EXI specification, for example by assigning a priority value on a single level. for each production. On the other hand, for each production, the sub-context SC1 (associated with the profile 201) to which it is linked is indicated. A StartTag path grammar similarly allows you to encode the content of a "path" element. This grammar includes the productions SE path and EE (end of element) associated with the sub-context SC1.

Each of the grammars GRAM also informs the context to which it is linked (by at least one production), here only the context SC1 (see header of the grammars in Figure 2b).

The processing of the Image 202 profile brings the addition of new grammars to the encoding context 12, as well as the addition of new productions to some existing grammars (StartTag svg and ElementContent svg). In fact, the Image 202 profile provides additional information on the svg element defined in the General 201 profile, which must be taken into account when decoding svg files. The grammars of the coding context 12 thus obtained are represented in FIG. 2c, the priority values not being represented. Within GRAM grammars, we distinguish the productions related to one or another static sub-context 14 ;, thanks to the indication 24 of the profile SC; corresponding. We also visualize globally, using the references to the grammars, to which contexts each grammar is linked: for example the references 22 make it possible to quickly read that the grammar StartTag svg is related to the contexts SC1 and SC2. However, this reference 22 can easily be dispensed with insofar as the indications at the level of each production make it possible to deduce these dependencies. Concerning the other part of the coding context 12, namely the vocabulary tables, only the table listing the values encountered for the different attributes is described here. Figure 2d shows this table. For each attribute name, we use, according to the terminology EXI, a partition P distinct from a vocabulary table. This partition associates identifiers and values. Here, we will have for example a partition for the attribute width, this partition associating the identifiers 0 and 1 with the values 100% and 250 (frequent values of the attribute width according to the profiles General and Image). It is also indicated to which sub-context SC; (Using the corresponding profile 20) each of the entries corresponds to: the "100%" entry of the "width" partition is notably related to the profile 201 and therefore to the associated sub-context referenced SC1. Following the order in which the subcontexts are added, the identifiers 0 and 1 will not designate the same values, that is why, in the general case, the subcontexts SC are ordered; and therefore the associated profiles 20 ;. The profiles / subcontexts are for example ordered according to the corresponding index: SC1 before SC2, or if one names the profiles, using the alphabetical order.

The order can be defined either in the profiles themselves or via another resource, for example a complementary file describing the order of the profiles and their possible dependencies, depending on the type of profiles considered. In our example, the General 201 profile being common and indexed "1", it is considered as priority over the image profile 202, and the identifier 0 of the width partition therefore designates 100% unambiguously. It will be noted here that a variant of the references 22 and indications 24 in the grammars and vocabulary tables consists in using one or more lists 18 of entries describing each sub-context SC; / 14 ;. These lists 18 are stored in memory 10 of the EXI processor.

For GRAM grammars, we keep a reference to each grammar added for the sub-context SC; considered as well as a reference to each production added for this sub-context. For vocabulary tables, a reference is kept to each partition added for the SC subcontext; considered, as well as the number of values added to this partition for this sub-context. In the case of grammars, it happens that the same grammar is used by two sub-contexts, that is why we must also keep information about each production. Similarly, a partition may be used by two sub-contexts, so the number of values added for each sub-context must be retained. In our example, we consider that the subcontexts are ordered, and that it is then enough to know this number of added values for each sub-context SC; to determine the values associated with a given sub-context.

The input lists associated with the general sub-context SC1 and the sub-context Image SC2 are shown in FIG. 2e.

Now that the processor EXI is configured with its initial coding context 12, the file "image.svg.exi" is decoded. This decoding is in accordance with known mechanisms, and therefore modifies the coding context 12 (which is scalable) as the XML elements of the file are processed. Thus, new values can be added to vocabulary tables, new grammars or new productions within grammars. As already mentioned above, all these elements added to the context 12 during this decoding constitute the dynamic sub-context 16. This sub-context is structurally similar to the static subcontexts SC; / 14; previously described. The invention applies when, the decoding being completed, the processor EXI is asked to decode another file, in this case the file "anim.svg.exi" type "Animation".

In the prior art techniques, the processor uses a reset function to delete the context objects 12 created for the previous decode, including grammars and vocabulary tables in the case of an EXI processor. According to an example of the invention, it first seeks to determine the type associated with the file to be processed, in this case the type "Animation". The profiles or sub-contexts necessary for this type of file are determined: here the sub-contexts General SC1 and Animation SC3. Compared to the decoding of the previous file "image.svg.exi", there is a shared profile (General 201), a profile less (Image 202) and a profile more (Animation 203). In addition, there is the dynamic sub-context 16, which contains information specific to the decoded document and therefore not necessary for the document "anim.svg.exi". By manipulating the coding context 12 through subcontexts 14, 16, SC, the invention makes it possible to remove the elements of the coding context 12 relating to the subtext SC2 and the dynamic sub-context 16, and add those related to the SC3 Animation sub-context. Thus, we do not proceed to load the sub-context General SC1 in memory from the corresponding profile. In practice, to delete the elements related to the SC2 Image sub-context, the list 18 of grammars and partitions related to this Image sub-context is scanned. If the grammar or the studied partition is related only to this sub-context (that is to say that it is not listed in another list 18 associated with another sub-context), then one can delete it in one go. On the other hand, if it is linked to another sub-context, it is necessary to delete only the productions related to the sub-context Image, just as if a partition is linked to another sub-context, it is necessary to delete only the values of this sub-context. partition related to the sub-context. For our example and the Image SC2 sub-context, we delete the StartTag rect grammar that is unique to it, as well as only the added productions in the StartTag svg and ElementContent svg grammars. For VOCA vocabulary tables, you simply delete the values 100 and 250 from the height and width partitions, not the height and width partitions in their entirety because there are values related to the General sub-context for each of these partitions. .

Once all the static sub-contexts concerned have been removed, here only the subframe Image SC2 deleted, in the coding context, the general sub-context SC1 (similar to FIG. 2b) and the dynamic sub-context are available. 16. We delete the dynamic sub-context in the same way as we removed the Image sub-context. The sub-context SC3 corresponding to the Animation profile 203 is then added in a manner similar to adding the sub-contexts General and Image as described above. At this stage, the coding context 12 is available to then proceed to the decoding of the target file. Thus, thanks to the invention, rather than reconstructing the entire coding context 12, it was therefore possible to retain the elements that already existed and avoid processing once again data already processed (here the General Profile 201). The invention thus allows a gain in terms of configuration time of the processor. An example of steps of the invention will now be described generally with reference to FIGS. 3 to 6. FIG. 3 presents the general steps. In step E100, an EXI processor receives a request for data processing. This processing can consist in encoding XML data in EXI format, or in decoding data encoded in the EXI format. The data considered can be of two kinds: either a document or a document fragment (typically an XML element and its content, within a document, in particular a self-content element). In step E110, the type of the data to be processed is determined.

In the case where the data to be processed is a document, this type can be determined from the document, by reading the header of the document or by using its name for example. In particular, in the case where the processing to be performed is the decoding of an EXI flow, it is possible that the type of the data is read in the schema identifier field of the EXI flow header, this field is intended to indicate the schema used to compress the data. In the case of processing an XML element and its contents, the type can be the qualified name of the element. Finally, if you have an interface with the EXI processor to specify a document and its type (this may be the case when you encode a document and specify a schema to use to encode it ), then the type is trivially determined by transmitting this information via the interface. Once the known type, it is determined, in step E115, the associated profiles, which are deduced sub-context SC / 14 to consider.

It is also deduced, in step E120, by difference with the current coding context 12, the subcontexts to be deleted and the subcontexts to be added. This step is in particular detailed below with reference to FIG. 4. Since the sets of subcontexts to be deleted and added are known, it is then possible to delete, in step E130, the sub-contexts which must to be, then to add, during step E140, the missing sub-contexts. These deletion and addition steps are described in more detail with reference, respectively, to FIG. 5 and FIG. 6. These deletion / addition operations carried out, the data processing can take place during step E150. , in particular conventional encoding or decoding by the EXI processor. In the case of not treating a document but a document fragment, once the data has been processed, it is necessary to delete the contexts that have been added, in order to return to the configuration of the coding context as it was before entering the fragment. This is particularly the case for self-contained elements. Unless the following fragment calls for a new configuration of the EXI processor, which configuration can be performed in accordance with the invention. It is thus possible to continue the treatment of the sequence of the fragment.

The treatment then ends at step E160. With reference to FIG. 4, the determination of the subcontexts to be considered for deletion or addition is now described. In step E200, we begin by obtaining the set ER of the static subcontexts 14 required for the desired processing. This set is known from the profiles associated with the data type, determined in step E115 of FIG. 1. The step E210 is continued by obtaining the set EC of the current static subcontexts (those which are already in the current 12 coding context). This set can be read directly from the list 18 stored in memory 10 of the EXI processor.

In step E220, we then build the set of sub-contexts to be deleted, consisting of sub-contexts of EC deprived of sub-contexts also belonging to ER. Likewise, in step E230, the set of subcontexts to be added is constructed, consisting of the subcontexts of RE deprived of the subcontexts also belonging to EC. Following these two steps E220 and E230, the lists of subcontexts to be deleted and added contain only static subcontexts 14.

It remains to determine what should be done dynamic sub-context or 16. For this, it is evaluated in step E240 if the data to be treated are a document. If so (YES output of step E240), the dynamic subcontexts 16 are no longer necessary since another document will be decoded. In step E250, they are therefore added to the list of sub-contexts to be deleted. On the other hand, if the data to be processed are not a document (NO output of step E240), it is determined in step E260 whether it is a self-contained element. Indeed, in the case of a self-contained element, the data must be processed independently of the dynamically learned context information; furthermore, the context information learned inside the self-contained element should not be taken into account once the end of this element has been reached. In the affirmative of step E260, a new dynamic sub-context 16 is then added to all the sub-contexts to be added (step E270), then the subcontexts are added. current dynamics to all sub-contexts to be deleted (step 250). Of course, the sub-contexts to be deleted are not to be deleted in absolute terms, but to delete from the coding context 12 of the processor. This is particularly the case for dynamic sub-contexts, which in the case of a self-contained element will be added to the list of sub-contexts to be added once the end of the element has been reached. As explained above, in the case of a self-contained element, the added subcontexts are deleted when the end of the content of this element is reached; Subcontexts that were deleted on entering this element are also restored. In this way, the coding context 12 is restored to process the remainder of the document.

Following step E250, or in the negative of step E260, the processing ends. The deletion step E130 is now described with reference to FIG. 5. It is recalled that this deletion does not necessarily mean that the subcontexts are completely erased, but means that they are removed from the coding context 12. thus save them in another part of the memory 10 of the processor, or simply de-reference the current context 12. Figure 1 illustrates these "disabled" sub-contexts 26 including the grammars and vocabulary defined by this sub-context. Thus, if we must reuse these subcontexts later, we avoid rereading the profiles 20 from which they were built the first time, and we only read locally these sub-contexts already pretreated. This saves time and provides more memory 10 for the corresponding storage. In order to limit the size of additional memory, a set of M subcontexts is kept to a maximum (M being for example defined according to memory constraints), and if this limit is reached, the sub-context is eliminated. less frequently used, or one whose last use goes back further in time. Note also that in the case where the fact of not deleting a coding sub-context has no impact on the encoded or decoded stream (in other words, if the deletion of the context is possible but not necessary), instead to delete this sub-context, one can simply mark it as optional and delete it only if one reaches a certain limit of memory. This may be particularly the case when the coding sub-context "to be deleted" refers to elements not concerned with the "active" coding sub-contexts for the current coding / decoding (for example totally different grammars). The deletion process starts at step E300 by obtaining the subcontexts to be deleted, determined in step E120 (result of the process of FIG. 4). In step E310, it is checked whether there remains a subcontext SC to delete untreated. If so, the list 18 of grammars and entries (partitions) of vocabulary tables related to the sub-context SC (list which can be established using references 22 and 24) is obtained in step E320. when list 18 is not directly considered). Since these lists 18 are constructed (steps E451, E452, E471 and E472 below) when adding each sub-context to the coding context, no calculation is necessary to obtain these lists.

In step E330, it is then determined if there remains a GRAM grammar thus listed untreated. If so, it is determined in step E340 whether GRAM is bound only to SC. If so, then the grammar GRAM is deleted in step E341. Otherwise, only SC-related GRAM productions are deleted in step E342. Following steps E341 and E342, we return to step E330 to evaluate whether there remains a grammar GRAM listed untreated among the grammars linked to the sub-context SC. In the negative of step E330, we proceed to the processing of the vocabulary, in step E350, where it is determined whether there remains a partition P listed untreated. If this is the case, it is verified in step E360 if P is linked only to SC. If so, we can delete the partition P in step E361. Otherwise, only the values of P which are related to SC are deleted in step E362.

Following steps E361 and E362, step E350 is returned to determine if there remains a partition P to be processed.

If not, proceed to step E370 where the off-partition vocabulary is deleted, that is, the vocabulary that belongs to lists of values (for example the list of global values). We then return to step E310, where it is determined whether there remains a sub-context to be removed untreated. When all sub-contexts to be deleted have been processed, processing ends at step E390. The addition step E140 is now described with reference to FIG. 6. At step E400, the set of current subcontexts (known to the processor) and all the subcontexts to be added ( determined in step E120). We continue at step E410, ordering the subcontexts obtained in step E400 as explained above. In step E420, it is evaluated whether there remains a sub-context SC to be added. If so, at step E430, the GRAM grammars and VOCA vocabulary tables defined in the sub-context SC to be added are obtained. To obtain this information, several alternatives are considered. One can read the profile 20 describing the sub-context SC (an XML schema for example), and build the grammars and the partitions which result from it.

In the case where the "inactive" sub-contexts are stored in the memory 26 of the processor, it is checked whether the searched sub-context SC belongs to the conserved subcontexts. If this is not the case, the corresponding profile is read to generate corresponding grammars and partitions. If this is the case, we get the corresponding grammars and partitions. The sub-context SC is then added to the coding context 12. For this, it is evaluated, in the step E440, whether there remains an untreated GRAM grammar among the grammars defined for SC. If this is the case (YES output of step E440), it is determined in step E450 whether such a grammar already exists in the processor's coding context, that is, whether it exists. a grammar GRAM 'describing the same type of element as GRAM. If so, then you should not create GRAM but add (step E451) the GRAM productions, specific to the SC sub-context, the GRAM 'grammar, and mark each added production as linked to SC. On the other hand, if such a grammar GRAM 'does not exist, then GRAM (step E452) is added to the coding context 12. In both cases, the processed grammar is marked (GRAM' in the first case, GRAM in the second). ) as linked to the sub-context SC. At the end of the steps E451 and E452, we return to the step E440 to evaluate whether there is still a grammar to add untreated. In the negative of step E440 (output NO), the processing of the vocabulary is carried out and it is first determined in step E460 whether there remains a partition P to be added that has not been processed. If so, it is determined in step E470 whether P is already defined in the coding context. If so, we add only the values specific to the sub-context SC for the partition P (step E471), and we mark these values as related to the sub-context SC. If not, the partition P with its values is added to the coding context (step E472). In both cases, the partition P is added to the list of partitions related to SC. Following steps E471 and E472, step E460 is returned to determine if there is still a partition to be processed. If not, go to step E480 where the off-partition vocabulary is added, that is, the vocabulary that belongs to lists of values (for example, the vocabulary belonging to the list of global values). We then go back to step E420, where it is determined whether there remains a sub-context SC to be added, and if not, when all subcontexts have been added, the processing ends at step E490. Depending on the type of profiles considered, it is possible, after the additions, to recalculate the production priority codes for certain grammars as well as the identifiers associated with the vocabulary values; for example, if there is for example a grammar containing five productions, each production having a single-level priority code of between 1 and 5, and deleting the productions having priority value 3, this means that priority codes must be updated for productions that previously have priority codes 4 and 5 with codes 3 and 4. For this purpose, it is advantageous to keep a list of grammars updated by adding or deleting of productions when configuring the encoding context, as well as a list of vocabulary tables (a list of partitions in the case of tables that contain partitions) updated by adding or deleting entries during the configuration of the coding context. For objects that existed before configuration and have not been modified, as well as for added objects, no additional calculation is required.

The invention described above simplifies the processing performed at a processor for its reconfiguration for encoding / decoding new structured data. Indeed, a part of the coding context can be preserved, where the known solutions of the prior art led to a complete reconfiguration of the processor.

The invention can be applied to the processing of successive documents, to effectively manage the passage of the coding context of a first document to that of a second document. The simplest case is fully compliant with the EXI specification and yet provides significant gains in document processing. Thus, in the EXI Schema mode, where an XML schema is used to further compress the data, when processing the second document, instead of resetting the encoding context, one begins by determining the schema to use. In particular, during decoding, this means that we begin to read the encoded file keeping the encoding context resulting from the decoding of the previous document, which goes against the conventional mechanism according to which the processing of a new document is accompanied by the reinitialization of the coding context. If the schema to be used is the same as for the previous document, then the context is reset by deleting the dynamic sub-context; if on the other hand it is different, we delete the context. A more complex and preferred case concerns the use of several profiles for a single document, which can be interesting for SVG documents for example. Indeed, the general model of SVG data is particularly rich, and building a coding context from this model is expensive and inefficient in terms of compression because it covers an extremely wide spectrum of documents. As a result, it is more advantageous to build profiles from the documents that one wishes to encode. In this case, each profile corresponds to a coding sub-context, and the transition from one document to another will consist, according to the current sub-contexts (used for the first document) and the following sub-contexts (used for the second document) to delete the current subcontexts that are not in the following and to add to the current subcontexts the following ones that are not in the currents. The invention can also be applied to the taking into account of new external information for the processing of an XML element within the same document processed. In particular, this is the case when step E100 is carried out during step E150, presented above. Here, unlike in the case of successive documents, the coding context is updated during the processing of a document, for example following the processing of a given XML element. According to this XML element, a type is determined, and the subcontexts corresponding to this type are added to the coding context. Thus, in the case where SOAP documents are processed, several schemas are generally needed: the SOAP schema first, but also other schemas that may be involved in the body of the documents. When we encode one of these documents, we do not know a priori which schemas will actually be used in the body of the document, and we therefore encode in the header a reference designating all the schemas. Since the processing of all these schemas for the purpose of constructing the coding context is expensive and may require a large amount of memory, one or more sub-contexts per schema are distinguished and added to the processor coding context only when data corresponding to them are encountered, for example the detection of the type of element concerned.

Referring to Figure 7, is now described by way of example a particular hardware configuration of a processing device adapted to implement the method according to the invention. A processing device embodying the invention is for example a microcomputer 50, a workstation, a personal assistant, or a mobile phone connected to different peripherals. According to yet another embodiment of the invention, the information processing device is in the form of a camera equipped with a communication interface to allow a connection to a network.

The peripherals connected to the information processing device comprise, for example, a digital camera 64, or a scanner or any other image acquisition or storage means, connected to an input / output card (not represented) and providing the information processing device of the multimedia data, possibly in the form of XML documents. The device 50 comprises a communication bus 51 to which are connected: a central processing unit CPU 52, for example in the form of a microprocessor; a read-only memory 53 in which can be contained the programs whose execution allows the implementation of the method according to the invention; a random access memory 54 which, after powering on the device 50, contains the executable code of the programs of the invention and records the coding context 12 and the "deactivated" sub-contexts 26 of FIG. 1; a screen 55 making it possible to display data and / or to serve as a graphical interface with the user who can thus interact with the programs of the invention, using a keyboard 56 or any other means such as a pointing device, such as for example a mouse 57 or an optical pen; a hard disk 58 or a storage memory, such as a compact flash type memory, which may comprise the programs of the invention as well as data used or produced during the implementation of the invention; an optional diskette reader 59 or another removable data medium reader adapted to receive a floppy disk 70 and to read / write data processed or to be processed in accordance with the invention; and a communication interface 60 connected to the telecommunications network 61, the interface 60 being able to transmit and receive data. In the case of audio data, the device 50 is preferably equipped with an input / output card (not shown) which is connected to a microphone 62. The communication bus 51 allows communication and interoperability between the different elements. included in the device 50 or connected thereto. The representation of the bus 51 is not limiting and, in particular, the central unit 52 is able to communicate instructions to any element of the device 50 directly or via another element of the device 50. be replaced by any information medium such as, for example, a rewritable compact disc (CD-ROM) or not, a ZIP disk or a memory card. In general, an information storage means, readable by a microcomputer or by a microprocessor, integrated or not integrated with the information processing device, possibly removable, is adapted to memorize one or more programs whose execution allows the implementation of the method according to the invention.

The executable code enabling the processing device to implement the invention can be indifferently stored in read-only memory 53, on hard disk 58 or on a removable digital medium such as for example a diskette 63 as described above. According to one variant, the executable code of the programs is received via the telecommunications network 61, via the interface 60, to be stored in one of the storage means of the device 50 (such as the hard disk 58 for example) before to be executed.

The central unit 52 controls and directs the execution of the instructions or portions of software code of the program or programs of the invention, the instructions or portions of software code being stored in one of the aforementioned storage means. When the device 50 is turned on, the program or programs that are stored in a non-volatile memory, for example the hard disk 58 or the read-only memory 53, are transferred into the random access memory 54 which then contains the executable code of the or programs of the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.

Note also that the device embodying the invention or incorporating it is also feasible in the form of a programmed apparatus. For example, such a device may then contain the code of the computer program or programs in a form fixed in a specific application integrated circuit (ASIC).

The device described here and, particularly, the central unit 52, are able to implement all or part of the processes described in connection with Figures 1 to 6, to implement the method of the present invention and constitute the system object of the present invention. The foregoing examples are only embodiments of the invention which are not limited thereto. In particular, the profiles 20 have been presented as structured around a common General 201 profile and specialized profiles 202 and 203. As a variant, a hierarchy of profiles is provided, each document corresponding to a particular profile in each hierarchical level (for example: 25 example General / Image / Icon for a three-level hierarchy). According to another variant, there are provided profiles describing the structure, and others describing the content Finally, it is possible to provide modular profiles, each document being able to correspond to different modules, independently of any hierarchy. It is also possible to separate the description of XML documents (obtained from an XML schema or from another source) into different parts, each part representing a sub-context SC. These different parts bring together elements / attributes very commonly used together. This separation makes it possible for example to load only part of the schema / profile for the coding / decoding of a document and not the whole schema. In this case, the decomposition into profiles according to a compression criterion is not carried out but according to a criterion of minimization of the memory consumption and processing time necessary for the use of an EXI mode with external information. There are two examples of cases where the description is divided into different parts. First, the one where we have to support a model (for example a schema, or a set of schemas), but where we know that in the majority of cases, we will restrict ourselves to a sub-part of the model: then, it is interesting to create a profile dedicated to this sub-part of the model, this profile defining a sub-context, and one or more other profiles defining as many complementary sub-contexts to describe the rest of the model. Secondly, in the case where we have to support a model and where we have a set of documents instantiating this model, we can try to restrict the model from the instances: thus, we can determine parts of the model. more frequent than others, and in this case define them in a dedicated profile. In both cases, the division of the starting model does not affect the EXI flow, the whole model remaining supported. Finally, to conclude on this aspect, the division of the model into profiles can be improved thanks to the successive processing of the documents instantiating the model by a learning algorithm.

Depending on the type of profiles chosen, the constraints imposed on the invention are different. Indeed, the more the profiles are independent of each other, the easier it is to add or delete a sub-context; on the other hand, if the profiles are very related (if, for example, several profiles give different definitions of an XML element), then the resulting grammars or vocabulary tables are likely to contain information related to different sub-contexts, and adding or removing a sub-context will require more calculations.

Therefore, if the invention does not require the use of a particular type of profile, it is however preferable to use disjoint profiles (i.e. concerning different grammars and partitions) if the we want to obtain the best efficiency gains.

We have also seen above that it is important to memorize the links between sub-context and production / partition entry. In this context, an interesting particular case is that where the profiles are constructed by ensuring that each value of a partition can belong to only one sub-context. In concrete terms, this means that the width attribute with the value 100 (see figure 2) does not appear in two profiles. In this case, by ordering the sub-contexts as mentioned above, it is sufficient to know the number of entries for each sub-context to fully determine the entries related to a given sub-context. Indeed, if one names Ni the number of values related to the i-th sub-context for a given partition, then the values for the first sub-context are the first NO, those for the second sub-context are the N1 following, etc. Moreover, to check if a grammar or a partition is linked to one or more sub-contexts (information which makes it possible to know if one can treat the grammar or the partition as a whole or if one must work at the level E340, E360), it may be interesting to keep, for each grammar and each partition, a counter of the number of subcontexts to which it is linked. In this way, when we treat a sub-context from the reference lists, we can easily determine whether to consider other sub-contexts (counter greater than 1) or not (counter equal to 1).

Claims (21)

REVENDICATIONS1. Method for configuring a coding / decoding processor (1) for encoding / decoding new structured data, said processor comprising in memory (10) a coding / decoding context (12) relating to the processing (E105) of old structured data, characterized in that the context is composed of a plurality of sub-contexts (14, 16, SC), and the method comprises the following steps: - determining (E120) a set of sub-contexts 10 defining a coding / decoding context (12) of said new structured data; the identification and deletion (E130, E220), in the context of coding / decoding (12) in memory (10) of the processor (1), of at least one sub-context (14, SC) not included in the set determined so as to retain the sub-contexts belonging to said set. The method according to claim 1, wherein said coding / decoding context (12) comprises a dynamic sub-context (16) comprising coding / decoding information learned by the processor (1) during the processing (E150) of said old data, and at least one static sub-context (14;) comprising encoding / decoding information created by the processor (1) from external configuration data (20;). 3. Method according to the preceding claim, wherein said deletion (E130) comprises that of the dynamic sub-context (16). 4. The method according to one of the preceding claims, wherein said deletion (E130) in the context comprises the storage in memory (26) of said at least one deleted sub-context. 5. Method according to the preceding claim, wherein the memory (26) storing the deleted sub-context has a limited size, and the least used memory sub-context is deleted when the available memory size is less than the size. the deleted subcontext to save. 6. Method according to one of the preceding claims, comprising the loading (E140) of a sub-context (14, SC) not present in said context (12) in memory (10) of the processor (1) and belonging to said set determined. The method of claim 6, wherein said loading (E140) comprises copying said sub-context from a memory (26) storing inactive subcontexts to said processor memory context (12). The method according to claim 6 or 7, wherein, during the loading (E140), one indicates (E451, E452, E471, E472), for each information of a sub-context loaded in said context (12) in memory (10) of the processor, the sub-context (14, SC) to which it is attached. 9. Method according to the preceding claim, wherein the context (12) is formed of grammars (GRAM) associating productions with coding values, and of dictionaries (VOCA) whose entries associate strings of characters with coding identifiers. , and said sub-context indication (22, 24) (14, SC) is filled in at the level of the productions and the entries of the dictionaries. The method according to claim 8 or 9, wherein the context (12) consists of grammars (GRAM) and dictionaries (VOCA) having partitions (P), and each grammar (GRAM) and partition ( P), a counter of the number of subcontexts (14, SC) linked to it. 11. The method according to one of claims 6 to 10, wherein the old and new structured data are each a different structured document. 12. Method according to one of claims 6 to 11, wherein the old and new structured data belong to the same document. 13. The method according to the preceding claim, wherein the new structured data comprise a self-contained element in the sense of the EXI standard. 14. Method according to one of claims 6 to 13, wherein said loading (E140) of a sub-context (14i, SC;) is performed from a file (20;) of configuration type XML Schema . The method according to one of the preceding claims, wherein said determining (E120) comprises determining (E110) a representative type of said new structured data, and said set of subcontexts (14, SC) is determined (E120). ) from said type. 16. The method according to the preceding claim, wherein said type is determined from said new data. 17. Method according to one of the preceding claims, wherein the subcontexts (14, SC) are disjoint two by two. 18. Method according to one of the preceding claims, comprising the scheduling of the subcontexts (14, SC) preserved and loaded. 19. Device for configuring a coding / decoding processor (1) for coding new structured data, said processor comprising in memory (10) a coding / decoding context (12) relating to the processing (E150) of old structured data, characterized in that the context is composed of a plurality of sub-contexts (14, 16, SC), and the device comprises: - a means for determining (E120) a set of sub-contexts defining a coding / decoding context (12) of said new structured data; an identification and deletion means (E130, E220), in the context of coding / decoding (12) in memory (10) of the processor (1), of at least one sub-context (14, SC) not included in the set determined so as to retain the sub-contexts belonging to said set. 20. Information storage medium, possibly totally or partially removable, readable by a computer system, comprising instructions for a computer program adapted to implement the method according to any one of claims 1 to 18, when the program is loaded and executed by the computer system. A microprocessor-readable computer program product comprising portions of software code adapted to implement the method of any of claims 1 to 18 when loaded and executed by the microprocessor.