Re: XPath Evaluation Types Are Not Easily Available Prior To Evaluation

Dominic Chambers wrote:

>
>
>The XPathResult interface defines the following constants:
>
>  const unsigned short      ANY_TYPE                       = 0;
>  const unsigned short      NUMBER_TYPE                    = 1;
>  const unsigned short      STRING_TYPE                    = 2;
>  const unsigned short      BOOLEAN_TYPE                   = 3;
>  const unsigned short      NODE_SET_TYPE                  = 4;
>  const unsigned short      SINGLE_NODE_TYPE               = 5;
>
>These are not available through the XPathEvaluator interface, and therefore
>can not be used prior to evaluation, unless using a two stepp process via
>the createResult method. The constants are used in the fourth parameter of
>the evaluate method:
>
>    XPathResult        evaluate(in DOMString expression,
>                              in Node contextNode,
>                              in XPathNSResolver resolver,
>                              in unsigned short type,
>                              in XPathResult result)
>
>I am aware that there is a desire to minimize the number of fields grafted
>to the Document interface, but a simple evaluationTypes attribute that
>contained these constants would be very useful. For example:
>
>    var barStr = document.evaluate("foo/@bar", document, null,
>document.evaluationTypes.STRING_TYPE, null).stringValue;
>  
>
The createResult method is not needed to access these constants. 
 Bindings make these available statically.

If you look, for example, at the Java binding of this API, they are 
declared statically.  This means you access XPathResult.ANY_TYPE without 
constructing an instance of XPathResult.

There is no advantage I can see to adding these to the Document interface.

With the resolution of the last-call issues, the possibility was raised 
that since there are differences in the XPath 2.0 data model, results 
from an XPath 2.0 evaluation may need a different result object -- the 
type system is quite different for starters.  In this case, different 
type codes would belong to that alternative result object.

These constants seem to make most sense in exactly the place where they 
are defined so that should alternative result types be introduced for 
XPath 2.0 or other eventualities we cannot see right now, these type 
codes do not clutter up the space of 2.0 users, for example, and vice 
versa, let alone of those that are not using XPath at all.

Ray Whitmer
rayw@netscape.com

Received on Friday, 1 November 2002 08:08:14 UTC