A.3 Architectural Form Definition Requirements (AFDR)

A.3.4 Architecture support declarations

Subclauses:

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

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

A.3.4.1 Architecture notation declaration

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

              <!-- Architecture Notation Declaration -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Notation
   ArcName        -- ArcName architecture --
                  -- A base architecture used in conformance with the
                     Architectural Form Definition Requirements of
                     International Standard ISO/IEC 10744. --

   PUBLIC "...//NOTATION AFDR ARCBASE ArcName Architecture//.."
                  -- Constraint: Public ID of ArcName architecture
                     definition document --
>

A.3.4.2 Architecture support attributes

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 architectural form attribute name (ArcFormA) specifies the name of an architecture control attribute (hereafter identified as the "ArcForm" attribute) that the client DTD must define for every architectural element type and notation to identify its architectural form (see A.3.5.1 Architectural form attribute).

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

NOTE 415 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 architectural attribute renamer name (ArcNamrA) specifies the name of an architecture control attribute (the "ArcNames" attribute) that allows an application to substitute its own names for architectural attribute names (see A.3.5.2 Architectural attribute renamer).

The attribute architecture suppressor attribute name (ArcSuprA) specifies the name of an architecture control attribute (the "ArcSupr" attribute) that controls suppression of architectural processing (see A.3.5.3 Architecture suppressor attribute).

The attribute architecture ignore data attribute name (ArcIgnDA) specifies the name of an architecture control attribute (the "ArcIgnDA" attribute) that controls whether the data content of an element is treated as architectural.

The attribute architecture document element form name (ArcDocF) specifies the name of the document element form (the "ArcDoc" form) (see A.3.6.1 Architectural document element).

The attribute architecture meta-DTD entity (ArcDTD) identifies the external entity that contains the meta-DTD to which the architectural document instance conforms. The value of the attribute is either the name of a parameter entity prefixed with the pero delimiter or the name of a general entity. It must be subject to the same SGML declaration as the client document, except that its quantity set could differ. The difference is specified by the attribute architecture quantity set (ArcQuant), which is a list of quantity and value pairs as found in the quantity set parameter of an SGML declaration. The values for the quantities named in the attribute value apply to the meta-DTD and architectural instance in place of those in the client document SGML declaration. (See A.3.4.3 Architecture entity declaration). If no value is specified, then the name of the meta-DTD entity is taken to be the name of the architectural notation after the application of SGML name and entity case folding rules.

NOTE 416 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 A.3.6.2 Architectural markup minimization):

The attribute architecture data form name (ArcDataF) specifies the name of an architectural notation form (the "ArcData" form) that is used as the default for external data entities.

The attribute architecture bridge form name (ArcBridF) specifies the name of an architectural form (the "ArcBrid" form) that bridges between the architecture and a non-architectural element or notation. It is the default architectural form for elements that are architectural but do not have a defined architectural form. Such elements are usually included because they exhibit an ID attribute.

The attribute architecture automatic form mapping (ArcAuto) indicates whether to map element types and external data entity notations to identically named architectural forms (ArcAuto) or not (nArcAuto).

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 architecture options support attribute names (ArcOptSA) specifies the names of one or more architecture support attributes. The support attributes list the names of parameter entities whose entity text should be declared as "INCLUDE" in the meta-DTD. The default architecture support attribute is architecture options (ArcOpt).

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

NOTE 418 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 A.3.4 Architecture support declarations), the system must report an error even if the document does not actually use those facilities.

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

               <!-- Architecture Support Attributes -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Attlist #NOTATION
   ArcName        -- Base architecture --

