nsgmls.src/doc/archform.htm

<!-- SCCS keyword
#pragma ident	"%Z%%M%	%I%	%E% SMI"
-->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<HTML>
<HEAD>
<TITLE>Architectural Form Processing</TITLE>
</HEAD>
<BODY>
<H1>Architectural Form Processing</H1>
<P>
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 <I>architecture engine</I> which can perform architectural form
processing for arbitrary architectures.  SP now includes such an
architecture engine.
<P>
Non-markup sensitive applications built using SP now support
architectural form processing using the <SAMP>-A
<VAR>archname</VAR></SAMP> 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.
<P>
This option is experimental and has not been subject to much testing.
Please be sure to report any bugs or problems you encounter.
<P>
Although spam does not support the <SAMP>-A</SAMP> option because it
works with the markup of your document, sgmlnorm does.

<H2>Architectural Support Attributes</H2>
<P>
To use the <SAMP>-A</SAMP> option with a document, you must add
<UL>
<LI>
an architecture base declaration for <SAMP><VAR>archname</VAR></SAMP>,
<LI>
a notation declaration and associated attribute definition list
declaration for <SAMP><VAR>archname</VAR></SAMP>;
this is called the <I>architecture notation declaration</I>.
</UL>
<P>
An architecture base declaration is a processing instruction of the form:
<PRE>
&lt;?ArcBase <VAR>archname</VAR>&gt;
</PRE>
<P>
The processing instruction is recognized either in the DTD or in an
active LPD.
<P>
The architecture notation declaration and associated attribute
definition list declaration serve to declare a number of architectural
support attributes which control the architecture engine.  The value
for each architecture support attribute is taken from the default
value, if any, specified for that attribute in the attribute
definition list declaration.  It is an error to declare an
architecture support attribute as <SAMP>#REQUIRED</SAMP>.
<P>
The following architectural support attributes are recognized:
<DL>
<DT>
<SAMP>ArcDTD</SAMP>
<DD>
The name of an external entity that contains the meta-DTD.
This attribute is required.
If the name starts with the PERO delimiter <SAMP>%</SAMP>,
the entity is a parameter entity,
otherwise it is a general entity.
<DT>
<SAMP>ArcQuant</SAMP>
<DD>
A list of tokens that looks like what follows <SAMP>QUANTITY SGMLREF</SAMP>
in the quantity set section of an SGML declaration.
The quantities used for parsing the meta-DTD
and validating the architectural document
will be the maximum of the quantities in the document's concrete syntax
and the quantities specified here.
<DT>
<SAMP>ArcDocF</SAMP>
<DD>
The name of the document element type in the meta-DTD.
This would be <SAMP>HyDoc</SAMP> for HyTime.
This defaults to <SAMP><VAR>archname</VAR></SAMP>.
<DT>
<SAMP>ArcFormA</SAMP>
<DD>
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 <SAMP>HyTime</SAMP> for HyTime.
This defaults to <SAMP><VAR>archname</VAR></SAMP>.
<DT>
<SAMP>ArcNamrA</SAMP>
<DD>
The name of the attribute that elements use to specify substitutes for
the names of attributes in the meta-DTD.  A value of
<SAMP>#DEFAULT</SAMP> is allowed for a substitute name; this inhibits
mapping of an attribute to an architectural attribute, but specifies
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 <SAMP>HyNames</SAMP>.
By default no attribute name substitutition is done.
<DT>
<SAMP>ArcSuprA</SAMP>
<DD>
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:
<DL>
<DT>
<SAMP>sArcAll</SAMP>
<DD>
Completely suppress all architectural processing of descendants.
It is not possible to restore architectural processing
for a descendant.
<DT>
<SAMP>sArcForm</SAMP>
<DD>
Suppress processing of the <SAMP>ArcFormA</SAMP> attribute of all
descendants of this element, except for those elements that have a
non-implied <SAMP>ArcSuprA</SAMP> attribute.
<DT>
<SAMP>sArcNone</SAMP>
<DD>
Don't suppress architectural processing for the descendants of
this element.
</DL>
<P>
The value may also be implied, in which case the state of
architectural processing is inherited.
<P>
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.
<DT>
<SAMP>ArcSuprF</SAMP>
<DD>
The name of the element type in the meta-DTD that suppresses
architectural processing in the same manner as does the
<SAMP>sHyTime</SAMP> form in HyTime.  By default, no element type
does.  This behaves like an element with an
<SAMP>ArcSuprA</SAMP> attribute of <SAMP>sArcForm</SAMP>.  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
<SAMP>ArcSuprA</SAMP> attribute.
<P>
This is a non-standardized extension.
<DT>
<SAMP>ArcIgnDA</SAMP>
<DD>
The name of an attribute that elements may use to control whether
data is ignored.
The value of the attribute must be one of the following values:
<DL>
<DT>
<SAMP>nArcIgnD</SAMP>
<DD>
Data is not ignored.
It is an error if data occurs where not allowed by the meta-DTD.
<DT>
<SAMP>cArcIgnD</SAMP>
<DD>
Data is conditionally ignored.
Data will be ignored only when it occurs where the meta-DTD
does not allow it.
<DT>
<SAMP>ArcIgnD</SAMP>
<DD>
Data is always ignored.
</DL>
<P>
The value may also be implied, in which case the state of
architectural processing is inherited.
If no the document element has no value specified,
<SAMP>cArcIgnD</SAMP> will be used.
<DT>
<SAMP>ArcBridF</SAMP>
<DD>
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 <SAMP>HyBrid</SAMP> for HyTime.
If your meta-DTD declares IDREF attributes, it will
usually be appropriate to specify a value for
<SAMP>ArcBridF</SAMP>, and to declare an ID attribute
for that form in your meta-DTD.
<DT>
<SAMP>ArcDataF</SAMP>
<DD>
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 <SAMP>ArcDataF</SAMP> notation.
This would be <SAMP>data</SAMP> for HyTime.
If your meta-DTD declares entity attributes, it will usually
be appropriate to specify a value for <SAMP>ArcDataF</SAMP>
even if your meta-DTD declares no data attributes for the
notation.
<DT>
<SAMP>ArcAuto</SAMP>
<DD>
This must have one of the following values:
<DL>
<DT>
<SAMP>ArcAuto</SAMP>
<DD>
If an element does not have an <SAMP>ArcFormA</SAMP> 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 <SAMP>ArcFormA</SAMP> attribute with an implied
value.  It is also prevented if processing of the
<SAMP>ArcFormA</SAMP> attribute is suppressed.  This applies equally
to the notations of external data entities.
The default element or notation specified with the
<SAMP>ArcBridF</SAMP> or <SAMP>ArcDfltN</SAMP> attribute
is only considered after the mapping specified by <SAMP>ArcAuto</SAMP>.
<DT>
<SAMP>nArcAuto</SAMP>
<DD>
Automatic mapping is not performed.
</DL>
<P>
The default value is <SAMP>ArcAuto</SAMP>.
<DT>
<SAMP>ArcOptSA</SAMP>
<DD>
A list of names of architectural support attributes,
each of which is interpreted as a list of parameter entities
to be defined with a replacement text of <SAMP>INCLUDE</SAMP>
when parsing the meta-DTD.
The default value is <SAMP>ArcOpt</SAMP>.
</DL>
<H2>Meta-DTDs</H2>
<P>
A meta-DTD is allowed to use the following extensions:
<UL>
<LI>
a single element type or notation is allowed to be an associated
element type or associated notation name for multiple attribute
definition lists.
<LI>
<SAMP>#ALL</SAMP> 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
</UL>
<P>
Before any of these extensions can be used, the meta-DTD must include a
declaration
<PRE>
&lt;!AFDR "ISO/IEC 10744:1992"&gt;
</PRE>
<P>
This declaration should only be included if the extensions are used.
<P>
In all other respects a meta-DTD must be a valid SGML DTD.
<P>
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 entities and subdoc entities are automatically
architectural.
<P>
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.
<P>
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.)

