🚀 go-pugleaf

Carsten Bormann writes:

>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.

I really think you must elaborate on your contention of the "complexity
and awkwardness" of basing HyTime on SGML.  I find HyTime to
be, at its base, simple and elegant.  The complexity is inherent
in the complexity of the task it supports.  Some HyTime
constructions may seem awkward, especially if you were to
code them by hand, but appear to me to be quite direct and
useful for the environment where HyTime claims to have best
application, namely a complete, heterogeneous hyper system
of great dynamics.  The only way for hyperlinking to work
in this system is for the link specifications to be complete
and robust, which usually means some significant overhead, which in the
case of HyTime gets expressed as markup overhead.

Note also that HyTime never says any part of the system, except
the "hub document" (which may not be the correct term any more),
has to actually be SGML.  The HyTime standard uses SGML constructs
to define the architecture, but it can actually support any
data encoding and structuring method because individual applications
(including any HyTime engines themselves) can translate the
semantics of the architectural forms into whatever internal
representation they want.  It happens to be convenient for
systems that apply hypertext to data that is already coded
in SGML to use SGML to express HyTime constructs, and implementers
may find SGML an advantageous technology for their specific
HyTime widgets, but there is no requirement to make them
so.  One of the beauties of HyTime is the ease with which any
existing application can be made HyTime compliant.

I would like to know in what sense SGML tolerates hypertext,
and what you would add to make it quote support unquote
hypertext.  The only thing I can think of is parser-validated
qualified IDs, but that doesn't really buy you
too much.

In my work for IBM defining SGML-based
publishing systems, I am finding many hypertext concepts
become not only natural in SGML but essential to the creation
of general document processors.  I have yet to find an aspect
of document processing that cannot be expressed in terms
of hypertext links and that does not benefit from being
implemented as such, at least architecturally.  In fact, I would
contend that SGML documents are inherently hypertext structures,
with one level of linkage being defined by the hierarchical
structure, another by SGML-validated cross references, the
rest being relationships derived by retrieval applications
from the document- and application-specific semantics
defined by the markup and the data.

For me, SGML also serves as an implementation-neutral
conceptual model for thinking about structuring data within
a large system.  It may not be the basis for the final
implementation, but I can think about the *design* and
the *architecture* in terms of SGML documents, containment,
content model validation, cross references, location via
attribute value queries, etc.   In short, SGML provides
a common language with which I can discuss any data
management problem and its solutions, independent of any
particular implementation of those solutions.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709