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.5 Architecture control attributes

Subclauses:


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 A.3.4.2 Architecture support attributes).

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

A.3.5.1 Architectural form attribute

The architecture control attribute architectural form (ArcForm) identifies the architectural form of an element or notation. Its value is the name of the architectural form to which the element or notation conforms.

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

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

NOTE 423 In other words, an architecture's set of architectural forms cannot be extended by an application (but see A.3.6.3 Derived enabling architectures).

                <!-- Architectural Form Attribute -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Attlist
   ElemTypeName   -- Client element type --

   ArcForm        -- Base element form name --
      NAME        -- Constraint: name of element form defined in base
                     architecture's meta-DTD --
      #IMPLIED    -- Default: non-architectural unless found to be
                     architectural via automatic form mapping or
                     architectural bridging --
>
<!Attlist #NOTATION
   NotationName   -- Client notation --

   ArcForm        -- Base notation form name --
      NAME        -- Constraint: name of notation form defined in base
                     architecture's meta-DTD --
      #IMPLIED    -- Default: non-architectural unless found to be
                     architectural via automatic form mapping or
                     architectural bridging --
>

A.3.5.2 Architectural attribute renamer

The architecture control attribute architectural attribute renamer (ArcNames) is an attribute that defines client substitutes for architecture attribute names. The substitute is treated as if it were the correspondingly-named architecture-defined attribute or architectural content. An attribute bearing an architecture-defined attribute name for which a substitute is defined will be ignored by the architecture engine. If the substitute name is "#DEFAULT", then an attribute bearing the architecture-defined attribute name is ignored in the usual way, but the value of the attribute is not taken from another attribute but is instead defaulted as specified in the meta-DTD.

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.

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

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

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

               <!-- Architectural Attribute Renamer -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Attlist
   ElemTypeName   -- Client element type --

   ArcNames       -- Architectural attribute renamer --
                  -- Defines user names for architecture attributes --
      CDATA       -- Lextype: ((NAME,(ATTORCON|"#DEFAULT"),
                                ("#MAPTOKEN", NMTOKEN, NMTOKEN)*)|
                               ("#ARCCONT",ATTNAME))* --
                  -- Constraint: a given ATTNAME or NAME, #CONTENT, or
                     #ARCCONT can occur only once --
                  -- Constraint: architecture name precedes user
                     name --
      #IMPLIED    -- Constant --
                  -- Default: no renaming --
>
<!Attlist #NOTATION
   NotationName   -- Client notation --

   ArcNames       -- Architectural attribute renamer --
                  -- Defines user names for architecture attributes --
      CDATA       -- Lextype: (NAME,(ATTNAME|"#DEFAULT"),
                               ("#MAPTOKEN", NMTOKEN, NMTOKEN)*)* --
                  -- Constraint: a given ATTNAME or NAME can occur
                     only once --
                  -- Constraint: architecture name precedes user
                     name --
      #IMPLIED    -- Default: no renaming --
>

A.3.5.3 Architecture suppressor attribute

The architecture control attribute architecture suppressor (ArcSupr) suppresses or restores architectural processing for the descendants of an element.

sArcAll

Completely suppress all architectural processing of descendants. It is not possible to restore architectural processing for a descendant.

sArcForm

Suppress processing of the ArcForm attribute of all descendants of this element, except for those elements that have a non-implied ArcSupr attribute.

sArcNone

Don't suppress architectural processing for the descendants of this element.

The value may also be implied, in which case the state of architectural processing is inherited.

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.

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

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

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

              <!-- Architecture Suppressor Attribute -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Attlist
   ElemTypeName   -- Client element type --

   ArcSupr        -- Architecture suppressor --
                  -- Suppress architectural processing --
      (sArcAll|sArcForm|sArcNone)
      #IMPLIED    -- Default: inherited --
>

A.3.5.4 Architecture ignore data attribute

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

nArcIgnD

Data is not ignored. It is an error if data occurs where not allowed by the meta-DTD.

cArcIgnD

Data is conditionally ignored. Data will be ignored only when it occurs where the meta-DTD does not allow it.

ArcIgnD

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.

             <!-- Architecture Ignore Data Attribute -->
     <!-- TEMPLATE FOR DECLARATION IN DTD or DERIVED META-DTD -->
<!Attlist
   ElemTypeName   -- Element type name --

   ArcIgnDA       -- Architecture ignore data --
      (nArcIgnD|cArcIgnD|ArcIgnD)
      #IMPLIED    -- Default: inherited from parent element; document
                     element defaults to cArcIgnD --
>

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.