FR2908539A1 - Expression e.g. XML Path expression, evaluating method for processing XML data flow, involves evaluating each sub-expression relative to location path on data of structured document using XML path browser - Google Patents

Abstract

The method involves determining data of a structured document satisfying an expression such as XML Path expression, where the expression is composed of two sub expressions. Each sub expression is relative to a XML location path. Each sub-expression relative to the location path is evaluated on the data of the structured document using one of a set of XML path browsers (23). The numbers of browsers are determined using a determining unit. Independent claims are also included for the following: (1) a device for evaluating an expression for accessing a part of a structured document (2) a computer program comprising a set of instructions for performing a expression evaluating method (3) an information storage medium comprising a set of instructions for performing a expression evaluating method.

Description

The present invention relates to a method and a device

  evaluating an expression, in particular an XPath-type expression on the data contained in a structured document. It finds a general application in the processing of XML data streams and more specifically on files in XML format. The XPath (acronym for XML Path Language) is derived from a W3C consortium specification called XPath Specification 1.0, available at www.w3.org/TR/xpath. The purpose of this language is to define a syntax suitable for addressing parts of a structured document of the XML type. The syntax of this language uses a syntax similar to that used in expressions relating to location paths in a file system, for example the expression relating to a location / library / book path. The XPath language defines four types of data that are string, Boolean, number and set of nodes, seven types of nodes, and expressions for manipulating the data, including the defined operators equality, difference, inferiority, superiority, addition, subtraction, multiplication, division, modulo, or binary and and binary. When at the nodes, they can represent different types of XML event, for example the beginning of the document (also called the root node), an element, an attribute, a text, a comment, a processing instruction (processing-instruction in English terminology) and a 2 2908539 2 namespace (namespace in Anglo-Saxon terminology). This syntax allows the expression of queries on structured documents in view, for example of their transformation (for example the XSLT transformation according to the W3C recommendation defined at the address www.w3.org/TR/xslt), of the fast access to subparts (for example according to the W3C recommendation: XPointer: www.w3.org/TR/WD-xptr) or performing processing on parts of the document (for example according to XQuery 1.0 , defined at www.w3.org/TR/xquery). The XPath language makes it possible to simplify the development of applications capable of traversing data in structured documents of the XML type. The entity capable of performing the evaluation of an XPath expression is called XPath processor (XPath Processor in English terminology). From an XPath expression and a reference to XML data stored in a document or received via a network transmission, the XPath processor evaluates the expression. The XPath syntax also defines a grammar describing the construction rules of different expressions and subexpressions. These expressions include expressions that return a boolean (for example, the expressions OrExpr, AndExpr, RelativeExpr, EqualityExpr), expressions that return a number (for example, AdditiveExpr, MultiplicativeExpr), expressions that return any type of data (for example, for example, FilterExpr and FunctionCall expressions), and expressions returning an ordered list of nodes (for example, LocationPath expressions corresponding to the specification of a path to be resolved in an XML document). The invention is particularly suitable for expressions relating to a location path (LocationPath according to the XPath syntax). An expression relating to a location path may be absolute or relative depending on whether it begins with / or not. In the case of an expression relating to an absolute path, the search starts from the beginning of the document, also called the root, whereas in the case of an expression relative to a relative path, the search is contextual, for example from the current node. Any expression relating to a location path is composed of a set of expressions indicating the location steps in this path (Steps in English terminology), and each location step corresponding to a level of decomposition for the evaluation. of the expression relating to a location path. Indeed, each location step can be mapped to a depth level in the XML document. For example, the expression relating to the path / library / book includes two localization steps which are on the one hand a library, searched for in depth 1 and on the other hand a book, searched for in depth 2. The evaluation of a The locating step is in particular based on the expression of the parent location step, ie the previous location step in the expression. The result of the evaluation of a location step provides the evaluation context for the next location step. This context is composed of three elements: a node called context node, a position and a size. The context node is the node in the document that verifies the previous location step, the position indicates the rank of the solution node of the current location step among its siblings, the context size indicates the number of solution nodes of the current location step. Any location step includes one to three of the following 25 entities. First, the entity expressing a filiation, also called axes, (AxisSpecifier according to the XPath syntax) describes the relationship between a context node and the solution nodes of a location step. This entity is optional. For example, the expressions / a / child :: b and / a / attribute :: b 30 mean that we look for, respectively, a child node b of a node a and a node representing a attribute b son of a child. node a. The specification defines 13 entity types expressing an affiliation relation 2908539 4 (AxisSpecifier) which are: self, child, attribute (or @), namespace, descendant, descendant-or-self, following, following-sibling which are considered as descendant expressions (forward axes in English) and parent, ancestor, ancestor-or-self, preceding and preceding-sibling which are considered as expressions of ascending parentage (backward or reverse axes in English). Next, the entity expressing an eligibility test of a candidate node (NodeTest according to the XPath syntax) defines either a type constraint or a name constraint that the candidate nodes must satisfy to be considered as a solution of a step location. This entity is mandatory. The syntax defines various tests on the type of nodes, notably the node () constraint according to the XPath syntax), the text constraint (XPath syntax), the comment type constraint ( how ()), according to the XPath syntax) and the processing-instruction () according to the XPath syntax). For example, the expression / child :: b imposes a name constraint while the / descendant :: commentO expression searches for all comment type nodes. Finally, the entity expressing a predicate (Predicate according to the XPath syntax) makes it possible to impose one or more additional conditions for searching for solution nodes of a location step. This entity is optional. An expression called predicate, enclosed in square brackets, follows the same construction rules as any XPath expression. For example, the expression / a / b [2] makes it possible to select all the second child elements of name b from each node of type element of name a, and the expression / a / b [@ id = 3] makes it possible to select the name threads of name element node a having an id attribute with a value of 3. The current XPath implementation provides access to parts of an XML document after constructing a representation 2908539 The intermediate of the XML document can facilitate the search, in particular in the form of a tree representing a model of objects of the document (Document Object Model or DOM in English terminology defined at the address www.w3.org/DOM ). Thus the search consists in traversing this tree as many as 5 times as necessary for the extraction of the requested nodes. Such an approach poses a double problem. This solution is expensive in memory space especially in the case of large XML documents. Indeed, if an XPath processor is implanted in a camera, photocopier or other type of apparatus with limited resources, the intermediate representation may be too large to be stored. Moreover, this solution proves costly in execution time because of the multiple paths on the DOM tree when searching for solution nodes of the XPath expression. The on-the-fly evaluation of an XPath expression consists in the ideal case of processing the XML events as they are received by the XPath processor. Thus, for each received event, the XPath processor decides whether or not the node satisfies the constraints of the current location step until the last location step expressed in the expression relating to a location path. However, determining compliance with the constraints of an XML event is not always possible at the moment the XPath processor receives and processes this event. This is particularly the case when the expression relating to a location path contains predicates. The example illustrated in FIG. 1 comprises an example of an XML document (0.1) where each line read represents an event to be processed (0.2). It is illustrated by the evaluation of the expression / a / b [b]. This evaluation will produce as a result <b val = 123 attr2 = blabla> when the event <B> b0 </ b> will be received (0. 3).  In addition, an additional problem is the problem of nested solutions.  This one corresponds to the application of the entities expressing a filiation 30 of type descendant (descendant according to the syntax XPath) and of type descendant or node context (descendant-or-self according to the syntax XPath) on recursive XML documents.  According to the example illustrated in FIG. 1, an expression of the type // b / c (i. e.  / Descendant-or-self. -: node0 / b / c) which consists of searching all the nodes of type element name c child of node of type element of name b being at any depth of the XML document poses the following problems.  First, during the evaluation, the correspondence between a location step and the depth in the XML document is lost.  Indeed, in the above expressions, the search is not limited to the search for elements b having a depth of two and elements 10 c having a depth of three.  Then, when searching for elements c solving the step of location of level three, the processor must first detect any b elements encountered as a solution of the level two location step and on which c son nodes are sought .  Thus, the resolution of the above expression can be seen as the search for the b / c pattern at any depth level.  The on-the-fly evaluation, to be complete, must also allow the results to be issued as and when they are determined.  It is known from document US2004068487 entitled Method for 20 streaming XPath processing with forward and backward axes a method capable of evaluating expressions on the fly in which the XPath expressions containing ascending parenting relations (reverse axes according to the XPath syntax) are re-evaluated. written.  This evaluation method is performed from a representation of the expression in the form of a tree (XTree) of the XML document.  This tree makes it possible to obtain relations of filiation forward and thus to guarantee a single course of the XML flow.  However, according to this method, the XPath processor must analyze all the nodes provided by an XML parser, which can lead in the case of the simplest expressions to an extra cost in evaluation time.  For each node thus received, the processor returns a status: solution, no solution or potential solution.  According to US20040172599 entitled Systems and methods for streaming XPath queries, there is described an XPath processor compatible with on-the-fly processing.  According to this method, the processor receives events from an analyzer, decides on the correspondence character of these events with respect to an expression and informs an application using the result nodes.  This solution has the same disadvantages as the previous one namely the exhaustive analysis of all the nodes of the XML flow.  In view of the foregoing, it would therefore be of interest to be able to evaluate expressions, including XPath expressions on the fly by limiting multiple paths and storing structured data and bypassing at least some of the mentioned drawbacks. above.  The present invention aims first of all at providing a method of evaluating an expression for accessing at least a part of a structured document by means of at least one browser able to extract the structured data from the document, the expression being composed of at least two sub-expressions each relating to a location path, characterized in that it comprises a step of evaluating each of the subexpressions on the basis of the data of the document by means of at least one 20 separate browser for each subexpression.  The method for evaluating an expression, in particular an XPath type expression, for accessing at least a portion of a structured document by means of at least one browser able to extract the structured data from the document according to the invention makes it possible to to determine the data of the document satisfying the expression.  The expression is composed of at least two sub expressions each relating to a location path.  According to the invention, each of the subexpressions relating to a location path is evaluated on the data of the document from at least one separate browser.  Thus, it is permissible to evaluate expressions on the fly by limiting, on the one hand, the data storage of the structured document and, on the other hand, limiting the multiple paths of the structured document in an optimized mode.  The method further provides the results as soon as they are calculated.  To do this, the method according to the invention uses several browsers able to process the subexpressions of the expression.  According to one particular characteristic, the method comprises a preliminary step of determining the number of browsers.  Thus, the number of browsers is chosen so as to optimize the processing of a given expression.  According to another particular characteristic, each subexpression relating to a path comprises a set of location steps.  According to a particular characteristic, each location step comprises at least one entity expressing a filiation between the structured data.  According to another particular characteristic, filiation is an indirect filiation.  According to a particular characteristic, the method comprises a step of determining subexpressions having at least one entity expressing indirect filiation.  According to one particular characteristic, the method comprises an in-depth test step on said at least one entity expressing indirect filiation, the in-depth test being a function of conditions on the data and on the previous evaluations of said data.  According to a particular characteristic, the method comprises: a step of extracting the data on the basis of which the subexpressions are evaluated; and a step of storing the extracted data.  The in-depth test makes it possible to extract results and in particular any nested (or nested) results regardless of their depth by only storing part of their history and without multiple paths.  According to a particular characteristic, when evaluating a second subexpression following a first subexpression, the at least one browser of the second subexpression is initialized with the browser context of the first subexpression. subexpression.  Thus, the browser used to analyze the second subexpression is able to resume processing at the same level as the browser used for the first subexpression.  According to a particular characteristic, each of said browsers controls at least one parser of the structured document.  According to a particular characteristic, if browsers use the same analyzer, the data extracted by a browser is reused by another browser using this same analyzer.  According to a particular characteristic, the method comprises a step of determining the data extracted from the document verifying all the subexpressions.  According to a particular characteristic, as soon as data are determined, said data is provided to an application capable of processing these data.  According to the invention, an application is allowed to obtain the results of the evaluation as and when the data satisfying the expression are determined.  The invention allows the transmission of data as it goes, which makes it possible to process the data more quickly at the application level, without having to wait for the complete processing and therefore without necessarily resorting to the storage of these results.  According to a particular characteristic, the determined data are stored.  According to a particular characteristic, if specific data have a direct or indirect affiliation relationship with previously determined data, then these data are sent after the previously determined data.  Furthermore, according to this characteristic, the data satisfying the expression are issued in the order of the document.  This makes it possible to be compatible, in particular, with the XPath 1 specification. 0.  According to a particular characteristic, the transmission of the determined data is preceded by a start signal and is followed by an end signal.  This allows the application to be informed of the beginning and the end of a result, which allows it to immediately process this result.  Thus, according to this characteristic, the application that receives the data satisfying the expression has no separation of the results to be performed.  Correlatively, the invention also provides a device for evaluating an expression for accessing at least a portion of a structured document by means of at least one browser able to extract the structured data from the document, the expression being composed of at least two sub-expressions each relating to a location path, characterized in that it comprises means for evaluating each of the subexpressions on the basis of the data of the document by means of at least one browser distinct for each subexpression.  This device has the same advantages as the evaluation method of an expression briefly described above and they will not be recalled here.  In other aspects, the invention also relates to computer programs for carrying out the method of the invention described briefly above.  Other aspects and advantages of the present invention will appear more clearly on reading the following description, this description being given solely by way of nonlimiting example and with reference to the appended drawings, in which: FIG. 1 represents an example of an XML document on which an expression is evaluated; FIG. 2 illustrates the application context of the invention; FIG. 3 schematically represents an apparatus in which the invention is implemented; FIG. 4 illustrates an algorithm for compiling an XPath expression according to the invention; FIG. 5 illustrates an analysis algorithm for expressions of filiation according to the invention; FIG. 6 represents an evaluation algorithm of an XPath expression according to the invention; FIG. 7 illustrates an evaluation algorithm for expressions of filiation according to the invention; FIG. 8 illustrates an algorithm for searching a candidate node 10 according to the invention; FIG. 9 illustrates a test algorithm according to the normal mode according to the invention; FIG. 10 illustrates a test algorithm according to the in-depth mode according to the invention; FIG. 11 illustrates the evaluation of an XPath expression on an XML document according to the invention; FIG. 12 illustrates an early signal processing by a browser according to the invention; FIG. 13 illustrates a processing of any XML event retrieved by the browser; and FIG. 14 illustrates an algorithm processing the nested results.  The invention consists in evaluating expressions, in particular XPath expressions, on the fly by limiting both the multiple paths and the storage of data, in particular XML data, to access at least part of a structured document.  More particularly, the description will relate to the evaluation of the expressions relating to a location path (XPath syntax LocationPath) containing descent expression entity entities (AxisSpecifier according to XPath syntax) (forward AxisSpecifier in English terminology). Saxon), that is, the entities that specify the parent or node descendants relationship to a given context node.  In addition, the description of the invention includes providing to an application the results of the evaluation as they are determined.  For this, the XPath processor uses several XML parsers also called XML (XML Parser) browsers.  As described below, the number of browsers can be determined in advance.  These can be enabled or disabled and can be synchronized as soon as necessary.  In addition, the invention makes it possible to detect and process the nested solutions, in particular by activating as soon as necessary the memorization of a history of the nodes processed by the analyzer and by carrying out an in-depth test on these nodes.  However, a prior step of analyzing the location steps from the compilation is necessary.  FIG. 2 illustrates the application context of the invention in which an application 1 processes XML data extracted by an XPath processor 2 by means of one or more XML analyzers 3 from an XML data stream 4, an XML parser can be an XML browser.  According to one embodiment, the XPath processor 2 comprises three entities.  First, it includes a compiler 21 whose role is to analyze the expressions and translate them into an internal representation.  The operation of this compiler is described below with reference to FIG. 4.  Next, the XPath processor comprises a execution control unit 22 able to manage, on the one hand, the interactions between the different modules of the XPath processor and, on the other hand, the communication of the XPath processor with the application 1. .  In addition, it supports the evaluation of nodes.  In addition, the XPath processor includes one or more XPath browsers 23 that enable the execution control unit 22 to generically drive one or more XML parsers 3.  The XPath browsers 23 are also able to represent the XML events received from the XML parsers 2908539 13 3 as XPath nodes.  XPath browsers 23 have a buffer, if necessary, to store XPath nodes.  XML parsers are responsible for extracting XML information from the stream or document 4 and sending it to the XPath processor 2.  The evaluation of an XPath expression is described in particular with reference to FIGS. 4 and 5, and comprises a compilation phase implemented for example by the compiler 21 and an evaluation phase implemented for example by the execution control unit 22.  With reference to FIG. 3, a device capable of functioning as a device for evaluating an expression, in particular an XPath expression for accessing at least a portion of a structured document, is now described in its hardware configuration. .  The device of FIG. 3 possesses all the means necessary for carrying out the method of evaluating an expression, in particular an XPath expression, for accessing at least a portion of a structured document according to FIG. invention.  According to the embodiment chosen, this device may be for example a microcomputer 300 connected to different peripherals, for example a digital camera 301 (or a scanner, or any other means 20 for acquiring or storing an image) connected to a graphics card.  The microcomputer 300 preferably comprises a communication interface 302 connected to a network 303 capable of transmitting digital information.  The microcomputer 300 also comprises a storage means 304, such as for example a hard disk, as well as a floppy disk drive 305.  Disk 306 as disk 304 may contain XML data according to the invention as well as the code of the invention which, once read by microcomputer 300, will be stored in hard disk 304.  According to one variant, the program or programs enabling the device 300 to implement the invention are stored in a ROM 307.  According to another variant, the program or programs are totally or partially received through the communication network 303 to be stored as indicated.  The microcomputer 300 may also be connected to a microphone 308 via an input / output card (not shown).  The microcomputer 300 also includes a screen 309 for viewing the results of the evaluations to the user.  Using the keyboard 310 or any other suitable means, the user can specify an XPath expression.  The CPU 311 executes the instructions relating to the implementation of the invention, these instructions being stored in the ROM ROM 307 or in the other storage elements described.  Upon power-up, programs and methods for evaluating expression, including XPath expression, and extracting XML events stored in one of the nonvolatile memories, for example ROM 307, are transferred to RAM RAM 312 which will contain the executable code of the invention and the variables necessary for the implementation of the invention.  Alternatively, the methods may be stored in different storage locations of the device 300.  In general, a means for storing information that can be read by a computer or by a microprocessor, whether or not integrated into the device, possibly removable, stores a program the execution of which implements the method for evaluating expressions.  It is also possible to change the embodiment of the invention, for example, by adding updated or improved evaluation methods which are transmitted by the communication network 303 or loaded via one or several discs 306.  Of course, floppy disks 306 can be replaced by any information medium such as CD-ROM or memory card.  A communication bus 313 allows communication between the different elements of the microcomputer 300 and the elements connected thereto.  Note that the representation of the bus 313 is not limiting.  Indeed, the CPU 311 is, for example, capable of communicating instructions to any element of the microcomputer 300, directly or via another element of the microcomputer 300.  FIG. 4 illustrates an algorithm for compiling an XPath expression implemented in the compiler of an XPath processor according to the invention.  The XPath expression to be evaluated may be specified by a user or stored for example in a file and read by the application 1.  According to another embodiment, the XPath expression results from the execution by the application of a program generating XPath expressions.  The expression is received by the XPath processor 2 in step E41.  Step E42, which follows step E41, begins the lexical analysis of the expression.  To do this and according to one embodiment, it is analyzed one by one the characters of the XPath expression to then group the characters and form symbols, also known as Anglo-Saxon Tokens.  The grouping of characters makes it possible to determine in particular the reserved symbols defined in the XPath specification, for example the / character, or character classes representing, for example, digits or simple characters.  Step E42 is followed by step E43 in which the validity of the determined symbols is checked.  If in step E43 an invalid, not allowed or unknown symbol is detected, then step E43 is followed by step E44 in which the compiler completes its execution and informs the XPath processor 2 of the non-conformity of the expression.  If in step E43, an invalid, not allowed or unknown symbol is not detected, then step E43 is followed by step E45 during which the parsing step is executed.  This step is for the compiler 21 to browse the list of symbols determined in step E42 and identify the types of expression defined by the XPath syntax 1. 0 in the expression to compile.  For example, if the first found symbol corresponds to /, then the expression is relative to an absolute localization path (AbsoluteLocationPath according to the XPath syntax) in the sense of the XPath grammar.  In this case, the compiler 21 continues the analysis of the symbols to identify the components of the path (LocationPath according to the XPath syntax), that is to say the location steps, which can be composed of entities expressing a filiation relation (AxisSpecifier according to the XPath syntax), an eligibility test (NodeTest according to the XPath syntax) and possibly one or more predicates.  During this same step E45, as soon as the compiler identifies a localization expression, it initializes an XPath navigator 23 which will support the search for candidate nodes for the resolution of this expression.  This treatment is described below with reference to FIGS. 6 and 7.  Step E45 is followed by step E46 in which it is verified that the expression, i.e., the symbol sequence, is valid in the sense of the XPath grammar.  If not, step E46 continues in step E44 previously described.  On the contrary, if the expression is valid, then the algorithm proceeds to step E47 during which the compiler 21 allocates in memory a representation structure of each component of the expression.  This step is followed by step E48 which consists of analyzing the localization steps extracted by the compiler 21 during step E45.  This step is described in more detail below with reference to Figure 5.  During this step, it is determined, for each location step of each expression relating to a location path, the test mode that must be performed by the execution control unit 22 during the evaluation of this step of location.  According to one embodiment according to the invention, two types of test can be performed: either the simple eligibility test (NodeTest in English terminology) or a test of the deep node, the latter is described below in reference to Figure 10.  After this analysis, the compiler 21 informs the execution control unit 22 of the end of the analysis, the latter will then start the evaluation of the expression (step E49).  Step E48 of FIG. 4 determines for each location step of each expression relating to a location path of an XPath expression the test mode to be applied during its evaluation.  Different test modes can be envisaged.  First of all, the normal test mode corresponds to the simple application of the eligibility test corresponding to the location step.  According to a particular embodiment, this is the default mode, especially when the representation of the location step is constructed by the compiler.  Next, a test mode may consist of the deep mode.  This requires a test on the history of the candidate node.  Finally, a test mode may consist of not performing any test.  This test mode corresponds to certain combinations of entities expressing a relation of filiation (AxisSpecifier) and of eligibility test.  In this case, any candidate node is a result for the location step.  We will then speak of virtual location step (VirtualStep in English terminology).  According to a particular embodiment, step E48 is performed at the same time as step E47 of constructing representation structures.  The analysis of locating steps is now described with reference to Figure 5.  The analysis of the location steps from the compilation starts with step E500 of obtaining the structure built by the compiler in step E47 of Figure 4 representing the expression relative to a location path whose location steps will be analyzed.  This structure includes a list of location steps that make up the expression relating to a location path.  The first location step is retrieved during step E501.  The representation of the location step stores references to the structures that compose it, for example the representation of the entity expressing a filiation relationship and the eligibility test as well as a representation of the type of node expected as a solution. .  For example, this representation comprises the type, a prefix, a name, a depth increment with respect to the context node.  The value of the entity expressing a relation of filiation of the expression relating to a location path is thus obtained during step E502, in particular by means of the reference contained in the representation structure of the location step .  The step E502 is followed by the step E503 of testing the value of the entity to determine whether it is a descending parent relationship (descending according to the XPath syntax).  If the test is positive, then step E503 is followed by step E504 in which the depth increment of the expected node is set to a value to represent infinity.  This step is then followed by step E505 of determining whether the representation structure of the locating step comprises a next locating step.  If there is no next location step, then the algorithm proceeds to step E506 of determining whether there is an expression relating to a next location path to be processed.  In the positive case, the algorithm continues in step E501 previously described.  If the test of step E506 is negative, then the algorithm of FIG. 5 is terminated.  Returning to step E505, if there is a next location step to be processed, then the algorithm proceeds to step E507.  Step E507 is to mark the next location step as undergoing a thorough test.  Then, this step is followed by the previously described step E502 during which the next location step is analyzed.  Returning to step E503, if the entity value determines a different descent relationship than the descending type, then the algorithm proceeds to step E508 in which the entity is tested to determine whether the value reflects a descendant-type relationship or itself (that is, of any depth, including the current depth).  If the test is negative, then the algorithm proceeds to step E509 of assigning the value 1 to the depth increment.  At the end of this step, the algorithm proceeds to step E510 of determining whether there is a next location step to be processed.  If this is the case, step E510 is followed by the previously described step E502 during which the next location step is analyzed.  If there is no next location step, then the algorithm proceeds to step E506, previously described, of determining whether there is an expression relating to a next location path to be processed.  Back to step E508, if the test is positive, that is, if the entity reflects a downlink or context node relationship, then the algorithm proceeds to step E511 during which one tests the value of the eligibility test of the current location step.  If this value corresponds to a test on the node () according to the XPath syntax, then the algorithm continues in step E512.  Indeed, in this case, the location step is considered to be a virtual location step (Virtual Step according to the XPath syntax).  For this reason, step E512 is to mark this location step as virtual.  The algorithm continues in step E510 previously described.  Returning to step E511, if the test is negative, then the algorithm proceeds to step E513 of marking the locating step as undergoing a normal test.  During this same step, the depth increment of the expected node is set to a value indicating infinity.  However, the next location step obtained in step E505 will be marked in step E506 as being for further testing.  At the end of this algorithm, the execution control unit 22 has a representation of the XPath expression in the form of data structures.  Then, the evaluation of the expression can begin as described in step E48 of FIG. 4, on the data of an XML stream either received by the network or originating from a document.  The evaluation of an XPath expression according to the invention is now described with reference to FIG.  The evaluation of an XPath expression is performed from the structure generated by the compiler, particularly as described with reference to FIG. 5.  Each expression type of the XPath syntax is associated with a representation structure with references to the sub-expression (s) that compose it.  In addition, each structure is associated with a list of instructions to be executed for its evaluation.  This list includes in particular a call for the execution of the sub expression (s) and instructions for handling the errors and / or the results.  For example, for an expression of type addition (AdditiveExpr according to the XPath syntax), the list of instructions would be: evaluate the operand on the left, evaluate the operand on the right and then apply the + operator on these 2 operands.  The evaluation algorithm of an XPath expression starts with step 20

  E600, consisting of executing the statement list associated with the higher level expression. According to the XPath syntax, the higher-level expression is identified by the Expr entity. This execution cascades the execution of the subexpressions that make up the XPath expression up to the level of the expression (s) relating to a location path.