<H2>Differences from HyTime</H2>
<P>
There are a number of differences from how architectural processing is
defined in the pre-Corringendum version of the HyTime standard.
<UL>
<LI>
The <SAMP>ArcNamrA</SAMP> and <SAMP>ArcFormA</SAMP> 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.
<LI>
The <SAMP>use:</SAMP> conventional comment is not recognized.  Instead
a single element type is allowed to be an associated element type for
multiple attribute definition lists.
<LI>
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.
<LI>
<SAMP>#FIXED</SAMP> 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.
</UL>

<H2>Specifying architectural processing with an LPD</H2>
<P>
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 <SAMP>ArcNamrA</SAMP> 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.
<P>
The <SAMP>-A <VAR>archname</VAR></SAMP> option automatically activates
any link type <SAMP><VAR>archname</VAR></SAMP>.
<P>
The architecture notation declaration and associated attribute
definition list declaration are allowed in the LPD.  Although the
productions of ISO 8879 do not allow a notation declaration in a link
type declaration subset, it is clearly the intent of the standard that
they be allowed.  You can use a <SAMP>-wlpd-notation</SAMP> option to
disallow them.

<H2>Notation set architecture</H2>
<P>
An architecture for which <VAR>archname</VAR> is declared
as a notation with a public identifier of
<PRE>
"ISO/IEC 10744//NOTATION AFDR ARCBASE
Notation Set Architecture Definition Document//EN"
</PRE>
<P>
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
<SAMP>ArcNamrA</SAMP> and <SAMP>ArcSuprA</SAMP> architectural support
attributes can be used with this architecture.
<P>
The notation set architecture can also be declared using
an architecture base declaration of the form:
<PRE>
&lt;?ArcBase #NOTATION&gt;
</PRE>
<P>
In this case, no architecture support attributes can be declared;
<SAMP>ArcNamrA</SAMP> will be defaulted to <SAMP>notnames</SAMP>,
and <SAMP>ArcSuprA</SAMP> to <SAMP>notsupr</SAMP>.

<H2>Derived architectures</H2>
<P>
A meta-DTD can have one or more base architectures in the same way as
a normal DTD.  Multiple <SAMP>-A</SAMP> options can be used to exploit
this.  For example,
<PRE>
-A <VAR>arch1</VAR> -A <VAR>arch2</VAR>
</PRE>
<P>
will perform architectural processing on the source document to
produce an architectural document conforming to the architecture
<SAMP><VAR>arch1</VAR></SAMP> declared in the source document, and
will then perform architectural processing on this architectural
document to produce an architectural document conforming to the
<SAMP><VAR>arch2</VAR></SAMP> architecture declared in
<SAMP><VAR>arch1</VAR></SAMP>'s meta-DTD.
<P>
A document that is validated against a meta-DTD will automatically
be validated against any base architectures of that meta-DTD.

<H2>Not implemented</H2>
<P>
The following features in the current AFDR draft are not implemented:
<UL>
<LI>
<SAMP>ArcIndr</SAMP> architectural support attribute with value
other than <SAMP>nArcIndr</SAMP>.
</UL>
<P>
<ADDRESS>
James Clark<BR>
jjc@jclark.com
</ADDRESS>
</BODY>
</HTML>