- From: Charles F. Goldfarb <Charles@SGMLsource.com>
- Date: Thu, 10 Oct 1996 04:48:51 GMT
- To: Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU>
- Cc: W3C SGML Working Group <w3c-sgml-wg@w3.org>
On Thu, 03 Oct 96 18:23:07 CDT, Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU> wrote: >On 9 October 1996, the ERB will vote to decide the following question. >A non-binding preliminary vote indicates the question needs further >discussion in the work group. > >A.7 Should XML have CDATA, RCDATA, and TEMP marked sections or not? > A number of thoughtful questions have been raised in this thread regarding the motivation for the CDATA design. I'll try to answer them. 1. The ugly (that is to say, distinctive) syntax. A design principle of SGML is that different kinds of information have different syntaxes. Processing instructions are different from comments are different from elements are different from specially-parsed data. The syntactic distinctions emphasize the semantic ones to remind the user that different rules are in effect and different behaviors will apply. The syntactic differences also allow SGML to avoid impinging on the user's name space, as it would have to do if, say, comments were element types. 2. Why a CDATA element is terminated by any end-tag. Because we goofed. An original objective of SGML, believe it or not, was to support DTD-less parsing of an instance. Obviously, we blew it in the final product by not making CDATA element types, etc., optional. (In fact, we had many more options at one time, but were pressured into "simplifying" things. SHORTTAG was a combination of what started as several independent features.) <digress>Multi-year projects in a highly political arena with changing personnel contributes to a loss of focus. WG8 has gotten much, much better at managing the standards process since then. The review process for SGML97 started out by agreeing on objectives and procedural rules and writing them down. XML has wisely done the same.</digress> The error was compounded by the fact that we couldn't agree (or occasionally forgot whether we agreed) whether we could expect a dumb parser to keep a stack. We'll fix this bug in SGML97. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management --
Received on Thursday, 10 October 1996 00:58:54 UTC