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

From: "Ray Whitmer" <rayw@netscape.com>
Sent: Sunday, July 01, 2001 8:57 AM
> This is a significant point to clarify.  As described, it would match
> the first node in the orderless set, I believe.  This method currently
> satisfies the situation where the application wants one node that
> matches the expression, but does not care which one if there are
> multiples.  There is a bit of confusion between XPath's node set which
> has no order and ActiveNodeSet, which has an implementation-defined
> order.  It might be less confusing to just say that it returns one node
> of the resulting set instead of saying it returns the first.

Yes, and it maximizes potential performance. So does giving no indication
how many more nodes there might be in the set; in other words, no exception.
This doesn't constrain the implementation in any way and meets the needs of
the most common use case we see, callers who know a priori there will be
only one node or no nodes in the set.

> It has already been suggested by others that some applications would
> like an exception if there is more than one match.  Or, as you point
> out, the application might want to guarantee which item is returned in
> the case of multiples.  Either of these constraints seem to impact
> performance because they require a more-complete evaluation of the
> expression, either to know that the node is the only match or to know
> that it is the first among all sorted results.

I don't know that order and exception variants are needed. Often the
developer's schema knowledge and perhaps a judiciously placed predicate will
be enough to deal with order. Otherwise, evaluateAsNodeSet() is always
available. Exceptions should not be used as tests or to substitute for
validation. If one is in doubt and/or cares about the number of possible
results, evaluateAsNodeSet() will tell.

> Implementations might minimize this difference by
> guaranteeing for certain expressions that results will always be
> computed in document order, so perhaps we should not be looking so hard
> at the implementation right now, but I believe based upon my
> implementation experience that it might be quite difficult to deal with
> this efficiently.

Agreed. My only concern is that if a large number of users would look to
implementations for an order guarantee where the spec has none, that is not
a good thing for interoperability. Either the standard interface should have
a way to guarantee order or it should explicitly define order to be
undefined rather than implementation-defined.

Bob Foster
WebGain

Received on Monday, 2 July 2001 02:02:49 UTC