🚀 go-pugleaf

In article <23246D@erik.naggum.no> Erik Naggum <erik@naggum.no> writes:

> [A number of interesting things about why, from his perspective, SGML
> cannot be denied to be the ultimate information modelling tool.]

First a meta comment, then for the contents of this (unfortunately
but necessarily rather long) article.

I love seeing the kind of reply that Erik gave, because it's a symptom
of the missionary approach a lot of people take in the SGML world (and
certainly not just there):  If you point out weaknesses of their
"baby", they'll reduce themselves to "keepers of the faith", instead
of acknowledging that there still is potential for further
improvement.  Having worked in some of the working groups of ISO/IEC
JTC1/SC18 for nearly five years now, an article like Erik's does not
come as a surprise to me, of course (except that Erik's caustic
personality and/or writing style make his article and the ad-hominem
attacks in it less fun to read than it might be).

I abhor reading point-to-point rebuttals, so I'll try to focus on my
main points, beginning with the less important ones.
While reading, please remember that my thesis was not that SGML is bad
or its inventors incompetent, but that SGML in its current form is not
a satisfactory substrate for all information interchange standards of
the future.


				 (1)

SGML vs. FORTRAN:

My comparison of SGML with FORTRAN was not with respect to one of the
two being more or less object oriented than the other one.
I made it to point out the usefulness of a historical allegory:
SGML does solve certain problems for information representation and
interchange; so does FORTRAN for programming.  Since FORTRAN, our
knowledge about programming languages has improved, so we are able to
define better programming languages today; actually, FORTRAN itself
has been improved as a result of experiences with its early versions.

Looking at FORTRAN, today we know about dynamic storage allocation
(and garbage collection), data types, data abstraction, object
oriented programming, etc.  We also know a number of things about good
language design *style*, which is why these features were not just
grafted onto FORTRAN (I know they were, recently), but new languages
have been defined (which, of course, all contain the major features of
early FORTRAN as their core -- making e.g. FORTRAN-to-C translators a
reality).  Finally, there are domains of application FORTRAN was not
designed for (but has been -- often successfully -- used for).

Looking at SGML, we are quite likely to see similar improvements of
the state of the art.  Darrell Raymond's articles just point out some
of them.  Are we going to graft on such improvements to SGML?
Probably.  (Erik mentioned the revision of SGML, which might result in a
language that is much more capable than SGML-1986.)


				 (2)

Complexity incurred by SGML's markup background:

Of course I am aware that many SGML features (such as OMITTAG,
SHORTREF etc.) can be "switched off" (i.e., not be used).  Still, the
legacy of efficient keyboarding comes up in areas such as RE
elimination.

Also, the attempt to make SGML acceptable for the typesetting machines
of the 1980s rears its ugly head now and then.  The problem with
ambiguous content models seems to have been incurred for two reasons:
First, a program that builds DFAs from regular expressions was
considered too complex for the typesetters of the 1980s (which were,
in turn, generally based on computer technology of the 1970s); second,
the semantics of markup minimization (contextually required etc.) are
defined with respect to simple-mindedly parsing the content model.

Many other design decisions of SGML would have been made differently
were it not for the requirement of efficient keyboarding: The result
is that SGML generally is a "heavyweight" standard, i.e., it is costly
to implement and its implementations are costly to integrate into a
product.  Other structured hierarchical expressions (such as Lisp's
S-expressions) carry much of the same functionality with much less
weight being added to an application (to forestall Erik's possible
nitpicking: No, I'm not suggesting replacing SGML by S-expressions;
see below).


				 (3)

Support for non-linear information structure:

Certainly I am informed about HyTime (you may remember the effect the
German comments on the HyTime CD had on the HyTime DIS).

No, Germany did not try to have HyTime voted down; it made two
specific minor comments on the DIS, which, being fulfilled, change
Germany's vote to YES.  Also, I'm not the mastermind behind DIN NI 18.

Much of the problem I (and most of the rest of DIN NI 18) see with
HyTime is that it has to make its information architecture fit with
the SGML standard.  SGML does not cater very much for the kind of
information HyTime needs to represent; in many cases, HyTime reads
like the result of a force-fit (and no, I'm not going to substantiate
this claim; if you read the DIS and do not feel the same, your good
senses are already gone).

Of course, SGML can represent everything; that's why HyTime was
possible.  However, as has been numerously pointed out, the fact that
every information model can be represented in SGML is about as useful
as the fact that every information model can be represented in ASCII:
The interesting question is how much support you get out of SGML, and
how much you have to do on your own (without the benefit of a standard
you can relate to).  A related (often less important, but never
negligible) question is how much support you get out of an SGML
implementation and whether the added weight, learning curve etc. for
using SGML is outweighed by the benefits of using an SGML parser in
the application.

The level of support SGML can provide seems to be quite high for
traditional document processing applications, as witnesses such as
Eliot Kimber can report.  The element declaration (content model)
aspect of the DTD provides a rather good way to model the overall
structural relationships of a (hierarchically) linear document, and
the attribute definitions provide a good way to associate simple
non-textual (but character-based) information to an element.
The entity structure can be used as a simple mechanism to support
cooperative work on documents, together with marked sections it
provides for simple versioning.  Non-SGML information can be attached
to an SGML document and (with a formal structure, but informal
semantics) be tagged as to its data type and additional attributes.
Most important, SGML generally is used as a vehicle to introduce some
form of information modelling into heretofore unstructured document
processing environments.

