🚀 go-pugleaf

(Please excuse the title, it must be the heat in Berlin.)

A few weeks ago there I started an interchange between Erik Naggum
(and other comp.text.sgml celebrities) and me about the utility of
SGML as an information modelling language.  In this discussion I
touched on my being unsatisfied with the way SGML was used (could be
used) to represent the ideas of HyTime.  I never followed up to that.

Unfortunately, I'm running off to the DSSSL SWG that is taking place
in Germany next week, so I will not be able to take part in any
ensuing discussion for another week or so.  Nonetheless, I thought the
following rough sketch of a paper might be useful to revive the
previous discussion.

The paper explicitly aims at generating ideas that might be useful for
the revision of SGML or any followup SGML extension process.
It does not aim to expose shortcomings of HyTime that cannot be
attributed to shortcomings of SGML (I may want to write another
article later about such issues as the unexploited relationship
between Hypertext links and SGML hierarchical relationships).

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

          Problems with representing HyTime in SGML: A plea
                              for SGML++

                           Carsten Bormann

                    Technische Universitaet Berlin

This short article is a reply to various requests I received to sub-
stantiate my claim that "SGML reluctantly tolerates, instead of sup-
ports" HyTime.

As in my previous articles, my intent is not to show that HyTime is a
substandard design or that Hypertext should not be married with SGML;
instead, my intent is to point out some shortcomings SGML currently
has as a substrate for standards such as HyTime, and thus (indirectly)
to point out some potential future developments that might benefit
SGML and its users.

By the way (since this article cites the German comments on the HyTime
CD), Germany finally voted NO on the HyTime DIS only because two small
editorial changes were deemed essential; fulfilling these change
requests converts the German vote to a YES vote.

1.  SGML is missing a meta-class or super-class mechanism
-   ---- -- ------- - ---- ----- -- ----- ----- ---------

The concept of architectural forms introduced in the HyTime draft
standard provides a way to represent the ancestry (in the inheritance
hierarchy) of an element by means of an attribute with a name defined
in the HyTime draft standard (which also can be changed by a HyTime
declaration).  Element types can be qualified as to their ancestries
by making use of #FIXED attributes.

However, the semantics of architectural forms do not form a part of
SGML yet, i.e., it is left to the application to ascertain the syntac-
tic correctness of the documents.  As there is no standard that
develops architectural forms to a general concept, it is quite likely
that different HyTime-like standards for other application domains
will interpret the concept differently, which is one reason that makes
it hard to integrate support for architectural forms into an SGML
parser product.  Possibly even worse, there is no formal language for
representing the architectural form level equivalent of a DTD (much of
the "formal" part of HyTime lives in comments, making it inaccessible
to SGML-based tools).

The difference between meta- and super-classes is not clearly taken
care of: Architectural forms are more like super-classes, in that they
describe minimum requirements on the actual elements (really: on the
element structure information set, ESIS, resulting from both the
information in the parsed document proper and from the DTD), but they
also have some meta-class semantics, in that certain attributes and
their values are mandated (hence the term "HyTime element type").
However, there is no super-content-model, i.e. HyTime does not make
any mandates on DTDs; as a result, the only interesting statement that
can be made about a DTD is that it allows both HyTime-conforming and
non-HyTime-conforming documents (there also are DTDs that only allow
non-HyTime-conforming documents, while it will be hard to construct a
useful DTD that only allows HyTime-conforming documents).

2.  Missing Attribute Structures in SGML
-   ------- --------- ---------- -- ----

