W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: (Resend) Re: A7: CDATA, RCDATA, TEMP marked sections?

From: Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU>
Date: Mon, 07 Oct 96 11:30:09 CDT
Message-Id: <199610071640.MAA04663@www10.w3.org>
To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
On Sun, 6 Oct 1996 19:37:40 -0400 Paul Grosso said:
>I see no reason for TEMP, and extremely little for RCDATA.  If we decide

Little, but not nil.  I've needed RCDATA when my SGML examples are trying
to illustrate the syntax of marked sections:  since CDATA marked
sections can't have nested marked sections within them, one needs
something like

  <![ RCDATA [
    This paragraph has one sentence.
    <![ %conditional [
    Or two?

The &nil; in the penultimate line prevents the marked section from
ending prematurely.

To be sure, this is a very rare requirement.  But it is in fact
reasonably easy to handle, with RCDATA; hence my sense that CDATA and
RCDATA may as well be handled alike.

>Otherwise, rather than invent new incompatible syntax, I suggest we
>just tell people to use an element with #PCDATA content, escape
>< and & (using &lt; and &amp; or some such), and indicate via the
>style sheet that the element is "verbatim" (and perhaps set it in
>a monospaced font).

This works.  I do hate to edit files like this using Ascii editors;
marked sections make it much easier to read the examples.  But any
argument in favor of retaining (R)CDATA marked sections seesm to rely
exclusively on aesthetics and convenience.  It's clear we *can* get by
without CDATA marked sections at all, and *should* do so, if they make
parsers harder.  They don't seem to me to complicate things,
particularly if we require the keyword to be a literal, not a parameter
entity reference, and so on the whole they seem to me to be worth
retaining.  But if we want, as Len Bullard puts it, to

  K.I.S.S. until your lips bleed

then they should definitely go, unless our lips are already bloody
from some other decisions.

Received on Monday, 7 October 1996 12:40:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC