Jacco van Ossenbruggen
Hypertext systems ended the linear structure of previous text systems by allowing readers to choose between several paths through the document. We call the situation in which a user can escape from the linear structure --- by hypertext traversal --- and manually select the next component to be displayed, a choice. In hypertext, support for hyperlinks is sufficient to provide choices, but this is generally not the case in hypermedia.
In multimedia presentations, there is typically a linear flow of information: despite the fact that several media streams can be active at the same time, all media objects contained in the presentation will eventually be played if the presentation is played from the beginning. As many other models, the AHM[1] models the linear structure containing multiple flows of media stream by a hierarchical structure with the atomic media objects as the leaf nodes of the tree, and temporal composites as the other nodes. Applications can identify subtypes of temporal composition: SMIL, for example, has parallel and sequential composites.
The mere addition of hyperlinks to multimedia does not change this linear character of the presentation. It only provides a more convenient way of jumping to a particular position when compared to traditional VCR-based interaction styles (e.g. fast-forward, rewind etc). To achieve true hypermedia, optional media objects (or even complete presentations), which are not part of the main, linear flow have to be included in the document. These optional components are not played unless explicitly selected by means of hyperlink traversal. Since parallel and sequential composites only allow for media content within the main flow, the AHM introduces atemporal composition. SMIL 1.0 does not support atemporal composition. In GRiNS this is implemented by the choice node. A choice node may have several children, but only one of them is played a time. A child of a choice is generally played as a direct result of the activation of a link to that component.
In early hypertexts, the scope of a link was usually the complete source and destination of the link. On link traversal, the source of the link was removed completely and replaced by the destination. Even HTML used this scheme until the concept of frames was introduced. While frames work reasonably well for simple hypertext documents, they do not suffice for more complex hypermedia documents. In such documents, a author should have full control over the scope and effect of hyperlink traversal. Especially, an author must be able to specify which media objects of the currently running presentation are to be stopped, paused or allowed to continue, and which part of the destination presentation will be played. Note that the destination may contain multiple choices as well, so just providing a start time as an offset from the beginning of the destination presentation is not sufficient. Both the scope of source and destination might be (and frequently are) different from the source and destination anchor of the link.
In practice, link scope is not as difficult as it might appear. Experiences of authors working with the GRiNS authoring environment suggest that even in complex presentations, source and destination scope of a link can usually be defined as a subtree in the parallel/sequential/choice hierarchy. This observation simplifies the link model which supports explicit link scope, as well as applications implementing the model and the authoring work required to indicate the scope of every link. Furthermore, the GRiNS work suggests a good default for a link's scope can be obtained by locating the first parent (of the anchor) which itself is the child of a choice composite. See [2,3] for details.
To accommodate for platforms with different media capabilities, alternatives for media objects may be included into a single document. E.g. a document may supply both an image and a text version of the information represented by a video. We call this an alternate composite. The alternate is called a switch in SMIL. Although they might appear to be similar to choices, the two composites have different aims: where choices provides for user selectable alternatives providing optional information not included in the main flow of the presentation, alternates provide alternatives to deal with differences in the multimedia capabilities of the user's platform. While a system is free to implement both constructs by the same primitives, we think it crucial to discriminate between choices and alternates in the document model presented to the author.
$Id: choice.html,v 1.1 2001/02/21 19:28:36 lynda Exp $