Re: Question for implementors: XPath model and CDATA sections

On Tue, 2002-02-12 at 16:10, Joseph Reagle wrote:
> Ok, to review the example that we put on the whiteboard in my office. Given 
> the instance:
> 
> <foo>
>   <a>it <![CDATA[is]]> sunny</a>
>   <a>clouds</a>
> </foo>
> 
> For the first element a:
>   o In XPath there is one text node of "it is sunny"
>   o In Infoset there are 11 character information items.
>   o In DOM there is 1 text node of "it", 1 CDATA of "is", and 
>     1 text node of "sunny"
> 
> Now the level-3 XPath text states, "Instead of returning multiple nodes 
> where XPath sees a single logical text node, only the first non-empty DOM 
> Text or CDATASection node of any logical XPath text will be returned in the 
> node set." And to me, this doesn't seem very XPath'ish at all.

I agree that it is not XPath'ish but keep in mind that the DOM Level 3
XPath suggests a mapping between the XPath Data Model and the DOM Data
Model. As of today, we don't know how to expose only one text node on
this case unless you change the DOM tree itself (i.e. you get rid of the
cdata section and you normalize the text nodes).

> However, you 
> explained that this is done *to be* compatible with XPath with respect to 
> ordering.

yes, it preserves the number of nodes from the XPath node sets. on
"a/text()", the second node in the node set will be the one representing
"clouds", and not the cdata section.

> For example 
>   1 = a.getFirstChild()
>   1.text() -> "it"
>   1 = a.getNextSibling()
>   1.text() -> "cloudy"  # We don't want to get "sunny here".
> 
> Ok, so I understand that now, and that after the first assignment to "1":
>   1.wholetext() ->"it is sunny"
> And lacking this, folks will have to manually suck up text and CDATA 
> sections until they hit a boundary ...?

Yes, the boundary is an element, a processing instruction, ... Check our
definition of logically-adjacent text nodes:
http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020114/glossary.html#dt-logically-adjacent-text-nodes



> So perhaps in your text you could point out that your motivation of being 
> "compatible with XPath" is not with respect to its datamodel, but with 
> respect to ordering?

It preserves the same number of nodes in the node sets, therefore the
ordering is preserved. I still think that it is with respect to the
XPath datamodel.


Philippe

Received on Tuesday, 12 February 2002 16:41:30 UTC