[This local archive copy is from the official and canonical URL, http://www.personal.u-net.com/~sgml/schedule.htm, 1999-01-29; please refer to the canonical source document if possible.]

Using HyTime for Scheduling Events

Martin Bryan, The SGML Centre

This paper summaries the event scheduling facilities provided in Clause 9 of ISO 10744, the Hypermedia/Time-based Structuring Language (HyTime) and illustrates how these facilities can be used in an XML environment.

Note: This paper has been prepared as an informative white paper for the AICI discussion on the relationship between MPEG-4, VRML, HTML and XML.


The HyTime scheduling module allows a set of information objects to be associated with an event that takes place within a finite coordinate space (fcs). Events have scheduled extents within the coordinate space. Multiple event schedules (evsched) can be defined within a single coordinate space. Events can be grouped within event groups (evgrp) within each schedule.

A HyTime finite coordinate space can have any number of dimensions, including one or more time-based dimensions. The coordinate space is defined in terms of a set of uniquely named axes. Each axis can be used to position a finite number of measurement granules. Measurement granules are defined with reference to measurement domains which have standard measurement units (SMUs) that are identified using notation declarations. A default set of measurement granules and related notations are provided in the standard that allow meaurements to be defined in terms of either SI units or virtual units. Users can define their own sets of measurement granules if this starter set is not sufficient.

For example, a simple video presentation may require axes that are called X-position, Y-position and Time, where X and Y are measured in terms of scan-lines or pixels while time is measured in terms of PC refresh rates or frames at the relevant transmission rate. The start of such a simple presentation could be defined, using XML constructs, as:

<!-- This example presumes that the following notations are declared in the
     relevant XML document type declaration:
     <!NOTATION virSpace PUBLIC "ISO/IEC 10744:1997//NOTATION
                                 Virtual Measurement Unit//EN">
     <!NOTATION SIsecond PUBLIC "ISO/IEC 10744:1997//NOTATION
                                 System International second//EN">
                                 HyTime Dimension Specification Notation//EN">
     and that the XML element names match those used in
     ISO/IEC 10744 to defined the HyTime Architectural Forms used for
     the Scheduling module (except that event-extents is a secondary
     instantiation of the event element form).
<measure smu=SIsecond>
   <granule gn=second>1 1 SIsecond</granule>
   <granule gn=PAL-frame>1 25 second</granule>
<measure smu=virSpace>
   <granule gn=vsu>1 1 virSpace</granule>
   <granule gn=pixel>1 1 vsu</granule>
<fcs axes="X-position virSpace Y-position virSpace Time SIsecond"
     X-position="800 pixel"
     Y-position="600 pixel"
     Time="75000 PAL-frame">
  <evsched axisord="X-position Y-position Time">
      <extent id="full-width" notation="HyExSpec">1 800</extent>
      <extent id="3-4-depth" notation="HyExSpec">1 450</extent>
      <extent id="bottom-quarter" notation="HyExSpec">451 600</extent>
      <extent id="clip1" notation="HyExSpec">1 2500</extent>
      <extent id="null" notation="HyExSpec">0 0</extent>
      -- Other extents go here --
    <evgrp id="title-credits">
      <event exspec="full-width 3-4-depth clip1" object="video1">
       Clip 1: Opening Credits</event>
      <event exspec="full-width bottom-quarter clip1" object="video2">
       Clip 1: Scrolling image of Bayeux Tapestry</event>
      <event exspec="null null clip1" object="audio1">
       Clip 1: Title music</event>
    -- Other event groups go here --

For more complex productions, such as a play, multiple co-ordinate spaces may be needed with many different dimensions. For example, there may be three sets of co-ordinate spaces, covering stage, pit and wings, with multiple time lines defining such diverse sequences as yearly calenders of performances, weekly listings of performance times, virtual timings for each act, virtual times for each piece of music performed by the orchestra, actual timings for pre-recorded music or picture sequence, etc.

The order in which items are defined is not controlled by the HyTime standard. For example, the extent of each event could be defined as a sub-element of the event if required, while the measurement granules could be in a separate file that is simply referenced at the start of each presentation using that set of granules. HyTime relies on the use of unique identifier (id) attributes, identifier referenes (idrefs), and predefined lexical references, such as the axis names used to automatically associate extents with axes, to allow objects to be created in a non-hierarchical fashion.

Measurement of Finite Coordinate Spaces

HyTime requires that all axes of coordinate spaces have a finite length, defined in terms of a predefined number of measurement granules of specified length. Axes are not numbered: their measurement granues are counted from start to finish or from finish to start. A negative number indicates a count starting from the end of the axis; a positive number indicates a count starting from the beginning of an axis. The axes making up a finite coordinate space have as a single common point the start of their first measurement granule.

Each axis must have associated with it a measurement domain definition which establishes a set of base granules that have been defined as a ratio to a reference granule that is specified in terms of a standard measurement unit (SMU) defined as the domain SMU for the measurement domain. To allow for more efficient processing developers are also allowed to define HyTime Measurement Units (HMU) that define a ratio of a measurment granule as a referenceable measurement unit. For example, a base granule of points could be defined, based on a reference granule defined as a subset of the SI metre, while the HMU used for measuring a particular distance could be defined as an em (12 points) or a tenth of a point, depending on the granularity required for processing the associated data.

Not all measurement can be absolute. For example, prior to recording, music is expressed in virtual time using beats such as 3/4, 4/4, etc. Space can also be virtual, as is seen by the difference between displaying a 800 by 600 pixel image on a 10" diameter portable or a 21" PC monitor. HyTime provides for both virtual time and space measurement, and also provides a generic quantum that can be used for measuring virtually any measurable unit, including things like currencies and positions in database tables.

The HyTime standard defines a set of granules based on subdivisions or multiples of the SI second and metre. Time measurements range in size from millenium down to the sort of very small units used in nuclear physics. They include as set of measurements specifically aimed at multimedia presentations, which include all the most common film, video and television frame rates, including those defined by SMPTE which drop certain frames to allow for synchronization. The standard also includes a number of "generic" timings, such as motion-picture (24 frames per second) and European (25 frames per second, which applies to both PAL and SECAM broadcasts, as opposed to the 30 frames per second rate used for NTSC broadcasts in America).

On the measurement front the default set of measurements includes all the standard metric units, the imperial inch and many units based on this, including picas and points (defined using the common, if incorrect, definition of 1/6th and 1/72nd of an inch used by most computer systems).

Note: Care must be taken to ensure that the set of measurement granules associated with a particular SMU have a common denominator within the range of the system. Unless otherwise specified a 32-bit counting system is presumed. If the ratio of the largest granule to the smallest granule using a specific SMU is greater than 232 the HyTime processor should report an error unless a larger size has been assigned for counting granules.

For each of the standard measurement units that are used as the basis for reference granules the system needs a formal notation declaration that can be used to link the axis definition to the parts of the processing program that understands that unit of measurement. A default set of notation declarations is provided in the standard for each of the Systeme International (SI) measurement units, for virtual space and time and for the generic quantum (the virtual units all sharing the same processing module.

When the elements used to define architectural forms are given the same names as their architectural forms measurement definitions will have the form:

<measure smu=SIsecond>
   <granule gn=second>1 1 SIsecond</granule>
   <granule gn=PAL-frame>1 25 second</granule>
<measure smu=virSpace>
   <granule gn=vsu>1 1 virSpace</granule>
   <granule gn=pixel>1 1 vsu</granule>

The formal XML definition for these elements in the associated DTD is likey to be:

<!ELEMENT measure  (granule+)>
<!ATTLIST measure  HyTime NAME   #FIXED    "measure"
                   smu    NAME   #REQUIRED>
<--Note: The NAME associated with the smu attribute of a measure element
         must be that assigned to a notation declaration in the current DTD.-->

<!ELEMENT granule  (#PCDATA)>
<!ATTLIST granule  HyTime NAME   #FIXED    "granule"
                   gn     CDATA  #REQUIRED
                   gdnot  NAME   #FIXED    "HyGrand">
                            HyTime Granule Definition Notation//EN">

Calendar measurements

HyTime includes a special notation for defining spaces in terms of calendar events. This HyTime Calendar Specification Notation (HyCalSpc) allows axes to be defined by reference to dates (UTC or Julian) and/or time (GMT or UTC related, with optional time zone offset). Dates can be assigned to specific eras (e.g. BC, AD, BP).

A special calendar specification (calspec) element type is provided to allow coordinate locations to be defined in terms of calendar dates, which are converted to the relevant measurement quanta using a special HyTime calendar marker function notation (HyCalFun). The UTC date format is ISO 8601 compliant (year, month, day, hour, minute, second).

A typical calendar location would take the form:

<calspec id="date-sent" GMTorUTC="GMT">199904121044+0100</calspec>

Definition of Finite Coordinate Spaces

For most applications a single finite coordinate space is all that will need to be defined. The fcs element used to define the space will often be the container of the event schedules that are to be used to control the sequence of a set of releted events, together with any object modifiers used to manage the presentation of one or more of the referenced event objects. Alternatively the fcs element can be given a unique identifier (id) attribute which event schedules can reference to indicate which space they apply to.

Note: This paper does not address the specification and use of HyTime object modifiers.

The axes attribute of the element defining the finite coordinate space identifies the names of attributes of the same element that define the set of axes required. Each attribute name is immediately followed by the name of the standard measurement unit to be used to measure that axis.

For each axis there must be an attribute of the name assigned in the axes attribute. The value of this attribute must consist of a number indicating the maximum count that can be made along that axis. Optionally this can be followed by the name of the required measurement granule.

Where the same SMU applies to a number of axes the definition of the axis should identify common denominator known as a measurement domain unit (MDU), and define the ratio of the selected granule to this MDU. For example, if you were trying to mix measurements in inches with those in millimetres you would need to define the axes along the following lines:

<!ELEMENT fcs (evsched+)>
<!ATTLIST fcs HyTime     CDATA  #FIXED  "fcs"
              axes       CDATA  #FIXED  "width SImetre depth SImetre"
              width      CDATA  #FIXED  "20 inch #MDU 25400 1 um"
              depth      CDATA  #FIXED  "200 mm  #MDU  1000 1 um"     >

Note that the above example shows all the axes of the finite coordinate space being defined as fixed attributes of the DTD. In such cases they do not need to appear as part of the event schedule specficiation, as shown in the initial example, but can be referenced in the schedule by entry of a simple <fcs> markup tag. This will be the more normal use of this element of the schedule definition.

Axes can be calibrated by reference to external contexts using an optional calibrat attribute. The value assigned to this attribute must be one or more triples consisting of:

Each of the attributes identified by the calibrat attribute as defining the calibration required contains a counter that identifies which measurement quantum on the axis the calibration is to start from, or end at, and a reference to the relevant alignment point in the notation used to manage the calibration. Optionally the first counter can be preceded by the name of the measurement granule used to express this position.

A typical use of the calibrat attribute is to associate a calendar period with an axis. A typical example might be:

<!ELEMENT fcs (evsched+)>
<!ATTLIST fcs HyTime     CDATA  #FIXED  "fcs"
              axes       CDATA  #FIXED  "X-position SImetre
                                         Y-position SImetre
                                         Time       SIsecond"
              calibrat   CDATA  #FIXED  "Time startdate HyCalSpc"
              startdate  CDATA  #FIXED  "day 14 STARTS #ORDER SGMLCASE 1999-04-12">

This example tells the system that the 14th day unit in the coordinate space is deemed to start on the 12th April 1999.

Note: The #ORDER SGMLCASE statement simply tells the HyTime engine processing this instruction that the preceding keyword can be in any case.

Defining Event Schedules

Event schedule (evsched) type elements are used to define a list events that are to take place within a given finite coordinate space. More than one event schedule can be assigned to a coordinate space, each containing multiple events. By default events within a schedule and multiple schedules can overlap each other.

Event schedules are either sub-elements within a finite coordinate space element or refernce the relevant coordinate space through a fcs attribute whose value matches the unique identifier assigned to the element used to define the space.

Event schedules can use any or all of the axes associated with the relevant space to control the relative positioning of events. The axis order (axisord) attribute can be used to specify which axes will be used and which order axis extents will be specified in. If no value is assigned to this attribute all of the axes defined by the axes attribute of the associated finite coordinate space must be specified in the order they have been listed in the attribute value for the axes attribute.

Where an event is being applied over multiple extents the sorted attribute can be used to indicate whether the events will defined in a sorted order. Unless otherwise stated it is presumed that the order in which extents are defined does not need to be sorted so that earlier extents always precede later ones.

If gaps are not to be premitted between scheduled events the value for the coverage attribute can be changed from its default value of sparse to solid.

If events within a particular event schedule are not to be allowed to overlap each other the value of the overlap attribute can be set to noverlap.

An event schedule contains definitions for one or more events or event groups. Event groups contain either events or event groups. Event groups always define contiguous sets of events. Groups can be assigned specific extents or can derive their extents from the sum of the extents of their contents.

Defining events

An event associates a presentable object with a particular extent within a finite coordinate space. The object to be associated with the event can be identified using any of the many methods of referencing objects defined in the HyTime standard, including:

If no object is identified the contents of the event element are taken to be the object to be presented.

Note: Referenced objects can be in any notation. Attributes, including data attributes associated with entity declarations, can be used to unambiguously identify the data format of the referenced object.

The nominal extent specification (exspec) attribute is used to define the part of the finite coordinate space the referenced object is to be presented in. The value of this attribute is an ordered sequence of references to the unique identifiers of scheduled extent (extent) elements, which may or may not be embedded within the current event specification.

The alignment of the object with respect to the extent specification can be contolled using the optional object alignment rule (align) attribute. This attribute is defined in terms of pairs of values consisting of an axis name followed by one of the keywords #LEFT, #RIGHT or #CENTER to indicate whether the first, last or median quanta of the object are to be aligned with the associated axis.

Note: An alternative method is also provided to allow users to define the alignment position in terms of a locally meaningful notation. The specifications are handled using the same mechanism employed to calibrate axes using the calibrat attribute.

Scheduled extents

Extents can be specified as part of an event or as a resuable HyTime component shared by multiple events. They are defined using scheduled extent (extent) type elements which contain dimension lists or other forms of HyTime dimension specifications. By default the contents of extent specifications are interpreted using a special HyTime Dimension Specficiation Notation (HyExSpec).

A simple dimension specification consist of two counts, the first identifying the start of the extent and the second the end of the count. If either number is negative the point being counted from is the end of the axis rather than its start. A dimension list can identify non-contiguous sets of measurements by listing more than pair of values for each of the axes associated with the enclosing event schedule.

Note: This paper does not contain a full explanation of HyTime's options for specifying dimensions.

Alternatively a scheduled extent list (extlist) element can be used to define a set of extents (including nested extent lists) that are to be used to define the extents over which the associated object is to be presented.