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

Re: ERB meeting, 30 October 1996

From: David G. Durand <dgd@cs.bu.edu>
Date: Thu, 31 Oct 1996 12:03:35 -0500
Message-Id: <v02130502ae9e38b62698@[]>
To: w3c-sgml-wg@w3.org
At 9:08 AM 10/31/96, Gavin Nicol wrote:
>>Another problem with the /> NET trick is that it's *still impossible
>>for a structure-controlled application to create a parseable
>>instance from ESIS*.  This is one of the more serious problems
>>with ISO 8879 from a tool-writer's standpoint; this is an issue
>>that XML *must* address for it to satisfy design goal #9:
>>"XML documents shall be easy to create."
>While this *is* an important point, one could just as easily say that
>ESIS is poorly designed: it doesn;' preserve imformation regarding
>empty elements, or entity boundaries, for example. Not all systems
>need such information, but many do.

   I tend to agree. ESIS defines a minimum level of information required,
but I don't see that we should enshrine its flaws, especially since it is
non-normative. I am able, for instance, to get the EMPTY element
information trivially from YASP, and I'm sure it can be done the same from
SP. If XML requires emty element information, that will be an argument for
an ESIS+ option to NSGMLS to easily support conversions to XML.

    Arguments of the form "this is in the ESIS, we need it" should hold a
_lot_ of weight. Arguments of the form "We need this (or would like it a
lot) but ESIS doesn't have it, so we'll have to live without" are not
totally negligible, but ease of implementing such extensions (for a
reasonable SGML parser) should be factored in.

   -- David

RE delenda est.
I am not a number. I am an undefined character.
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Thursday, 31 October 1996 12:03:34 UTC

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