Re: We need an XPath API

[terje@in-progress.com (Terje Norderhaug)]

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
>> instance).

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[2]/text()[1]" 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 <terje@in-progress.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!