- From: Steven J. DeRose <sjd@ebt.com>
- Date: Fri, 13 Sep 1996 17:45:42 -0400
- To: w3c-sgml-wg@w3.org
At 10:11 AM 09/13/96 CDT, Paul Grosso wrote: ... >But if XML uses a different syntax in the instance to indicate EMPTY >elements, will SGML tools be able to generate XML? It seems there are >two parts to the answer: > >1. can an SGML decl be configured so that an SGML editor that handles > generation of all variant syntaxes would generate the proper stuff > for XML's empty elements, and > >2. what is the fraction of existing SGML editors that, when handed that > SGML decl, would in fact support the generation of the specified form > for XML's empty elements. I think you're mixing two proposals. Under "Raw Bits" and "Cooked Bits", XML is basically the same as SGML with respect to EMPTY elements: they use start-tag syntax but prohibit end-tags, and (as a consequence) you must have a declaration so the parser knows who's empty. In that case you don't need to use the NET trick or any other special syntax. That's an *alternative* solution, specifically designed for dealing with the case where there *is* no declaration. Thus, under Raw/Cooked bits an SGML system does not have to do anything special on export. No variant syntax, no special treatment of EMPTY (beyond what SGML already requires of them), etc. Note the original definitions: >6 Raw Bits, or What's So Hard about Reading DTDs? This resolves the >problem by declaring it a non-problem: if one wants EMPTY elements, one >has to declare them ... >If there's no DTD to read, then there are no EMPTY elements. Period. ... > >7 Cooked Bits. A variant of the Raw Bits (parse it and like it!) >approach would be to provide a different syntax for the declarations, to >make them really, really easy to parse. ...
Received on Friday, 13 September 1996 17:47:39 UTC