🚀 go-pugleaf

In the discussion of data modeling and SGML, the issue of
interchange was mentioned.  I wanted to present my views
on interchange and SGML.  There seems to be a common
misconception about what sort of interchange SGML does and
doesn't provide, and people often seem to think that SGML
offers more than it really does.  What follows was originally
written for an IBM audience that is only dimly aware of SGML,
so it's a little more explicit than I would normally be
in this forum.  If I have oversimplified, it was to avoid
confusing my audience with unnecessary details.

The discussion at hand was one of the propogation and re-use
of different DTDs within IBM.  My append below was specifically
to the statement "shouldn't there be a single DTD for all
IBM documents?"

Eliot

Original append follows:

There is a common misconception that SGML means "one true tag
language".  This is not the case.  SGML only defines the
language and processing for creating tag languages (in other
words, the syntax of tags, not the tags themselves).

Specific applications need specific tags.  For example,
creating large software manuals is one application and has
one set of elements (BookMaster), while creating online
panels is a completely different application and has another,
different, set of elements (Dialog Tag Language).  It would
not be sensical to combine both BookMaster and DTL so that
any BookMaster or DTL document could be interchanged.
Interchange with SGML is primarily at the *application* level.

Thus, if you have a different application than I have, you
should have your own tags.  However, if we have the same
application, then we should use the same tags.  In SGML,
the tags for a given application are defined in a DTD, or
document type declaration, which defines a single set of
elements intended for a single application, or "document
type".  Thus the USERDOC document type supports the
application of creating hardware and software manuals.
The document type DTLDOC supports the application of creating
online panels.  Note that by "application" I mean "applications
of a certain type", not specific programs or products.

So where is the interchange, you ask?

There are several levels and types of interchange.  The first
level is at the application level, where documents of the
same document type can be interchanged and processed by
any SGML system that supports that document type.
When people talk about document interchange, this is usually
what they mean.

The second is at the element level.  If two otherwise
disparate applications share some basic elements, and
they use the same tag names, document fragments using only
those elements can be shared between those applications.
For example, the DTL language includes text elements that
go on panels, such as paragraphs and phrases.  If the tag
names* for these elements in the DTL document type and in
the USERDOC document type are the same, then paragraph markup
for DTL panels can also be used in USERDOC documents.
This type of interchange facilitates re-use of small bits.

The third level of interchange is just being SGML, regardless
of document type.  This interchange is provided by generalized
SGML systems such as editors that can work with any document
type.  The DTD contains enough information to allow editors
to generate context-specific tag menus, for example, as well
as to validate the structure of the document, without knowing
anything more about it.  It also allows applications to know,
up front, whether or not they know how to process a given
document type.

There will never be "one true SGML tag language".  Such a thing
is neither possible nor sensical.  We should expect to see a
range of document types carefully crafted to support the range
of applications we have.  However, we should not expect to see
different DTDs for the same basic application.  If your
application defines online panels, you should use the same
DTD as other online panel defining systems.  If you present
text elements, you should use the same elements and structures
as other text systems.  Note that this puts on us, IBM employees
creating new systems, the need to consider carefully what our information
structuring needs are and to create new tag languages carefully
and with an eye toward use by other, similar, applications.
This implies some central guiding agent, whether a Corporate
guiding body or just an informal collection of developers with a
common set of interests (I would prefer the latter).  The sharing
of DTDs via <an internal re-use database>
is certainly a good step in the right direction.

By sharing DTDs for specific applications, we can know what
applications are out there and what DTDs are available and
thus determine if they meet our needs or not.  We should, as
a community, strive to develop as great a degree of commonality
across applications as possible, but we should not, on the
other hand, try to force-fit elements specific to one application
into our own if they are not appropriate.  By clearly defining
document and information structures on an application-by-application
basis, SGML frees us to to tailor our tag languages to specific
applications while still ensuring interchange at several levels.

(Note too that SGML defines a processing model where application-
specific documents are transformed into general documents for
the purposes of output processing.  Thus, a processor like
BookMaster defines a set of very general elements and processing
functions to go with them.  An application-specific document
would first be transformed into a Bookie document and then
processed by BookMaster for output.  The transformation from
application-specific elements to Bookie elements is usually
very easy to write and quick to perform, so it is easy to
create support for new document types by leveraging off the
general Bookie base.  I have a sample application that demonstrates
this idea.

I have some of the poetry of Yeats online marked up with poetry-specific
elements representing a unique document type (POEMDOC).
I wrote a 100-line SGML Translator application to translate
the POEMDOC elements into standard Bookie tags from which
I can either print or build an online book.  The poetry-specific
tags define the real structures unique to my application (poetry),
but being in SGML, it was easy for me to write a transform to transform
my application-specific elements into general Bookie elements.
It was not necessary for me to, for example, write DCF macros to
support the poetry tags.

Eliot "Dr. Macro" Kimber
---------
*And content models, of course--a detail my audience wouldn't have
 understood.