Re: CDATA sections in W3C XML Infoset

[John Cowan <jcowan@reutershealth.com>]

Bob Kline wrote:


> Yes, the inability to nest CDATA sections is a flaw in the XML rec to
> which we've resigned ourselves.

There was no help for it.  Either (a) we allowed nesting, in which case
unmatched occurrences of "<![CDATA[" couldn't be allowed; or else (b) we
disallowed nesting, in which case unmatched occurrences of "]]>" couldn't
be allowed.  SGML had already settled on (b), and there was no compelling
reason to change it.

> We don't accept documents into the
> repository with CDATA sections.  We can do that because we're not a
> general-purpose XML repository product.

Okay.  Then in fact what you allow is any random text, XML or not,
provided it doesn't contain "<![CDATA[" or "]]>".  (You stated
in the earlier message that not-well-formed text was acceptable;
"not well formed" means the same as "not XML".)

> Yuck.  We should re-write our software (client and server) because the
> W3C changed its mind about what an XML document's tree consists of?

No.  You are doing something that is not generally interoperable.
If it works for you, fine.  After all, I'm the guy that publicly
announced he was processing XML documents with "fgrep".

> If
> the W3C was going to stomp on the distinctions enabled by CDATA
> sections, it shouldn't have included them in XML in the first place.

XML has not changed.  The DOM has not changed.  The Infoset simply
declines to provide a standardized model for representing the
difference between CDATA sections and other text.  A future standard
may, if it wants, re-introduce the distinction for its own purposes.
(But we hope not.)

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein