A.3 Architectural Form Definition Requirements (AFDR)

Subclauses:

• A.3.2.1 Element forms
  • A.3.2.1.1 Element type declaration
  • A.3.2.1.2 Meta-DTD
  • A.3.2.1.3 Attribute definition list declaration
• A.3.2.2 Attribute forms
• A.3.2.3 Attribute list conventions
  • A.3.2.3.1 Default value prescription
• A.3.2.4 Processing link attributes

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 A.3.5.3 Architecture suppressor attribute). Otherwise, data does not affect the checking against the meta-DTD.

NOTE 400 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:

<!ELEMENT MyNameLoc
  - O (Title?,nmlist+,Desc?)
>
<!ATTLIST MyNameLoc
  HyTime   NAME     #FIXED nameloc
  ...
>

...

<mynameloc>
<title>All About Otters</title>
<nmlist>aao</>
<desc>
Locates the section on "Athletic Achievements"
</desc>
</mynameloc>

Any failure of a document instance to conform to the meta-DTD is a reportable architecture error (RAE). In particular:

1. 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.

2. 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.

3. 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.

NOTE 401 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 A.3.4 Architecture support declarations) 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 A.3.6.1 Architectural document element). 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.

NOTE 402 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)". The content model "(a|x)" could also be used. In that case, if "x" is not architectural (it is not derived from any form in the architecture or is not taken to be architectural) it would not be an architectural error for "x" to occur (because non-architectural elements are simply ignored for the purpose of validation against an architectural meta-DTD). If "x" is architectural, 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 A.3.5 Architecture control attributes). 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 A.3.6.2 Architectural markup minimization).

NOTE 403 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 A.3.2.3 Attribute list conventions.

1. 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.

   NOTE 408 An application can conveniently specify the defaulting of impliable attributes by using the default value list facility of the General Architecture (see A.5.6 Default value list).

2. 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.

3. 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.

   NOTE 409 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.

4. 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.

   NOTE 410 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 5 Notation for details.

NOTE 411 The following list gives examples of the forms of declared value and default value prescriptions used to document each combination of attribute categories:

1. Mandatory

               NAMES     #REQUIRED

2. Non-mandatory/constant

               NOTATION  #FIXED SDQL

3. Non-mandatory/variable

               NUMBER    #IMPLIED
               NAME      #CONREF
               NAMES     novamp
               (order|disorder) order
               CDATA     ""