-- Support attributes for all architectures --

   ArcFormA       -- Architectural form attribute name --
      NAME        -- Constraint: must be unique among all attribute
                     names in DTD in which it is specified --
      #IMPLIED    -- Default: ArcName --

   ArcNamrA       -- Architectural attribute renamer attribute name --
      NAME        -- Constraint: must be unique among all attribute
                     names in DTD in which it is specified --
      #IMPLIED    -- Default: no renaming --

   ArcSuprA       -- Architecture suppressor attribute name --
      NAME        -- Constraint: must be unique among all attribute
                     names in DTD in which it is specified --
      #IMPLIED    -- Default: no suppression --

   ArcIgnDA       -- Architecture ignore data attribute name --
      NAME        -- Constraint: must be unique among all attribute
                     names in DTD in which it is specified --
      #IMPLIED    -- Default: data is conditionally ignored --

   ArcDocF        -- Architecture document element form name --
      NAME        -- Constraint: name of element form in architecture
                     meta-DTD --
      #IMPLIED    -- Default: ArcName --

   ArcDTD         -- Architecture meta-DTD entity --
      CDATA       -- Lextype: (ENTITY|PENTITY) --
      #IMPLIED    -- Default: entity whose name matches the notation name
                     after SGML name and entity folding is applied. --
                  -- Constraint: a name must be specified or the meta-DTD
                     entity name after folding must match notation name
                     after folding. --

   ArcQuant       -- Architecture quantity set --
      CDATA       -- Lextype: (NAME,NUMBER)+ --
                  -- Constraint: quantity name/value pairs --
      #IMPLIED    -- Default: no variation --

   ArcDataF       -- Architecture data form name --
                  -- For external data entities whose notation names
                     don't match architectural notations --
      NAME        -- Constraint: name of notation form in architecture
                     meta-DTD --
      #IMPLIED    -- Default: no defaulting --

   ArcBridF       -- Architecture bridge form name --
                  -- For elements with an ID and no ArcForm attribute
                     whose form isn't defaulted --
      NAME        -- Constraint: name of element form in architecture
                     meta-DTD --
      #IMPLIED    -- Default: no defaulting --

   ArcAuto        -- Architecture automatic form mapping --
                  -- Automatic form mapping for identically named
                     element types and external data entity
                     notations --
      (ArcAuto|nArcAuto)
      ArcAuto

   ArcOptSA       -- Architecture options support attribute names --
      NAMES       -- Lextype: ATTNAME+ --
      ArcOpt

-- Support attributes for this architecture --

   ArcOpt         -- Architecture options --
      CDATA       -- Lextype: csname+ --
                  -- Constraint: parameter entities in meta-DTD to be
                     set to "INCLUDE" --
      #IMPLIED    -- Default: none --

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

A.3.4.3 Architecture entity declaration

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 A.3.2.2 Attribute forms).

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.

NOTE 420 In either case, it is only accessed directly by the architecture engine (if at all), outside the parsing context of the document.

              <!-- Architecture Entity Declarations -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
    <!-- For use when AFDRMeta extensions are used in meta-DTD -->
<!NOTATION
   AFDRMeta       -- AFDR Meta-DTD Notation --

   PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR Meta-DTD Notation//EN"
>
<!Entity
   ArcName        -- ArcName architecture meta-DTD --

   PUBLIC "...//DTD AFDR Meta-DTD ArcName Architecure//.."
                  -- Constraint: Public ID of ArcName architecture
                     meta-DTD --
   CDATA AFDRMeta
>

<!-- For use when AFDRMeta extensions are not used and meta-DTD is not
     referenced as part of DTD -->
<!NOTATION
   SGML           -- Standard Generalized Markup Language --

   PUBLIC "ISO 8879:1986//NOTATION
           Standard Generalized Markup Language//EN"
>
<!Entity
   ArcName        -- ArcName architecture meta-DTD --

   PUBLIC "...//DTD AFDR Meta-DTD ArcName Architecure//.."
                  -- Constraint: Public ID of ArcName architecture
                     meta-DTD --
   CDATA SGML
>

<!-- For use when AFDRMeta extensions are not used and meta-DTD is
     referenced as part of DTD -->
<!Entity %
   ArcName        -- ArcName architecture meta-DTD --

   PUBLIC "...//DTD AFDR Meta-DTD ArcName Architecure//.."
                  -- Constraint: Public ID of ArcName architecture
                     meta-DTD --
>

			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