RE: CDATA Section nodes in DOM.

> -----Original Message-----
> From: www-dom-request@w3.org 
> [mailto:www-dom-request@w3.org]On Behalf Of
> Jan-Arve Saether
> Sent: Monday, October 29, 2001 6:13 AM
> To: 'www-dom@w3.org'
> Subject: CDATA Section nodes in DOM.
> 

> 
> Why does DOM have the CDATASection interface. Isn't CDATA Sections
> just of interest when you are serializing a document?
> (You need to escape certain characters etc)

A Frequently Asked, but Seldom Answered Question.  The DOM Level 1 had a
requirement to be able to support the serialization of any well-formed
document (without any DTD information), so it needed a CDATA Section
interface.  More practically, we also had a use case to support XML editors,
and CDATA Sections are markup that editor users need to manipulate.

> 
> This also gives a potential problem when you are performing XPath
> queries on your document, and it does not comply with the Infoset
> specification. (Yes, I know that the specification is quite fresh :-)

I don't fully understand the question about Text nodes and CDATA nodes.  The
DOM just specifies interfaces, not classes or types of the actual underlying
data.   As long as the DOM implementation recognizes that certain chunks of
text *behave* like CDATA sections, that's fine.  As for the differences
between the DOM and XPath data models, I'd suggest looking at the DOM Level
3 XPath support draft for background on the problem and how we are trying to
resolve it.

CDATA sections are definitely a wart on XML and/or the DOM and/or XPath
and/or the W3C for not coordinating better ... the best practical advice I
could offer is to avoid using them if at all possible, although they
definitely have their uses (e.g., escaping script).

Received on Monday, 29 October 2001 07:00:34 UTC