[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.]
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">
<!NOTATION HyExSpec PUBLIC "ISO/IEC 10744:1997//NOTATION
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>
<measure smu=virSpace>
<granule gn=vsu>1 1 virSpace</granule>
<granule gn=pixel>1 1 vsu</granule>
</measure>
<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">
<event-extents>
<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 --
</event-extents>
<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>
</evgrp>
-- Other event groups go here --
</evsched>
</fcs>
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.
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> <measure smu=virSpace> <granule gn=vsu>1 1 virSpace</granule> <granule gn=pixel>1 1 vsu</granule> </measure>
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">
<!NOTATION HyGrand PUBLIC "ISO/IEC 10744:1997//NOTATION
HyTime Granule Definition Notation//EN">
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>
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:
axes attribute
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.
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.
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.
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.