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 ClausePrevious Clause  

homeParent clauseNext major clausePrevious major clauseNext clause at this levelPrevious clause at this level


A.3 Architectural Form Definition Requirements (AFDR)

A.3.6 Other architecture-related considerations

Subclauses:


This clause discusses other considerations related to architectures.

A.3.6.1 Architectural document element

Every architecture must provide the element form architectural document element (ArcDoc), to which the document element of a client document must conform if it does not already conform to another element form in the architecture. The actual name of the architectural form need not be ArcDoc; it could reflect the name of the architecture. The actual name is specified by the ArcDocF attribute of the architecture notation declaration.

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.

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

NOTE 431 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 Document Element -->
     <!-- TEMPLATE FOR DOCUMENT ELEMENT FORM IN ANY META-DTD -->
<!Entity %
   ArcCFC         -- Architectural context-free content --

   "ANY"
>
<!Element
   ArcDoc         -- Architectural document element --

   - O
   %ArcCFC;
>
<!Attlist
   ArcDoc         -- Architectural document element --

-- Document attributes for this architecture may be added by meta-DTD
   designer. --
>

A.3.6.2 Architectural markup minimization

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:

  1. If the ArcForm architecture control attribute is declared:

    1. If ArcForm is implied, the object is non-architectural.

    2. If ArcForm has a value, the architectural form is that value.

  2. If the ArcForm architecture control attribute is not declared:

    1. If the object is the document element, the architectural form is ArcDoc.

      NOTE 432 This is a mandatory form of minimization; the others are optional.

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

      NOTE 433 The external identifiers in the meta- and client notation declarations need not be the same.

    3. If not, and the object is an element with an ID, use the ArcBrid form name if one was specified.

    4. If not, and the object is an external data entity, use the ArcData form name if one was specified.

    5. If not, the object is not architectural.

A.3.6.3 Derived enabling architectures

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.

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

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

A.3.6.4 Relating applications and architectures

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"):

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

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

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

    NOTE 436 An external data entity can have an architectural form by virtue of either an explicit ArcForm attribute or through architectural markup minimization.

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

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

Next ClausePrevious 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.