Re: KISS (was: Parameter entity references in WF docs)

Martin Bryan wrote:
> 
> At 11:23 1/6/97 -0500, len bullard wrote:
> >  On the other hand, I do know
> >which features of SGML and which implementations of SGML give
> >users/authors
> >the perception of difficulty and overbuilt parameterized DTDs are
> >among them.
> 
> Many years of experience has shown that the best way to get users to
> understand DTDs is to break them up into small digestable pieces that are
> easy to understand, rather than to try to give them a one-size-fits-all
> solution. The easiest way to do this is to create the DTD as a set of
> reusable fragments that can be fitted together using PEs to make a complete
> model for a final deliverable. Only by using such approaches do you get user
> buy-in.

The teaching approach is certainly right.  The approach to 
aggregation is certainly right.  You are a master. :-)

My trouble with this is that in too many cases, the DTD being maintained 
is actually a clever aggregate for separate types of documents that 
happen to share element type defintions.  In production, these are
unwieldy.
When building a stylesheet, they are frustrating.  

When they are used as template generators (ahh... menus), they produce 
very large sets of choices which do not reflect the actual contents 
of any given document production (instance).  We could say this is an
unclever 
implementation, but that begs the question which is really ease of 
use at more than one level of the system.  In these cases, balancing 
production against the problem of DTD maintenance I find after 
some years of experience that it is easier to maintain multiple DTDs.  
Why?  Once done, their rate of change isn't that high particularly 
if the designs are done well, and balanced against the error rates 
complex DTDs can cause in production, simply not worth it.  

I have a bigger horror of more 28001s and DocBooks as we watch the
newbies 
begin to repeat our mistakes as they too set out to conquer the 
worlds with The One True DTD than I have of lots of little 
tight DTDs for documents with short, fast lifecycles.  Given the 
choice, I'd like a sane period where XMLers learn to write small ones 
and get used to that idea.  I believe a document is a signal.  
Call it an infoObject if you like (very old term) but for applications 
where documents are transactions, small and concise and 
errorfree as discipline enables is better.  IMO, lots of 
little DTDs are much better than a very big one.  Maybe 
we will discover data dictionaries (gee, we need a 
trendier name for these).
 
> The goose is the twerp who tries to create, deliver and maintain DTDs
> withiout using PEs! The greedy gander at the moment would seem to be 'lazy'
> developers who want to duck the problem.

As to the *twerp* of the first part, my experience contradicts yours. 
As 
to the duck of the second part, the charter of XML is to make this 
duck's job easier.  Given choices of things that I as an SGML 
designer have to give up to get freedom of markup back on the 
Web, I'm willing to let PEs go in the first pass.

Programmers are the ultimate reduction artists.  As soon as they 
see enough repeating groups under the root of a DTD, they'll 
put them back.  It's that old nagging habit from algebra, ya know.
 
> We must at least follow Henry's solution and allow PEs for calling in
> element sets if not elsewhere. For real world use, though, we should allow
> PE's in models as well.

I've said my piece.  You find them useful and I find them 
a source of obsfuscation.  I don't have to implement them, 
so, have at.

len

Received on Monday, 2 June 1997 21:15:47 UTC