10 Rendition module

10.2 Object Modification

Subclauses:

Although the semantics of objects, and therefore of their modification, is outside the scope of this International Standard, it can nevertheless be useful to specify the relationships between objects and their modifiers in a standardized way.

NOTE 316 In the same way, instructions for patching together a series of audio signal processing devices could be executed by a person who knows nothing about the effects they create.

NOTE 317 Although object modification is an optional facility of HyTime and requires support of the "modify" option, the modify option need not be supported by applications in which modification is merged into the application processing and is therefore not independently specifiable.

10.2.1 Object modifier

An object modifier affects the object of an event during its rendition.

NOTE 318 Obvious examples of object modifiers include color mapping functions and audio signal processing instructions.

Object modifiers are defined by applications, not by this standard.

NOTE 319 Useful sets of object modifiers can be defined by industry groups for public use.

An object modifier can be represented by any element type or data.

NOTE 320 In particular, it can be represented by information expressed in terms of a data content notation.

NOTE 321 An object modifier is not necessarily an element.

An object modifier is itself subject to object modification by object modifiers.

10.2.2 Direct association of modifiers (modifier rule)

The element form modifier rule (modrule) directly associates one or more events, event groups, event schedules, modscopes, modgrps, and wands with a modifier or modifier patch (see 10.2.4 Modifier Patch and Wand Patch); the association indicates that the objects scheduled by the events (and scheduled by the events contained by the event groups and event schedules), or the modifiers scheduled by the modscopes (and scheduled by the modscopes contained by the modgrps and wands), are modified by the modifier or modifier patch. The attribute events and event groups (events) identifies the events, event groups, event schedules, modifier scopes, modifier groups, and wands whose objects and modifiers are to be modified. The attribute modifier or modifier patch (modifier) identifies the modifier or modifier patch to be applied.

                        <!-- Modifier Rule -->
<![ %modify; [
<!element
   modrule        -- Modifier rule --
                  -- Clause: 10.2.2 --
   - O
   (%HyCFC;)*

-- Attributes [rend]: modrule --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: rendrule --
>
<!attlist
   modrule        -- Modifier rule --
                  -- Clause: 10.2.2 --

   events         -- Events and modscopes --
      CDATA       -- Reference --
                  -- Reftype:
                     (event|evgrp|evsched|modscope|modgrp|wand)* --
      #REQUIRED

   modifier       -- Modifier or modifier patch --
      CDATA       -- Reference --
                  -- Constraint: only one modifier or modifier
                     patch --
      #REQUIRED
>
<!entity % rend "INCLUDE">
]]><!-- modify -->

10.2.3 Association of modifiers by position in finite coordinate spaces

In HyTime, modifiers can occur in schedules called "wands"; these are associated with one or more event schedules by means of wand rules (see 10.2.3.1 Wand Rule), optionally with the aid of wand patches (see 10.2.4 Modifier Patch and Wand Patch). Within a wand, a modifier is scheduled by an event-like element called a "modifier scope", in the same way that an information object is scheduled by an event. The extent of the modifier scope defines the region of the FCS wherein the objects scheduled by events contained in the associated event schedules (or modifiers scheduled by modscopes contained in associated wands) will be modified.

NOTE 322 A wand is a symbol of authority. Its well-known association with magic seems appropriate, considering that modification semantics are undefined by HyTime. This magical connotation is in contrast with the baton construct of the projection facility (see 10.3 Projection), which, though also a symbol of authority, has semantics defined by HyTime.

10.2.3.1 Wand Rule

The element form wand rule (wandrule) associates one or more event schedules (whose objects are to be modified) and/or wands (whose modifiers are to be modified) with a modifying wand or wand patch (see 10.2.4 Modifier Patch and Wand Patch). The modifiers scheduled by the modifying wand or wand patch are applied to the objects and modifiers scheduled by the event schedules and wands, insofar as the extents of the modscopes contained in the modifying wand are co-located with the extents of the events and modscopes of those event schedules and wands.

NOTE 323 The co-location criteria required to trigger modification can be flexibly specified using the select and portion attributes of the modifying wands, modgrps, and modscopes (see 10.1.1 Precision of Selection).

