Re: DOM Level 3 XPath updates really confusing me

Christian Parpart wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all,
>
>I once implemented the DOM Level 3 XPath Module WD which contained 
>things like XPathSetSnapshot, XPathSetIterator, createExpression, 
>SINGLE_NODE_TYPE, NODE_SET_TYPE, etc etc... everything that does
> not exist anylonger. Why? Huh? What's the ChangeLog? Can't there just 
>be a changelog for enforce the developer to re-read the whole draft? This
> of course applies to all drafts out there.
>  
>
The document you implemented was quite a long while ago, which clearly 
stated that things were likely to change.  The model did change 
significantly in response to comments we received.  I think a re-read is 
required when the model changes so much.

>ChangeLogs would make life so much easier(!).
>  
>
That is not part of the process for the current documents as we publish 
them.  If you were regularly reading the specification, and the changes 
were fairly minor, I agree that in some cases a change log could be useful.

If you intend to follow the drafts so closely, change by change, I would 
suggest becoming a member of W3C and subscribing to the internal 
interest group lists where each technical decision is discussed.  The 
drafts which are publicly published typically are at longer intervals 
and, hence, are likely to contain a large number of fundamental changes.

>The types SINGLE_NODE_TYPE and NODE_SET_TYPE are gone 
>and the following has been added:
>	* UNORDERED_NODE_ITERATOR_TYPE,
>	* ORDERED_NODE_ITERATOR_TYPE,
>	* UNORDERED_NODE_SNAPSHOT_TYPE,
>	* ORDERED_NODE_SNAPSHOT_TYPE,
>	* ANY_UNORDERED_NODE_TYPE, and
>	* FIRST_ORDERED_NODE_TYPE.
>  
>
The last-call document which also contained these major changes went 
into review over 10 months ago.  Working drafts are a work in progress, 
and you cannot expect to come back months later and have the 
specification be similar, necessarily, until it becomes a candidate 
recommendation or recommendation.

>But when should a XPathResult be what of them?
>  
>
If you request the type, then the type you requested will be returned or 
an error will be raised if it is not possible.  If you request ANY type, 
then you get back either a primitive type, or 
UNORDERED_NODE_ITERATOR_TYPE.  To quote the specification, where it 
describes the "ANY" type, "any other representation of a node set must 
be explicitly requested.  What do you not find clear in the 
documentation of these types?

>What about comparisons between all these new node types?
>  
>
These are not node types.  These are result types.  They have never been 
node types.

What do you mean comparisons?  They are sets of nodes, not nodes.  We 
define no comparisons between node sets or result types.

Level 3 core defines comparisons between nodes.  It is not within the 
requirements of our module to compare the sets of nodes or any other result.

>What of the above node types is to be used for a single node result?
>  
>
Any of these you have mentioned may be used for a single node result, 
depending upon your needs.  If you were asking which are optimised to 
return a single node, it is the last two in your list.  If you look in 
the descriptions in the specification, these say "single node" within 
the first sentence of the description.

>What of the above node types is to be used for a simple node list? 
>e.g. for "/*", "//elem[@attr=$b]"? Both result a node set,but of what 
>result-type?
>  
>
Again, any of those you listed may be used for a simple node list, 
depending upon your requirements.  That is why you explicitly request 
the model you need, as the documentation states.

>Also, the evaluate function does not take any parameter for 
>function/variable-scope. Why? This would be a nice way to extend the 
>function's provided as well as allow you easily to manipulate the variables 
>needed by the xpath expression of interest.
>  
>
On the one hand, it is not difficult to extend XPathEvaluator to permit 
this sort of thing, which we expect derived standards to do if they need 
to.  On the other hand, there are lots of complexities involved in 
completely providing this facility, which is why it was made out of 
scope very early on in the standard.  We tried to hit some form of the 
80-20 rule.  There was no version of the specification ever published 
that provided this functionality.  That does not prevent custom 
functions and variables or even custom interfaces for adding functions 
and variables.

>Also, why does DOM Level 3 Modules rely on DOM Level 2 Core and not Level 3 
>Core? Core 2.0 is in recommendation state, yes, but I think that XPath 3.0 
>should rely on Core 3.0 or it should be said somewhere in the XPath 3.0 
>Module draft that this also applies to Core 3.0 (WD) shouldn't it?
>  
>
We made XPath rely on Core 2.0 so it was not necessary to implement Core 
3.0 to implement XPath.  Since Core 3.0 is dependent upon Core 2.0, any 
implementation of Core 3.0 satisfies the dependencies of Core 2.0, 
permitting XPath to be implemented.


I hope this is helpful.

Ray Whitmer
rayw@netscape.com

Received on Friday, 21 February 2003 09:41:38 UTC