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

Re: Parameter entity references

From: len bullard <cbullard@hiwaay.net>
Date: Thu, 29 May 1997 20:58:51 -0500
Message-ID: <338E345B.2DBD@hiwaay.net>
To: "Eve L. Maler" <elm@arbortext.com>
CC: w3c-sgml-wg@w3.org
Eve L. Maler wrote:
> 
> Just one thought to add:
> 
> At 09:01 AM 5/29/97 -0700, Deborah A. Lapeyre wrote:
> >1)  This is to second the plea that we look very very
> >carefully at requirements on this one.  Could someone
> >state what we all feel they are? please?
> >
> >2) Can we also look at this as a cost (and to whom) and
> >benefit (and to whom).
> >
> >Parameter entities in DTDs:
> >   - are the mechanism DOCBOOK, TEI, and others
> >     have used for extensibility and customizing
> >   - are a godsend in DTD maintenance and legibility
> >   - make multi-DTD libraries practical

> PEs have a lot of the power needed for managing problems that have come up
> under the heading of "the namespace problem."  There are relatively
> well-established ways to write DTDs to make it possible to add new DTD
> fragments in collections of similar contexts, and depending on the type of
> fragment (does it need to allow markup inside it from the "outside" DTD?),
> the whole business can be highly regularized and even given a slick
> interface.  (Perhaps we should concentrate on these kinds of PEs and dump
> some of the others?)
> 
> So I believe the gain to users/authors could be quite large, and possibly
> even easy to see. :-)

I have to disagree with both of you.  In my experience, heavily 
parameterized DTDs have lead to much of the bloat and misunderstanding 
of SGML practice and systems.  Very complex DTDs that sometimes 
resemble sophomore attempts at SGML erudition became tools mandated 
by committees that often did not use their own work in production 
environments with lesser-cost tools.  In these environments, 
more precise menus, shallower trees and very precise tagging 
resulted when it became obvious that it was faster, cheaper and 
cleaner to change the DOCTYPE than to wrestle down a complex 
tree.  In my opinion, for what is trivial maintenance, the authors 
have been made to suffer at the hands of the DTD designers 
and for that reason, SGML has suffered a richly undeserved 
reputation for complexity.

Just as many care little for the work done on prior standards, 
I care less for the existing DTD constructs that are still in 
too many cases print and SGML literati centric with a smattering  
trendy infomatics thrown in.

My vote:  not in XML 1.0.  Do a simpler SGML for awhile and 
see if that suffices.  

Len Bullard
Intergraph Corporation
Received on Thursday, 29 May 1997 21:59:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC