W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > February 1997

Re: implementation comments

From: Deborah A. Lapeyre <dlapeyre@mulberrytech.com>
Date: Thu, 20 Feb 1997 09:31:51 -0800 (PST)
To: James David Mason <masonjd@ornl.gov>
cc: w3c-sgml-wg@w3.org
Message-ID: <Pine.3.89.9702200821.A929-0100000@netcom11>

I'm REALLY glad to see other folks concerned about the
comments, but I do feel we have already lost on this
one.  We, as an industry, can cope.

At Mulberry, we see two big problems for us personally:
   1)  All those standard sets of SDATA entities
   2)  Our "house-style", which embedded comments
       concerning every attribute, within the ATTLIST
       Declaration, before the attribute definition.

On the comment issue, we figured:
   1)  One of the vendors would undertake to produce
       an XML conformant version of the standard
       ISO special-character general entities (maybe
       SGML Open can volunteer) and we would all replace.
       Since this is only a comment definition, we need
       not maintain 2 sets, only replace the one we have.
       (In the days before the SGML Open catalogue
       agreement, we kept as many sets as we had
       software packages; this is not as uncomfortable
       as that was.)
   2)  Every SGML DTD we have ever written would have
       to be modified, but we're pretty sure that it could 
       be done programatically, and only once.

So the comments will require work, but are no big deal.

Unfortunately, there are still other reasons that
every SGML DTD will need to be re-written for XML,
the peskiest being the omissability indicators.
If the syntax could just be written to ignore
ANYTHING found in that position (after the first
ps following the element name and before the "("
of the content model ... ).  Sigh.

As XML is shaping up, I see no alternatives for an SGML 
shop but to:
   1)  Generate XML DTDs on the fly from SGML DTDs, as 
       you need them; or
   2)  Maintain duplicate XML/SGML DTDs (Ouch); or
   3)  Generate both XML and SGML DTDs from another 
       source (we're working on this, actually).

And while I see this as inconvenient I don't see it as any 
sort of a show-stopper.  It looks like XML will be, like all 
standards, an imperfect compromise.  That's OK.


Deborah A. Lapeyre                   Phone: 301-231-6933
Mulberry Technologies, Inc.          Fax:   301-231-6935
6010 Executive Blvd.  Suite 608      E-mail: dlapeyre@mulberrytech.com
Rockville, MD USA 20852
Received on Thursday, 20 February 1997 12:39:17 UTC

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