🚀 go-pugleaf

In article <8149@mcshh.hanse.de>, schiers@mcshh.hanse.de (Carsten
Schiers) writes:

> Hello,
> 
> is the Document Type Definition (DTD) part of an SGML text interchange?
 ....
> Is there something inside the SGML definition, which I don't have at
> my desk, sorry, which tells me that a DTD is part of an SGML document?

Clause 6 of ISO 8879 -- SGML deals with the structure of the entities
which make up an SGML document and Clause 7 deals with the nature
of elements within SGML.  Together they explain that, for all practical purposes,
an SGML document begins with an SGML declaration (which establishes the
"default values" for a system, and which is optional), followed by a
prolog (usually simply one DTD or a reference to it as Jim Howe points
out in his article), followed by one or more "document instances", which
follow the markup declared in the DTD.

It is therefore the intention of SGML that interchange include, at the
very least, a DTD (or reference to one) and an encoded text stream.
_________________________________________________________________

However, Herman Silbiger (hsilbiger@attmail.com) writes:

> SGML encoded documents cannot be used in an Open Interchange environment,
> since, as you have found out, the document cannot be interpreted unless you
> also have the DTD.  This is one of the reasons that ODA adopted a standardized
> architecture.

> While it is true that ODA applications also must conform to a Document 
> Application Profile (DAP), these are hierarchical subsets of the complete
> standard.  If you conform to the highest level, you can understand all the
> lower levels.  In SGML, conforming to one DTD does not help you with the others.

Conforming to SGML -- not (as Carsten has realised) to one DTD -- is the
secret of success.  SGML is a **language** which we use to build
the architectures we need.

This is precisely the strength of SGML.  The odds are slim of all of us agreeing
on architectures that will support us in our trade book publishing, our
electronic disclosure of financial information, our creation of technical
manuals for airplanes and aircraft carriers, our building of hypertexts in
a variety of disciplines, our encoding of music, or poetry, or drama,
our interchange of machine-readable dictionaries and research texts,
our creation of training manuals and software reference guides. Indeed, the
odds are very slim of our finding **one architecture** to support all this
plus the things we can't yet imagine.

But, with systems which can read any DTD, and "reconfigure" themselves
to understand a variety of architectures, one is not restricted.
_________________________________________________________________

jwh@boston.ifs.umich.edu (Jim Howe)
is absolutely right in his description:

> SGML is a language for defining DTD's.  Since the DTD specifies the rules
> used by your document it must be associated with your document in one
> manner or another.  This can be done either by including the DTD at the
> start of your document or referring to the DTD through the use of the 
> PUBLIC identifier.  If PUBLIC is used, the document processor must know
> how to process documents that conform to the DTD specified by the PUBLIC
> keyword.  It could do this by knowing where to go to read the specified
> DTD, or it could have the rules of the specified DTD built in.  

The last line of Jim's reply is particularly interesting.  Clause 15 of
the standard, which defines conformance, answers Carsten's other question:
> To specify my question: does a software product, e.g.  a publishing
> system, which tells to be able to use SGML format, have to be able to
> read an SGML document and *any* DTD? As I understand, then it has to 
> read the DTD, which is something like a grammmar for me, and then parse
> the text, using this DTD.

As Jim indicates, a software product may have a DTD built in which it
supports.  That product CANNOT claim to be a conforming SGML system:
     "A conforming SGML system shall be capable of processing any
     conforming SGML document ..."
(where an SGML document may include any conforming DTD)
but it may be a conforming **SGML application**.  

An application includes both formal (DTD, data content notations, etc)
and often informal (application conventions, processing strategies)
specifications for the handling of a particular class of documents.
Generally "SGML application" has been treated as if synonymous with DTD,
or as if it implies just one DTD, and that works most of the time.
_________________________________________________________________

Carsten again:
> I ask this, because a software manufacturer tells me, I have to send the
> DTD for my special problem to him, and then he will return a special 
> filter for documents which behave like this DTD.  So anytime I have a new
> type of document, I have to buy a new filter.  

Your vendor is trying to cover for the fact that the software in question
has an application built in, and is not a conforming **system**.  You may
have better luck by obtaining an SGML parser and translating your SGML 
input to the input required by the publishing system.
_________________________________________________________________

Carsten also asks:
> What is the idea of the CALS standard with SGML text exchange?
CALS is a very broad defense industries initiative for the
automation of acquisition and logistics databases.  Among many
other aspects, it specifies an SGML application strategy (an
architecture for technical manuals and a direction for specifying
architectures for other kinds of paper and paperless documents)
as well as naming graphic standards for 2D, 3D and raster images.

This is an enormous topic.  My prediction is that it will one day
have its own newsgroup.

----------------------------------------------------------------
Yuri Rubinsky				(416) 963-8337
President                               (800) 387-2777 (from U.S. only)
SoftQuad Inc.				uucp: {uunet,utzoo}!sq!yuri
720 Spadina Ave.			Internet: yuri@sq.com
Toronto, Ontario, Canada M5S 2T9	Fax: (416) 963-9575