The algorithm continues in step E601 by launching the execution of the expression relating to a location path. This step is followed by the step E602 during which the execution control unit 22 checks whether this expression represents the main expression or if this expression is issued for example from a predicate.

If so, then the algorithm proceeds to step E603 in which the execution control unit 22 uses its main browser XPath 23. If the latter has not been initialized, then an analyzer 3 of an XML data stream 4 is created and connected to the main XPath browser 23. The execution control unit 22 is then able to launch the evaluation of the steps of locating the expression relating to a location path according to the step E606 which is detailed hereinafter with reference to FIG. 7. Back to step E602, if the check is negative, then the execution control unit 22 initializes an XPath navigator 23. However, in the step E604 following the step E602, the values of the variables d state of the browser 10 in use, designated by reference browser, are stored. This step is followed by step E605 in which the browser initialized by the execution control unit 22 will be synchronized with the reference browser. This synchronization step is carried out in particular in 4 steps.

First of all, the synchronization starts at step E650 during which the new XPath browser 23 has its history reset. This history can contain information on one or more processed nodes, statistics on the node types already analyzed. Then the algorithm proceeds to step E651 of retrieving the XML parser 3 associated with the new XPath browser 23. If the latter was not previously created, then a new browser is created. Step E651 is followed by step E652 of copying the values of the state variables of the reference XML parser into the state variables of the XML parser of the new XPath browser 23. The next step (step E653) is to assign the data of the reference XML parser to the buffer of the XML parser associated with the new XPath browser. This memory stores the data from the XML stream 4.

