🚀 go-pugleaf

Erik brings up some interesting points and I think he's generally
correct.  The abstract model I have in my mind for SGML systems
is one where applications are separated from the data storage
component (database) by a true SGML parser and entity manager
that provides a completely-conforming SGML parsing "view" of
the data and hides the details of how the data is stored.  On
top of this layer is what we might call a "logical access
interface" that only presents the resolved element tree view,
augmented by knowledge of data entities, something like this:


         Application Layer
          :   A     : A
          :   :     V :
          :   :    Logical Access Interface
          :   :     : A
          V   :     V :
         SGML Parser/Entity Manager
                      : A
                      V :
         Data storage and access


In this model, applications can either interact directly with the SGML
parser and entity manager or interact with the logical access
interface.  The first choice represents traditional "translator"
applications where the application itself performs all document data
handling (e.g., builds its own data structures for holding information
about the document as it's processed).  The other option is a "query
interface", where the knowledge of the document structure and content
is held and managed by the logical access interface as a service for
the application.  This effectively provides a more abstract view of
the document data for the application.  This is the sort of view that
data retrieval systems normally want.  How the creation of this view is
implemented in practice is not important and could be via parsing of
the document instance on demand if the parser is fast enough.

This is a very abstract model and the methods of implementing
it are many and varied.  I'm not sure there's a meaningful
difference between a system where SGML documents are parsed
into a database (without loss of structural data or knowledge
of data entities), from which all subsequent access is done,
and a system where all data access is done against the raw
SGML data itself.  As long as the SGMLness of the data is
preserved such that it can be restored at will, it conforms.
Note that this is different from using "SGML-like" structures
or parsing SGML into a form in which some SGML aspects are
lost, even if the structure is preserved.

For example, the definition of SFQL presented at SGML '92 had no
mechanism for preserving knowledge of NDATA entities within
element content.  Therefore, it fails the test defined above
because there is loss of vital SGML information.  By the same token,
if the validity of the data in an "SGML database" cannot be
determined in exactly the same was as if the data was parsed
normally, the database system fails.

I can see a tremendous utility in the library system Erik
outlined, where a set of SGML access services are provided
that make SGML applications independent of any given SGML
parser or entity manager.  I suspect that the first generally-
available (which may mean free) or well-defined set of functions
will become a defacto standard.  It would be interesting to
see such a library defined as part of OSF/1, for example, or
as part of IBM's SAA architecture for application interfaces.
The DSSSL standard may provide such a definition,
I don't know, or it may provide sufficient definition of
what such a definition would have to provide in terms of
information about SGML documents to enable creation of a
complete design in the abstract.  I would want to see such
an interface defined outside the scope of any implementations,
even if it is provided as part of a vendor product.

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

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