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

Re: Trying to sum up a bit

From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Date: Tue, 17 Dec 1996 16:53:38 -0500
Message-Id: <>
To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org
At 03:07 PM 12/17/96 CST, Paul Grosso wrote:
>> 3. All non-markup bytes are signicant, whitespace or not (Durand)
>> Pro: Everyone can understand the rules, it's easy to implement
>> Con: You lose certain Hytime addressing facilities, and the application
>>      gets no help from the XML processor in ignoring WS that to the user
>>      is "obviously" irrelevant.
>Does this mean that SGML tools will necessarily lose XML-significant
>whitespace when reading XML, or did we come up with an SGML trick
>to avoid this?

That's what Tim means when he says that "certain Hytime addressing
facilities" breaks. Any tool that depends on having the same parse tree
breaks. Right now that is HyTime, DSSSL, SDQL, TEI Locators and other
addressing and stylesheet syntaxes. In the future, who knows?

List of Principles

This list of principles is presented in descending order of priority. We
currently regard items #1 through #4 as "non-negotiable", required
characteristics of any successful XML design.

3. XML shall be compatible with SGML.

1.Existing SGML tools will be able to read and write XML data. 2.XML
instances are SGML documents as they are, without changes to the instance.
3.For any XML document, a DTD can be generated such that SGML will produce
"the same parse" as would an XML processor. 4.XML should have essentially
the same expressive power as SGML.

Note: ...

#3 and #4 indicate our intentions accurately, but it is not yet clear how
best to formalize and explain the phrase "the same parse", or the phrase
"essentially the same expressive power". These remain open questions; see
point 8 also.


I think that the HyTime TC (and DSSSL) formalize the concept of the "same
parse", and proposal 3 breaks that compatibility.

 Paul Prescod
Received on Tuesday, 17 December 1996 16:50:49 UTC

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