A quick (and possibly dirty) hack of the SGML source of the public WG8 N 1920 ("Final Text of the HyTime TC", May 1997) to HTMLish markup. This representation is therefore unofficial: use the SGML source on the WG8 server for official purposes, or see the official HTML version from the editors. June 21, 1997.
Contents
This annex states the requirements for the formal definition of the architectural forms by which an enabling document architecture governs the SGML representation of its documents.
The formal definitions of the HyTime architectural forms satisfy these requirements and (without loss of generality) are used to illustrate them.
A document architecture, as that term is defined in ISO 8879, can be "encompassing", governing every aspect of its documents' representation and processing. The document representation requirements for an encompassing architecture are expressed formally -- at least insofar as SGML is capable of expressing them -- in a document type definition (DTD).
A document architecture can also be "enabling", in which case it does not specify complete document types. Instead, an enabling architecture defines rules, known as "architectural forms", that application designers can apply in their document type definitions. These rules, and the associated architectural semantics, are described in an "architecture definition document". The set of formal SGML specifications of the architectural forms, and related declarations for an enabling architecture, comprises a "meta-DTD".
Conceptually, there are two steps to architectural processing. In the first step, generic architectural processing, a generic architecture engine validates a client document against the meta-DTD of its base architectures and, optionally, creates an architectural instance for each base architecture. In the second step, an architecture-specific semantic engine processes both the relevant architectural instances and the client document in order to implement and/or validate architecture-specific semantics.
In practice, these steps may be combined into a single architecture- or application-specific processor. In other words, an application-specific processor may implement architecture-defined semantics without doing generalized architectural processing.
Architectural forms are rules for creating and processing components of documents, just as document architectures are rules for creating and processing documents. There are four kinds:
This is defined by an element type declaration in conjunction with an attribute definition list declaration. The element type declaration can have a content model that constrains the elements conforming to the form.
This is defined solely by an attribute definition list declaration. Its attribute definitions can be used only with designated element forms.
This is defined by a notation declaration in conjunction with an attribute definition list declaration.
This is defined solely by an attribute definition list declaration for a notation. Its attribute definitions can be used only with data entities conforming to the associated notations.
An element type whose instances conform to an element form defined by, say, the "ArcName" architecture, is informally called an "ArcName element type", even though the element type itself is not defined by the ArcName architecture, but by an application. An instance of such an ArcName element type is called an "ArcName element". An element, notation, data portion, or attribute that does not conform to an architectural form is termed "non-architectural".
An application DTD can include element types of different enabling architectures, element types that conform to no formally-defined architecture (other than the encompassing architecture represented by the DTD itself), and element types that conform to several enabling architectures at once. Where multiple architectures govern a document, the rules of each are enforced without regard to objects that are non-architectural with respect to it.
The enabling architectures that govern a DTD are called its "base" architectures. The DTD is their client and its architecture is said to be "derived" from the base architecture. An enabling architecture can itself be derived from one or more base architectures.
For example, the full HyTime architecture is derived from the HyBase architecture, which is in turn derived from the General Architecture.
An individual element cannot conform to more than one element type form of a given architecture. It can, however, conform to multiple attribute forms unless prohibited by the rules of the particular architecture.
A derived architecture is unaware of whether its base architecture is itself a derived architecture. For this reason, an element can conform to the element forms of two base architectures even when one of the architectures is derived from the other.
Most architectural information is conveyed by attributes, which are classified as follows:
These describe the semantics of the architecture. They are semantically defined in the architectural definition document, declared in the meta-DTD and client DTD or LPD, and specified in the client document instance or LPD.
These describe properties of a client document's use of the architecture as a whole, including the names of architecture control attributes (see below). Generic support attributes for all architectures are semantically defined in the AFDR, which provides templates for them. Architecture-specific ones are semantically defined in the architecture definition document, which should also provide templates for them. Support attributes are declared in the client DTD or LPD and specified using the default value parameter of the definitions.
These allow architectural parsing and processing to be controlled from the document instance. They are semantically defined in the AFDR, which provides templates for them. Control attributes are declared in the client DTD or LPD, and specified in the client document instance or LPD.
For an SGML document and each of its base architectures there exists an "architectural document" that is a derivation of the SGML document. The architectural document for a base architecture consists only of the element types, notations, attributes, and data defined in that base architecture's meta-DTD, as affected by the document's architecture control attributes.
The syntax and structure of architectural forms and element types are specified rigorously using SGML markup declarations. The declarations conform to valid SGML syntax in every respect, except for two modifications to attribute definition list declaration syntax, as identified later in this annex.
This practice permits the declarations to be copied for use as models when creating DTDs derived from the architecture. It also allows any DTD to serve as a meta-DTD.
Although any DTD can serve as a meta-DTD, architecture definition documents (such as this International Standard) use a convention to distinguish meta-DTDs from application DTDs when both are being discussed. Declarations used to define architectures are presented with the declaration names in lower-case. Those that define application document types follow the normal SGML convention; their declaration names are presented in upper-case. Declarations that are templates (that is, they are intended to be customized and used in an application DTD) have their declaration names in mixed-case.
Some templates are actually "template forms", in that they must first be customized into templates by an architecture definition document, then customized again for use in an application DTD. These declarations are presented as templates when they are in a state that requires customization prior to use in an application DTD, but they are presented as application declarations when further customization is merely optional (that is, when they can be used as-is if the user accepts the recommended names and attribute values).
An element form is defined by an element type declaration, optionally in conjunction with an attribute list declaration.
The structure of an element form is defined by a "meta" content model in the element type declaration. The model is "meta" in the sense that its "element types" is really an architectural form and means "any element conforming to that form". An application DTD could therefore define several element types conforming to a given architectural form. Moreover, each could have a different content model as long as it allowed content that satisfies the meta-model.
The text of the document that specifies the architecture (the "architecture definition document") states whether the architecture associates any semantics with the content of an element form. If the text is silent, subelements have no special semantics in their role as content of their containing element. However, they still have their normal architectural semantics as individual elements.
For example, no special HyTime semantics are defined for the content of an activity policy association rule element, but a contextual link element occurring in the content would retain its normal HyTime semantics.
As with a normal content model, a meta-model can incorporate inclusion exceptions. However, the meaning and effect are different in the two cases. In a normal content model, an inclusion means that an occurrence of an included element is transparent to its surroundings, which affects record-end handling in SGML and can have semantic consequences in architectures and applications. In a meta-model, inclusions are strictly a syntactic convenience with no implications for the included element.
Use of inclusions in an element type declaration's meta-model means that the architecture allows elements of the named forms to occur anywhere in the declared element's content in the document instance, including the content of subordinate elements. The application designer can choose, in his DTD, to require the elements to be proper subelements, inclusions, or both. The fact that an element type was an inclusion in the architecture does not necessarily mean it would be an appropriate inclusion in the DTD.
An example of a content meta-model with an inclusion is:
The construct "(a|b|c)*" is a model group while "+(x|y)" is called an "inclusion exception" in SGML. It means that the element types in parentheses can occur at any level of the element structure. In contrast, element types in the model group can occur only as "proper subelements", in the immediate content.]]>
The omitted tag minimization parameter is primarily a suggestion to the DTD designer. It may also affect architectural processing during the creation of architectural documents by enabling the recognition of architectural elements by normal SGML markup minimization rules. (For example, architectural data in a client document may imply the start of the architectural element that contains the data in the architectural document.)
The set of declarations defined in an architecture definition collectively represent a meta-DTD. The occurrence of an architectural object in a document instance is checked against the meta-DTD to see if it is allowed. Other objects are not checked.
Data is considered architectural only when it occurs at a point where the meta-DTD allows data. This rule includes data in the content of non-architectural elements (unless architectural processing has been suppressed for the descendants of that element as described in [arcsupr]). Otherwise, data does not affect the checking against the meta-DTD.
This requirement means that architectural form definitions need not provide for the occurrence of non-architecture element types. For example, in HyTime, the following would be valid, even though the nameloc form does not include title or description subelements:
... ]]> All About Otters aao Locates the section on "Athletic Achievements"
Any failure of a document instance to conform to the meta-DTD is a reportable architecture error (RAE). In particular:
It is an RAE if an element occurs in a document instance at a point where its architectural form is not permitted by the meta-DTD of that form's architecture.
It is an RAE if, at a point in a document instance where a meta-DTD requires data or an instance of a particular architectural form, the required object fails to occur.
It is an RAE if the value of an architectural attribute does not satisfy its declared value.
An architecture does not constrain the construction of document type definitions, only document instances. For example, any document's DTD can declare HyTime as a base architecture, as long as its document instance conforms to HyTime.
A validating architecture engine can optionally report DTD constructs (such as poorly designed content models) that would prevent the creation of a valid conforming instance, or that would allow the creation of a nonconforming instance.
A meta-DTD is flexible and does not necessarily clarify all issues of contextual relevance; some elements may be meaningful only in the context of other elements from which they are referenced, or only as resources for the processing of other elements.
The meta-DTD comprising all of the SGML definitions of an architecture necessarily includes all of the architecture's optional facilities (if any). In contrast, for any given architecture implementation's system declaration (see [arcdec]) there will be a single meta-DTD that permits only the optional facilities supported by that system. Moreover, the actual meta-DTD applicable to a given document could be more restrictive than either of those, depending on the facilities required by that document (see [arcdoc]). The constraints of a more restrictive meta-DTD that is required by a document's architecture support declarations can also be enforced by the document's DTD.
The declared content or content model of an application's element type can differ from the meta-model of the architectural form as long as it allows instances that conform to the architectural form meta-model. For example, a meta-model might be "(a|b|c)". An application designer could legally exclude the possibility of "c" by using the content model "(a|b)" (or even "(a|x)", except that if an "x" occurred in the instance it would be an RAE).
As with normal DTDs, parameter entities can be used in the construction of meta-DTDs. The parameter entity declarations are primarily an aid for tailoring the meta-DTD to correspond to any modularization of facilities supported by the architecture definition document. They can be used in conjunction with marked sections for automatic tailoring in conjunction with the ArcOptSA attribute (see [arcctl]). They can also serve to document relationships among the architectural forms, but otherwise have no semantic significance.
The meta-DTD of a derived enabling architecture is a "derived meta-DTD". The meta-DTDs of its base architectures are its "base meta-DTDs". The meta-DTDs of base architectures of application DTDs are the application's base meta-DTDs.
An architectural element type's attribute definition list in an application DTD includes the ArcForm attribute, which identifies the architectural form. The ArcForm attribute is unique in that it must be defined for every element type whose instances are to be processed in a manner defined by the architecture (unless architectural markup minimization is used, as described in [arcmin]).
Normally, every element of the same type has the same architectural form, which allows the ArcForm value to be fixed in the DTD. However, this is not a requirement: an element type definition, could, for example, allow its instances to be one of a choice of architectural forms.
The other attribute definitions follow the conventions described in [attcon].
An attribute form defines attributes that can be used in the attribute definition lists of element types conforming to one or more element forms, including SGML processing link attribute lists. The element forms with which the attributes can be used are indicated by declaring their names as associated element types.
In a meta-DTD, unlike a normal DTD, there can be more than one attribute definition list declaration associated with the same element type. Moreover, if the associated element type is specified as the reserved name "#ALL", the attributes can be used with any of the architecture's element forms. (Such attributes are known as "common attributes".) These two facilities are part of the "AFDR meta-DTD notation" extensions and can be used only in a meta-DTD.
It is not an error if the same attribute name occurs in more than one such declaration, but later definitions of the same attribute name for the same associated element type have no effect. The order in which the declarations are parsed governs, except that common attribute declarations are considered to follow all the other attribute definition list declarations.
As SGML requires that an attribute name be unique in its attribute list, designers should make sure that a common attribute -- which could occur in all attribute lists -- has a name that is different from all other attribute names in the architecture.
In an application DTD, "#ALL" cannot be specified as SGML does not allow it. Nor can more than one attribute definition list declaration be associated with the same element type.
An attribute form can also be defined for use with notation forms by specifying their names as associated notation names in the attribute definition list declaration. In meta-DTDs, the same extensions are available for these as for associated element types. The same rules regarding common data attributes can be used with all of the architecture's data attribute forms.
All architectural attributes, whether part of an element form or an attribute form, are specified using the conventions in this sub-clause.
For a given element or notation form, an application can replace an attribute's architecture-defined name by using the "ArcNames" attribute (see [arcatt]).
It is a reportable architecture error if a document instance contains a value for an attribute that fails to satisfy the declared value defined for it in the meta-DTD.
As an attribute value must satisfy an attribute definition in both the meta-DTD and the client DTD, there is a possibility for a conflict of concrete syntaxes. For this reason, it is recommended that the concrete syntax of a meta-DTD be designed for use with all expected client documents. The broader the potential use, the closer the concrete syntax (and particularly its name spelling rules) should be to the reference concrete syntax (or the usual concrete syntax of the expected user community, if different).
An architecture's attributes are categorized as being "mandatory" or "non-mandatory", and also as being "constant" or "variable", as follows:
Non-mandatory attributes
These attributes may be defined in the application DTD, but need not be. If an attribute is not defined in the client DTD, the architecture either provides a default value either as part of the attribute definition in the architecture meta-DTD, or, in the case of an impliable or content reference attribute, documents the default behavior as part of the architecture definition document. The non-mandatory status of an attribute is documented in the default value prescription of the attribute definition by the presence of "#IMPLIED", "#CONREF", or a literal (possibly fixed) default value.
If a non-mandatory attribute is not defined, or a defined impliable attribute has no default value and is not specified on the start-tag, the architectural semantic processor uses the default value documented in the architecture definition document.
An application can conveniently specify the defaulting of impliable attributes by using the default value list facility of the General Architecture (see [dvl]).
Mandatory attributes
These attributes must be defined in the application DTD and values must be provided by the application, either by defaulting or by an attribute specification. The mandatory status of an attribute is documented in the default value prescription of the attribute definition by the presence of "#REQUIRED".
When an architecture definition document modularizes an architecture, an optional facility could have attributes that are mandatory with respect to that facility. The meta-DTD used by a client document must contain all the declarations that are required by the facilities used by the document. It need not contain declarations that are required by optional facilities that are not used.
Constant attributes
The default value prescription of an architectural attribute may be the token "#FIXED" followed by a default value specification; this denotes a constant attribute whose value must always be equal to its default.
If an attribute is fixed in the meta-DTD, an application should not declare it at all; this ensures that it will always be assigned its default value. Alternatively, it may be declared as a fixed attribute with a default value identical to the architectural default value.
Variable attributes
An attribute that is not a fixed attribute is a variable attribute.
In an application DTD, the default value prescription for a variable attribute, whether mandatory or not, can use any keyword or attribute value specification allowed by SGML. The form used to document the attribute in the architecture definition is irrelevant.
Some attributes defined in the HyTime architecture are variable with respect to their associated element forms, but are required to be constant with respect to client element types. See [notation] for details.
The following list gives examples of the forms of declared value and default value prescriptions used to document each combination of attribute categories:
Mandatory
Non-mandatory/fixed
Non-mandatory/variable
SGML processing link attribute lists can be used to specify both architectural attributes and architecture control attributes for base architectures declared in the source document DTD. When an element has both a link attribute and an SGML source element attribute with the same name, only the link attribute will be considered for architectural processing, with the exception of the "ArcNames" architecture control attribute (see [arcnamr]).
A document indicates conformance to architectures by using an architecture base declaration (ArcBase).
An ArcBase declaration identifies one or more base architectures of a DTD or a derived meta-DTD. It cannot be used in a meta-DTD that is not derived. It should precede the architecture support declarations pertaining to the base architectures that it identifies. There can be more than one ArcBase declaration in a DTD or meta-DTD.
Syntactically, the ArcBase declaration is a processing instruction
(PI), not an SGML markup declaration. In the template below, it is
shown in the reference concrete syntax. In use, the ArcName-list
parameter must be replaced by one or more architecture names (ArcName)
declared as notation names, separated by SGML
The declaration name is the initial character string, up to the first s separator. The declaration name is subject to upper-case substitution if the SGML declaration of the client document specifies general upper-case substitution.
The name is normally "ArcBase" but it can be changed using the APPINFO parameter of the SGML declaration, if necessary, to avoid the (admittedly unlikely) possibility of conflicts when retrofitting an architecture to a document that already has PIs that begin with "ArcBase " (see [appinfo]).
The ArcBase declaration will only be recognized in the DTDs and LPDs with respect to which the document is being parsed.
]]>
To determine when enabling architectures are in use, the APPINFO parameter of the SGML declaration is parsed as a space-delimited sequence of tokens. Conformance of a document to one or more architectures defined in accordance with these requirements is indicated by specifying the keyword "ArcBase" as such a token. The keyword indicates the potential presence in one or more DTDs or LPDs of an architecture base (ArcBase) declaration that identifies the "architecture support declarations" for the architectures on which the DTD is based. The use of the APPINFO parameter to indicate conformance to an architecture is optional.
The use of APPINFO serves to declare the use of architectures within SGML declarations. However, it is sufficient to enable architectural processing to declare the use of an architecture with the ArcBase declaration within DOCTYPE declarations.
The format of the token is:
where "ArcBase" is not case-sensitive. The token can also specify the name of the ArcBase declarations in the document's DTDs and LPDs if it is other than "ArcBase". The format is:
The APPINFO parameter is interpreted as an s-separator-delimited list of tokens.
Specification of the ArcBase name to be used in documents is optional when the name of the ArcBase declarations is ArcBase.
A DTD contains architecture support declarations for each architecture on which its instances are based. There is a notation declaration that identifies the architecture definition document (including the architecture version, if any) and an external entity that contains the meta-DTD. Associated with the notation declaration is an attribute definition list declaration for "architecture support attributes".
It is not necessarily an error if the definition document and/or meta-DTD cannot be accessed, as an implementation might not require access to these objects. The primary purpose of the declarations is to declare and specify architecture support attributes. However, the meta-DTD must be accessible if the architecture engine is to produce a parsed architectural document.
To the extent permitted by SGML, architecture support declarations should precede other declarations.
Each base architecture name (ArcName) specified in an ArcBase declaration must be declared as a notation name in a notation declaration that identifies the architecture definition document. (It is recommended that such notation declarations be identified by the use of a formal public identifier in which the public text description component begins with the words "AFDR ARCBASE".)
The template for such a declaration is shown below. In use, ArcName is replaced by the actual notation name for the architecture, as specified in the ArcBase declaration. The conformance statement shows that the architecture client claims conformance to the AFDR. (It does not indicate conformance to the HyTime architecture.)
]]>
There must be an attribute definition list declaration for each architecture notation declaration to define mandatory architecture support attributes. An individual architecture can define additional architecture support attributes of its own.
The template for such a declaration is shown below. In use, ArcName is replaced by the actual notation name for the architecture and the default values prescriptions are replaced by the desired values of the support attributes. For non-mandatory attributes, the "Default:" conventional comment states the effect of not declaring the attribute.
The attribute
This attribute does not appear in the meta-DTD unless the meta-DTD is also a client DTD, in which case the attribute's value would be an architectural form name from its base architecture, not from the client DTD. For example, an architecture derived from HyTime would define its own architecture naming attribute, e.g. "MyArch". This attribute would be used in client documents derived from the MyArch architecture but would not appear in the MyArch meta-DTD. Because the MyArch architecture is derived from HyTime, the meta-DTD would use the HyTime attribute to define the derivation of MyArch element forms from HyTime element forms.
The ArcName can be used as the name of the ArcForm attribute. For example, "HyTime" is both an architecture name and the name of that architecture's ArcForm attribute.
The attribute
The attribute
The attribute
The attribute
The attribute
In the reference syntax, this means that the meta-DTD entity name must be in upper case.
The following three attributes are used in connection with "architectural markup minimization" (which is described in [arcmin]):
The attribute
The attribute
The attribute
When an architecture definition document modularizes an architecture, an application designer can define additional support attributes that identify the facilities for which support may be required by the document. Additional support attributes can also be used to specify attributes that are properties of documents (as opposed to being properties of the document element), or to set parameters for the initialization of architectural processing. The architecture support attribute declaration is passed by the architecture engine to the architectural semantic processor at the end of the prolog.
One useful modularization technique, which was applied to the HyTime architecture, is to create a master meta-DTD that is modularized by means of marked sections. Each marked section start contains a parameter entity reference whose entity name is that of the facility (or optional component of a facility) whose declarations are in the marked section. When those entities are declared with the entity text "INCLUDE", the declarations are included in the meta-DTD; when the entity text is "IGNORE", they are not.
The attribute
A single architecture options attribute will suffice for simple architectures, which may have little or no modularization. For a large modularized architecture such as HyTime, it can be convenient to have a separate options attribute for each module that names the included optional facilities of that module.
It is an error if a document requires an architecture facility that is not identified in the support declarations, but a system is not required to report such an error as it may not be able to do so. However, it is not an RAE if the declarations identify facilities that are not actually required by the document.
A system is free to supply facilities for which support requirements were not declared, if it is capable of doing so.
If a system attempts to process a document whose support declarations identify facilities that the system does not support (see [arcdec]), the system must report an error even if the document does not actually use those facilities.
In other words, a system can give the user the option of ignoring an "unsupported facility" error, but it must report the error in the first instance.
Identification of a facility implies automatic identification of any facilities on which it is dependent.
]]>
The value of the ArcDTD support attribute must be declared as an entity name in an entity declaration that identifies an architecture meta-DTD to which the document instance conforms. The meta-DTD entity must conform to the SGML declaration of the client document, except for the quantity set variations specified in the ArcQuant support attribute.
If the architecture has architecture-specific support attributes, it is not an error if they are more or less restrictive than the meta-DTD. The document instance must conform to both.
It is possible (though not required) for meta-DTDs to be processed by a generic "architecture engine". Such an engine behaves similarly to an SGML parser validating conformance to a DTD, except that:
Element form names, rather than GIs, are checked against the meta-content models.
The AFDR meta-DTD notation is recognized (see [AFDRmeta]).
Several templates for architecture entity declarations are shown below. In use, the string "ArcName" is replaced by the actual notation name for the architecture. The choice of template depends on whether the AFDR meta-DTD notation is used and, if not, whether the meta-DTD is also incorporated within the client DTD by means of a parameter entity reference.
In either case, it is only accessed directly by the architecture engine (if at all), outside the parsing context of the document.
]]>
Architecture control attributes allow architectural parsing and processing to be controlled from the client document instance. The names of the architecture control attributes are specified as values of corresponding architecture support attributes (see [arcatt]).
Note that a single client element may have as many sets of architectural control attributes as the client document has base architectures.
An architecture does not declare architecture control attributes in a meta-DTD. Instead, the client declares them for those element types and notations that require them.
The architecture control attribute
The actual name of the attribute should not be ArcForm; it must be unique for each base architecture and should ideally be unique among all the attribute names in client documents. The actual name is specified by the ArcFormA attribute of the architecture notation declaration.
A client must declare the ArcForm attribute for every architectural element and external data entity, except where architectural markup minimization is used (see [arcmin]).
An architecture engine uses this attribute to determine the architecture-specific processing that the architectural semantic processor will perform, and to know which architecture-defined attributes to examine. The application processor supplements this processing by using the application-defined element type and other attributes to determine the application-specific processing to perform. In object-oriented programming terms, an application-defined derived class (the element type) inherits the properties of its base class (the architectural form).
It is an RAE if a document instance contains a value for the architectural form attribute other than one specified in the meta-DTD.
In other words, an architecture's set of architectural forms cannot be extended by an application (but see [arcder]).
]]>
The architecture control attribute
If the substitute name is "#CONTENT", the value of the attribute occurs as the syntactic content of the element in the client document. The syntactic content of the element is converted into the attribute value by concatenating the data from the leaves of the tree rooted at that element. In this case the syntactic content is not treated as architectural content.
The architectural content will therefore be empty unless some attribute value in the client document is serving as the source of architectural content because of the use of "#ARCCONT".
A substitute name may be followed by one or more triples of tokens each consisting of "#MAPTOKEN" followed by two name tokens. These specify user substitutes for architecture-defined tokens occurring in the value of this attribute. If a token in a value specified for this attribute in the client document is equal to the second token, then it will be replaced by the first token. If "#MAPTOKEN" is specified for an architecture-defined attribute whose declared value is CDATA then the value of the attribute shall be tokenized before tokens are substituted.
The attribute might have to be declared as CDATA because, for example, it could contain tokens starting with the RNI delimiter.
Architectural syntactic data content can be entered as an attribute value by specifying the architectural attribute name as "#ARCCONT" and naming the client attribute in whose value it will occur. In this case, any syntactic content in the client document is considered non-architectural.
As always, the data must satisfy the lexical and semantic constraints of both the architectural form and the application element type. For example, although comment declarations can be intermixed with parsed character data in syntactic content, they are not allowed if the data is entered as an attribute value.
A single element may have both an ArcNames source element attribute and an ArcNames link attribute. In an ArcNames source element attribute value, an ATTNAME must refer to a source element attribute. In an ArcNames link attribute value, an ATTNAME is first assumed to be that of a link attribute. However, if no such link attribute exists, an identically named source element attribute will be used if it exists.
It is an RAE if ArcNames is used in a way that causes conflicts or duplications.
]]>
The architecture control attribute
Completely suppress all architectural processing of descendants. It is not possible to restore architectural processing for a descendant.
Suppress processing of the ArcForm attribute of all descendants of this element, except for those elements that have a non-implied ArcSupr attribute.
Don't suppress architectural processing for the descendants of this element.
If an element has an ArcSupr attribute that was processed, its ArcForm attribute will always be processed. Otherwise its ArcForm attribute will be processed unless its closest ancestor that has a non-implied value for the ArcSupr attribute suppressed processing of the ArcForm attribute. An element whose ArcForm attribute is processed will not be treated as architectural if it has an implied value for the ArcForm attribute.
For example, "sArcAll" suppresses all architectural processing at any level of the element's content, while "sArcForm" allows the possibility that a descendant element's ArcSupr attribute could restore processing within its own content.
The suppression of architectural processing can be useful if architectural elements are to be used for other purposes; for example, to display or edit HyTime resource elements within a HyTime document.
When sArcForm is specified, meta-model checking is suspended. The element can therefore contain any of an architecture's elements, even those that normally are not part of the ArcCFC (that is, that can occur only in the content of some other architectural element). This freedom is possible because the architectural processing is suppressed, and therefore does not require the processing context that would have been established by the omitted containing element.
]]>
The architecture control attribute
Data is not ignored. It is an error if data occurs where not allowed by the meta-DTD.
Data is conditionally ignored. Data will be ignored only when it occurs where the meta-DTD does not allow it.
Data is always ignored.
The value may also be implied, in which case the state of architectural processing is inherited. If the document element has no value specified, cArcIgnD will be used.
]]>
This clause discusses other considerations related to architectures.
Every architecture must provide the element form
The ArcDoc form allows an architecture to define attributes for the document element, and to specify the "architectural context-free content" (ArcCFC). The ArcCFC is the set of element forms that can occur independently at the highest level of a document.
As not all architectural elements have constrained content models, there could be many forms for which ArcCFC is the permitted content. A useful convention is to declare an ArcCFC parameter entity for reference in element form declarations.
A template for declaring a document element form is shown below. In use, ArcDoc is replaced by its actual name and a name other than ArcCFC could be used for the content entity. The architecture designer could add the architecture's own attribute definitions for the document element form.
Designers may choose to have meta-inclusions in %ArcCFC as well as a model group. Alternatively, they may choose not to have an ArcCFC entity at all.
]]>
Architectural markup minimization allows the determination of the architectural form of an element or an external data entity even when there is no explicitly specified ArcForm attribute. The value of the ArcAuto architecture support attribute determines whether minimization is in effect. If so, the values of the ArcBridF and ArcDataF architecture support attributes determine the default form, in accordance with the following procedure:
If the ArcForm architecture control attribute is declared:
If ArcForm is implied, the object is non-architectural.
If ArcForm has a value, the architectural form is that value.
If the ArcForm architecture control attribute is not declared:
If the object is the document element, the architectural form is ArcDoc.
This is a mandatory form of minimization; the others are optional.
If not, and the ArcAuto support attribute is ArcAuto and the element type or notation name of the object is the same as that of an element form or notation form name in the meta-DTD, that form is considered the architectural form of the object.
The external identifiers in the meta- and client notation declarations need not be the same.
If not, and the object is an element with an ID, use the ArcBrid form name if one was specified.
If not, and the object is an external data entity, use the ArcData form name if one was specified.
If not, the object is not architectural.
An enabling architecture can be derived from one or more base architectures by the same means that a DTD is derived from one or more base architectures. That is, an ArcBase declaration and support declarations for the specified base architectures are present in the meta-DTD. A derived architecture can also serve as a base architecture for DTDs and for other derived architectures.
This facility provides designers the tools for subclassing and scaling SGML information bases without compromising the accuracy and consistency obtained from SGML's rigorous document type conformance checking. It brings to document data modeling OOPS benefits like multiple inheritance and encapsulation, while preserving SGML's ability to control a document's properties through a single coherent document type definition.
A conforming instance of a derived architecture provides the information needed to construct a conforming instance of each of its base architectures. Therefore, if a system does not support the semantics of a derived architecture, it could, as an error-recovery fallback, treat the document as an instance of a base architecture instead.
Just as an architecture engine can construct an architectural document for a base architecture of a client document, so can it construct architectural documents for the base architecture(s) of architectural documents.
The following rules apply with respect to the relationship of attributes declared for an element form in a meta-DTD ("base attributes") and attributes of an element of that form in a client document ("client attributes"):
If a base attribute has a declared value prescription of ID (an "ID attribute"), then a client ID attribute will be treated as the corresponding architectural attribute regardless of whether the attribute names are the same or whether there is an ArcNames attribute.
If a value is specified for a client attribute whose base attribute is an ID attribute, the client attribute must also be an ID attribute.
A client attribute value satisfies a base attribute whose declared value is ENTITY or ENTITIES if it is the name of an architectural general entity declared in the client document. An entity is architectural if it is a SUBDOC or an external data entity that has an architectural form.
An external data entity can have an architectural form by virtue of either an explicit ArcForm attribute or through architectural markup minimization.
A client attribute value satisfies a base attribute whose declared value is NOTATION if it is the name of a notation declared in the meta-DTD and allowed as a value of the base attribute, or if the value of the client attribute is the name of a notation derived from a notation declared in the meta-DTD and allowed as a value of the base attribute.
A client architectural attribute value satisfies a base attribute whose declared value is IDREF if there is an architectural element with that ID as the value of a client architectural attribute whose base attribute is an ID attribute.
These options are used in SGML Extended Facilities system declarations to indicate the capabilities of generic architecture engines.
The engine can validate conformance to the AFDR.
The engine can construct architectural instances of client documents that conform to the AFDR.
Documents, meta-DTDs, and architecture engines may all conform to this Annex. In addition, this Annex distinguishes validating architecture engines from conforming architecture engines that do not provide complete validation of documents and meta-DTDs against the provisions of this Annex.
A meta-DTD that uses the AFDRMeta extensions shall so indicate by including the following invalid markup declaration as near as practicable to the start of the meta-DTD and before any use of the AFDRMeta extensions:
]]>
A meta-DTD that does not use the AFDRMeta extensions is a valid meta-DTD if the declarations it contains are valid SGML markup declarations.
Documents and meta-DTDs derived from a conforming architecture should so indicate by including the following statement in the architecture support notation declaration:
Conforming architecture engines may be either general or architecture specific. A general architecture engine supports architectural processing independent of the semantics of any architecture. Architecture-specific engines provide architectural processing only for those architectures for which they are designed.
If an architecture engine meets the requirements of this sub-clause it is a conforming architecture engine.
Either form of architecture engine may be a validating architecture engine.
A conforming architecture engine shall require its documents to be conforming SGML documents, and shall not prohibit any markup that ISO 8879 and this Annex would allow in such documents.
For example, an application markup convention could recommend that only certain minimization functions be used, but could not prohibit the use of other functions if they are allowed by the formal specification.
A conforming architecture engine's documentation shall meet the requirements of this International Standard (see [docreq]).
A conforming architecture engine shall not enforce application conventions as though they were requirements of this International Standard.
Warnings of the violation of application conventions can be given, but they must be distinguished from reports of architecture errors.
A validating architecture engine shall find and report a reportable architectural error (RAE) if one exists, and shall not report an error when none exists. Such engines can optionally report other errors and may warn of conditions that are potentially, but not necessarily, errors.
Reports of architecture errors, including optional reports, shall be identified as architecture messages in such a manner as to distinguish them clearly from all other messages, including warnings of potential architecture errors.
A report of a architecture error, including an optional report, shall state the nature and location of the error in sufficient detail to permit its correction.
This requirement is worded to allow implementors maximum flexibility to meet their user and system requirements.
An architecture system declaration is an SGML system declaration as defined in ISO 8879, modified as indicated in this subclause.
A new parameter,
means that all reportable architectural errors will be found and reported.
means that the engine is capable of creating architectural instances from client documents.