9 Scheduling module

9.5 Event schedule

Subclauses:

The element form event schedule (evsched) is a list of events, each having a dimension on all axes of the coordinate space.

Syntactically contiguous events can occur in "event groups" so that common properties can be associated with them.

There can be more than one event schedule in a coordinate space, and multiple events can potentially exist in the same position, whether in the same or different schedules.

NOTE 282 An application must determine whether multiple events can validly exist in the same position, and the significance of their doing so.

HyTime implies no inherent relationship among event schedules, other than the fact that event schedules that are contained by or refer to the same fcs element exist within the same FCS. Also, when the projection facility is used, batons and baton rules can relate schedules for projection, and wands and wand rules can relate schedules for object modification.

NOTE 283 Other relationships can be defined by applications through the use of element types, attributes, hierarchy, and hyperlinks.

NOTE 284 An application can define several types of event schedule. For example, it could allow different kinds of multimedia event to be intermixed in a generalized "multimedia schedule", or it could define specialized schedules that are limited to particular event types. An example of a specialized type could be a "storyboard" schedule whose elements are pictures with a specified duration in virtual time, separated by "dissolve" elements of various types, also with durations.

                       <!-- Event Schedule -->
<![ %sched; [
<!element
   evsched        -- Event schedule --
                  -- Clause: 9.5 --
   - O
   (event|evgrp)*

-- Attributes [sched]: sched --
-- OptionalAttributes [sched]: pulsemap --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [sched]: dimref:elemspec, dimref:schdspec,
   pdimref:prjtarg, pulsemap:pulsemap, rfcsloc:prjsrc --
-- Referrers [rend]: batrule:scheds, batrule:targschd, modrule:events,
   prorule:sources, prorule:targschd, wandrule:evscheds --
>
]]><!-- sched -->

9.5.1 Scheduled Event

An object has no inherent position in a coordinate space. It is given one by placing it in an "event" (like placing a picture in a frame), which has a dimension on each axis. The set of dimensions is the "scheduled extent" of the event, and it can be said that the event schedules its object by framing it within its scheduled extent.

The element form scheduled event (event) represents the occurrence of an object within an event schedule. Its extent specification specifies the nominal position and size of that occurrence.

NOTE 285 Due to the nature of some objects, and because of the effect of style sheets and/or the rendering conventions inherent in applications, the extents of the events that schedule objects are not necessarily the same as the extents of the objects as actually rendered. For example, the actual extent occupied by an object may be smaller along some axes, and larger on others, and it may be accurately describable only in terms of many extents which altogether comprise exactly those quanta, along each axis, in which the rendered object appears. This is why it is said that the scheduled extent is "nominal".

The attribute event objects (object) is used to designate the object(s) to be scheduled by the event. If left unspecified, the event is its own object.

The attribute object alignment rule (align) specifies how the object is to be aligned with respect to the extent.

The alignment of an object with an event can be defined on each axis by specifying the name of the axis followed by one of the keywords #LEFT, #RIGHT, or #CENTER. If the keyword is #LEFT, the lowest (leftmost) edge of the object is aligned with the point at the beginning of the lowest quantum of the event. If the keyword is #RIGHT, the highest (rightmost) edge of the object is aligned with the point at the end of the highest quantum of the event. If the keyword is #CENTER, the center point of the object is aligned with the center point of the event.

Alternatively, objects can be aligned with events in much the same way that axes are calibrated with respect to external contexts (see 9.3.1 Axis calibration), using an object-specific notation. The name of any axis may be followed by the name of an attribute of the client element whose value determines the position of the object with respect to the event. Attributes so named have an unnormalized lexical type of (s*, granule?, s+, snzi, s+, ("STARTS"|"ENDS") #ORDER SGMLCASE, s, char*). The first part of the attribute value (up to the last s separator) specifies the calibration point within the event. The optional granule (granule?) is the granule in which the quantum number is expressed. If a granule name is not specified, the granule used to express the dimension(s) of the event on the axis is assumed. The quantum number on the axis, a signed non-zero integer (snzi), where 1 is the first quantum of the extent, is specified as if it were the first marker in a marker pair used to specify a dimension; the second number of the pair is understood always to be 1 (only one quantum is ever specified). Either "starts" or "ends" must be specified. (The case of these tokens is not significant, as indicated by the "#ORDER SGMLCASE" HyLex specification that follows it.) "Starts" means that the alignment point is at the beginning of the specified quantum; "ends" means that it is at the end of it. The rest of the value (that which matches char*) is a position within the object and is specified in the notation given following the attribute's name in the object alignment attribute.

HyTime offers several techniques for reusing an event element without repeating its complete specification:

If there is a semantic implication to the reuse, the extent specification can position the event in several places in an FCS (see 9.4 Scheduling and extents). Repetitions can also be scheduled using an event group (see 9.4.3 Group extent specification). In addition, event projection can be used to cause semantic copies of an event to appear in the same and/or other FCSs.
If there is no semantic implication to the reuse (that is, the application will see the repetitions as independent specifications), an SGML entity reference can be used.
If the repetitions are the only instances of a unique event type, and the extent is the same for each repetition, it is possible to define the event type as an element type with fixed attribute values. (Example: the company logo.)
If the repetitions are not the only instances of an event type, it is possible to create a description table entry for it and specify the repetitions with the descriptive text attribute. (Example: the company logo as one class of instances of the element type "logo".) (See 6.7.2 Descriptive text.)
Any other reuse requirements can be met by using value references (and, if necessary, indirect addresses as provided by the location address module).

NOTE 286 Because extent specifications are architecturally defined as resources (and thus inclusions of the architectural document element), designers can declare event elements in client documents that allow extent or extlist elements as proper subelements or as included subelements.

                            <!-- Event -->
<![ %sched; [
<!element
   event          -- Scheduled event --
                  -- Clause: 9.5.1 --
   - O
   (%HyCFC;)*

-- Attributes [base]: overrun --
-- Attributes [sched]: exspec --
-- OptionalAttributes [sched]: pulsemap, objalign --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [sched]: dimref:elemspec, rfcsloc:prjsrc --
-- Referrers [rend]: modrule:events, prorule:sources --
>
<!attlist
   event          -- Event --
                  -- Clause: 9.5.1 --

   object         -- Event objects --
      CDATA       -- Reference --
      #IMPLIED    -- Default: Event is the object --
>
<!entity % overrun "INCLUDE">
]]><!-- sched -->

                    <!-- Object alignment rule -->
<![ %objalign; [
<!attlist
-- objalign --    -- Object alignment rule --
                  -- Clause: 9.5.1 --
   (event)

   align          -- Object alignment rule --
                  -- The alignment of an object with an event on each
                     axis can be defined by specifying the name of the
                     axis followed by one of the keywords #LEFT,
                     #RIGHT, or #CENTER.  Alternatively, the name of
                     any axis may be followed by the name of an
                     attribute of the client element whose value
                     determines the position of the object with
                     respect to the event. --
      CDATA       -- Lextype: (AXISNM,(("#LEFT"|"#RIGHT"|#CENTER)|
                                       (ATTNAME,NOTATION)))+ --
                  -- Constraint: Each axis name may appear only
                     once. --
      #IMPLIED    -- Default: no explicit alignment --

-- Attributes named by the object alignment rule attribute have
   an unnormalized lexical type of:

   (s*,granule?,s+,snzi,s+,("STARTS"|"ENDS") #ORDER SGMLCASE,s,char*)

   The first part of the attribute value (up to the last s separator)
   specifies the calibration point within the event.  The rest of the
   value (that which matches char*) is a position within the object,
   and is specified in the notation given following the attribute's
   name in the object alignment attribute. --
>
<!entity % sched "INCLUDE">
]]><!-- objalign -->

9.5.2 Event group

The element form event group (evgrp) is a set of elements that are specified contiguously in a schedule. The elements it contains can be events or other event groups. The significance of these syntactic containers is primarily application-defined. However, HyTime does define certain semantics for the grpdex and grprepet attribute forms (see 9.4.3 Group extent specification) that can be useful aids in expressing repetitions and derived extents for the events in the content of an event group.

NOTE 287 The grpdex and grprepet attribute forms come in handy, for example, when:

In a music application, three quarter-notes are given the duration of a half-note (a "triplet").
In a slide presentation, the nominal duration of a sequence of slides is compressed to fit the duration of a musical accompaniment.
When creating a pulsemap, to avoid having to specify repeated pulses individually.

                         <!-- Event Group -->
<![ %sched; [
<!element
   evgrp          -- Event group --
                  -- Clause: 9.5.2 --
   - O
   (event|evgrp)+

-- Attributes [base]: overrun --
-- OptionalAttributes [sched]: pulsemap, grpdex, grprepet --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [sched]: dimref:elemspec, rfcsloc:prjsrc --
-- Referrers [rend]: modrule:events, prorule:sources --
>
]]><!-- sched -->

			Copyright © 1992, 1997 International Organization for Standardization. All rights reserved. This electronic document is for use during development and review of International Standards. Official printed copies of International Standards can be purchased from the ISO and the national standards organization of your country.
Next Clause	Previous Clause