The algorithm continues in step E606. Indeed, after selecting the XPath browser 23 to use, the execution control unit 22 performs the evaluation of the location steps of the expression relating to a current location path. This step is described hereinafter with reference to FIG. 7. Step E607 follows step E606 in which execution control unit 22 restores the state of the XPath navigator 23 stored in memory. step E604 when the evaluation of the localization steps leads to the sending of a result or ends without result. The expression relating to a location path restored in step E607 uses the eventual result determined in step E606 and the processor continues its evaluation. To do this, it tests in step E608 if the expression relating to a location path has been fully evaluated or not. In the negative case, the step E608 is followed by the previously described step E606 in which the next location step is evaluated.

If the expression relating to a location path has been fully evaluated, then the evaluation algorithm is terminated. The evaluation of the locating steps is now described with reference to Figure 7. The evaluation of the locating steps composing a locator path expression consists in consecutively processing each locating step that composes it. The algorithm starts at step E710 of selecting the first location step. Then, in step E711, it is determined whether the current location step requires a thorough test. If so, then the algorithm proceeds to step E712 of enabling the XPath browser history backup 23 for this and subsequent locating step. The deactivation of the backup (performed in step E713) will occur when the execution control unit 2230 is again positioned on the parent location step of the one that triggered the activation of the backup.

