 |  | 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 | |||
Each finite coordinate space (fcs) element corresponds to a distinct logical FCS. Each fcs element defines a set of coordinate axes, each of which is associated with a single measurement domain. An FCS with more than one axis requires support of the "manyaxes" option with no value specified, or with a value greater than 1.
NOTE 267 Throughout this international standard, the lowercase name "fcs" means "finite coordinate space element", and the uppercase "FCS" means the logical (that is, semantic) finite coordinate space represented as nodes in a grove after all HyTime processing has been completed.
The FCS axis names (axes) attribute defines the axes of the FCS by defining a name for each axis and associating with it an SMU that identifies the measurement domain of the axis. The value of the attribute is a list of axis name/notation name pairs, one for each axis.
An fcs element governs associated elements that use the "sched" attribute form. Event schedules, wands (which require the object modification facility), and batons (which require the event projection facility) become associated with an fcs element by being contained in it and/or by referring to it with their fcs attributes.
Axis names must be unique within the axes attribute's value. Client fcs elements must declare for each axis named an "axis dimension specification" attribute whose name is the same as an axis named by the axes attribute (or is mapped to an axis name by the HyNames architectural renaming attribute).
HyTime engines schedule extents in terms of "measurement domain units" (MDUs). The MDU is the finest internal granularity on the basis of which all calculations will be made.
NOTE 268 The MDU is normally the common denominator of all HMUs used to schedule extents on a given axis. MDU granularity should be fine enough that roundoff errors will not be significant (that is, under normal circumstances, perceivable).
Each axis dimension specification attribute has the lexical type:
(NUMBER, granule?, ("#MDU", ratio, granule?)?)The number specifies the dimension of the axis (ultimately, the total
number of MDU quanta along the axis), expressed in terms of the
following granule, if specified; otherwise, the units of the dimension
used are the SMU specified for the axis. If a granule is specified,
it is both the default base granule and default HMU for the axis;
otherwise the default base granule and HMU is the axis SMU.
NOTE 269 The "default base granule" for an axis is the granule used to express dimensions (in HMUs) along it in, for example, events scheduled in evscheds in which an axis attribute does not specify a granule to which the HMU is proportional. The default HMU for an axis is the HMU used to express dimensions in, for example, events scheduled in evscheds in which an axis attribute for the axis does not exist, or does not specify a ratio of HMUs to default granules.
If #MDU and a ratio is specified, it defines the MDU to SMU ratio for the axis, specified in terms of either the following granule or the default HMU. All granule names must be defined in terms of the axis SMU.
The number of MDUs on any axis must not exceed the number derived from the value of the HyTime architecture use declaration hyqcnt attribute for the document in which the fcs element occurs.
NOTE 270 The aspects of a finite coordinate space defined by HyTime in the fcs architectural form do not fully define a space. However, application designers can use them in conjunction with application semantics to do so.
<!-- Finite Coordinate Space -->
<![ %sched; [
<!element
fcs -- Finite coordinate space --
-- Clause: 9.3 --
- O
(baton|evsched|wand)*
-- Attributes [sched]: fcs --
-- OptionalAttributes [sched]: calibrat --
-- 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:prjtarg,
rfcsloc:prjsrc, sched:fcs --
>
<!attlist
fcs -- Finite coordinate space --
-- Clause: 9.3 --
axes -- Axis names and measurement domains --
-- The name and measurement domain (SMU) of each
axis. --
CDATA -- Lextype: (AXISNM,SMU)+ --
-- Constraint: Each axis name must be unique
within the list. --
#REQUIRED -- Constant --
-- Each axis name specified in the value of the axes attribute is
taken to be the name of an attribute of the client element that
specifies the dimension and granularity of the axis. Each such
attribute has the lexical type (NUMBER, granule?, ("#MDU", ratio,
granule?)?), where the number is the dimension of the axis,
expressed in terms of the following granule, if specified;
otherwise the dimension is in terms of the axis SMU. If a granule
is specified, it is both the default base granule and default HMU
for the axis; otherwise the default base granule and HMU is the
axis SMU. If #MDU and a ratio is specified, it defines the MDU to
SMU ratio for the axis, specified in terms of either the following
granule or the default HMU. All granule names must be defined in
terms of the axis SMU. --
>
]]><!-- sched -->One or more axes of a finite coordinate space may be calibrated with respect to an external context. The external context need not be finite in dimension or resolution; its meaning is unknown to a HyTime engine. The external context should be appropriate to the measurement domains of their corresponding axes.
NOTE 271 For example, it would make sense to peg a point on an axis measured real time to a particular historical (or future) date, or a point on an axis measured in degrees Celsius to the boiling point of water at one bar of atmospheric pressure. It would not be appropriate to calibrate an axis measured in Australian dollars in terms of a geographic meridian.
Because the external context with respect to which an axis is calibrated is of potentially infinite resolution, the calibration must take place at a point along the axis rather than at a quantum. A calibration point is defined by specifying a quantum number and whether the point occurs at the beginning point of the quantum ("STARTS"), or at end point of the quantum ("ENDS").
The attribute axis calibration (calibrat) specifies one or more axis name, attribute, notation tuples, one tuple for each axis to be calibrated The attribute name is the name of an attribute of the client element whose value determines the position of the axis with respect to an external context. The notation names the coordinate specification notation used by the attribute named in the tuple (e.g., the HyTime Calendar Specification Notation, HyCalSpc).
The values of client attributes named in the calibrat 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 for the axis. The optional granule ("granule?") is the granule in which the quantum number is expressed. If a granule name is not specified, the default granule for the axis is assumed. The quantum number on the axis, a signed non-zero integer (snzi), 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 calibration 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 an external context, and is specified in the notation specified following the attribute's name in the axis calibration attribute.
NOTE 272 Real time axes can be calibrated using the HyCalSpc notation defined by this international standard (see 9.9.1 HyTime calendar specification notation). For example, "1972-01-01 CE" is data in HyCalSpc notation meaning "January 1 of the year 1972 of the common era". The axis calibration value "year -1 ends 1972-01-01 CE" means that the last year on the axis would conclude just at the point in real time when 1972 began. Any notation could be used, of course, and the point in real time could be expressed with whatever level of precision is supported by the notation.
<!-- Axis calibration -->
<![ %calibrat; [
<!attlist
-- calibrat -- -- Axis calibration --
-- Clause: 9.3.1 --
(fcs)
calibrat -- Axis calibration --
-- The calibration of an axis is defined by
specifying the name of the axis followed by the
name of an attribute of the client element whose
value determines the position of the axis with
respect to an external context. --
CDATA -- Lextype: (AXISNM,ATTNAME,NOTATION)+ --
-- Constraint: Each axis name may appear only
once. --
-- Constraint: Calibration points should be
expressed in notations which make sense, given
the measurement domains of their corresponding
axes. --
#IMPLIED -- Default: no axis calibration --
-- Attributes named by the axis calibration attributes 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 for the axis. The rest of the
value (that which matches char*) is a position within an external
context, and is specified in the notation given following the
attribute's name in the axis calibration attribute. --
>
<!entity % sched "INCLUDE">
]]><!-- calibrat -->| 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.