🚀 go-pugleaf

As is the case with almost all standards, SGML defines a number of terms
to relieve itself of becoming excessively verbose.  In the discussions
of the past month, much has been focused on the absence of any means to
express the semantics of elements in SGML itself.  The argument has been
that the semantics is left to the application.

Those who know SGML will have no problem with accepting this, since the
term "application" is defined in the standard, and elaborated upon in
Goldfarb (The SGML Handbook): Chapter 3 (in Part Two) is dedicated to
the topic.

An SGML application consists of a document type definition (DTD), part
of which can be expressed in a document type declaration in SGML, and
attendant documentation (which, by the way, is required by the standard;
see Clause 15 Conformance.)  That which cannot be expressed in SGML
includes a specification of the semantics of the element types, the
attributes, and the notations, as well as any markup conventions or
other application conventions used.  These can be included in a document
architecture, of which different DTDs could be seen as instances with
common semantics.  Another way to specify common semantics is to use
architectural forms, and build DTDs with them.  HyTime is an example of
the latter, while ODA is an example of the former.

An SGML application exists independently of any implementation.  (See
Section 3.2, p 126.)  It's the task of an SGML system to either
provide an implementation of a given application or the facilities to
implement one (or more).  (See Section 3.3, p 128.)  Which is to say:
An SGML application is a specification, part of which is expressed in
SGML, and part of which in the documentation, in informal comments, or
in more formal specifications in a different language.  Part of the
semantics can also be expressed in DSSSL.

It appears to me that there has been significant confusion on the
point of "where the semantics is located", and that those who argue
against SGML on the grounds that it does not address semantics do so
on the condition that they think an "SGML application" is a concrete
implementation on a given hardware.  In particular, the statement
"SGML will result in non-portable, application-dependent documents",
conveys the lack of interest in the precise terms that SGML defines,
even though the author seemed overly occupied with the precise terms
he already knew how to use (but not define).

An SGML document is, by the very definition of "SGML document" (see
definition 4.282, and Chapter 4, pp 132ff), application-dependent, and
it has to be.  It is therefore rather odd to use this as a derogatory
term, but to those who have studied the standard instead of blindly
attacking it, it says much more about the knowledge and attention to
detail of the author than anything else.

An SGML document includes a reference to (or includes) the document
type declaration, which, in sufficient detail to allow parsers to
process the document, defines the application.  Further processing
requires implementing the application.  The implementation, in turn,
is greatly simplified by having a parser which handles all the gory
details of parsing the markup, completely transparently handles the
entity structure, and also validates the document against the markup
language specified, to the great relief of any application program
implementer.

Considering the inherent self-descriptive features of an SGML
document, as found in the SGML declaration, it's difficult to both
know SGML and say that "SGML will result in non-portable documents".
In fact, I think it's impossible to both know SGML and to claim this
as true at the same time.

There are problems facing blind document interchange using SGML, but
they are not insurmountable, and with a little less blindness than
some think is mandatory for document interchange, they are not hard
at all, and certainly a lot easier than any other interchange means,
which usually do not even include any information about the data
representation used, or a formal definition thereof, if any.

Computers deal with the representation of information, and not with
the information itself.  The information appears when a human
reader accesses the representation.  SGML has catered to this fact
by specifying a language for the representation of many sorts of
information.  Realizing that how the information represented should
be processed heavily depends on the reader, and in many cases the
process of interpreting a representation takes many stages.  One of
them takes place in the SGML parser, one or more in a back-end
engine (DSSSL, HyTime), and at least one in user application
programs implementing the semantics defined in the SGML application.

In summary, I think much of the debate hinged on a misunderstanding of
the meaning of "SGML application", and an impression that our opponent
knew what it meant, when in fact that was not the case.

Best regards,
</Erik>
--
Administrative note: I'm changing the address from which I'm sending
these articles in an attempt to mollify the anti-commercial activists
who think that my postings to this group constitute using university
resources as an unfair marketing advantage.  Since I don't sell or
market anything in these articles, but instead give away commercially
valuable information in an attempt to inform the newsgroup readership
and raise the level of discussion to the seemingly academic, this is
difficult to understand, but time will tell if they are sufficiently
appeased by not seeing my company name in the headers.
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.