Steps E712 and E713 are followed by step E714 of searching for a candidate node from the XML data. An algorithm according to the invention detailing this step is illustrated in FIG. 8 and is described below.

If the test of step E714 is negative, i.e. if no candidate node has been found, then the algorithm proceeds to step E720. Step E720 determines whether there is a previous location step at the current location step. If this is the case, then the preceding location step becomes the current location step and the algorithm proceeds to the previously described step E711. In the opposite case, the expression relating to a location path has been fully evaluated and the algorithm is terminated. When a candidate node has been found in step E714, the algorithm proceeds to step E715 in which the candidate node is tested by applying the eligibility test to determine if it is a candidate. potential solution of the current location step. If not, step E715 is followed by step E714 previously described in which: a new candidate is sought, the current candidate not being eligible for resolution of the current location step. In the positive case, the algorithm continues in step E716 consisting in checking any predicates associated with the current location step.

Predicates are represented by expressions, including XPath expressions composed of subexpressions. The evaluation of the predicates is done according to the evaluation of an expression as illustrated in Figure 6 except that the result nodes of an expression representing a predicate are not transmitted to the application but translated into a result 30 Boolean according to the test to be performed in the predicate. It can be a test of value, position, name or mere existence.

If the test is negative, step E716 is followed by step E714 previously described. If, on the other hand, the test is positive, the algorithm continues in step E717 of determining whether the processed localization step is the last step of the expression relating to a location path. If not, step E717 is followed by step E719 of determining the next location step. This step is then followed by step E711 previously described. If the locating step is the last of the location path expression then the algorithm proceeds to step E718. During this step, the result of evaluating the expression relating to a location path is issued. The general principle of this algorithm is to consider the following location step (step E719) when a result for an intermediate localization step has been found (positive test in step E716 followed by a negative test when step E717). It is now described the search for a candidate node corresponding to step E714 of Figure 7. An algorithm according to the invention is illustrated in Figure 8.

