- From: Tim Bray <tbray@textuality.com>
- Date: Wed, 09 Oct 1996 12:56:39 -0700
- To: w3c-sgml-wg@w3.org
The SGML ERB met Wed. Oct 9th and voted on quite a few items. In attendence: Bosak, Bray, Clark, DeRose, Hollander, Kimber, Maler, Paoli, Sperberg-McQueen, and Sharpe. Absent: Magliery and Connolly. By a recent resolution of the ERB, and at Dan Connolly's request, he is now a non-voting liaison member. Thus, "Unanimous" means 10 in favor. No votes were close enough that Tom's presence or absence would have made a difference. Several issues were left unresolved at the end of the meeting; the ERB will be meeting tomorrow and Saturday to get through this stuff. >A.1 XML will have only one concrete syntax, fixed at XML >specification time, not document-instance parse time (0.2, 13.3, >13.4). Passed, Unanimous >A.2 All or virtually all the information provided by a normal >SGML declaration will be fixed for all documents; no SGML declaration >will be necessary. (Possible exception: character-set information may >vary document to document, but will be conveyed in other ways.) >(6.2.3) Passed, Unanimous >A.3 XML will have no OMITTAG, DATATAG, SHORTREF, LINK, CONCUR, >RANK, or SUBDOC features (7.3.1, 7.3.1.1, 7.3.1.2, 7.3.2, 7.4, 7.5, 7.6, >7.7, 7.8, 9.4.6, 11.2, 11.5, 11.6, 13.5). Passed, Unanimous >A.4 XML will make only partial use of the SHORTTAG feature: > > * no minimized start-tags or, probably, end-tags (7.4, 7.5) > * no omission of attribute name and value indicator (7.9.1.2) >But > * omission of attribute-value specification will be legal for >attributes not declared REQUIRED (7.9) (applies only when >DTD is supplied and used) >The final point, on omitted attribute-value specifications, raises the >general question of how XML systems will behave when no DTD, or a >partial DTD, is provided -- if such omitted or partial DTDs are allowed. >It also raises the question of providing a way for a document to signal >that its DTD can be skipped without loss of information (e.g. because it >has no default attribute values, or no empty elements, etc.). These >questions are to be discussed and decided separately. Passed, Unanimous >A.5 XML will have no quantities or capacities (7.3.3, 7.4.2, >7.9.2, 7.9.4.5, 9.4.1, 9.4.2, 9.8, 11.3.1, 13.2). Passed, Unanimous >A.6 XML will not allow asynchronous marked sections -- marked >sections must begin and end in the same element. Passed; Unanimous. As Harvey Bingham pointed out, this needs careful phrasing to avoid ambiguity. >A.7 Should XML have CDATA, RCDATA, and TEMP marked sections or >not? XML will have CDATA marked sections, which must begin with the 9-character literal string "<![CDATA[" and end with the 3-character literal string "]]>". This is essentially Charles Goldfarb's proposal, although we may not call them CLEARDATA. XML will not have RCDATA or TEMP marked sections. Both Unanimous. >A.8 Should XML have INCLUDE and IGNORE marked sections or not? >(If this question is answered YES, it leads to a separate question, how >to achieve conditional inclusion in XML markup declarations. This >related question is to be decided separately.) Split in two: XML will not have INCLUDE or IGNORE marked sections in document instances; Unanimous. The question of conditional markup in declarations is still open. >A.9 XML will have no CDATA or RCDATA elements (11.2.3). Passed, Unanimous. >A.10 How should XML escape markup delimiter characters in content >(especially if (R)CDATA elements and marked sections are not >allowed)? Unanimously agreed that CDATA marked sections are to be used for blocks of text. See A19 for more on this. >A.11 XML will retain the distinction between element content and >mixed content (7.6, 11.2.4). (Applies only if DTD supplied and >used.) Passed, DeRose dissenting. >A.12 XML will require all attribute-value specifications to take >the form of attribute-value literals (7.9.3, 7.9.3.1). Passed, Unanimous. >A.13 XML will not allow RE to end an entity or character >reference; an explicit refc must provided, and it must be a semicolon >(9.4.4). Passed, Unanimous. >A.16 XML will stipulate that character references within >processing instructions should be resolved by the XML parser (8). Defeated, Sperberg-McQueen dissenting. >A.18 XML will have declarations for elements, and attributes, but not for short-references or links (11.1). Passed, Unanimous, for elements and attributes. Notations and entities remain open. >A.19 XML will retain fundamentally the same parsing rules as >SGML, though they may be expressed differently. (N.B. there is some >sentiment for making XML's rules more restrictive than SGML's.) Agreed unanimously that the rules should be stricter than SGML in that the characters '&', '<', and '>' are deemed always to delimit markup, and must always be escaped, specifically as "&", "<", and ">", when appearing in parsed character data. The ERB recognizes that this impinges on the user's name space in an un-SGML-like way, but feels that this has already, de facto, happened. >A.21 like SGML, XML will forbid empty strings as attribute values >for non-CDATA attributes, require FIXED attributes to take their default >values (7.9.4.1, 7.9.4.2), and distinguish implied values from >null-string values (11.3.4). Passed, 7 in favor, DeRose, Hollander, and Sperberg-McQueen dissenting. >A.23 XML will have no CURRENT attributes, but it will have FIXED, >REQUIRED, and IMPLIED attributes, and attributes with explicit >defaults. Passed, Unanimous. >A.24 Unlike SGML, XML will not allow direct references to >external data entities from within parsed character data (9.4). Passed, Unanimous. >A.25 Like SGML, XML will forbid recursive entity reference >(9.4). Passed, Unanimous. >A.26 Like SGML, XML will allow elements to be declared ANY >(11.2.4). (Whether other similar shorthand declarations will be >defined, e.g. for any subelements but not allowing PCDATA, will be >decided separately.) Passed, Bray dissenting. >A.27 XML will behave like SGML as regards behavior and precedence >of occurrence indicators and connectors in content models (11.2.4.1, >11.2.4.2). (Whether to abolish the AND connector will be decided >separately.) Passed, Unanimous. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167
Received on Wednesday, 9 October 1996 15:57:01 UTC