[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: We need an XPath API

  • From: Robin Berjon <robin@k...>
  • To: Mike.Champion@S...
  • Date: Sun, 04 Mar 2001 00:29:31 +0100

need of xpath
At 17:58 03/03/2001, Mike.Champion@S... 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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.