The attribute event schedules (evscheds) identifies the event schedules containing the events that schedule the objects to be modified and/or the wands containing the modscopes that schedule the modifiers to be modified; the attribute wand or wand patch (wand) identifies the modifying wand or wand patch.

NOTE 324 HyTime allows more than one wand or modifier rule to be used to specify the application of modification to the same object or modifier. Applications may choose to constrain such phenomena, and/or to define the effect of multiple modifications. However, a single wandrule can associate only one wand or wand patch. The use of wand patches makes the order in which the modifications are to be applied explicit.

NOTE 325 Although the wand rule form allows applications to associate different wands with different schedules and/or wands, there is no implication that all wands are interchangeable: they must be designed with the properties of the schedules and/or wands they are to modify in mind.

NOTE 326 Wand patches are discussed along with modifier patches in 10.2.4 Modifier Patch and Wand Patch.

NOTE 327 The wand rules and modifier rules required for a rendition can be collected in a "rendition rule" (see 10.4 Rendition rule).

In any rendition, all modifications specified for scheduled modifiers must be made before such scheduled modifiers are themselves applied.

NOTE 328 HyTime imposes no validation requirement that circular modification specifications, such as when a modifier modifies itself, be avoided in documents or hyperdocuments. It may be reasonable, however, for some kinds of HyTime engines to detect such loops, and for certain kinds of applications to support efforts intended to avoid, create, and/or manage such loops.

                          <!-- Wand Rule -->
<![ %wand; [
<!element
   wandrule       -- Wand rule --
                  -- Clause: 10.2.3.1 --
   - O
   (%HyCFC;)*

-- Attributes [rend]: wandrule --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: rendrule --
>
<!attlist
   wandrule       -- Wand rule --
                  -- Clause: 10.2.3.1 --

   evscheds       -- Event schedules --
      CDATA       -- Reference --
                  -- Reftype: (evsched|wand)* --
                  -- Constraint: all evscheds and wands must be in
                     same logical FCS as all of the wands referenced
                     by the wand attribute. --
      #REQUIRED

   wand           -- Wand or wand patch --
      CDATA       -- Reference --
                  -- Reftype: (wand|wndpatch) --
      #IMPLIED    -- Default: none --
>
<!entity % modify "INCLUDE">
]]><!-- wand -->

10.2.3.2 Wand

The element form wand (wand) is a schedule for modifier scopes.

The modifier scopes in a wand cannot overlap on any coordinate axis. However, it is permissible that there be gaps along the axes in which no modification is specified.

NOTE 329 This rule prevents situations in which the order in which overlapping modifications should be applied would be ambiguous.

                            <!-- Wand -->
<![ %wand; [
<!element
   wand           -- Wand --
                  -- Clause: 10.2.3.2 --
   - O
   (modgrp|modscope)+

-- Attributes [sched]: sched --
-- Attributes [rend]: select --
-- 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,
   prorule:sources, prorule:targschd, wandrule:wand, wndpatch --
>
<!entity % modify "INCLUDE">
]]><!-- wand -->

10.2.3.3 Modifier scope

The element form modifier scope (modscope) associates one or more extents with a modifier, in order to specify the modification of objects and modifiers that occur within those extents.

If a value is specified for the attribute object modifier (modifier), it identifies the object modifier(s) and/or modifier patches to be applied. If no value is specified, the modscope is either merely a "placeholder" used to affect the next specified modscope's extent by means of the implicit dimref facility (see 9.8.1 Implicit dimension reference) or the modscope itself carries the modifier parameters and semantics directly, in some fashion defined by the application.

NOTE 330 If no value is specified for the value of the modifier attribute, the semantics of object modification could be conveyed directly by the element type, by the values of one or more additional attributes, by the content, or by any combination of the foregoing, as defined by the application. For example, the application might define a specific element type for use as a placeholder that carries no modification semantics.

                       <!-- Modifier Scope -->
