> > [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@megginson.com
http://www.megginson.com/