Etc., etc.; this is all fine.

My conjecture was that SGML in its current form provides a less
convincing cost-benefit relation (including the benefits you receive
from using a standard in the first place) for general data interchange
applications.  Ironically, the complexity and awkwardness incurred by
the decision to base HyTime on unadorned SGML may be a very good piece
of evidence for this conjecture.  (Note that the "SGML++" part of
HyTime -- architectural forms etc. -- is positively a useful addition
to SGML and should become a feature of the base standard over time.)
In essence, SGML reluctantly tolerates, instead of supports, the
inclusion of Hypertext (and, less so, time-based) information in documents.


				 (4)

Artificial limitations and other creatures of the past:

Again, I am fully aware that the artificial limitations can be changed
in an SGML declaration; this is about as good as the equivalent
feature of the lex language.  It is the fact that the provision for
artificial limitations are a significant part of the standard and of
the mental energy that an SGML implementor and user must afford that
makes me sad.  It is also a sad fact that many SGML application
designers feel compelled to live with the reference concrete syntax
and its inadequate set of artificial limitations (such as 8-character
names etc.).

Experience from computer language theory and practice could have been
used to make SGML an easier to parse language.  It is ironic that the
rather impenetrable code (no offense intended) of ARC SGML is a good
model of how to write an SGML parser.  Of course, the baggage required
for markup minimization etc. alluded to above would have made applying
the computer language theory harder -- see above.


				 (5)

Accessibility to formal reasoning:

Formal reasoning is not an end to itself (except for certain Ph.D.
candidates :-).  Two kinds of formal reasoning about SGML come to mind
that I would consider quite useful:

1) formal definition of the language, e.g. to facilitate statements
about conformance.  The FODA effort going on within the ODA community
is but one example why this is a good thing: It has helped to uncover
some of the numerous bugs in the standard and to disambiguate other
areas.  For SGML, this should be a much simpler effort than for ODA,
and it should be able to cover the SGML semantics (see below for my
definition of what that is).

2) definition of the SGML semantics.  Yes, SGML does have semantics.
The statement you often hear that SGML is "semantics-free" simply
means that the depth of standardization was deliberately held low and
that all attempts have been made to keep SGML as general as possible.
This is, of course, a good thing.

Nonetheless, SGML does not simply define a language.  It does provide
semantics for this language as well, for the simple reason that a
language without semantics is (literally) meaningless.  The problem is
that this simple fact initially was denied and a serious definition of
these semantics was not attempted.

A few years after SGML had been issued as a standard, the group of
SGML developers (WG8/SWG-SGML) tried to define the set of information
an SGML parser should make available to an application, under the name
of "Element Structure Information Set" (ESIS).  This is one (and
probably the major) aspect of the semantics of the language: What
information is provided to the application, and what information is
quietly processed by the parser and not made available to the
application.

The latter kind of information is not necessarily redundant: It may be
within comments, part of the entity structure of the document, aspects
such as ignored REs, etc.  In effect, the definition of ESIS specifies
an _equivalence_relationship_ between different SGML documents: If
their ESIS is the same, they _mean_ the same (although the final
meaning of course is only determined by the application, it cannot
tell the difference between two ESIS-equivalent documents).

Besides ESIS, there seem to be other information sets derivable from a
document that should be the subject of more formal reasoning, one of
which has been termed "Markup Structure Information Sets" (MSIS).  An
SGML editor needs to know more about a document than its ESIS, or it
is prone to write back a document with a completely different entity
structure, lose comments, etc.  MSIS would define another equivalence
relationship (hopefully with the property that MSIS equivalence
implies ESIS equivalence).  MSIS would also be used by certain
document conversion applications such as an ODL to ODIF converter.

While a paper that defines ESIS is available (and has been printed
in Goldfarb's SGML book), it is not quite clear that the ESIS
described is exactly the correct foundation for SGML applications:
In the definition of DSSSL, it used to be a big point of debate
whether ESIS is sufficient or some information from the MSIS domain
needs to be made available (such as information about marked
sections).  
Ironically, the current WG8 ESIS document has been claimed to be
more or less derived from the wording of the standard by the agreement
of the people sitting in a room in a WG8 meeting.
As long as a rigorously defined ESIS is not a part of the
standard, SGML's semantics must be said to be poorly defined (and that
was the hand-waving that I talked about in my previous article).


				 oOo

While I have not answered all problems Erik had with my short previous
article, I hope that the present article is more comprehensible than
the previous one, whose briefness combined with a certain degree of
acerbity may have been quite useful in spawning the present discussion.

Roughly, the current discussion in comp.text.sgml seems to divide into
two camps: One that is so happy about being able to represent their
information in SGML that they are content with the language as it is,
and the other camp that is simply expecting more from a major standard
that is now being touted as the basis for future data interchange. 
It would be saddening if input from the second group were dismissed by
the first group just because SGML proponents are used to having the
major fights you get when they try to replace earlier, even uglier
information representations with SGML, and thus routinely fend off
anything they perceive as an attack on SGML.

Gruesse, Carsten
--
Carsten Bormann, <cabo@cs.tu-berlin.de>, Fax: +49.30.31425156
Communications and Operating Systems Research Group, TU Berlin