Re: Document Object Model (DOM) Level 3 XPath Specification

Philippe Le Hegaret wrote:

>Christian Nentwich wrote:
>
>>My requirements are such that I don't know the return type of evaluating an
>>XPath expression in advance. I can't choose between evaluateAs* beforehand.
>>
>
>>I would find it much preferable to get a result object. Such a result object
>>could indicate its type and be able to return its value as a string, nodeset,
>>etc. I would also stress (even though there is some reference to this in the
>>document), that it would be vital to be able to pass an evaluation context to
>>the functions (i.e. containing variables and so on).
>>
>
>We thought about a result object but it creates an indirection since you need
>to get the result object and then the result value. Based on the assumption
>that most of the apllications will know the result type before invoking the
>methods, we didn't change the current proposal. But, in order to address your
>use case, the current approach is to add a new method that returned the type of
>the XPath expression.
> 
>
>>I have further requirements that require the repeated evaluation of XPaths
>>(>= 100000 times). I find the Xalan approach quite useful here, which parses
>>the path once to be evaluated multiple times. I see quite a bad performance
>>hit coming along if I use the interfaces from the draft (which take a string
>>rather than a parsed path object.
>>
>
>Unfortunately, we didn't find enough interest across the current DOM
>implementations to add this functionality in the API. The current approach is
>not meant to cover all the use cases but to provide a simple approach [1].
>IMHO, a complete version of a Query API could be addressed in the future based
>on the work of the XML Query WG.
>
Either of these cases can be improved in the implementation by very 
simple caching schemes:

With respect to separating out the method for getting the type as 
opposed to returning a result object, if a certain implementation has 
use cases that demonstrate that getting the type is common and if 
getting the type does most of the same processing as evaluating, the 
getType call can cache anything valuable until the next call is made on 
the evaluator or until the results become invalidated, whichever comes 
first.  If the next call is not for the actual results of the same 
expression, the results are discarded.

With respect to executing expressions multiple times, the implementation 
can use a look-aside cache for compiled expressions, which also can be 
trimmed on a least recently used basis.  Other types of caching such as 
result caching based upon compiled fragments as applied to trees would 
be possible as well depending upon the expected use cases for the 
implementation.  These things will be a quality of implementation issue, 
not exposed in the interface.

Ray Whitmer
rayw@netscape.com

Received on Thursday, 21 June 2001 18:27:16 UTC