Another problem is illustrated by the following comment that Germany
made on the HyTime CD.  While the problems cited in the comment have
been resolved by moving some of the information from attributes to
elements, the current solution continues to highlight the strange
relationship between attributes and elements.

          As generally known, SGML currently does not provide a
          mechanism for expressing non-trivial attribute structures.
          Therefore, non-trivial attribute structures must either be
          modeled by means of element structures (thus, the useful
          distinction between objects and attributes is lost) or by a
          set of seemingly unrelated attributes which are solely cou-
          pled by means of the English descriptive text.  A simple
          structuring mechanism (like the one provided by ASN.1) could
          significantly improve the consiseness and clarity of HyTime.

          Examples for this kind of problem:

          a)   The set of isolated attributes defined for ``ilink'' is
               not at all appropriate for expressing the intended
               semantics (see also comment #1 e)).  The same informa-
               tion could be expressed simply by means of the subse-
               quent (ASN.1-like) structure:

               ilink-att ::=	SEQUENCE OF SEQUENCE {
                  name		   CDATA,
                  role		   BIT STRING {endtrav (0), endretrn (1), endacc (2)},
                  linkend	   IDREF,
                  endterm	   IDREF OPTIONAL }

               In other words, the attribute of ``ilink'' must provide
               a specification of the characteristics of each link end
               - containing

               -    a name,

               -    a specification of whether the link end can be
                    used as starting point, as return point or whether
                    direct access is used (three booleans),

               -    an optional term for the user interface (why does
                    this have to be an IDREF?),

               -    the reference to the corresponding location
                    address.

          b)   The definition of ``fcs'' has similar problems.  An
               adequate (slightly simplified) structure may be (again,
               in an ASN.1-like notation):

               Fcs-Att ::=	SEQUENCE {
                  hytime	   ...,
                  id		   ...,
                  fcs-spec	   Fcs-Spec }

               Fcs-Spec ::=	SEQUENCE OF Axis-Spec

               Axis-Spec ::=	SEQUENCE {
                  name		   CDATA,
                  unit		   INTEGER {gquantum (0), SIsecond (1), SImeter (2),
               	                   virtime (3), virspace (4) },
                  smu2fcsu	   SEQUENCE {
                     nom	      INTEGER,
                     denom	      INTEGER },
                  axisdims	   INTEGER }

               The modified attribute structure proposed here would
               also avoid the necessity of having to invent
               application-specific attributes in order to replace the
               meta attributes ``linkend1'' and ``linkend2'' (for
               ``ilink'') and ``virtime'' and ``SImeter'' (for
               ``fcs'').

          c)   Because of the missing attribute structure a number of
               HyTime concepts are specified as elements which semant-
               ically are (parts of) attributes, e.g. default value
               lists or location addresses.

          d)   The HyTime specifications make excessive use of IDREFs
               without being able to specify (in the SGML syntax) the
               type of the element that is being referred to.

     The ability to define lextypes for an attribute is only part of
     the solution, as these lextypes do not define the structure of
     the attribute, only the permissible representations.

     3.  Other issues
     -   ----- ------

     3.1.  The CLINK problem
     - -   --- ----- -------

     In many cases, a DTD can be extended by HyTime-specific element
     types.  A particular problem with the way SGML uses content
     models is that a content model can only be coupled to a GI (ele-
     ment name), not to its role within a context.  As a result, it is
     not possible to add a generalized CLINK element to a DTD,
     instead, many different GIs must be invented in order to be able
     to maintain the content model relationships.  E.g. (this is a
     trivialized example):

             <!ELEMENT chapter - o (p*, section*)>
             <!ELEMENT section - o (p*, subsection*)>
             <!ELEMENT subsection - o (p*, subsubsection*)>

     becomes:

             <!ELEMENT chapter - o (p*, (section|sectionclink)*)>
             <!ELEMENT sectionclink - o (section)>
             <!ELEMENT section - o (p*, (subsection|subsectionclink)*)>
             <!ELEMENT subsectionclink - o (subsection)>
             <!ELEMENT subsection - o (p*, (subsubsection|subsubsectionclink)*)>
             <!ELEMENT subsubsectionclink - o (subsubsection)>

     Of course, HyTime also allows for ILINKs, so this problem can be
     circumvented.

     3.2.  IDREF and ENTITY typing
     - -   ----- --- ------ ------

     As noted in the German comments cited above, SGML does not allow
     to qualify IDREF attributes with the type -- element type or
     architectural form type(s) -- of the element that is to be refer-
     enced.

     A similar problem exists ENTITY attributes.  Here, an additional
     problem surfaces: Entities can only be qualified by their nota-
     tion (i.e. their intrinsic data type), not by a "type" within a
     document.  (This is comparable to a situation where all elements
     with #PCDATA content were of the same "type" within SGML.)

     4.  Conclusion
     -   ----------

     HyTime invents a restricted form of SGML++ that is just OK for
     representing the specific requirements of HyTime.  A HyTime
     implementation must extend the SGML parser not only by HyTime-
     specific functionality, but also by that part of SGML++ func-
     tionality required by HyTime.

     Other domain-specific standards will have to invent other SGML++
     features, and are likely do so in a way that will be mutually
     incompatible. In particular, standards derived from HyTime
     (HyTime refinements, such as SMDL), are likely to require similar
             -----------
     mechanisms, possibly with extensions from those defined in
     HyTime.

     In summary, the depth of standardization offered by SGML-1986 is
     not sufficient to cope with the more advanced hierarchies of SGML
     applications being developed today.  This deficiency does not
     render SGML ineffective, but it certainly reduces SGML's utility
     as a substrate for such applications and therefore should receive
     significant attention in the development of extensions for future
     versions of the standard.

                            August 8, 1992