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

Thanks for your response. I understand your intentions better now. Some
follow-up comments below.

From: "Ray Whitmer" <rayw@netscape.com>
Sent: Wednesday, June 27, 2001 9:52 AM
> Bob Foster wrote:
>
> >Very nice to see this! As an implementor of a DOM-based XPath, it is
always
> >nice to think that someday I will be able to stop maintaining it. I tried
to
> >make my comments brief, but there are 10 of them.
> >
> >1) [1.2.1 Text Nodes] This is very imprecise. Does the section describe
the
> >behavior of the text() node test or are there other incompatibilities?
Each
> >incompatibility should be specifically identified.
> >
> I do not understand your confusion.  As I attempt to respond, I write
> exactly what is there, so I don't know how I can clarify (without
> further feedback).  We are talking about the actual DOM nodes returned
> from an xpath expression, and what to do when XPath says there should be
> a single node, having discarded information, but DOM has fragmented it
> across multiple nodes.  Answer: in case of fragmentation, return just
> the first node.

Well, you stumped me back. It took two days to decide that maybe you mean
that text processing within an XPath expression is compatible with XPath 1.0
and it is only Text subclass nodes returned by evaluateAsXXX() that get this
special treatment.

Is this what you mean?

> >3) If you are going to add a method to the DOM, it would be far better to
> >introduce a variant of normalize() that coalesces adjacent text (that is,
> >Text and CDATA) nodes exactly as described in the XPath specification.
> >
> While such a normalize function is a good idea, it is not sufficient in
> cases where stripping out all CDATASections and EntityReferences is not
> an option.  It is also questionable whether XPath inquiries should only
> function correctly on a completely normalized tree.

Agreed it's a good idea and not always an option. But sometimes it is an
option.

Function correctly is different than function compatibly. DOM XPath will not
function compatibly on an unnormalized tree. It would be nice to think it
would function compatibly on a "completely normalized" tree.

> A big part of the use of XPath in DOM is to find nodes in the document
> so that they can be manipulated and later written out...

Yes, that is primarily how we use it in our implementation, and we have the
same kind of shortcut.

There should still be an evaluateAsObject(), for reasons enumerated
previously in this list.

> The [evaluateAsNode()] call is not a "hint", but a
> very clear statement that one node is
> requested.  The implementation may or may not be "sly" about only
> computing the first node, just as it may be sly enough to evaluate
> ActiveNodeSets incrementally as the caller requests additional nodes, in
> which case this method wasn't needed to avoid computation.  There are
> quite a few gains, and some of the best ones have to do with not
> returning a NodeSet, and are just as true of evaluateAsString, for
> example.  It is not clear to me that we should spend a lot of time in
> the specification discussing these implementation optimizations which
> may or may not be available.  Implementations will choose how sly they
> should be.

Ok, you got me on sly.

Along the lines of very clear statements, the document says evaluateAsNode()
returns the "first node of the resulting set". What set? Node-sets are
unordered. The first node in document order? The first node in position
order? Undefined? Implementation-defined?

Bob

Received on Saturday, 30 June 2001 03:16:11 UTC