[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an XPath API
- From: email@example.com (Terje Norderhaug)
- To: firstname.lastname@example.org
- Date: Mon, 05 Mar 2001 15:10:34 -0800
At 2:10 PM 3/5/01, Christian Nentwich wrote:
>>For instance, in DOM you can have consecutive text nodes. This usually
>>happens as a result of XML parsers returning text in several chunks. XPath
>>has no notion of that, if it selects the text() inside an element, I guess
>>that what is expected is that it returns a single text node.
>That's certainly not what I expect. In fact, I expect XPath to get me stuff
>from my DOM tree without modifying it. If text nodes are to be merged, the
>parser can be instructed to do that. Also, text() and node() would exhibit
>different behaviour.. you certainly don't want nodes to be merged ?
>In any case, a merge function would be nice.. merge(text()) and all your
>problems are dealt with :)
DOM already provides a Normalize method on Element that merges adjacent
Text nodes. The remaining problem is that DOM distinguishes between CDATA
and Text nodes, in contrast to XPath.
>> The other option is to return as many text nodes as there are in the DOM,
>> but that could break various expectations (stuff relying on position for
Exactly, which is why an XPath implemention on top of DOM has to consider a
CDATA and text node next to each other as one text object. If not, an XPath
expression like "paragraph/text()" may not give the expected result.
>In my experience, "stuff relying on positions" equates to a bad stylesheet /
>xpath expressions the same way that specifying a row would in SQL: it
>removes a level of independence - there is almost always a way around it.
There are many cases where positioning makes sense, included the above
"select the first text of the second paragraph".
-- Terje <email@example.com> | Media Design in*Progress
Software for Mac Web Professionals at <http://www.in-progress.com>
Take Advantage of Server Side XML and XSL with Interaction!