<![ %wand; [
<!element
   modscope       -- Modifier scope --
                  -- Defines the scope of a modifier as one or more
                     extents. --
                  -- Clause: 10.2.3.3 --
   - O
   (%HyCFC;)*

-- Attributes [base]: overrun --
-- Attributes [sched]: exspec --
-- Attributes [rend]: modscope, select --
-- 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, rfcsloc:prjsrc --
-- Referrers [rend]: prorule:sources --
>
<!attlist
   modscope       -- Modifier scope --
                  -- Clause: 10.2.3.3 --

   modifier       -- Modifiers and modifier patches to be
                     applied --
      CDATA       -- Reference --
      #IMPLIED    -- Default: the modification semantics, if any, are
                     specified directly by the GI, attributes and/or
                     content of this element in some
                     application-defined fashion --
>
<!entity % modify "INCLUDE">
]]><!-- wand -->

10.2.3.4 Modifier scope group

The element form modifier scope group (modgrp) is a container for a set of modifier scopes or other modifier scope group elements that are specified contiguously within a wand element. The elements it contains can be modscopes or other modgrps. These syntactic containers fulfill a role which corresponds precisely to that of event groups, and the same features, most notably the grpdex and grprepet attribute forms, are provided (see 9.4.3 Group extent specification).

                    <!-- Modifier Scope Group -->
<![ %wand; [
<!element
   modgrp         -- Modifier scope group --
                  -- Clause: 10.2.3.4 --
   - O
   (modgrp|modscope)+

-- Attributes [rend]: select --
-- OptionalAttributes [sched]: grpdex, grprepet, 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, rfcsloc:prjsrc --
-- Referrers [rend]: prorule:sources --
>
<!entity % modify "INCLUDE">
]]><!-- wand -->

10.2.4 Modifier Patch and Wand Patch

The term "patch" is applied collectively to the element forms wand patch (wndpatch) and modifier patch (modpatch). A modifier patch contains a list of references to modifiers and modifier patches; a wand patch contains a list of references to wands and wand patches. The order of references in the list determines, in general, the order in which the modifications that correspond to the referenced modifiers are applied to the objects.

NOTE 331 "In general" because the specification order of sets of modifiers that are applied in parallel is not significant.

NOTE 332 The term "patch" is borrowed from the traditional lexicon of analog electronic music. In that context, the term meant a particular sequence of connections between such devices as voltage-controlled amplifiers, oscillators, and filters, all usually accomplished with "patch cords", to create a particular effect.

Serial and parallel processing are indicated in the list by a subset of the SGML model group syntax in which the "and" connector (&) represents parallel processing and the "seq" connector (,) represents serial.

NOTE 333 For example, in the case of audio effect processing, a patch of

(id1, id2, (id3 & (id4, id5)), id6)

means that the audio signal passes through id1 effects, then id2, then is directed to both id3 and id4, with the output of id4 going to id5. Finally, the output of both id3 and id5 is processed by id6.

The element form wand patch (wndpatch) is a patch in which all of the references are to wands or wand patches. Wndpatch elements are referenced in the values of the wand attributes of wandrule elements.

The element form modifier patch (modpatch) is a patch in which all of the references are to object modifiers or modifier patches. Modpatch elements are referenced in the values of the modpatch attributes of modrule elements.

NOTE 334 HyTime does not constrain patches that include loops or recursions, e.g., a patch that references itself. The validity of such a patch depends on the application.

                       <!-- Modifier Patch -->
<![ %patch; [
<!element
   modpatch       -- Modifier patch --
                  -- Clause: 10.2.4 --
   - O
   (#PCDATA)      -- Reference --
                  -- Note: IDREFs may refer to modpatch
                     elements. --

-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: modpatch, modrule:modpatch --
>
<!entity % modify "INCLUDE">
]]><!-- patch -->

                         <!-- Wand Patch -->
<![ %wndpatch; [
<!element
   wndpatch       -- Wand patch --
                  -- Clause: 10.2.4 --
   - O
   (#PCDATA)      -- Reference --
                  -- Reftype: (wndpatch|wand)* --
                  -- Constraint: subset of SGML model group with
                     IDREFs as names and no occurrence indicators or
                     OR connectors. --

-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
   ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: wandrule:wand, wndpatch --
>
<!entity % wand "INCLUDE">
]]><!-- wndpatch -->

			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