OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: We need an XPath API

At 17:58 03/03/2001, Mike.Champion@SoftwareAG-USA.com wrote: 
>The basic problems have been: 
>- The wretched inconsistency between the DOM data model 
>and the XPath data model.  DOM "trees" can have CDATA nodes,
>adjacent Text nodes, entity reference nodes (and maybe some 
>other rot) that is transparent to XPath.  So, an XPath expression 
>can point at something that is not neatly aligned on DOM Node 
>boundaries ... so what should a NodeList or NodeIterator returned
>by an XPath expression do?

I liked the TextContent idea in the DOM3-Core draft. That would most likely
solve most (if not all) the problems relating to node boundaries. XPath
could use that and decide to return Text nodes that may not exist as such
on the DOM tree. Or it could return all matching Text and CDATA nodes. One
could give an option to the user.

>- The equally wretched matter (I'm sure I will suffer painfully in the 
>Hereafter for ever agreeing with this) of live NodeLists.  The obvious
>thing for something like selectNodes to return would be a NodeList, 
>but keeping this in synch with the XPath expression as the underlying
>DOM tree is edited is non-trivial.  NodeIterators are probably a better 
>idea, but they are less familiar and less widely supported, and still have
>some "liveness" semantics that might be problematic here ... not sure. 

We would definitely have to make live NodeLists optional. People wanting to
get a simple list of nodes back shouldn't suffer the overhead (and
implementors shouldn't feel like hanging themselves trying to get live
nodelists to work). Also, XPath normally returns NodeSets and I don't
remember reading that those ought to be live (but then, maybe my brain
filtered it out).

We could tell people that a query is a snapshot of the tree at the moment
at which it is taken. Sounds simple but the problem is in that case in
order to be consistent the Nodes should be clones of the ones in the tree
lest they be live even if the list isn't. And if clones, then in order to
be useful they ought to be deep clones. I can hear those boxes swapping
from here.

That's a rub... how do XPath implementors deal with this presently ?

-- robin b.
We've been following your progress with considerable interest, not to say
contempt. -- Zaphod Beeblebrox