The execution control unit 22 obtains the value of the entity expressing a filiation relationship from the current location step in step E800. This step is followed by step E801 in which it is checked whether the parent relationship contains the relation self, ie whether this value is a context node (self according to the XPath specification) or a descendant or context node (descendant-or -self according to the XPath specification). If the value contains a node-context relationship then the algorithm proceeds to step E802 in which the execution control unit requests the XPath browser 23 to provide it with the current node. The result of the preceding location step is therefore the context node of the current location step.

Step E803 follows step E802 during which this current node is transmitted as a candidate node. If in step E801, the values are different, then the algorithm proceeds to step E804 in which the execution control unit 22 compares the value of the entity with the attribute value ( attribute according to XPath syntax). If the value is attribute then the algorithm proceeds to step E805 in which the execution control unit 22 requests the XPath browser 23 to provide it with the current attribute type node.

This step is followed by the step E806 during which it is determined whether this node has been searched by the XML parser 3. If this is the case, this node is stored in the browser memory. XPath 23. The next step (step E803) is to transmit this node as a candidate node. The storage of the nodes and their transmission to the application are described below with reference to FIGS. 12 and 13. If, during step E805, no attribute is found, the backup performed in step E806 does not occur. is not realized. In addition, in step E803, the transmitted event is the end event. Returning to step E804, if the value of the entity is different from the attribute value, then the algorithm proceeds to step E807 in which the execution control unit 22 compares the value of the entity to the child value (child according to the XPath syntax). If the value is child then the algorithm proceeds to step E808 in which the execution control unit 22 indicates to the XPath browser 23 the depth at which the XPath navigator must look for a candidate node. The calculation of the depth is the depth value of the incremented context node of the value 1 if the location step has not been identified as having to undergo a deep mode. In the opposite case, the target depth 30 takes the infinite value.

Step E808 is followed by step E810 during which the XPath browser 23 searches for the candidate by using the XML parser 3. To do this, the XML parser 3 traverses the part of the XML stream 4 5 corresponding to the subtree under the context node until a child node of the text, comment or element context node is found. It thus appears that, unlike the solutions mentioned in the state of the art, the XPath browser 23 only provides the execution controller 22 with the relevant nodes.

