From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
Newsgroups: comp.text.sgml
Subject: <!DOCTYPE limerick
Date: 10 Apr 92 14:11:14 GMT

I like Erik's solution.  The differences between his and mine
point up some interesting philosophical issues of tag design.
One is generality versus specificity.

Erik's key content model is:

<!ELEMENT limerick - - (line1, line1, line2, line2, line1)>

This is very precise, and probably most appropriate for the
stated application, which was creating *limericks*.  It also
demonstrates the power of SGML as a language for describing
very precisely information structures and then enabling the
enforcement of those structures.  In other words, with Erik's
content model driving an editor, I cannot create an invalid
limerick (although it can't force me to meet Assimov's
requirement that limericks be bawdy :-) ).

For my submission, I automatically generalized limerick to
"poetry" and created a content model that supports any form
of poetry.  This approach is probably best for a tag language
design that has to meet a wide range of applications (this is
the case for languages like BookMaster).  This is my personal bias
and thus informed my approach without me even being conscious of it.

I've come to realize that one of the most powerful aspects of
SGML is that it enables the creation of very specialized applications
(like Erik's) that can provide very precise description of
structures, yet it is easy (often trivially easy) to write
processing programs to translate precise, application-specific
tags into general tags.

Let's say I have a general-purpose text-formatting system
based on a general "BookMaster-like" language (or, if you
prefer, a LaTeX-like language just to take the IBM sting
out of it) I'll call "GenDoc".  Given a general tag-to-tag mapping application
(like the IBM SGML Translator, DCF Edition), it is easy
to set up a system like this:

LimerickDoc   Limerick                                 GenDoc
Authoring  -->Instances-->LimDoc2GenDoc-->GenDoc   --> Formatting -->Formatted
System                    Processor       Instances    Application   Limericks


Note that the LimDoc2GenDoc program is *very simple*, on the
order of 100 lines of code or less, and easy to write, being
nothing more than a mapping table (e.g., <limerick> -> <poem>,
<line1> -> <line>, etc.).  This means that it is easy for
me to add other such applications to support a wide range of
specialized tag sets.

This is all made possible because of the infrastructure
that SGML systems become just by dint of being standard (i.e.,
general-use, standardized parsers and applications like ARCSGL
and SGMLS), as well as DTD-driven editors like Author/Editor
or TextWrite.

I've discovered in talking to customers who are starting to
develop these sorts of systems that once they get the first
one set up, suddenly all sorts of difficult problems become
solveable, and many become easily solvable.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709
Newsgroups: comp.text.sgml