Re: XPath DOM and XPath 2.0 (Was Re: Comments on DOM XPath Interface)

Y'know, I'm currently looking at the XPath2 data model -- which, by the
way, is also the basis for XQuery and XSLT2 -- and I don't see major
conflicts with the DOM.

Yes, there are some things which are a nuisance, such as the concept of
"namespace nodes" -- but the current draft says namespace nodes have no
parent, which fixes a major problem we had in supporting XPath 1.0.

Yes, attributes have a parent. But I don't think anyone considers the DOM's
ownerElement an inadequate implementation of that.  (There was a proposal
that ownerElement be generalized to work on all nodes to be more directly
equivalent to XPath's concept of parentage; I don't know offhand whether we
voted that up, down, or just never decided.)

Yes, they discard entity boundaries. The DOM can be used that way

They add some post-schema-validation information. Not a lot of it,
actually. Validity state, declared type this was validated against,
instance type actually found. I'm not sure the DOM is currently addressing
any of this, but I don't see it as being in conflict with anything we've
done.

And they add the ability to retrieve typed values for built-in types and
lists thereof. Note that they don't require _storing_ the data as typed
values. If you want to store strings and generate vectors of primitives on
demand, OR vice versa, OR store both and have a caching scheme that updates
one from the other when necessary, any of those choices are fine. That
doesn't requre changing a DOM implementation, and as far as I can tell
doesn't require changing the DOM APIs or behaviors -- it's really not much
more than a convenience layer.


Admittedly, the XPath2 Data Model is still a moving target, and if we don't
want to wait for them there is a risk that we may not match what they do.
So if we really want to go into Last Call _now_, we don't have much choice.

Of course the users' response to the DOM Xpath LC may be "Wait for XPath2".
If that's really their preference...


______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 29 March 2002 15:48:01 UTC