[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: CDATA by any other name... (was The raw and the cooked)

• From: <david@m...>
• To: XML Dev <xml-dev@i...>
• Date: Fri, 30 Oct 1998 12:56:43 -0500 (EST)

John Cowan writes:

 > > [A] CDATA section['s]
 > > contents are equivalent to character data (see clause 2.7).
 > 
 > You're kicking the ball through your own goalposts here.  Clause
 > 3.2.1 says:
 > 
 > # [E]lement content [...] must contain only child elements
 > # (no character data), optionally separated by white space
 > # (characters matching the nonterminal S).

Actually, I think that the game might have to be called off on account
of inconsistent terminology in the spec.  For example, clause 2.4 says
that

  All text that is not markup constitutes the character data of the 
  document.

In other words, the "characters matching the nonterminal S" *are*
character data.  OOPS!

I wonder if this is already on the XML 1.0 errata list.

 > So if CDATA sections are equivalent to character data, they are
 > unequivocally forbidden.  

No, unfortunately for parser writers, they're only equivocally
forbidden.  Like most religious texts, the XML 1.0 spec has proven
itself internally-inconsistent, so we're going to have to invent some
kind of exegetical method now to show how it's really all an allegory.

 > Only whitespace is permitted.  To suppose otherwise is to suppose
 > that CDATA sections with whitespace are allowable anywhere that
 > whitespace is allowable, which is absurd: "<FOO<![CDATA[
 > ]]>bar=baz>" anyone?

No, fortunately things aren't that bad.  As clause 2.4 makes clear,
character data appears only outside of markup.

 > > Presumably, because of #1, the rule in clause 2.10 that "an XML
 > > processor must always pass all characters in a document that are
 > > not markup through to the application" applies here.
 > 
 > I take that merely to mean that none of the content of the CDATA
 > section can be elided, not that the parser is forbidden to mark
 > content coming from a CDATA section as such.

Quite correct -- as I've pointed out in another posting, there is no
explicit upper limit on the amount of information a parser may report.

The real problem here is simply that the spec cannot answer my
(originally, Henry's) question, and will have to be fixed.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: there's empty, and then there's REALLY empty
    • From: "James Tauber" <jtauber@j...>
  • Re: there's empty, and then there's REALLY empty
    • From: ht@c... (Henry S. Thompson)
  • Re: there's empty, and then there's REALLY empty
    • From: John Cowan <cowan@l...>
  • Re: there's empty, and then there's REALLY empty
    • From: <david@m...>
  • Re: there's empty, and then there's REALLY empty
    • From: ht@c... (Henry S. Thompson)
  • The raw and the cooked (was: there's empty ...)
    • From: John Cowan <cowan@l...>
  • CDATA by any other name... (was The raw and the cooked)
    • From: <david@m...>
  • Re: CDATA by any other name... (was The raw and the cooked)
    • From: John Cowan <cowan@l...>

• Prev by Date: Re: CDATA by any other name... (was The raw and the cooked)
• Next by Date: Re: CDATA by any other name... (was The raw and the cooked)
• Previous by thread: Re: CDATA by any other name... (was The raw and the cooked)
• Next by thread: XML WG Reorganization questions
• Index(es):
  • Date
  • Thread