This node is then saved in memory of the XPath browser 23 in the next step (step E811). Then, step E811 is followed by step E803 during which the node is sent as candidate node. However, if no node has been found between the beginning of the context node and its end, identified by a closing XML tag then, in the step E803, the end event is issued. Returning to step E807, if the value of the entity is different from the child value, then the algorithm proceeds to step E812 in which the execution control unit 22 checks whether the entity contains a descending-type (descending or descending-or-self) relationship according to the XPath syntax. If the value is descending or descending or context node then the algorithm proceeds to step E813 in which the execution control unit 22 indicates to the XPath browser 23 that the search for a son or descendant is to achieve without depth limit from the current depth. Step E813 is followed by step E810 previously described. If, in step E812, the value of the entity does not contain a descending type value then the algorithm proceeds to step E814 during which information is emitted indicating that no candidate Was found. In the particular case in which the value of the entity is the descending value or context node (descendant-or-self according to the syntax 2908539 27 XPath), the execution control unit 22 performs a search according to the value context node as described in step E801 if the latter has not already been made for the current location step. However, if no candidate has been found then the search is performed according to the descending value as described from step E812. The test of the candidate mentioned in step E715 of FIG. 7 is now described. If step E714 did not emit an end or error event, then the test step E715 is activated. If the current location step has been identified during the compilation (described in step E506 of FIG. 5) as requiring an in-depth test, step E715 of FIG. 7 is performed as described below in FIG. 10. If the current location step has been identified as a virtual location step (virtual step according to the XPath syntax) (described in step E502 of FIG. 5) then the test of the step E715 returns the true value. If the current location step has been identified as requiring a normal test mode, then step E715 is performed as described below with reference to FIG. 9. This normal mode test algorithm is now described in FIG. FIG. 9. The algorithm starts at step E901 in which the execution control unit 22 obtains the value of the eligibility test (XPath syntax-based Node Test) associated with the representation of the current location step. This entity can take the test value of the name (NameTest 25 according to the XPath syntax), or test of the type (NodeType according to the XPath syntax) that can be: node () () according to the XPath syntax), text (textO according to the XPath syntax), comment (comment ())) according to the XPath syntax) or processing-instruction ())) according to the XPath syntax according to the XPath specification. The name test may relate to both the value of the node's namespace (represented by a prefix) and its local, unique name within that namespace.

Step E901 is followed by step E902 in which the value of the eligibility test of the obtained node is compared with the test value of the name. If the test of eligibility has the test value of the name then the The algorithm proceeds to step E903 in which the execution control unit 22 resolves the prefix, ie the value of the namespace, associated with the candidate node. This information is stored in the memory of the XPath navigator 23. The step E903 is followed by the step E904 of comparing the value of the prefix thus obtained with the value of the namespace corresponding to the prefix contained in the test. name. If these values are equivalent then the algorithm proceeds to step E905 in which the execution control unit 22 obtains the local name of the candidate node, i.e., for example, the unique name of the candidate node. inside the namespace. Step E905 is followed by step E906 in which the local name of the candidate node is compared to the local name port specified in the name test. If the names are equivalent then the candidate node satisfies the test associated with the current location step and can be considered as a potential solution of the location step. Then the predicate checks will be carried out, in particular during step E716 of FIG. 7. In the opposite case, the candidate node does not satisfy the test associated with the current location step and it is considered as not being a solution of the locating step. Returning to step E902 in the case where the eligibility test does not have the test value of the name then the algorithm continues in step E907 of comparing the value of the eligibility test with the standard value of the node. If the eligibility test does not have the node's type value then the algorithm is terminated by returning an error message. Otherwise, if the eligibility test has the node's standard value then the algorithm proceeds to step E908 in which the execution control unit 22 obtains the type of the candidate node. This information is stored in the memory of the XPath navigator 23. The algorithm continues in step E909 in which the type of the candidate is compared with the value of the type contained in the standard value of the node. If the values are similar then the candidate node is a potential solution of the location step. Otherwise, the candidate node is not a solution. It is now described, with reference to FIG. 10, an algorithm 10 carrying out the in-depth test according to the invention. The decision to implement the further test at a later stage is taken when compiling a location step conditionally on the value of the entity expressing a parentage relationship as described in Figure 5. This test mode can be activated. , especially during the test of a candidate as described with reference to step E715 of FIG. 7. As previously described with reference to FIG. 7, if the current location step requires a thorough test (step E711 ), the execution control unit 22 obtains the profile of the expected node determined during the analysis of the location step in order to compare it with the candidate node determined during the step E714. The algorithm of the in-depth test starts at step E1000 by obtaining the candidate node. This step is followed by the step E1001 of obtaining the expected node. The latter is available in the representation structure of the current location step. The next step (step E1002) is for the execution control unit 22, to compare the type of the candidate node with the type of the expected node. If the types of the nodes are comparable, then the algorithm proceeds to step E1003 in which the execution control unit applies the test of the name of the current location step.

If the eligibility test of the locate step has the node type value and not the test value of the name, this step is not executed by the execution control unit. Otherwise, this test consists of the sequence of steps E903 to E906 with reference to FIG. 9.

If the test performed in step E1003 is true, the algorithm continues at step E1003a during which the execution control unit obtains the depth. Then step E1003a is followed by step E1004 during which the depth obtained and the depth expected for the results of the current location step are compared.

If the depth obtained is different from the expected depth then the algorithm is terminated and the eligibility test returns the false value. The expected depth is the depth between the context node and a node that would be the solution of the current step of the path. This increment is calculated during step E504 or step E509 of FIG. 5.

If, on the contrary, the depth obtained is similar to the expected depth then step E1004 is followed by step E1005 of obtaining the expected depth increment between the result node and its context node. The next step (step E1006) is to obtain the context node of the candidate node that has been stored in the history of the XPath browser 23.

If the context node does not exist, then there is no constraint to check on its history and the candidate node is declared potential solution thus ending the algorithm. In the opposite case, that is, if a parent node exists in the history, then the algorithm proceeds to step E1007 in which its depth is used to calculate the depth increment between the parent node and the candidate node. The next step (step E1008) is to compare this increment to the expected increment. If the increment is different from the expected increment, then the algorithm is terminated by returning the false value. If, on the other hand, the increment is similar to the expected increment, then the context node becomes the node to test thoroughly.

To do this, the algorithm continues in step E1009 during which the execution control unit 22 obtains the expected node profile for the location step preceding the current location step of treatment. If there is no longer an expected node, then the deep test algorithm is terminated by declaring the candidate node as a potential solution. In the opposite case, that is to say if a reference node exists, then the algorithm continues in the previously described step E1002. The steps E1002 to E1008 are repeated until reaching the end of the history (negative test performed in step E1006), or the initialization of the deep test 10 of the locating step (step E1009). It is now presented an example of evaluation illustrated in Figure 11 according to the in-depth test mode. Two XPath expressions relating to an equivalent location path (1111), but written differently, include four location steps: S0, S1 and S2, and a virtual location step SV1 (1113). For each expression to be thoroughly tested (SI and S2), the expected node profiles (1112), in terms of type, prefix, name, and depth increment, are illustrated by way of example. In Fig. 11, there is also illustrated a document containing XML data (1114) on which XPath expressions are evaluated. It is illustrated the different contexts nodes (1115) that are encountered during the evaluation of expressions. These context nodes correspond to the solutions of the virtual location step SV1. According to the solution described in the preceding paragraphs, when a solution is found for the virtual location step SV1, the evaluation proceeds with the evaluation of the location step S1, in particular by the execution of the steps E714. at E716 of Figure 7, then by evaluating the locating step S2 when an element b with a depth increment equal to 1 relative to the context node is found.

The solutions of the expression (1116) will then be the elements, having any name, located at a depth level +1 with respect to the solutions of the locating step S1.

