A Reader's Guide to the HyTime Standard

The Editors of ISO/IEC 10744:1992 2nd Edition:
Charles Goldfarb, Information Management Consulting
Steven R. Newcomb, TechnoTeacher Inc.
W. Eliot Kimber, ISOGEN International Corp.
Peter J. Newcomb, TechnoTeacher Inc.

The HyTime standard is a very large document (over 450 pages in printed form [ouch!]). In fact, can be considered to be three separate but related standards bound under one cover. Some 200 of those 450 pages consist of SGML markup that, while important and informative, also serves to bulk up an already large document. Finding your way around in this standard can be a challenge.

As the creators of this formidable document, we the editors want your HyTime learning experience to be a pleasant and rewarding one. We're very proud of this document and want you to get the most value from it you can. To that end, we provide this little guide to reading the HyTime Standard...while we're fond of every one of those 450 pages, we don't want you to read one page more than you need to (and there are a lot of pages you probably won't ever need to read {at least not right away}).

If you are presented with a printed version of the HyTime standard...DON'T PANIC! Of the 450+ pages of the HyTime standard, you will only ever need to actually read, at most, about 250, and of those, only 150 make up HyTime proper, and of those, only about 60 are required reading if you are only interested in hyperlinking. (Which is not to say that there's not lots of interesting stuff in the other 400 pages, just that you don't need to read it all right away, if ever.)

So, before starting on a journey of HyTime exploration, please repeat: "I don't have to read all of this...I don't have to read all of this...I don't have to read all of this..."

This guide helps you find your way around in the HyTime standard, avoid those parts you can avoid, and shows you what you should read first (and why).

Understanding the Language of the Standard

HyTime, ISO/IEC 10744:1992, is a formal standard. That means it's written in a very formal style designed for accuracy of specification, not necessarily ease of understanding. The first thing to realize when reading a standard like HyTime (or SGML, or DSSSL) is that it is highly formal, conforming to a rigid set of guidelines designed to produce clear and unambiguous specification statements. This style avoids repetition and redundancy and therefore constrasts strongly with accessible technical writing (in other words, you need to say things several times, and in several different ways, to ensure comprehension).

This formal style and lack of repetition sometimes make it hard to get the meaning on first read. Expect to read through important bits several times. We've tried to put in cross references wherever needed and point out key dependencies, but you still need to pay close attention to what has been said elsewhere. We've also put in as many explanatory notes as we felt we could get away with in a standard. And most important--if you get stuck on something, post a question to the Internet news group comp.text.sgml--you will get an answer to your question, and you can be sure someone else has the same question.

Remember too that the HyTime standard is very general and therefore highly abstract, to the point that it is not always obvious how the abstractions of HyTime might be applied to the challenges of the moment. Rest assured that the designers of HyTime always had real-world applications in mind and that the path to application can be found. The other papers on this site and elsewhere are provided, in large part, to provide a bridge from the abstract to the concrete. And again, don't hesitate to ask questions or ask for application examples. Once the abstractions of HyTime take hold in your brain, you'll start to see more and more ways they can be applied, but getting your mind around those abstractions can be a challenge (we know, we had to do it ourselves). Remind yourself that HyTime doesn't do anything you're not already doing in one way or another, it just does it with more generality and as an integrated part of a very large, coherent schema.

Like reading Shakespeare, the language of the standard may at first seem strange and impenetrable, but once you've spent some time with the standard, its specialized language and writing style will become more familiar.

The Lay of the Land

