E.1.2 HyTime, architectures and groves

As noted above, in Appendix E.1.1, this DTD is an application of the HyTime standard.

The HyTime standard [iso10744] specifies three things, which are distinct, but easily confused (the standards document is not an easy read - not because it is unclear, but because it is so very abstract; there are unfortunately few accessible alternatives). It defines a standard processing model for SGML documents in terms of the `grove'; it extends the SGML standard by introducing the notion of `architectures'; and it specifies a particular architecture - the HyTime architecture - for abstracting the semantics of document links.

A `grove' is an acyclic directed labelled graph (I think!) - alternatively defined, even in the HyTime standard, as `a bunch of trees and other stuff' - which is the data structure into which an SGML document is nominally transformed, and with respect to which the semantics of SGML standards (SGML itself, HyTime, DSSSL and others) are now formally defined. DSSSL is designed to be able to query the grove straightforwardly and efficiently, but unless you are maintaining the more recondite parts of the DSSSL sources, which query a few grove properties directly, you will not need to be aware of anything more than the grove's formal existence. The grove is formally defined in ISO/IEC 10179, clause A.4: there are introductions and tutorials on the relevant Oasis special topic list, of which Paul Prescod's tutorial [prescod99] is particularly good, and Kimber has written variously on this [kimber97c].

An `architecture' is a skeleton DTD (the HyTime first edition name for it was `meta-DTD'). An individual DTD may declare itself to be a `client' of the architecture by asserting the fact, and defining (or allowing to be defaulted) a mapping between the element forms it defines, and those defined in the architecture (the architectural elements are referred to as `architectural forms' in that context). For example, the Starlink General DTD declares itself to be a client of the DocumentSummary DTD (which is easy, because the elements defined in the latter are a subset of the elements defined in the former), and the DSSSL programcode DTD declares itself to be a client of the DSSSL architecture, with suitable remappings of element and attribute names (see Section 5.2.2 for discussion, and see the reference cited there). For formal details see the HyTime standard, particularly clause A.3, Architectural forms declaration requirement. The relevant Oasis special topic has an overwhelming number of references on this, of which Kimber's article [kimber97b] is very good.

Finally, the HyTime standard defines a particular architecture - the so-called HyTime Architecture. This architecture defines forms (ie, elements in a meta-DTD) suitable for expressing all kinds of linking semantics, from a simple link from one part of a document to another, all the way up to indirect many-to-many links between fragments of non-SGML media (for example sections of an image or passages in a piece of music). Crucially, it defines the semantics of these forms formally and precisely.

As a consequence a DTD can declare itself to be a client of (some subset of) the HyTime architecture, formally associate elements it defines with the available architectural forms, and thus inherit the precise semantics and associated documentation. The point of this is twofold. Firstly, it means that the DTD inherits the documentation of the forms it has referred to. A reader of the DTD, who is familiar with HyTime, can therefore look at a declaration and immediately know what its intended meaning is. Secondly, that reader of the DTD need not be human: a `HyTime engine' is a processor which can interpret the HyTime forms in a document and process them correctly without further configuration.

For example, the Panorama SGML viewer is an application, which is also available as a Netscape plug-in, which will display SGML. When it displays SGML, it formats it appropriately, guided by a style-sheet which expresses things like what font to display headings in. It also, however, has built-in knowledge about the HyTime clink element (`contextual link'), and knows what to do with it. If the viewer is given a document and DTD which has properly declared itself as a HyTime client, such as the Starlink General DTD, then Panorama can format and follow <ref> elements (for example) immediately.

The webref element in the Starlink General DTD is declared much as follows (compare [iso10744], clause 7.8)

<!ELEMENT WEBREF - - (#PCDATA)>
<!ATTLIST WEBREF
    url      CDATA #REQUIRED
    -- HyTime attributes... --
    HyTime   NAME  #FIXED clink
    HyNames  CDATA #FIXED "linkend url"
    anchcstr NAMES #FIXED "self required"
    linktrav NAMES #FIXED "A D"
    loctype  CDATA #FIXED "url QUERYLOC URL"
    >

If you're curious, you can obtain the HyTime view of a document with the command sgmlnorm -A hytime ssn70.sgml.[Note 12]

The linking elements in the Starlink General DTD have been defined in terms of HyTime. This is partly for documentation purposes, partly for completeness, but mostly so that the groundwork will have been done when there is an opportunity to use a HyTime-aware application such as Panorama. I will claim this as a full implementation, however: I have no access to a HyTime engine, and so I cannot test that the HyTime declarations here are in fact correct.

See Appendix E.6 for online resources.