An embodiment variant of the implementation of multiple browsers with the purpose of limiting the number of accesses to the XML stream, based on synchronization of XPath browsers, is now described. The XPath browsers 23 of the XPath processor 2 may have a reference to a memory area of the XPath processor. In this memory zone, the current XPath browser 23 writes the XML data extracted by the XML parser 3 and read from the stream 4 as a series of events. This memory can be implemented in the form of an ordered list managed such that the first stored event is the first consumed event. Only the main XPath browser 23 is entitled to remove the items from this list and process them. This implementation requires, however, an initialization step 15 in which, during the backup of the state of the variables of the reference browser (carried out in step E604 of FIG. 6), the browser keeps a reference on the last item in the list. This reference is the starting point for navigations that are created following the E607 restore step in Figure 6.

When the main browser is restored in step E607, it resumes navigation from the various elements of the event list. When the last event of the list is reached, the browser resumes navigation using its XML parser 3. Thus, according to this implementation, a single XML parser 3 is used.

In addition, this particular embodiment has the advantage of reducing the bandwidth consumption in cases where the XML stream 4 comes from a network connection. According to the invention, the decomposition of the evaluation of an XPath expression into several tasks is facilitated. Indeed, in the implementation mode based on a plurality of XPath browsers (i.e., in multi-tasking mode), the main XPath navigator 23 performs the evaluations according to the location steps of the expression. relative to a main location path, while in parallel, the other XPath browsers 23 perform the evaluations of the subexpressions corresponding for example to predicates or localization expressions found in function calls.

In the particular implementation embodiment of the multiple browsers, the main XPath navigator 23 fills the memory of the XPath processor 2 via its associated XML parser 3. The synchronization of a new browser occurs when the main browser detects a node as a potential solution (test 10 performed in step E715 of Figure 7). A new task and the new XPath Browser 23 are created. In this task, the new browser obtains the XML events from the XPath processor memory 2 and evaluates the current subexpression while in the main task, the XPath browser 23 continues the flow of the XML stream 4 via its XML parser 3 to looking for potential solutions. Subexpression resolution tasks terminate when a solution has been found or when the sequence of events representing the subtree has been fully traversed.

According to another embodiment, this mechanism can be extended to a multi-task approach based on the location steps. In this embodiment, a main XPath browser attempts to resolve the first location step and as soon as a potential solution is found, one or two tasks can be created to respectively resolve a possible predicate on the step of Current location and support the resolution of the next location step. This implementation is particularly advantageous in the case of XML documents indexed by depth. Indeed, it allows, on the one hand, rapid access to the elements located at the same depth and, on the other hand, not to consider the subtrees corresponding to the location steps consecutive to a location step without solution. .

2908539 34 It is now described with reference to Figure 12, the emission of results. In order to fully evaluate the data on the fly, the results extracted from the XML stream 4 by the XPath processor 2 via its XPath navigator 23 are returned to the application 1 as they are detected. In order to do this, the XPath main navigator 23 of the XPath processor comprises two fields called transmission and storage respectively indicating the status in terms of sending events to the application, especially when a result has been found during the step E718 of Figure 7 and the status in terms of event storage representing a result included in the result being issued. Indeed, the main problem lies in the management of nested results. For example, if we consider the following XML stream: <a> <b> <b> <c /> </ b> </ b> </a>, on which we evaluate the expression // b we will obtain the following two results: <b> <b> <c /> </ b> </ b> and <b> <c /> </ b>. It can be seen in this example that the second element b and its contents are included in the first result and must therefore be emitted twice. The algorithm described below with reference to FIGS. 12 and 13 makes it possible to deal with this kind of situation without resorting to multiple storage of the nested results (<b> <c /> </ b> in our example). The table below summarizes the actions to be performed according to the type of event received or retrieved by the XPath navigator 23 during the course of the XML stream 4. This path is performed during the step E714 of search for candidate nodes. . The result start event is issued by the execution controller 22 in step E718. The processing of this event is described with reference to FIG.

2908539 Event: Start of Event XML end of result result Statuses Non-issue Activate Can not issue, consider issue the current node Emission, non-Enable Transmit Emit, unstack storage storage, event queues store and de events then emit the node disable the current broadcast Emission, Activate a Store Store the event storage new the event then disable the storage, last store store and emit the current node As shown in the table above, the events can be of three kinds. 1. First of all, the result start event is an event emitted by the execution control unit 22 during the step E718 of Figure 7 in order to signal to the browser that the current node corresponds to the start of a new result. 2. Then, the event event XML describes all the XML events extracted by the parser 3 during the flow of the XML stream 4. 10 3. Finally, the event end result is an event generated during the search for candidate nodes of step E810 of Figure 8. This event is generated when the XPath browser 23 retrieves from the XML stream 4 the closing tag that corresponds to the end of the result element. In the example described above, end events are detected for <lb> elements. FIG. 12 illustrates the processing of the start-of-result signal by the XPath navigator 23. The processing of the start-of-result signal starts at the step E1200 by the reception of this signal by the XPath navigator 23. This signal comes from the unit of FIG. execution control 22.

This step is followed by a test step (step E1201) to determine if the browser is already in transmission mode, in particular, if the newly detected result is within the previous result. In the negative case, the algorithm continues in step E1202 during which the transmission mode is activated. To do this, the value of the sending field of the browser is set to true. Then, in the next step (step E1203), the start of result signal is sent to the application. This signal is supported by one of the event handlers of the application.

Indeed, the application can implement event handlers, for example similar to those of XML parsers, having a SAX type interface (as described in particular at the following address: sax.sourceforge.net/) and specific managers to use the XPath processor as a start and end result handler.

If the test of step E1201 proves to be positive, the storage mode of the XPath navigator 23 is then activated in step E1204. Then, step E1205 allows the XPath browser to index this node corresponding to a result start nested in a start list of results. This list will be used to detect the end of a nested result and to issue the corresponding nodes at the appropriate time. FIG. 13 describes the processing of any XML event extracted by the XPath navigator 23. This processing starts (step E1300) with the reading of a new event in the XML stream 4 by means of an XML parser 3.

Step E1300 is followed by step E1301 during which this event is translated into an XPath node and stored in memory of the XPath browser 23 for evaluation (step E715) by the execution control unit 22. The next step E1302 is to check whether the transmission mode of the XPath navigator 23 is active or not.

If this is not the case, the node is cleared from the memory of the XPath browser 23 and the browser waits for the execution control unit 22 to request a search for a new candidate (step 22). E714). If the test of step E1302 is positive, the XPath browser must emit the current node. Prior to this transmission, during step E1304, it is checked whether the storage mode is active. If this is the case, step E1304 is followed by step E1305 in which the current node is marked as to be retained after it is transmitted. This marking also associates if necessary the information beginning or end of result on the nodes respectively corresponding to beginnings and ends of elements. The next step E1306 is to check if the current node represents the end of the last detected result. According to one embodiment, this test verifies that the current node is a closing tag of the same depth as the opening tag that gave rise to this result detection. If this is the case, the algorithm continues in step E1307 of deactivating the storage mode. Then the node is emitted in step E1308. If the test of step E1306 is negative, the node is emitted in step E1308. This step E1308 transmits the node to the application without, however, deleting it from the memory of the XPath navigator 23. In the case of a test of the negative step E1304, the next step 25 (step E1309) consists in checking whether the current node corresponds to the end of the current result. In other words, it consists of ensuring, if the current result corresponds to an element, that the current node corresponds to a closing tag of this result element node.