The HyTime standard actually defines a number of related but largely independent architectures and facilities. These facilities have been bundled together in one package largely for convenience and timing reasons [It's easier to get one large standard approved than a bunch of little standards. Thus, when you refer to "the HyTime standard", you are referring to a suite of technical specifications that cover a very wide scope of function and possible application.] Within the HyTime standard are the following distinct architectures and facilities:

The HyTime Architecture, which started it all¹. The HyTime Architecture can be further divided into three parts: the base linking and addressing architecture, the scheduling architecture, which is derived from the base architecture, and the rendition architecture, which is an application of the scheduling architecture. If, like most initial users of HyTime, you are interested primarily in linking and addressing, you can focus on that part of HyTime to the exclusion of scheduling and rendition. If you are coming to HyTime from the XML Link specification, you can narrow your focus to just the queryloc element form from the location addressing module and the hylink, clink, and varlink element forms in the hyperlinking module (and you might want to look at some of the stuff in the base module as well, such as bounded object sets).
The General Architecture, which defines a small set of common constructs used by HyTime but applicable to any use of SGML, not just hyperlinking.
The SGML Extended Facilities:
- The Lexical Type Definition Requirements (LTDR), which provide a general mechanism for associating lexical rules with attributes and element content
- The Architectural Form Definition Requirements (AFDR), which define a general mechanism for declaring and using SGML architectures. All the architectures defined in the HyTime standard conform to the AFDR. [Most of the provisions of the AFDR are implemented by James Clark's SP suite of SGML processing tools.]
- The Property Set Definition Requirements (PSDR), which define a general mechanism for defining implementation-independent object schemas. All the "property sets" defined in the HyTime standard conform to the PSDR.
- The Formal System Identifier Definition Requirements (FSIDR), which define a general mechanism for creating "formal system identifiers" for entities.²

In addition to these facilities, the HyTime standard includes formal, machine-readable architectural meta-DTDs, lexical type specifications, and property sets. These are included in the printed document primarily to establish their normative³ status as part of the standard. As these machine-readable files are also available electronically (from the materials area on this site), we don't really expect anyone to read the printed versions of these formal materials, except possibly for reference.

As a document, the HyTime standard is divided into 11 clauses (corresponding to chapters in a normal book) and four annexes (roughly equivalent to appendixes), three of which are normative, one of which is informative. Clause 3 defines all the terms used formally in the standard. Clause 5 explains the formal notation used to define the HyTime architecture. Clauses 6 through 11 define the HyTime architecture proper.

Annex A contains the SGML Extended Facilities and can be treated as an independent document (see below). In addition to the General Architecture and the four facilities described above, Annex A also contains the updated SGML property set (published originally in the DSSSL Standard, ISO/IEC 10179). Again, the SGML property set is printed in the standard to establish its normative role. Property sets are somewhat like the source code of computer programs; they are machine-parsable formalisms that are generally easier for computers to read than for human beings. Because of the difficulty of deciphering the formal text of property sets by eye, we have formatted the various property sets of the standard for human consumption. These rendered versions are are provided at this site in HTML (see listing for property sets on the materials page).

Annex B contains the HyTime property set and HyTime lexical type declarations. This reference material is required reading only for HyTime system implementors and (possibly) by developers of unusually sophisticated and/or specialized applications. If you need to read it, you'll know it.

Annex C contains the full meta-DTDs for the HyTime and General architectures. The bulk of these meta-DTDs is derived directly (and literally) from the formal declarations in the body of the standard. However, the configuration mechanisms used to reflect all the options of these architectures are complex enough that they can't really be understood without having them made explicit. Again, we don't expect anyone to actually read these sections unless they really need to. These meta-DTDs are available from the materials area.

If you have a printed copy of the Standard we recommend that you break it up physically as follows:

Clauses 1 to 8. These clauses comprise the core of HyTime and are usually all you need to have (in addition to the electronic copy of the HyTime meta-DTD) to use and understand the linking and addressing facilities of the HyTime architecture. You may prefer to pull out clause 3, Definitions, for easy reference while reading the other parts.
Clauses 9 and 10. These two clauses define the scheduling and rendition architectures. These are essential if you're doing scheduling and rendition, but not necessary to have on hand if you're not.
Clause 11, conformance, is important but not necessary for handy reference.
Annex A, up to, but not including, the SGML Property Set. Clauses 1 to 6 of Annex A define the SGML Extended Facilities and the General Architecture. You'll need to have these handy for reference in general but they're really a separate specification from the HyTime Architecture, so there is no need to keep them together. If you're doing or implementing complete architecture processing, you'll be referring to the AFDR clause (A.3) regularly.
Annexes B, C, and D. Unless you need to refer to these and happen to like paper better than electrons, you'll never need to look at these, so leave them by themselves.

When you're done cutting up your standard, you'll have three documents, each less than 100 pages, each describing a useful and independent architecture or set of facilities.

First Steps

Now that you've pared the standard down into manageable chunks, it's time to start reading. Most people's natural inclination would be to start at the beginning...DON'T DO IT!

For the best understanding of HyTime, you should read the following parts in the order shown before starting in on the main clauses:

Clause 5, Notation. This short clause explains the notational conventions used in the formal declarations used throughout the standard.
Annex A.3 Architectural Form Definition Requirements. Because HyTime is an architecture, it is difficult to understand the HyTime specification until you understand the formal architecture mechanism in general. You may also find the paper A Tutorial Introduction to SGML Architectures on this site helpful as well.
Clause 3, Definitions. There is no need to read all the definitions in detail, but at least glance through them, looking for terms whose everyday or domain-specific meaning may be different from its HyTime usage (for example, the term "anchor" has a specific meaning in HyTime that is subtly different from its usage elsewhere).

As you get into the clauses, remember that HyTime is highly modular. This means that you can ignore those facilities or forms that you don't think you need--there is no reason to understand or implement all of HyTime before using any of it.

Core HyTime

The base module, clause 6, defines those facilities of the HyTime architecture that are either of a general purpose (with respect to managing hypermedia documents) or needed by all the other modules (as in the case of coordinate addressing).

Hyperlinking requires the ability to address things (point at things, as with an ID reference, URL, etc.), as do scheduling and rendition. The location addressing (locs) module, clause 7, provides all the addressing machinery you might need. There are many ways to do addressing and the locs module covers them all. This makes clause 7 the longest clause because it has the most detail. However, of the total set of location addressing facilities, you can probably start by focusing on name addressing (nmsploc (clause 7.9.3) and nameloc (clause 7.9.5)) and query addressing (queryloc) (clause 7.11). If you are applying HyTime to existing documents that already provide their own linking and addressing syntax, you should also look at the reference location address facility (clause 7.8), which makes it possible to define to a HyTime engine what your documents already do (although it sometimes requires a bit of cleverness and indirection to do so).

The hyperlinking module (clause 8) is the smallest because the syntactic representation of hyperlinks is comparatively straightforward. The core element form here is the "hylink" (hyperlink) form. The forms clink and agglink are derived from the hylink form and simply provide hylink configurations that represent common practice. The varlink form provides an alternative syntax for addressing anchors (subelements instead of attributes, as for hylink and the forms derived from it). The ilink form provides yet another anchor addressing syntax (a single attribute rather than one for each anchor) and was the original "independent link" form defined in the first edition of the Standard. All the hyperlinking form have the same basic link representation semantics and differ largely in their syntax. In particular, all the three indendent link forms hylink, varlink, and ilink can be used to represent arbitrary relationship types and any link using one of the three forms can be transformed into the syntax of either of the other two without changing the meaning of the link.

The hyperlinking module only defines the syntax and semantics of hyperlink representation in documents. The HyTime property set (in Annex B) defines the abstract object model by which the semantics of HyTime-defined hyperlink processing can be represented by processing programs. If you're building hyperlinking software, you should study the HyTime property set in addition to the linking and location addressing modules.

These three clauses make up the core of the HyTime architecture. If you're not doing more sophisticated hypermedia presentations, you can stop here.

Hypermedia: Scheduling and Rendition

The scheduling module of HyTime defines an architecture for the abstract representation of arbitrarily complex hypermedia structures, including music, interactive presentations, multi-track sequences, and so on. Its basic mechanism is a simple one: the sequencing of object containers along axes measured in temporal or spatial units. Like hyperlinking, while the basic model is simple, there are many facets to its implementation and many subtleties to its design. Because hypermedia presentations can be very complex, the scheduling module must provide facilities to deal with those complexities. When reading the scheduling module, focus on the core ideas first and come to understand those before trying to add in the rest. In particular, don't worry about the details of defining measurement units and dimension referencing before you develop an understanding of scheduling in general.

The rendition module is essentially an application of scheduling that defines a general mechanism for defining the creation of new schedules from existing schedules by applying "rendition rules" of various sorts. Again, the basic idea is a simple one, familiar to anyone who has ever performed a piece of music, but this simplicity can get lost in the details. One of the challenges in reading the rendition module is keeping up with the all the qualifications needed to make it completely clear what things apply to what contexts. Because rendition deals with the results of processing in addition to the original data being processed there is lots of verbiage to distinguish different contexts. Don't let this extra verbiage slow you down. Once you understand the contexts well enough to understand the purpose and meaning of the verbiage, you'll be well on your way to understanding rendition.

Finally, keep in mind that the scheduling module can be used quite productively without the rendition module. While the rendition module defines a standard way of representing rendition, it is likely that most systems that support scheduling will provide their own optimized and non-standard rendition mechanisms, at least in the near future. For example, you might expect to have systems that take HyTime event schedules and "compile" them into executable forms such as Macromedia Director or MIDI or some such. Therefore, don't feel that you must understand rendition in order to understand or use scheduling--you don't.