Architectural Form Processing

The Hytime standard (ISO/IEC 10744) introduced the concept of architectural forms. This document assumes you are already familiar with this concept. The first Technical Corrigendum to HyTime, which is soon to be published, generalizes this, and makes it possible to have an architecture engine which can perform architectural form processing for arbitrary architectures. SP now includes such an architecture engine.

Non-markup sensitive applications built using SP now support architectural form processing using the -A archname option. When this option is specified, the document will be validated against all declared base architectures, and the output will be for the architectural document for that architecture: the element types, notations and attributes will be those defined in the meta-DTD.

This option is experimental and has not been subject to much testing. Please be sure to report any bugs or problems you encounter.

Although spam does not support the -A option because it works with the markup of your document, sgmlnorm does.

Architectural Support Attributes

To use the -A option with a document, you must add must add:

• an architecture base declaration for archname, and
• architectural support attributes for archname

An architecture base declaration is a processing instruction of the form:

<?ArcBase archname>

The processing instruction is recognized either in the DTD or in an active LPD.

You can specify architectural support attributes in several different ways:

• by an attribute definition list for a notation archname in the DTD; the default values in the attribute definition list provide the values for the support attributes.
• as link attributes on the document element in a simple link process;
• as link attributes of the document element type in the initial link set in an implicit or explicit link process; note that there must be a link rule for the document element type in the initial link set even if all the attributes can be defaulted.

If the architectural support attributes are specified as link attributes, then they must occur in the same LPD as the architecture base declaration occurred, if it occurred in an LPD, and otherwise in the LPD must be named archname.

The -A archname option automatically activates any link type archname.

Note that SGML does not allow a notation declaration in a link type declaration subset.

The following architectural support attributes are recognized:

ArcDocF

The name of the document element type in the meta-DTD. This would be HyDoc for HyTime. This defaults to archname.

ArcDTD

The name of an external parameter entity that contains the meta-DTD. The declared value of this attribute should be CDATA: it can't be ENTITY, because the value of a ENTITY attribute has to be a data or subdoc entity; it can't be any other kind of tokenized attribute, because general name substitution would be done to it. By default, if a notation archname was declared with a formal public identifier, the meta-DTD will be treated as if it had been declared:

<!DOCTYPE ArcDocF PUBLIC pubid>

where pubid is the public identifier specified for the notation with the public text class changed from NOTATION to DTD; otherwise it will be treated as if it had been declared

<!DOCTYPE ArcDocF SYSTEM>

ArcFormA

The name of the attribute that elements use to specify the corresponding element type, if any, in the meta-DTD. Data entities also use this attribute to specify the corresponding notation in the meta-DTD. This would be HyTime for HyTime. This defaults to archname.

ArcNamrA

The name of the attribute that elements use to specify substitutes for the names of attributes in the meta-DTD. A value of #DEFAULT is allowed for a substitute name; this inhibits mapping of an attribute to an architectural attribute, but specified that the value of the architectural attribute should be defaulted rather than taken from the value of another attribute in the document. For HyTime the value of this attribute would be HyNames. By default no attribute name substitutition is done.

ArcSuprA

The name of an attribute that elements may use to suppress processing of their descendants. This attribute is not recognized for data entities. The value of the attribute must be one of the following tokens:

sArcAll

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

sArcForm

Suppress processing of the ArcFormA attribute of all descendants of this element, except for those elements that have a non-implied ArcSuprA 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 ArcSuprA attribute that was processed, its ArcFormA attribute will always be processed. Otherwise its ArcFormA attribute will be processed unless its closest ancestor that has a non-implied value for the ArcSuprA attribute suppressed processing of the ArcFormA attribute. An element whose ArcFormA attribute is processed will not be treated as architectural if it has an implied value for the ArcFormA attribute.

ArcSuprF

The name of the element type in the meta-DTD that suppresses architectural processing in the same manner as does the sHyTime form in HyTime. By default, no element type does. This behaves like an element with an ArcSuprA attribute of sArcForm. The element type should be declared in the meta-DTD. You should not specify a value for this attribute if you specified a value for the ArcSuprA attribute.

ArcBridF

The name of a default element type declared in a meta-DTD, to which elements in the document should be automatically mapped if they have an ID and would not otherwise be considered architectural. This would be HyBrid for HyTime. If your meta-DTD declares IDREF attributes, it will usually be appropriate to specify a value for ArcBridF, and to declare an ID attribute for that form in your meta-DTD.

ArcDfltN

The name of a default notation declared in the meta-DTD, to which the external data entities in the document should be automatically mapped if they would not otherwise be considered architectural. If this attribute is defined, then general entities will be automatically architectural: any external data entity whose notation cannot otherwise be mapped into a notation in the meta-DTD will be automatically treated as an instance of the ArcDfltN notation. This would be data for HyTime. If your meta-DTD declares entity attributes, it will usually be appropriate to specify a value for ArcDfltN even if your meta-DTD declares no data attributes for the notation.

ArcAuto

This must have one of the following values:

ArcAuto

If an element does not have an ArcFormA attribute and the meta-DTD defines an element type with the same name as the element's type, the element will be automatically treated as being an instance of the meta-type. This rule does not apply to the document element type; this is automatically treated as being an instance of the meta-DTD's document element type. Note that this automatic mapping is prevented if the element has an ArcFormA attribute with an implied value. It is also prevented if processing of the ArcFormA attribute is suppressed. This applies equally to the notations of external data entities. The default element or notation specified with the ArcBridF or ArcDfltN attribute is only considered after the mapping specified by ArcAuto.

nArcAuto

Automatic mapping is not performed.

The default value is ArcAuto.

Meta-DTDs

A meta-DTD is allowed to use the following extensions:

• a single element type or notation is allowed to be an associated element type or associated notation name for multiple attribute definition lists.
• #ALL can be used as an associated element type or associated notation name in an attribute definition list to define attributes for all element types or notations in the meta-DTD

In all other respects a meta-DTD must be a valid SGML DTD.

A meta-DTD is interpreted using the SGML declaration of the document.

A declared value of ENTITY for an attribute in a meta-DTD means that the value of the attribute must be an entity declared in the (non-meta) DTD that is architectural. An external data entity is architectural only if its notation can be mapped into a notation in the meta-DTD. All other kinds of data and subdoc entities are automatically architectural.

An IDREF attribute in the meta-document must have a corresponding ID in the meta-document. An attribute with a declared value of ID in the document will be automatically mapped to an attribute with a declared value of ID in the meta-DTD.

A declared value of NOTATION in the meta-DTD means that the value of the attribute must have one the values specified in the name group and that it must be a notation in the meta-DTD. (Perhaps if the attribute also has a declared value of NOTATION in the non-meta-DTD, the value should be mapped in a similar way to the notation of an external data entity.)

Differences from HyTime

There are a number of differences from how architectural processing is defined in the pre-Corringendum version of the HyTime standard.

• The ArcNamrA and ArcFormA attributes are not part of the meta-DTD. Rather they are used by the architecture engine in deriving the meta-document that is validated against the meta-DTD.
• The use: conventional comment is not recognized. Instead a single element type is allowed to be an associated element type for multiple attribute definition lists.
• The notation and data attributes of an external data entity are treated just like the element type and attributes of an element. The notation of an external data entity is mapped into a notation in the meta-DTD and the data attributes of the entity are mapped onto attributes defined for the meta-DTD notation.
• #FIXED has the same meaning in a meta-DTD that it does in a regular DTD: the value of the attribute must be the same as the default value of the attribute specified in the meta-DTD.
• Data is only treated as architectural if it occurs in a context in which the meta-DTD allows data.

Link attributes

Link attributes defined by an implicit link process are treated in the same way as non-link attributes. The only complication is that SGML allows link attributes to have the same name as non-link attributes. If there is a link attribute and a non-link attribute with the same name, the architecture engine will only look at the link attribute, even if the value of the link attribute is implied. The only exception is the ArcNamrA attribute: the architecture engine will use both the link attribute and the non-link attribute, but the substitute names in the value of the non-link attribute cannot refer to link attribute names.

Notation set architecture

An architecture for which archname is declared as a notation with a public identifier of

"ISO/IEC 10744//NOTATION Notation Set Architecture//EN"

is special. The element types in the meta-DTD for this architecture are the notations of the document DTD and the attributes defined for the element types in the meta-DTD are the data attributes defined for the notations in the document DTD. For each element, the attribute with a declared value of NOTATION performs the function that the ArcFormA attribute performs for normal architectures. Only the ArcNamrA and ArcSuprA architectural support attributes can be used with this architecture.

The notation set acrhitecture can also be declared using an architecture base declaration of the form:

<?ArcBase #NOTATION>

In this case, no architecture support attributes can be declared; ArcNamrA will be defaulted to notnames.

Derived architectures

A meta-DTD can have one or more base architectures in the same way as a normal DTD. Multiple -A options can be used to exploit this. For example,

-A arch1 -A arch2

will perform architectural processing on the source document to produce an architectural document conforming to the architecture arch1 declared in the source document, and will then perform architectural processing on this architectural document to produce an architectural document conforming to the arch2 architecture declared in arch1's meta-DTD.

A document that is validated against a meta-DTD will automatically be validated against any base architectures of that meta-DTD.