For any other type of node, the node itself is both the beginning and the end of the result.

If the test of step E1309 is positive, the end of the current result is reached and the transmission mode is thus deactivated in step E1310. Then in step E1311, the node is sent and cleared from the memory of the XPath browser.

Step E1311 is followed by step E1312 in which the end of result signal is issued. The next step (step E1313) consists of issuing any nested results. This step is detailed below with reference to Figure 14.

If the test of step E1309 is negative then the algorithm ends in step E1314 during which the current node is transmitted. Referring to Fig. 14, the algorithm starts at step E1400 in which the XPath browser checks whether the nested result debug list is empty.

If the list is not empty, it retrieves the first result beginning in step E1401. This step is then followed by sending a start-of-result signal to step E1402. The current node is then transmitted and removed from the XPath browser memory in step E1403.

This step is followed by step E1404 of recovering the next node. Step E1404 is followed by step E1405 in which it tests whether this node is marked as belonging to another nested result. If this is the case, then the algorithm proceeds to step E1406 during which it is checked whether it is the end of the current result. In the positive case, the step E1406 is followed by the step E1407 during which the corresponding node is emitted. The node is also cleared from the XPath browser memory. Then the end of result signal is issued in the next step E1408, and then iterates on the result start index list (step E1400), until that list is empty.

Back to the test during step E1406, if the current node does not correspond to the end of the current result, it is then a node belonging to the result and it is emitted during the step following (step E1410). This step is followed by step E1404 in which the course of the list of 5 nodes is continued. Returning to the test of step E1405, if the node is not marked then it is issued and removed from the list of nodes of the browser XPath 23 in step E1409. Next, this step is followed by step E1404 previously described in order to traverse the next nodes. Thus, the invention provides a means of evaluating XPath expressions on the fly. For this, the XPath processor uses at least one XPath browser, a main browser remaining positioned on a potentially resultant node, and possibly one or more other browsers locally exploring the XML data. In addition, in order to detect possible nested solutions, the processor analyzes the location steps of the expressions relating to a location path to assign them a specific test mode if necessary and store the history of the nodes only when necessary.

Claims (25)

  A method of evaluating an expression for accessing at least a portion of a structured document by means of at least one browser capable of extracting the structured data from the document, the expression being composed of at least two expressions each relating to a location path, characterized in that it comprises a step of evaluating each of the subexpressions on the basis of the data of the document by means of at least one separate browser for each subexpression.   2. Evaluation method according to claim 1, characterized in that it comprises a preliminary step of determining the number of browsers.   3. Evaluation method according to claim 1 or claim 2, characterized in that each subexpression relating to a path comprises a set of location steps.   4. Evaluation method according to claim 3, characterized in that each location step comprises at least one entity expressing a filiation between the structured data.   5. Evaluation method according to claim 4, characterized in that the filiation is indirect filiation.   6. Evaluation method according to claim 5, characterized in that the method comprises a step of determining sub-expressions having at least one entity expressing indirect filiation. 30   7. Evaluation method according to claim 6, characterized in that it comprises a step of extensive testing on said at least one entity expressing indirect filiation, the in-depth test being a function of conditions on the data and on the data. previous evaluations of said data.   8. Evaluation method according to claim 7, characterized in that the method comprises: a step of extracting the data on the basis of which the subexpressions are evaluated; and a step of storing the extracted data. 10   9. Evaluation method according to any one of the preceding claims, characterized in that during the evaluation of a second subexpression following a first subexpression, said at least one browser of the second subset. expression is initialized with the browser context of the first subexpression. 15   10. Evaluation method according to any one of the preceding claims, characterized in that each of said browsers controls at least one analyzer of the structured document.   11. Evaluation method according to claim 10, characterized in that if browsers use the same analyzer (3), the data extracted by a browser are reused by another browser using the same analyzer.   12. Evaluation method according to any one of the preceding claims, characterized in that the method comprises a step of determining the data extracted from the document verifying all the subexpressions.   13. Evaluation method according to claim 12, characterized in that as soon as data are determined, said data are provided to an application capable of processing these data. 2908539 42   14. Evaluation method according to claim 12, characterized in that the determined data are stored. 5   15. Evaluation method according to claim 12, characterized in that if determined data have a direct or indirect relationship of filiation with previously determined data, then these data are issued after the previously determined data. 10   16. Evaluation method according to claim 15, characterized in that the transmission of the determined data is preceded by a start signal and is followed by an end signal.   17. Evaluation method according to any one of the preceding claims, characterized in that the expression is an expression of XPath type.   18. An expression evaluation device for accessing at least a portion of a structured document by means of at least one browser able to extract the structured data from the document, the expression being composed of at least two under expressions each relating to a location path, characterized in that it comprises means for evaluating each of the subexpressions on the basis of the data of the document by means of at least one separate browser for each subexpression. 25   19. Evaluation device according to claim 18, characterized in that it comprises means for determining the number of browsers.   20. An evaluation apparatus according to claim 18 or claim 19, characterized in that each path-related subexpression comprises a set of locating steps. 2908539 43   21. Evaluation device according to claim 20, characterized in that each location step comprises at least one entity expressing a filiation between the structured data. 5   22. Evaluation device according to claim 21, characterized in that the filiation is indirect filiation.   23. Evaluation device according to claim 22, characterized in that the device comprises means for determining sub-expressions having at least one entity expressing indirect filiation.   24. Evaluation device according to claim 23, characterized in that it comprises means for in-depth testing on said at least one entity expressing indirect filiation, the in-depth test being a function of conditions on the data and on the previous evaluations. said data.   25. Evaluation device according to claim 24, characterized in that the device comprises: data extraction means on the basis of which the subexpressions are evaluated; and - storage means of the extracted data. 28. Evaluation device according to any one of claims 18 to 25, characterized in that it comprises initialization means capable of initializing said at least one browser of the second sub-expression with the context of the browser of the first subexpression when evaluating a second subexpression following a first subexpression. 29. An evaluation device according to any one of claims 18 to 26, characterized in that each of said browsers controls at least one analyzer of the structured document. 28. A computer program loadable into a computer system, said program containing instructions for implementing the method of evaluating an expression according to any one of claims 1 to 17, when the program is loaded and executed by a computer system. 29. Information storage medium, removable or not, partially or completely readable by a computer or a microprocessor comprising code instructions of a computer program for the execution of the steps of the evaluation method of a computer. expression according to any one of claims 1 to 17.