🚀 go-pugleaf

I agree with what Eliot and Eric have said about the need for an
abstraction of the SGML information using an interface definition
through an applications interface of some kind.  I tend to think of the
SGML parser/entity "interface" as an export/import cycle into and out of
the data storage.  This data storage is accessed through Eliot's Logical
Access Interface for applications that support it.  The SGML "interface"
is used by any other SGML application that cannot make use of the
logical access interface.

Why have a logical access interface?  Why not use the SGML data as the
data storage?  Efficiency is one reason.  Backward compatibility with
current product code is also another reason.  In my thinking, it also
does away with concerns for markup minimization and entity structures,
although it cannot lose ignored marked section information or comments
(I believe Eliot and I have a minor disagreement on this).  At one level
I think that the semantics which may be accessed across this interface
must be flexible, depending on the nature of the application and the
"wit" of the developers; I can see some real value to a standard here
that many different products may plug into.  In any case, this
abstraction need need not mean a loss of important semantics if the
underlying data storage has the semantics necessary to carry the
necessary SGML information.

What is the necessary SGML information?  There is one definition today,
that is ESIS.  It is defined as that information which the SGML standard
indicates must be available to the application, no more, no less.
Unfortunately, given this definition some information that even a basic
SGML application may need could not be included ... like the name of
SDATA external entities.  The DSSSL group is planning to support this
ESIS definition in its work.  We have asked for a few additions to the
ESIS set to support our requirements.  In addition, DSSSL also supports
what we are calling ESIS+ which contains all the information necessary
to recreate the SGML datastream, including ignored marked sections,
comments, tag specification strings, etc..

The model is that DSSSL systems and DSSSL applications on these systems
may choose one or the other to work with (with appropriately defined
behaviour for both cases).  Are there other public definitions of the
"necessary" SGML information?  Every SGML product intrinsically supports
some view of what is necessary or unnecessary based on the information
the application has access to.

Wayne L. Wohler                   Internet:  wohler@vnet.ibm.com
Dept G82/910M                     IBMMAIL:   USIB29WX@IBMMAIL
Publishing Solutions Development             Phone: 1-303-924-0470
IBM Corporation
Boulder, Colorado  80301-9191