- From: len bullard <cbullard@hiwaay.net>
- Date: Thu, 29 May 1997 20:58:51 -0500
- 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