 |  | 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 | |||
Projection deals with the semantic copying of events, modifier scopes, and projector scopes, together with the objects, modifiers, and projectors they schedule, to event schedules, wands, and batons, respectively, perhaps transforming their positions and extents in the process. Events and modscopes whose objects and modifiers are subject to modification in their source contexts can be projected with or without that modification in effect.
NOTE 335 The semantic effects of projection on objects and modifiers are necessarily application defined, inasmuch as HyTime does not standardize the semantics of objects and modifiers.
NOTE 336 Although projection is an optional feature of HyTime and requires support of the "project" option, support for the "project" option is not needed for applications in which projection is merged into the application processing and is therefore not independently specifiable.
Projection can be from one schedule (evsched, wand, or baton) to another--the "source" schedule to the "target" schedule. The targets of the projected events, modscopes, and proscopes can be other schedules of the same FCS as the source schedules, or the schedules of other FCSs. If the source FCS and the target FCS(s) are not the same, the possibility exists for the measurement domains and/or scales of the axes to differ.
NOTE 337 For example, in the case of the rendition of a musical score, notes scheduled in terms of the virtual time can be projected onto schedules in another FCS measured in terms of real time. Another example is in the realm of project management, in which a sequence of tasks is arrayed along an axis of a visible graph intended to show a time line, which, when rendered (that is, when the project is executed), is projected onto a real time axis in another FCS. A third example is the projection of events that describe a geographic area in real space units, which is rendered as a map by proportional projection onto another FCS using much smaller real space units.
The source and target FCSs need not have the same number of coordinate axes. However, the source and target schedules must have the same number of axes, and the order of their axes are treated as corresponding to one another.
NOTE 338 In other words, the first axis of the source schedule corresponds to the first axis of the target schedule, the second to the second, and so on.
It is possible for events, modscopes and proscopes to be projected any number of times from one schedule to another. In the case of subsequent projections, the rendition in effect may become the source for another rendition.
NOTE 339 If there is no need for the semantic of renditional projection, it may be preferable to accomplish essentially the same end using the grprepet attributes of an evgrp, modgrp, or progrp to schedule the event, modscope or proscope multiple times.
NOTE 340 HyTime imposes no validation requirement that circular projection specifications 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.
Target schedules can be the targets of projection from multiple source schedules, and they can also contain "directly" scheduled events, modscopes, and proscopes, that is, elements scheduled in the normal way, without the use of projection.
The objects scheduled by events (and the modifiers scheduled by modscopes) that were projected onto the target event schedules (or wands) are subject to any modifiers scheduled by modscopes contained in and/or projected onto wands that govern (by virtue of a wand rule specification) the objects (or modifiers) scheduled by such target event schedules (or wands). Similarly, projected events, modscopes, and proscopes are subject to further projection by projectors scheduled by proscopes contained in and/or projected onto batons that govern (by virtue of a baton rule specification) the events, modscopes, and proscopes scheduled by such target event schedules, wands and batons.
In HyTime, the specifications for projection are called "projectors"; they specify projection functions that determine the scheduled extents of the elements as projected onto the target schedules.
NOTE 341 Depending upon the nature of the document, the modes of specifying
projections can vary widely. For example:
A single projector could be fixed for the entire
schedule; for example, when a sequence of graphics events is to
be scaled uniformly. Alternatively, it could change from place to
place; for example, in a slide show where the durations of some slides
are sped up to create a special effect, or in music that slows down at
the end of a piece. The scaling factor could be expressed precisely; for example,
if an HMU corresponded to a frame in NTSC video, the time scaling factor
(the "tempo") might be 1/30 second per HMU. Alternatively, the
expression of the scaling factor could be imprecise (by using
descriptive text, for example). In music, for example, it is common
to specify tempos in such natural language terms as "slow",
"moderate", and even "not too fast". A precise definition
would eventually be supplied for an imprecise scaling factor at
rendition time. (Any notation can be used to specify the projection
functions, including notations that only human beings, such as
musicians reading tempo markings in Italian, can be expected to
interpret for best results.) A change to a scaling factor could occur over a period of space or
time, in which case the rate of change and final scaling factor can be
expressed as a projection function in the content of a projector using
any appropriate notation. Such a projection function could be
specified as a precise formula (for example, linear acceleration to 4
beats per second), or as imprecise instructions (for example, "speed
up little by little to a moderate rate", or "zoom quickly to a tight
close-up"). A precise definition would eventually be supplied for an
imprecise projection function at rendition time.
By preserving source extents and their governing projectors, rather than just the extents of a given rendition of the document, the intention of the document creator is preserved.
NOTE 342 In other words, we know why different portions of the rendition lasted as long as they did (or occupied as much space as they did), and where it is acceptable to vary the extents in a subsequent rendition. For example, we can tell whether two events occurred simultaneously by chance, or whether the author intended that they be synchronized in all renditions.
This information can be valuable during subsequent editing of the information, or if portions of it are extracted for use elsewhere, as is common in hypermedia applications.
NOTE 343 Text processing and compound document page layout are outside the scope of this International Standard. Nonetheless, it can be useful for understanding projection to draw an analogy from text processing. In this analogy, unprojected extent is like an unformatted document, projected extent is like a formatted document, and projectors are like a style sheet that specifies how a formatted document can be produced from the unformatted. Depending upon the precision and completeness of the style sheet, only one formatted version of the document may be possible, or many different ones. However, projectors can be part of the document creator's intention as well as the expression of a stylistic interpretation. Therefore, they are representable in HyTime even though applications may also include them in style sheets whose values override those in the document, or define them more precisely.
The content of the element form projector (projectr) defines a projection function for the events, modscopes, and proscopes it projects.
The projector notation (notation) attribute specifies the notation used in the content. If no value is specified, the projector functions in the content are assumed to be expressed as a set of extent projector (expro) elements.
NOTE 344 The HyTime-defined "HyPro" projector notation may be used (see 10.3.1.1 HyTime Projector Notation).
The attribute strictness (strict) is a character string that indicates the intended degree of adherence to the projection function. The values are application specific and affect only the application's execution of the calculated projection, not the calculation itself.
NOTE 345 For example, values might be "rubato" or "within 10 percent".
NOTE 346 An application can build a library of projectors by creating descriptive text and description table definitions for commonly used values, e.g., "double" for 2:1 ratio (see 6.7.2 Descriptive text).
<!-- Projector -->
<![ %project; [
<![ %HyPro; [
<!entity % dpro "HyPro">
]]>
<!entity %
dpro -- Default projector notation --
-- Clause: 10.3.1 --
"#IMPLIED"
>
<!element
projectr -- Projector --
-- Clause: 10.3.1 --
-- Defines a projection function for events,
modscopes, and proscopes in a source FCS. --
O O
(%HyCFC;|%dimlist;|dimpro|expro|extent|extlist)*
-- Constraint: If no extent projector function
notation is specified, content is restricted to
(expro)* --
-- Attributes [rend]: projectr --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: prorule:proseq, proscope:projectr, proseq --
>
<!attlist
projectr -- Projector --
-- Clause: 10.3.1 --
notation -- Projector notation --
NAME -- Lextype: NOTATION --
%dpro; -- Default: Content restricted to (expro)* --
strict -- Strictness --
-- Indication of the strictness with which the
projection function is intended to be
executed. --
CDATA
#IMPLIED -- Default: No indication --
>
<!entity % rend "INCLUDE">
]]><!-- project -->The notation HyTime Projector Notation (HyPro) specifies projection functions implicitly by specifying the target extents on the target schedules into which the events, modscopes, and proscopes of the source schedules are projected. All of the extents of all of the source events, modscopes, and proscopes projected by the containing projectr are projected as a matrix, with each source extent being projected onto as many target extents as are specified. All projections of events, modscopes, and proscopes are done linearly.
The attribute extent list notation (extlistn) specifies the notation used to describe extent lists within HyPro notation. If no value is specified, the HyPro notation consists entirely of expro, dimpro, extent, and extlist elements. If a value is specified, the HyPro notation can also include extents specified in the notation named in the value.
NOTE 347 HyExtLst notation may be used as a HyPro extent list notation (see 9.4.6 HyTime extent list notation).
NOTE 348 The HyPro notation is syntactically indistinguishable from HyExtLst when xpro and dimpro are not used and the value of the extlistn attribute is "HyExtLst". Even in those circumstances, HyExtLst cannot be used to describe projectors because it is semantically different from HyPro; HyExtLst is used simply to specify extents, whereas HyPro is used to specify sets of projection functions derived from the extents it specifies (and from the source extents to be projected).
<!-- HyTime Projector Notation -->
<![ %HyPro; [
<![ %HyExtLst; [
<!entity % dpextlst "HyExtLst">
]]>
<!entity %
dpextlst -- Default projector extent list notation --
-- Clause: 10.3.1.1 --
"#IMPLIED"
>
<!notation
HyPro -- HyTime Projector Notation --
-- Clause: 10.3.1.1 --
-- Defines projection functions by deriving linear
relationships between each dimension of each of
the specified extents (in the target FCS) and its
corresponding dimension in the source FCS.
Projector functions for individual extents or
dimensions may also be specified using expro or
dimpro elements. --
PUBLIC "ISO/IEC 10744:1997//NOTATION
HyTime Projector Notation//EN"
-- Attributes [rend]: HyPro --
-- CommonAttributes [GenArc]: altreps, included, superdcn --
-- CommonAttributes [base]: bosdatt --
-- CommonAttributes [locs]: egrvplan --
>
<!attlist #NOTATION
HyPro -- HyTime Projector Notation --
-- Clause: 10.3.1.1 --
extlistn -- Extent list notation --
-- Notation used to specify the target extents. --
NAME -- Lextype: NOTATION --
%dpextlst; -- Default: Only expro, dimpro, extent, and extlist
elements allowed. --
>
<!entity % project "INCLUDE">
]]><!-- HyPro -->The content of the element form extent projector (expro) defines projection functions for projection of the events, modscopes, and proscopes it projects to a single target extent.
The extent projector notation (notation) attribute specifies the notation used in the content. If no value is specified, the projector functions in the content are assumed to be expressed as a set of dimension projector (dimpro) elements.
NOTE 349 The HyTime-defined "HyExPro" extent projector notation may be used (see 10.3.1.3 HyTime Extent Projector Notation).
<!-- Extent Projector -->
<![ %project; [
<![ %HyExPro; [
<!entity % dexpro "HyExPro">
]]>
<!entity %
dexpro -- Default extent projector notation --
-- Clause: 10.3.1.2 --
"#IMPLIED"
>
<!element
expro -- Extent Projector --
-- Clause: 10.3.1.2 --
-- Defines projection functions to a single target
extent for extents in a source FCS. --
O O
(%HyCFC;|%dimlist;|dimpro)*
-- Constraint: If no extent projector notation is
specified, content is restricted to (dimpro)* --
-- Attributes [rend]: expro --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist
expro -- Extent Projector --
-- Clause: 10.3.1.2 --
notation -- Extent projector notation --
NAME -- Lextype: NOTATION --
%dexpro; -- Default: Content restricted to (dimpro)* --
>
<!entity % rend "INCLUDE">
]]><!-- project -->The notation HyTime Extent Projector Notation (HyExPro) specifies projection functions implicitly by specifying the dimensions of a single target extent on the target schedule. All of the extents of all of the source events, modscopes, and proscopes projected by the containing expro element are projected linearly onto this single extent.
The attribute extent specification notation (exspnot) specifies the notation used to describe the target extent. If no value is specified, the HyExPro notation consists entirely of dimpro and dimspec elements.
NOTE 350 HyExSpec notation can be used (see 9.4.4 Scheduled extent).
<!-- HyTime Extent Projector Notation -->
<![ %HyExPro; [
<![ %HyExSpec; [
<!entity % dpexspec "HyExSpec">
]]>
<!entity %
dpexspec -- Default projector extent specification
notation --
-- Clause: 10.3.1.3 --
"#IMPLIED"
>
<!notation
HyExPro -- HyTime Extent Projector Notation --
-- Clause: 10.3.1.3 --
-- Defines projection functions by deriving linear
relationships between each dimension of the
specified extent (in the target FCS) and its
corresponding dimension in the source FCS.
Projector functions for particular dimensions may
also be specified using dimension projector
elements. --
PUBLIC "ISO/IEC 10744:1997//NOTATION
HyTime Extent Projector Notation//EN"
-- Attributes [rend]: HyExPro --
-- CommonAttributes [GenArc]: altreps, included, superdcn --
-- CommonAttributes [base]: bosdatt --
-- CommonAttributes [locs]: egrvplan --
>
<!attlist #NOTATION
HyExPro -- HyTime Extent Projector Notation --
-- Clause: 10.3.1.3 --
exspnot -- Extent specification notation --
-- Notation used to specify the target extent. --
NAME -- Lextype: NOTATION --
%dpexspec; -- Default: Only dimpro and dimspec elements
allowed. --
>
<!entity % project "INCLUDE">
]]><!-- HyExPro -->The content of the element form dimension projector (dimpro) defines projection functions for projection of the dimensions of the events, modscopes, and proscopes it projects to a single dimension on a single axis of the target schedule.
The dimension projector notation (notation) attribute specifies the notation used in the content. A value is required for this attribute.
NOTE 351 Signed nonzero integers, dimrefs, and markfuns (axis markers and elements that resolve to axis markers) are permitted in the content by virtue of the %marklist parameter entity in the content model, but the markers themselves do not constitute an implicit notation. How to interpret the markers would not be known without specifying a notation using the notation attribute; this is the reason why the notation must be known to the HyTime engine.
NOTE 352 HyDimPro notation can be used (see 10.3.1.5 HyTime Dimension Projector Notation).
<!-- Dimension Projector -->
<![ %project; [
<![ %HyDimPro; [
<!entity % ddimpro "HyDimPro">
]]>
<!entity %
ddimpro -- Default dimension projector notation --
-- Clause: 10.3.1.4 --
"#REQUIRED"
>
<!element
dimpro -- Dimension projector --
-- Clause: 10.3.1.4 --
-- Defines a projection function for dimensions
along an axis of a source FCS. --
O O
(%HyCFC;|%marklist;)*
-- Attributes [rend]: dimpro --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist
dimpro -- Dimension projector --
-- Clause: 10.3.1.4 --
notation -- Dimension projector notation --
NAME -- Lextype: NOTATION --
%ddimpro;
>
<!entity % rend "INCLUDE">
]]><!-- project -->The notation HyTime Dimension Projector Notation (HyDimPro) specifies projection functions implicitly, by specifying a single target dimension on a single axis of the target schedule. All of the dimensions on the corresponding axis of all of the source events, modscopes, and proscopes projected by the containing dimpro element are projected linearly onto this single dimension of the target axis.
The attribute dimension specification notation (dimspnot) specifies the notation used to describe the target dimension. A value must be specified if HyDimSpc is not supported.
<!-- HyTime Dimension Projector Notation -->
<![ %HyDimPro; [
<![ %HyDimSpc; [
<!entity % dpdimspc "HyDimSpc">
]]>
<!entity %
dpdimspc -- Default projector dimension specification
notation --
-- Clause: 10.3.1.5 --
"#REQUIRED"
>
<!notation
HyDimPro -- HyTime Dimension Projector Notation --
-- Clause: 10.3.1.5 --
-- Defines a projection function by deriving a
linear relationship between the specified
dimension (in the target FCS) and its
corresponding dimension in the source FCS. --
PUBLIC "ISO/IEC 10744:1997//NOTATION
HyTime Extent Projector Notation//EN"
-- Attributes [rend]: HyDimPro --
-- CommonAttributes [GenArc]: altreps, included, superdcn --
-- CommonAttributes [base]: bosdatt --
-- CommonAttributes [locs]: egrvplan --
>
<!attlist #NOTATION
HyDimPro -- HyTime Dimension Projector Notation --
-- Clause: 10.3.1.5 --
dimspnot -- Dimension specification notation --
-- Notation used to specify the target dimension. --
NAME -- Lextype: NOTATION --
%dpdimspc;
>
<!entity % project "INCLUDE">
]]><!-- HyDimPro -->Events, event groups, event schedules, modifier scopes, modifier scope groups, wands, projector scopes, projector scope groups, and batons can all be directly associated with projectors by means of "projector rules."
The attribute project modified or unmodified objects (modified) specifies whether the object scheduled by any source event (or the modifier scheduled by any source modscope) is modified by any modifiers to which it is subject in the source event schedule (or wand) when it is projected ("modify"), or whether the event's object (or the modscope's modifier) is projected without such modification ("unmodify").
<!-- Project modified or unmodified object -->
<![ %modify; %project; [
<!attlist
-- modified -- -- Project modified or unmodified object --
-- Clause: 10.3.2.1 --
(batrule|prorule)
modified -- Project event (or modscope) with object (or
modifier) modified or unmodified --
-- Project modified objects (or modifiers)
("modify"), or project objects (or modifiers)
without the modifications that are applied to
them ("unmodify") in their source schedules. --
-- Constraint: value is ignored for projected
elements that are not events or modscopes. --
(modify|unmodify)
modify
>
]]><!-- modify, project -->The element form projector rule (prorule) directly associates one or more events, event groups, event schedules, modscopes, modgrps, wands, proscopes, progrps, and batons with a projector (see 10.3.1 Projector) or projector sequence (see 10.3.2.3 Projector sequence). The association indicates that the events, modscopes, and proscopes consisting of and/or contained by the elements specified by the projection sources (sources) attribute are projected by the projectors specified by the projectors and projector sequences (projectr) attribute onto the schedules specified by the target schedules (targschd) attribute. Events will only be projected onto event schedules, modscopes will only be projected onto wands, and proscopes will only be projected onto batons.
NOTE 353 A combination of events, modscopes, and proscopes can be projected with a single prorule onto their respective appropriate schedules.
<!-- Projector Rule -->
<![ %project; [
<!element
prorule -- Projector rule --
-- Clause: 10.3.2.2 --
-- Direct association between sources, projectors,
and target schedules. --
- O
(%HyCFC;)*
-- Attributes [rend]: modified, prorule --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [sched]: pdimref:prjby, rfcsloc:prjby --
-- Referrers [rend]: rendrule --
>
<!attlist
prorule -- Projector rule --
-- Clause: 10.3.2.2 --
sources -- Projection sources --
-- Sources for projection --
CDATA -- Reference --
-- Reftype: (baton|event|evgrp|evsched|modgrp|
modscope|progrp|proscope|wand)* --
#REQUIRED
projectr -- Projectors and projector sequences --
-- Projectors and/or projector sequences to be used
for projection from sources to targets. --
CDATA -- Reference --
-- Reftype: (projectr|proseq)* --
#REQUIRED
targschd -- Target schedules --
-- Schedules onto which sources will be projected by
projectors and/or projector sequences. --
CDATA -- Reference --
-- Reftype: (evsched|wand|baton)+ --
-- Constraint: Only events will be projected onto
event schedule targets; only modscopes will be
projected onto wands, and only proscopes will be
projected onto batons. --
#REQUIRED
>
<!entity % rend "INCLUDE">
]]><!-- project -->The element form projector sequence (proseq) contains a list of IDs of projectors or projector sequences. The order of unique identifiers in the list determines the order in which the identified elements are applied.
<!-- Projector sequence -->
<![ %proseq; [
<!element
proseq -- Projector sequence --
-- Clause: 10.3.2.3 --
- O
(#PCDATA) -- Reference --
-- Reftype: (proseq|projectr)* --
-- Constraint: subset of SGML model group with
IDREFs as names and no occurrence indicators, OR
connectors, or AND connectors. --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: prorule:proseq, proseq --
>
<!entity % project "INCLUDE">
]]><!-- proseq -->Projectors can be scheduled in FCSs by means of "batons". Batons are like event schedules; they contain projector scopes and projector scope groups, which are like events and event groups, respectively. Projector scopes contain projectors, in much the same way that events contain information objects. The extent of the projector scope is the nominal region of the FCS which contains the events, modscopes, and/or proscopes that are projected by the projector it contains. The events, modscopes, and proscopes within the region that are projected are limited to those scheduled by (or projected onto) the schedules specified by one or more "baton rules" that associate the source schedules, target schedules, and the batons that schedule the projectors that specify the projection functions.
The element form baton rule (batrule) associates one or more schedules (event schedules, wands, and/or batons) with a baton or baton sequence that governs their projection, and with the resulting target schedules. The attribute schedules (scheds) identifies the schedules; the attribute baton (baton) identifies the baton or baton sequence.
The attribute target schedules (targschd) identifies one or more schedules in the coordinate spaces onto which events affected by the baton are to be projected. The events, modscopes, and proscopes in all of the source schedules will be projected into all of the target schedules.
NOTE 354 A baton does not create schedules; it populates the target schedules associated with it by the baton rule. During rendition, the HyTime engine maintains an internal form of each target schedule that contains the projected events, modscopes or proscopes, together with any events, modscopes, or proscopes that may have been directly scheduled in the schedule.
NOTE 355 Although the baton rule form allows applications to associate different batons with different schedules there is no implication that all batons are interchangeable: they must be designed with the properties of the schedules they are to affect in mind.
NOTE 356 The baton rules required for a rendition can be collected in a "rendition rule" (see 10.4 Rendition rule).
In any rendition, all projections specifying a given target schedule must be completed before projections that use that target schedule as a projection source are made.
<!-- Baton Rule -->
<![ %baton; [
<!element
batrule -- Baton rule --
-- Clause: 10.3.3.1 --
- O
(%HyCFC;)*
-- Attributes [rend]: batrule, modified --
-- 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
batrule -- Baton rule --
-- Clause: 10.3.3.1 --
scheds -- Schedules --
CDATA -- Reference --
-- Reftype: (baton|evsched|wand)* --
#REQUIRED
baton -- Baton --
CDATA -- Reference --
-- Reftype: (baton|batonseq) --
#REQUIRED
targschd -- Target schedules --
CDATA -- Reference --
-- Reftype: (baton|evsched|wand)+ --
#REQUIRED
>
<!entity % project "INCLUDE">
]]><!-- baton -->The element form baton (baton) is a schedule of projector scopes that, when a baton rule so specifies, governs the projection of events, modscopes, and proscopes semantically present in one or more schedules. A baton must be a schedule of the same semantic FCS as the event schedules, wands, and batons it affects.
NOTE 357 The baton element, like the baton of an orchestra conductor, controls the rendition of the document (hence the name). The name also reflects the fact that the projection model of HyTime was originally derived from the handling of duration and tempo in music.
The projector scope occurrences in a baton may overlap on any or all coordinate axes, and there can also be gaps between them in which no events, modscopes, or proscopes will be projected.
<!-- Baton -->
<![ %baton; [
<!element
baton -- Baton --
-- Clause: 10.3.3.2 --
- O
(progrp|proscope)+
-- 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:prjby,
pdimref:prjtarg, pulsemap:pulsemap, rfcsloc:prjby,
rfcsloc:prjsrc --
-- Referrers [rend]: batonseq, batrule:baton, batrule:scheds,
batrule:targschd, prorule:sources, prorule:targschd --
>
<!entity % project "INCLUDE">
]]><!-- baton -->The element form projector scope (proscope) associates one or more extents with a projector, in order to specify the projection of events, modscopes and proscopes that occur within those extents.
The attribute scheduled projectors (projectr) refers to the projectors scheduled by the projector scope.
NOTE 358 The semantic of having multiple extents for a single proscope is defined by the projector or projectors scheduled by the proscope.
<!-- Projector Scope -->
<![ %baton; [
<!element
proscope -- Projector scope --
-- Clause: 10.3.3.3 --
-- Defines the scope of a projector as one or more
extents. --
- O
(%HyCFC;)*
-- Attributes [base]: overrun --
-- Attributes [sched]: exspec --
-- Attributes [rend]: proscope, 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, pdimref:prjby, rfcsloc:prjby,
rfcsloc:prjsrc --
-- Referrers [rend]: prorule:sources --
>
<!attlist
proscope -- Projector scope --
-- Clause: 10.3.3.3 --
projectr -- Scheduled projectors --
CDATA -- Reference --
-- Reftype: projectr* --
#IMPLIED -- Default: none --
>
<!entity % project "INCLUDE">
]]><!-- baton -->The element form projector scope group (progrp) is a container for a set of projector scopes or other projector scope group elements that are specified contiguously in a schedule. These syntactic containers fulfill a role that 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).
<!-- Projector Scope Group -->
<![ %baton; [
<!element
progrp -- Projector scope group --
-- Clause: 10.3.3.4 --
- O
(progrp|proscope)+
-- 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, pdimref:prjby, rfcsloc:prjby,
rfcsloc:prjsrc --
-- Referrers [rend]: prorule:sources --
>
<!entity % project "INCLUDE">
]]><!-- baton -->The element form baton sequence (batonseq) contains a list of IDs of batons or baton sequences. The order of unique identifiers in the list determines the order in which the identified elements are applied. Using a baton sequence is exactly like using a sequence of projections from one FCS to a second, from the second FCS to a third, etc., but without the intervening FCSs.
<!-- Baton sequences -->
<![ %batonseq; [
<!element
batonseq -- Baton sequence --
-- Clause: 10.3.3.5 --
- O
(#PCDATA) -- Reference --
-- Reftype: (batonseq|baton)* --
-- Constraint: subset of SGML model group with
IDREFs as names and no occurrence indicators, OR
connectors, or AND connectors. --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [rend]: batonseq, batrule:baton --
>
<!entity % baton "INCLUDE">
]]><!-- batonseq -->| Next Clause | Previous Clause |
| 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. | |
HTML generated from the original SGML source using a DSSSL style specification and the SGML output back-end of the JADE DSSSL engine.