 |  | 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 | |||
The fundamental form of location is that which coincides with the fundamental form of addressing; that is, an element in the current document that is identified by an ID. This form of location is supported directly by SGML. It can be addressed by attributes of the type "ID reference" (IDREF) and "ID reference list" (IDREFS).
However, SGML provides no direct way to assign an ID to arbitrary pieces of data, to elements in read-only documents that have no IDs, to collections of elements, and to other arbitrary locations.
As elements need not have unique identifiers, and as hypermedia linking need not be to complete elements, the HyTime location address module provides the ability to define "location address" elements that associate an ID with an object at an arbitrary location (that is, a location addressed by some form of address other than a local ID). When an ID reference is made to the ID of a location address, it is interpreted as a reference to the located object.
NOTE 138 When a location address element is simply encountered in the content of a document, however, it is not automatically resolved. Its attributes and data are passed to the application by the SGML parser in the normal way. The application could, as part of its processing, request the HyTime engine to resolve the location address, but there is no requirement that it do so.
NOTE 139 With few exceptions, HyTime does not distinguish locations by the time needed to access them in storage, as the time could vary depending on the environment in which the document is processed. In practice, a HyTime engine could alert an application when access is expected to exceed a previously specified threshold. The HyTime BOS control facilities can be used to organize the members of a hyperdocument so as to allow optimization of object access based on expected access time.
Location addresses operate on groves and always return nodes in groves (see 7.1.4 Groves and Location Addressing).
NOTE 140 Informally it is normal to speak of "locating an element"; formally this means "locating the node derived from the element in the applicable grove."
The following list summarizes the types of object that can be addressed in a HyTime document, categorized by the form of address.
Nodes addressed by a name ("name-space locations")
Entity (uses either direct entity reference by attributes with a value prescription of ENTITY or "name-space location address").
Identified external element: element with an ID in another document (uses "name-space location address").
Unidentified document element: the root element of this or another document that has no ID (uses "named location address").
Identified local element: an element in this document that is not a location address but has an ID (does not use a location address).
Property value: the value of a property of a node in a grove addressed by property name, such as the value property of an attribute node in an SGML document grove (uses "property location address").
Locations addressed by a coordinate position ("coordinate locations")
List nodes: nodes in a node list addressed by position within the list (uses "list location address").
Tree nodes: nodes in a tree addressed by their positions within a tree (uses "tree location address"), by their positions within a table of paths from the tree root to the leaves (uses "path location address"), or by their genealogical relationshipa to other nodes (uses "relative location address").
Scheduled objects: objects occurring within a region of a finite coordinate space. Addressed either by coordinate location (uses "FCS location address") or by absolute date and time (requires the "calendar specification" option, see 9.9.2 Calendar specification). Requires the scheduling module (see 9.10 Finite coordinate space location address).
Objects addressed by a semantic construct ("semantic locations")
Nodes addressed by queries on their properties (uses "query location address").
Inaccessible (by computer) object: description of a document, person, or other information object to which access cannot be automated (uses "bibliographic location address").
NOTE 141 In terms of the theory of measurement, name-space locations are positions on a "nominal" scale. Coordinate locations are positions on either an "ordinal", "interval", or "ratio" scale, depending on how the application chooses to construct the axes and schedules, the SMU and granules used, how dimensions are specified, and any semantics attached to the element types or granule names by the application. For example, an ordinal scale can be represented by creating a resource pool of extents corresponding to the intervals of the scale, and positioning events by means of dimension references to those extents (see 279 in 9.4 Scheduling and extents).
A location address element can address more than one object simultaneously, creating a "multiple location". No significance is attached to the grouping implied by such a "multiple location address": the locations are treated as though each had been referenced individually. However, the elements that use multiple location addresses may associate specific semantics with multiple locations. Multiple locations require support for the "multloc" option.
NOTE 142 Attributes with a declared value of "IDREFS" do not constitute multiple locations unless they are also given a location type of "IDLOC" through the use of the refloc facility (see 7.8 Reference location address).
Location addresses operate by selecting nodes from a group of nodes. The set of nodes from which a location address selects is its "location source". The location source for one location address may be the nodes selected by another location address. The second location address is the location source of the first location address.
Because location addresses operate on nodes in a grove, the ultimate location source for every location address is the grove or groves that contain the nodes addressed by the location address. Groves are addressed by addressing the document or data entities from which they are constructed or by addressing grove definition elements. Groves may also be addressed implicitly by semantics defined for particular location address elements. Addressing a grove is equivalent to addressing the root node of the grove (the "grove root").
NOTE 143 The grove formalism used by HyTime is needed for definitional purposes but need not be exposed to users and document authors under normal circumstances. The location addressing mechanisms have been designed so that their default behavior will almost always be what an author would intuitively expect.
When one location address acts as the location source for another location address, a "location ladder" is formed. Each "rung" in the location ladder forms a location source for the rung below it. The top rung of the location ladder always has a grove or groves as its location source. The bottom rung of a location ladder is the location address to which initial reference is made. The resolution of a location ladder in which a treeloc is the bottom rung and a nmsploc is the top rung can be described as follows::
A contextual link addresses a tree location address element (treeloc) by its ID.
The treeloc refers to a name-space location address (nmsploc) as its location source.
The nmsploc names another document entity as its location source (implicitly addressing the value of the elements property of the SGML document grove derived from the document entity).
The nmsploc addresses an element within the document by selecting it by name from the element nodes listed in the value of the elements property.
The element node selected by the nmsploc is the root of the tree the treeloc selects from.
The treeloc selects a node in the tree by specifying a tree position.
NOTE 144 This location ladder can be viewed schematically as:
Document
Entity --->SGMLDOC node (exhibits "elements"
A name space for nmsploc)
|
|
nmsploc--->Element addressed by name
A (becomes root of tree for treeloc)
|
|
Clink--->Treeloc--->Element in tree (anchor of clink)
The rungs of the location ladders needed to address groves may be implied under the circumstances defined for each form of location address. For example, the implicit grove address for name-space locations described above can be made explicit by creating a grove definition whose "grove source" is the document entity. That grove definition is then the location source for a property location address that addresses the elements property of the grove root. This property location address would then be the location source for the name-space location address.
NOTE 145 Implicit grove addressing is conceptually a form of
markup minimization because any implicit grove
addressing behavior can be replaced by the equivalent
direct or indirect reference to a grove definition.
For example, the default
implied location source for name-space location addresses is the "elements"
property of the SGMLDOC object in an SGML document grove. This location
ladder could be specified explicitly as follows:
Each of the implied location sources can be specified explicitly with the
appropriate location ladder. In general, any node in a grove can be located
by a combination of property locations, name-space locations, list
locations, and tree locations whose ultimate location source is an explicit
or implicit grove constructor.<!-- Note: Entity DocB declared as data entity with notation SGML -->
<pgrovdef id=docbgrov grovesrc=DocB grovplan=HyTime>
<nmsploc id=docb.foo namespc=elements locsrc=docbgrov>foo</nmsploc>
This International Standard does not require an implementation to reflect the discrete rungs of a location ladder, or to pass information between those rungs in the form specified in a HyTime document.
NOTE 146 This provision allows a HyTime engine to optimize interpretation of a location ladder and access to the bottom rung.
NOTE 147 The HyTime constructs for location addressing and location ladder
construction are quite robust. They are based
on a few simple rules that allow modular implementation of a HyTime
engine. As a result, it is possible to construct location
ladders that could in some contexts appear to be unusual, but which
HyTime would accept as valid and process consistently. For example, in an SGML parsing context, a book chapter can be
used as the location source for dataloc, even though the chapter could
contain subelements as well as data.
HyTime, following the rules for recognizing word tokens as quanta,
would tokenize all of the data in the content of the chapter and its
subelements, which could be useful if an application wanted to
count the words, for example. Restricting the generality of location addressing
would introduce needless policy
decisions into HyTime. It is for the
applications using HyTime to decide whether to restrict any
forms of location address; there is no way for HyTime to
determine what one application might consider to be
nonsense and another would find to be useful, or even essential.
Objects that do not have names can be given names by location address elements that have IDs and that address the objects, directly or indirectly.
For example, a tree location address element with an ID associates its ID with the node it addresses such that a reference to the tree location address' ID is equivalent to having used that ID on the node directly.
Thus, when a location address element addresses another location address element, the effect is to address whatever the second location address addresses, regardless of how the first location address addresses the second location address. For example, a tree location address that happens to address a name-space location will effectively address the objects addressed by the name-space location.
NOTE 148 The only exception to this is when reference is made to a location address element by a referential attribute or content that has an associated reference range of "D" (direct reference). See 7.7.2 Reference resolution range.
"Location path" is the term for the indirect address chaining that occurs when one location element addresses another. Each is a step in the location path. The locsrc of a path step is the bottom rung (and possibly the only rung, in which case it is also the top rung) of its location ladder.
Note that the top rung of a location ladder is always a grove root, represented by a grove definition element or the entity from which the grove is constructed. Normally, the upper rungs of the ladder are implied from the specified locsrc. Only location address elements can be part of a location path or location ladder.
NOTE 149 Visually, paths go from left to right; ladders are above the steps
that they are the location source of. For example, a two-step
path using two name-space location addresses, each
addressing element IDs, the first
addressing the second, can be viewed
schematically as:
Document Document Entity
Entity (contains nodes
(contains addressed by
nmsploc[2]) nmsploc[2])
A A
| |
| |
Clink--->nmsploc[1]--->nmsploc[2]--->nodes addressed by name (anchor of clink)Each name-space location is a step in the path from the
clink (the referrer) to the nodes ultimately addressed (which
become the anchor of the clink). Above each name-space location
is its location ladder. For the first name-space location,
the location source is the document entity that contains the
second name-space location address. For the second name-space location,
the location source is the document entity that contains the
nodes it names.
NOTE 150 The fact that different path steps in different paths might use the same elements as rungs of their location ladders is irrelevant from an information modeling standpoint, but might be of interest to an implementation. The same is true for common elements used in different paths. In other words, with respect to a given location address element, HyTime knows nothing of what is below or to the left of it; it knows only the rungs of its location ladder above (locsrc and its locsrc, etc.) and the steps to the right (the located object and the object it locates, etc.).
When the multloc option is not supported, a location path is always a single sequence of steps connecting a single initial reference to a single object that is not a location address. When the multloc option is supported, any step in a path can address multiple location addresses as well as non-location address elements, creating a "fan out" of the path. However, the end result of resolving a branching location path is a single list of nodes.
NOTE 151 It is an RHE for a step in a location path to address itself directly or indirectly.
Each step in a location path has its own location ladder.
All location addresses operate on and address nodes in groves. Groves are constructed by "grove construction processes" according to a particular property set and grove plan. The ultimate location source for any location ladder is a grove. In HyTime, groves may be addressed implicitly by the rules for implied location sources and the semantics of specialized location address elements. Groves may also be defined and addressed explicitly. In addition, any location address element can use a grove plan different from that used to construct the grove that is its ultimate location source in order to address the grove according to a particular "view".
See A.4 Property Set Definition Requirements (PSDR) for more information on groves in general.
A grove is constructed according to a particular property set, which defines the set of node classes and properties from which a grove is constructed. Each data notation must have its own property set (e.g., the SGML Property Set for the SGML notation, see A.7 SGML Property Set). Which classes and properties are included in the constructed grove is determined by the "grove plan" used by the grove constructor. The grove plan is either specified explicitly or is a default grove plan, defined either in the property set itself or through some other defaulting mechanism. The grove plan that includes all classes and properties in the property set is the "complete grove plan" and results in a "complete grove." Property sets typically define a default grove plan that is not a complete grove plan.
Grove plans are specified by referring to grove plan elements from grove definition elements, data entities, and location address elements. Explicit grove plans and references to them require support for the grovplan option.
Grove plans can be used to control how a grove is viewed by a particular location address. When applied to an already constructed grove, a grove plan acts as a "filter" on the grove for the purposes of resolving the location address.
NOTE 152 The grove plan does not modify the grove from which the addressed nodes are selected. For example, properties of the addressed nodes excluded by the grove plan are still available.
The element form grove plan (grovplan) defines a grove plan for use by location address elements or by a HyTime document (to define the grove plan used to construct a HyTime document's effective SGML grove, see 6.4 HyTime document). A grove plan contains subelements that list the modules, classes, and properties to be included or omitted when constructing or addressing a grove. A grove plan modifies the default grove plan defined in the property set to which the grove plan refers.
The attribute property set (propset) refers to the entity containing the property set definition document to which the grove plan applies.
NOTE 153 It is not necessarily an error if the property set definition document cannot be accessed; an implementation might not require access to it as knowledge of the property set is normally built into the relevant software.
The element forms included modules (inclmods) and omitted modules (omitmods) list modules to be included or omitted. Including or omitting a module does not preclude separately including or omitting classes or properties defined in that module. The omission of a module always supersedes inclusion of the module in the same grove plan. The content of an inclmods or omitmods element must be a list of module names.
The element forms included classes (inclclas) and omitted classes (omitclas) list classes to be included or omitted. The omission of a class always supersedes inclusion of the class. The content of an inclclas or omitclas element must be a list of class names.
The element forms included properties (inclprop) and omitted properties (omitprop) list properties to be included or omitted. The attribute classes from which to include or omit (classes) lists the classes from which the property is to be included or omitted. If no value is specified, the properties are included or omitted from all classes that exhibit the property. The omission of a class always supersedes the inclusion of any of its properties. The omission of a property always supersedes inclusion of the property. The content of an inclprop or omitprop element must be a list of property names.
<!-- Grove Plan -->
<![ %grovplan; [
<!element
grovplan -- Grove plan --
-- Clause: 7.1.4.1 --
-- Specifies a subset of a complete grove's address
space. --
- O
(inclmod?,omitmod?,inclclas?,omitclas?,inclprop?,omitprop?)
-- Constraint: Can include classes and properties
from omitted modules (but not properties from
omitted classes). --
-- Attributes [locs]: grovplan --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
-- Referrers [locs]: agrovdef:grovplan, dgrvplan:grovplan,
egrovplan:grovplan, lgrvplan:grovplan, pgrovdef:grovplan --
>
<!attlist
grovplan -- Grove plan --
-- Clause: 7.1.4.1 --
propset -- Property set definition document --
ENTITY -- Constraint: not an error if the property
set document entity is not available. --
#REQUIRED
>
<!element
-- inomcomp -- -- Include component/omit component elements --
-- Clause: 7.1.4.1 --
(inclclas,inclmod,omitclas,omitmod)
- O
(#PCDATA) -- Lextype: cnmlist --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!element
-- inomprop -- -- Include property/omit property --
-- Clause: 7.1.4.1 --
(inclprop,omitprop)
- O
(#PCDATA) -- Lextype: cnmlist --
-- Attributes [locs]: inomprop --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist
-- inomprop -- -- Include property/omit property --
-- Clause: 7.1.4.1 --
(inclprop,omitprop)
classes -- Classes from which to include or omit the named
properties --
NAMES
#IMPLIED -- Default: all classes that exhibit the
property. --
>
]]><!-- grovplan -->For HyTime document elements, the attribute grove plan (grovplan) refers to the grovplan element to be used to control the construction of the HyTime extended SGML document grove for this document. The grove plan element can be in another document if external referencing is supported.
<!-- HyTime Document Grove Plan -->
<![ %grovplan; [
<!attlist
-- dgrvplan -- -- HyTime document grove plan --
-- Clause: 7.1.4.1 --
(HyDoc)
grovplan -- Grove plan --
-- Grove plan for HyTime extended SGML document
grove --
CDATA -- Reference --
-- Reftype: grovplan --
#IMPLIED -- Default: HyTime default grove plan --
>
]]><!-- grovplan -->For data entities named as location sources, the data attribute grove plan (grovplan) refers to the grovplan element to be used to control the construction of the principal grove for an entity. The value is interpreted as a direct or indirect ID reference to a grove plan. The grove plan element can be in another document if external referencing is supported. If not specified, the default grove plan for the entity's data content notation is used.
<!-- Entity Grove Plan -->
<![ %grovplan; [
<!attlist #NOTATION
-- egrvplan -- -- Entity grove plan --
-- Clause: 7.1.4.1 --
#ALL
grovplan -- Grove plan --
-- Grove plan to use when constructing grove from
entity. --
CDATA -- Reference --
-- Reftype: grovplan --
#IMPLIED -- Default: default grove plan for entity's DCN. --
>
]]><!-- grovplan -->For location address elements, the attribute grove plan (grovplan) names the grove plans to be used to interpret the grove that is the direct or indirect location source (7.2 Location source). It is not an error to refer to grove plans for property sets that are not used by the location source.
<![ %grovplan; [
<!attlist
-- lgrvplan -- -- Location source grove plan --
-- Clause: 7.1.4.1 --
(anchloc,dataloc,fcsloc,linkloc,listloc,nmlist,nmquery,nmsploc,
pathloc,proploc,queryloc,relloc,treeloc)
grovplan -- Grove plans --
-- Grove plans that govern resolution of address --
CDATA -- Reference --
-- Reftype: grovplan* --
#IMPLIED -- Default: grove plans of location source groves as
defined by their grove definitions, whether
explicitly specified or implied. --
>
]]><!-- grovplan -->NOTE 154 Indirect addressing may be used to refer to grove plans in a document other than the one in which the location address, grove definition, or HyTime document element that uses it occurs.
As defined by the SGML property set, the principal tree in an SGML document is the tree of elements and their content rooted at the document element. The SGML property set allows everything that can occur within an element to be in an element's content property (and thus be a child of the element for the purpose of tree addressing). However, because HyTime is intended to be used primarily to address elements and their "semantic content" (informally, the content of the element that would normally be presented in a formatted view of the document), HyTime defines a default view of SGML documents that restricts the children of elements to elements and data portions.
The HyTime default grove plan restricts the content of elements to two node types: elements and pseudo-elements. Pseudo-elements represent a contiguous sequence of nodes allowed in mixed content between a tag close and the next tag open.
NOTE 155 Pseudo-elements make it easier to address elements and character data using tree location addresses by making tree positions insensitive to the number of data characters between elements (except in the case of addition or deletion of complete pseudo-elements).
Because they are not considered children of elements in the HyTime default grove plan, comments, markup declarations, and processing instructions are ignored when determining the content of pseudo-element nodes. (But these node classes will be in the content of pseudo-elements returned by HyTime location addresses if the grove was constructed with a grove plan that includes these node classes generally.)
Location addresses default to using the grove plan of the constructed grove. The HyTime default grove plan is used to construct the HyTime effective SGML grove for HyTime documents for which an explicit grove plan is not specified (either through the grovplan attribute of the hydoc element form or the grovplan data attribute for SGML document entities). The HyTime grove plan modifies the SGML default grove plan as defined by the SGML property set (the SGML default grove plan is also the DSSSL default grove plan).
The HyTime default grove plan is:
<!DOCTYPE grovplan [
<?IS10744 ArcBase HyTime>
<!NOTATION HyTime
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR ARCBASE
Hypermedia/Time-based Structuring Language (HyTime)//EN"
>
<!ATTLIST #NOTATION HyTime
ArcDocF NAME #FIXED grovplan
ArcDataF NAME #FIXED HyBridN
ArcDTD CDATA #FIXED "HyTime"
ArcQuant CDATA #FIXED "NAMELEN 9"
ArcOpt CDATA #FIXED "grovplan"
>
<!NOTATION AFDRMeta
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR Meta-DTD Notation//EN"
>
<!ENTITY HyTime
PUBLIC "ISO/IEC 10744:1997//DTD AFDR Meta-DTD
Hypermedia/Time-based Structuring Language (HyTime)//EN"
CDATA AFDRMeta
>
<!ELEMENT grovplan
- - (title,desc,inclmod?,omitmod?,inclclas?,omitclas?)
>
<!ATTLIST grovplan
id ID #IMPLIED
propset ENTITY #REQUIRED
>
<!ELEMENT (title,desc,inclclas,inclmod,omitclas,omitmod)
- - (#PCDATA)
>
<!NOTATION PROPSET
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR ARCBASE
Property Set Definition Architecture//EN"
>
<!ENTITY SGMLProp
PUBLIC "ISO/IEC 10744:1997//DOCUMENT SGML Property Set//EN"
CDATA PROPSET
>
]>
<grovplan propset=SGMLProp id=htdefgp>
<title>HyTime Default SGML Grove Plan</title>
<desc>
Removes processing instructions (pi) from and
adds pseudo-elements (pelement) to the default SGML
grove plan defined in the SGML property set.
</desc><inclmod>
pelement
</inclmod><omitclas>
pi
</omitclas>
</grovplan>When a HyTime engine processes a HyTime document it produces an "effective SGML document grove" that includes classes and properties unique to HyTime. By default the effective SGML grove is constructed using the HyTime default grove plan. However, the HyTime document element can name a different grove plan to use when constructing the effective SGML grove for the document using the grovplan attribute of the hydoc element form (see 7.1.4.1 Grove Plan).
The ultimate location source for any location address is a grove, represented by the grove root. The grove definition element forms enable explicit references to groves. Reference to a grove definition causes the construction of the grove if it has not already been constructed. A grove definition associates source data (the "grove source") with a grove construction process definition and, optionally, a grove plan.
A HyTime engine constructs only one grove for each combination of grove source and grove construction process. If two or more grove definitions share both grove source and grove construction process, the grove plan of the constructed grove is the union of the sets of classes and properties defined by the grove plans of the grove definitions. The grove plans specified by each grove definition then act as filters over the constructed grove, just as for grove plans specified by location address elements, but applying to all further processing based on that particular grove definition.
The element form primary grove definition (pgrovdef) defines groves constructed from data that is not already in a grove (for example, an unparsed SGML document). The attribute grove source (grovesrc) refers to the entity that contains the source data. The attribute grove construction process (grovecon) names the grove construction process to be used. If grovecon is not specified, the grove construction process is defined by the notation of the grove source entity.
NOTE 156 The values of attributes defined for the grove construction process may be specified through use of the DAFE facility of the General Architecture (see A.5.3 Data Attributes for Elements (DAFE).)
The attribute grove plan (grovplan) refers to the grove plan that controls the construction of the grove. If grovplan is not specified, the grove plan is the default grove plan used by the grove construction process (which may be the default grove plan defined by the property set for the source entity's notation).
The element form auxiliary grove definition (agrovdef) defines groves constructed from nodes in an existing grove (for example, an SGML document grove). The attribute grove source (grovesrc) addresses, directly or indirectly, the nodes from which the auxiliary grove is constructed. The attribute grove construction process (grovecon) names the grove construction process to be used. A grove construction process must be specified for auxiliary groves. The attribute grove plan (grovplan) refers to the grove plan that controls the construction of the grove. If grovplan is not specified, the grove plan is the default grove plan used by the grove construction process.
Support for the grovedef option allows both pgrovdef and agrovdef to be used.
<!-- Primary Grove Definition -->
<![ %pgrovdef; [
<!element
pgrovdef -- Primary grove definition --
-- Clause: 7.1.4.4 --
- O
(%HyCFC;)*
-- Attributes [locs]: pgrovdef --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist
pgrovdef -- Primary grove definition --
-- Clause: 7.1.4.4 --
grovesrc -- Grove source --
ENTITY
#REQUIRED
grovecon -- Grove construction process --
NAME -- Lextype: NOTATION --
#IMPLIED -- Default: inherent in notation of grove source --
grovplan -- Grove plan --
CDATA -- Reference --
-- Reftype: grovplan --
#IMPLIED -- Default: default grove plan of grove
construction process. --
>
]]><!-- pgrovdef --> <!-- Auxiliary Grove Definition -->
<![ %agrovdef; [
<!element
agrovdef -- Auxiliary grove definition --
-- Clause: 7.1.4.4 --
- O
(%HyCFC;)*
-- Attributes [locs]: agrovdef --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist
agrovdef -- Auxiliary grove definition --
-- Clause: 7.1.4.4 --
grovesrc -- Grove source --
CDATA -- Reference --
#REQUIRED
grovecon -- Grove construction process --
NAME -- Lextype: NOTATION --
#REQUIRED
grovplan -- Grove plan --
CDATA -- Reference --
-- Reftype: grovplan --
#IMPLIED -- Default: default grove plan of grove
construction process. --
>
]]><!-- agrovdef -->| 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.