🚀 go-pugleaf

Erik wrote:

>...Well, I certainly won't speak for Darrell, but there is no issue of
>a portability problem for SGML documents.

Erik, if I mail you a document to do *any* processing on (other than confirming
its validity, which is merely solipsistic), it is still hard.  Please list
for me any two SGML application programs meant to do comparable processing on
SGML documents, which can take an SGML document and produce comparable results
without a lot of painful manual set-up first.  They must work for any DTD.

This *is* "a portability problem for SGML documents".  If as you say
SGML wasn't designed to handle this, it is perfectly legitimate for others
to ask "Why not?" or "Well, then, how CAN I get this done?"  As yet
there are precious few answers.  This is quite different from the situation
with something like C programs (which are painful enough themselves), and
is a problem that has great effects on the wider acceptance of SGML.

Most of the benefits of SGML, ironically, derive not from SGML per se
but from a set of conventions that SGML users encourage.  The SGML standard
per se does not preclude making a bunch of EMPTY element types, each 
corresponding to a troff tag.  The resulting documents are "portable" as
Erik has defined portability, yet virtually useless.

On another point, to suggest that SGML is not for representing semantics, and
yet "is intended to be a information representation vehicle", is oxymoronic.

Steve