doc/archform.htm

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>Architectural Form Processing</TITLE>
   5 </HEAD>
   6 <BODY>
   7 <H1>Architectural Form Processing</H1>
   8 <P>
   9 The Hytime standard (ISO/IEC 10744) introduced the concept of
  10 architectural forms.  This document assumes you are already familiar
  11 with this concept. HyTime 2nd Edition generalizes this, and makes it
  12 possible to have an <I>architecture engine</I> which can perform
  13 architectural form processing for arbitrary architectures.  OpenSP
  14 includes such an architecture engine.
  15 <P>
  16 Non-markup sensitive applications built using OpenSP now support
  17 architectural form processing using the <SAMP>-A
  18 <VAR>archname</VAR></SAMP> option.  When this option is specified, the
  19 document will be validated against all declared base architectures,
  20 and the output will be for the architectural document for that
  21 architecture: the element types, notations and attributes will be
  22 those defined in the meta-DTD.
  23 <P>
  24 Although spam does not support the <SAMP>-A</SAMP> option because it
  25 works with the markup of your document, sgmlnorm does.
  26
  27 <H2>Architectural Support Attributes</H2>
  28 <P>
  29 To use the <SAMP>-A</SAMP> option with a document, you must add
  30 <UL>
  31 <LI>
  32 an architecture base declaration for <SAMP><VAR>archname</VAR></SAMP>,
  33 <LI>
  34 a notation declaration and associated attribute definition list
  35 declaration for <SAMP><VAR>archname</VAR></SAMP>;
  36 this is called the <I>architecture notation declaration</I>.
  37 </UL>
  38 <P>
  39 An architecture base declaration is a processing instruction of the form:
  40 <PRE>
  41 &lt;?IS10744 ArcBase <VAR>archname</VAR>&gt;
  42 </PRE>
  43 <P>
  44 The processing instruction is recognized either in the DTD or in an
  45 active LPD.
  46 <P>
  47 The architecture notation declaration and associated attribute
  48 definition list declaration serve to declare a number of architectural
  49 support attributes which control the architecture engine.  The value
  50 for each architecture support attribute is taken from the default
  51 value, if any, specified for that attribute in the attribute
  52 definition list declaration.  It is an error to declare an
  53 architecture support attribute as <SAMP>#REQUIRED</SAMP>.
  54 <P>
  55 The following architectural support attributes are recognized:
  56 <DL>
  57 <DT>
  58 <SAMP>ArcDTD</SAMP>
  59 <DD>
  60 The name of an external entity that contains the meta-DTD.
  61 This attribute is required.
  62 If the name starts with the PERO delimiter <SAMP>%</SAMP>,
  63 the entity is a parameter entity,
  64 otherwise it is a general entity.
  65 <DT>
  66 <SAMP>ArcQuant</SAMP>
  67 <DD>
  68 A list of tokens that looks like what follows <SAMP>QUANTITY SGMLREF</SAMP>
  69 in the quantity set section of an SGML declaration.
  70 The quantities used for parsing the meta-DTD
  71 and validating the architectural document
  72 will be the maximum of the quantities in the document's concrete syntax
  73 and the quantities specified here.
  74 <DT>
  75 <SAMP>ArcDocF</SAMP>
  76 <DD>
  77 The name of the document element type in the meta-DTD.
  78 This would be <SAMP>HyDoc</SAMP> for HyTime.
  79 This defaults to <SAMP><VAR>archname</VAR></SAMP>.
  80 <DT>
  81 <SAMP>ArcFormA</SAMP>
  82 <DD>
  83 The name of the attribute that elements use to specify the
  84 corresponding element type, if any, in the meta-DTD.
  85 Data entities also use this attribute to specify the corresponding
  86 notation in the meta-DTD.
  87 This would be <SAMP>HyTime</SAMP> for HyTime.
  88 This defaults to <SAMP><VAR>archname</VAR></SAMP>.
  89 <DT>
  90 <SAMP>ArcNamrA</SAMP>
  91 <DD>
  92 The name of the attribute that elements use to specify substitutes for
  93 the names of attributes in the meta-DTD.  A value of
  94 <SAMP>#DEFAULT</SAMP> is allowed for a substitute name; this inhibits
  95 mapping of an attribute to an architectural attribute, but specifies
  96 that the value of the architectural attribute should be defaulted
  97 rather than taken from the value of another attribute in the document.
  98 For HyTime the value of this attribute would be <SAMP>HyNames</SAMP>.
  99 By default no attribute name substitutition is done.
 100 <DT>
 101 <SAMP>ArcSuprA</SAMP>
 102 <DD>
 103 The name of an attribute that elements may use to suppress processing
 104 of their descendants.  This attribute is not recognized for data
 105 entities.  The value of the attribute must be one of the following
 106 tokens:
 107 <DL>
 108 <DT>
 109 <SAMP>sArcAll</SAMP>
 110 <DD>
 111 Completely suppress all architectural processing of descendants.
 112 It is not possible to restore architectural processing
 113 for a descendant.
 114 <DT>
 115 <SAMP>sArcForm</SAMP>
 116 <DD>
 117 Suppress processing of the <SAMP>ArcFormA</SAMP> attribute of all
 118 descendants of this element, except for those elements that have a
 119 non-implied <SAMP>ArcSuprA</SAMP> attribute.
 120 <DT>
 121 <SAMP>sArcNone</SAMP>
 122 <DD>
 123 Don't suppress architectural processing for the descendants of
 124 this element.
 125 </DL>
 126 <P>
 127 The value may also be implied, in which case the state of
 128 architectural processing is inherited.
 129 <P>
 130 If an element has an ArcSuprA attribute that was processed, its
 131 ArcFormA attribute will always be processed.  Otherwise its ArcFormA
 132 attribute will be processed unless its closest ancestor that has a
 133 non-implied value for the ArcSuprA attribute suppressed processing of
 134 the ArcFormA attribute.  An element whose ArcFormA attribute is
 135 processed will not be treated as architectural if it has an implied
 136 value for the ArcFormA attribute.
 137 <DT>
 138 <SAMP>ArcSuprF</SAMP>
 139 <DD>
 140 The name of the element type in the meta-DTD that suppresses
 141 architectural processing in the same manner as does the
 142 <SAMP>sHyTime</SAMP> form in HyTime.  By default, no element type
 143 does.  This behaves like an element with an
 144 <SAMP>ArcSuprA</SAMP> attribute of <SAMP>sArcForm</SAMP>.  The element
 145 type should be declared in the meta-DTD.  You should not specify a
 146 value for this attribute if you specified a value for the
 147 <SAMP>ArcSuprA</SAMP> attribute.
 148 <P>
 149 This is a non-standardized extension.
 150 <DT>
 151 <SAMP>ArcIgnDA</SAMP>
 152 <DD>
 153 The name of an attribute that elements may use to control whether
 154 data is ignored.
 155 The value of the attribute must be one of the following values:
 156 <DL>
 157 <DT>
 158 <SAMP>nArcIgnD</SAMP>
 159 <DD>
 160 Data is not ignored.
 161 It is an error if data occurs where not allowed by the meta-DTD.
 162 <DT>
 163 <SAMP>cArcIgnD</SAMP>
 164 <DD>
 165 Data is conditionally ignored.
 166 Data will be ignored only when it occurs where the meta-DTD
 167 does not allow it.
 168 <DT>
 169 <SAMP>ArcIgnD</SAMP>
 170 <DD>
 171 Data is always ignored.
 172 </DL>
 173 <P>
 174 The value may also be implied, in which case the state of
 175 architectural processing is inherited.
 176 If no the document element has no value specified,
 177 <SAMP>cArcIgnD</SAMP> will be used.
 178 <DT>
 179 <SAMP>ArcBridF</SAMP>
 180 <DD>
 181 The name of a default element type declared in a meta-DTD,
 182 to which elements in the document should be automatically mapped
 183 if they have an ID and would not otherwise be considered
 184 architectural.
 185 This would be <SAMP>HyBrid</SAMP> for HyTime.
 186 If your meta-DTD declares IDREF attributes, it will
 187 usually be appropriate to specify a value for
 188 <SAMP>ArcBridF</SAMP>, and to declare an ID attribute
 189 for that form in your meta-DTD.
 190 <DT>
 191 <SAMP>ArcDataF</SAMP>
 192 <DD>
 193 The name of a default notation declared in the meta-DTD,
 194 to which the external data entities in the document
 195 should be automatically mapped if they would
 196 not otherwise be considered architectural.
 197 If this attribute is defined,
 198 then general entities will be automatically architectural:
 199 any external data entity whose notation cannot otherwise be mapped
 200 into a notation in the meta-DTD will be automatically treated
 201 as an instance of the <SAMP>ArcDataF</SAMP> notation.
 202 This would be <SAMP>data</SAMP> for HyTime.
 203 If your meta-DTD declares entity attributes, it will usually
 204 be appropriate to specify a value for <SAMP>ArcDataF</SAMP>
 205 even if your meta-DTD declares no data attributes for the
 206 notation.
 207 <DT>
 208 <SAMP>ArcAuto</SAMP>
 209 <DD>
 210 This must have one of the following values:
 211 <DL>
 212 <DT>
 213 <SAMP>ArcAuto</SAMP>
 214 <DD>
 215 If an element does not have an <SAMP>ArcFormA</SAMP> attribute and the
 216 meta-DTD defines an element type with the same name as the element's
 217 type, the element will be automatically treated as being an instance
 218 of the meta-type.  This rule does not apply to the
 219 document element type; this is automatically treated as being an
 220 instance of the meta-DTD's document element type.
 221 Note that this automatic mapping is prevented if
 222 the element has an <SAMP>ArcFormA</SAMP> attribute with an implied
 223 value.  It is also prevented if processing of the
 224 <SAMP>ArcFormA</SAMP> attribute is suppressed.  This applies equally
 225 to the notations of external data entities.
 226 The default element or notation specified with the
 227 <SAMP>ArcBridF</SAMP> or <SAMP>ArcDfltN</SAMP> attribute
 228 is only considered after the mapping specified by <SAMP>ArcAuto</SAMP>.
 229 <DT>
 230 <SAMP>nArcAuto</SAMP>
 231 <DD>
 232 Automatic mapping is not performed.
 233 </DL>
 234 <P>
 235 The default value is <SAMP>ArcAuto</SAMP>.
 236 <DT>
 237 <SAMP>ArcOptSA</SAMP>
 238 <DD>
 239 A list of names of architectural support attributes,
 240 each of which is interpreted as a list of parameter entities
 241 to be defined with a replacement text of <SAMP>INCLUDE</SAMP>
 242 when parsing the meta-DTD.
 243 The default value is <SAMP>ArcOpt</SAMP>.
 244 </DL>
 245 <H2>Meta-DTDs</H2>
 246 <P>
 247 A meta-DTD is allowed to use the following extensions:
 248 <UL>
 249 <LI>
 250 a single element type or notation is allowed to be an associated
 251 element type or associated notation name for multiple attribute
 252 definition lists.
 253 <LI>
 254 <SAMP>#ALL</SAMP> can be used as an associated element type
 255 or associated notation name in an attribute definition list
 256 to define attributes for all element types or notations
 257 in the meta-DTD
 258 </UL>
 259 <P>
 260 Before any of these extensions can be used, the meta-DTD must include a
 261 declaration
 262 <PRE>
 263 &lt;!AFDR "ISO/IEC 10744:1997"&gt;
 264 </PRE>
 265 <P>
 266 This declaration should only be included if the extensions are used.
 267 <P>
 268 In all other respects a meta-DTD must be a valid SGML DTD.
 269 <P>
 270 A declared value of ENTITY for an attribute in a meta-DTD means that
 271 the value of the attribute must be an entity declared in
 272 the (non-meta) DTD that is architectural.
 273 An external data entity is architectural only if its notation can be
 274 mapped into a notation in the meta-DTD.
 275 All other kinds of data entities and subdoc entities are automatically
 276 architectural.
 277 <P>
 278 An IDREF attribute in the meta-document must have a corresponding ID
 279 in the meta-document.  An attribute with a declared value of ID in the
 280 document will be automatically mapped to an attribute with a declared
 281 value of ID in the meta-DTD.
 282 <P>
 283 A declared value of NOTATION in the meta-DTD means that the value of
 284 the attribute must have one the values specified in the name group and
 285 that it must be a notation in the meta-DTD.
 286 (Perhaps if the attribute also has a declared value of NOTATION
 287 in the non-meta-DTD, the value should be mapped in a similar
 288 way to the notation of an external data entity.)
 289
 290 <H2>Differences from HyTime</H2>
 291 <P>
 292 There are a number of differences from how architectural processing is
 293 defined in the pre-Corringendum version of the HyTime standard.
 294 <UL>
 295 <LI>
 296 The <SAMP>ArcNamrA</SAMP> and <SAMP>ArcFormA</SAMP> attributes are not
 297 part of the meta-DTD.  Rather they are used by the architecture engine
 298 in deriving the meta-document that is validated against the meta-DTD.
 299 <LI>
 300 The <SAMP>use:</SAMP> conventional comment is not recognized.  Instead
 301 a single element type is allowed to be an associated element type for
 302 multiple attribute definition lists.
 303 <LI>
 304 The notation and data attributes of an external data entity are
 305 treated just like the element type and attributes of an element.  The
 306 notation of an external data entity is mapped into a notation in the
 307 meta-DTD and the data attributes of the entity are mapped onto
 308 attributes defined for the meta-DTD notation.
 309 <LI>
 310 <SAMP>#FIXED</SAMP> has the same meaning in a meta-DTD that it does in
 311 a regular DTD: the value of the attribute must be the same as the
 312 default value of the attribute specified in the meta-DTD.
 313 </UL>
 314
 315 <H2>Specifying architectural processing with an LPD</H2>
 316 <P>
 317 Link attributes defined by an implicit link process are treated in the
 318 same way as non-link attributes.  The only complication is that SGML
 319 allows link attributes to have the same name as non-link attributes.
 320 If there is a link attribute and a non-link attribute with the same
 321 name, the architecture engine will only look at the link attribute,
 322 even if the value of the link attribute is implied.  The only
 323 exception is the <SAMP>ArcNamrA</SAMP> attribute: the architecture
 324 engine will use both the link attribute and the non-link attribute,
 325 but the substitute names in the value of the non-link attribute cannot
 326 refer to link attribute names.
 327 <P>
 328 The <SAMP>-A <VAR>archname</VAR></SAMP> option automatically activates
 329 any link type <SAMP><VAR>archname</VAR></SAMP>.
 330 <P>
 331 The architecture notation declaration and associated attribute
 332 definition list declaration are allowed in the LPD.  Although the
 333 productions of ISO 8879 do not allow a notation declaration in a link
 334 type declaration subset, it is clearly the intent of the standard that
 335 they be allowed.  You can use a <SAMP>-wlpd-notation</SAMP> option to
 336 disallow them.
 337
 338 <H2>Derived architectures</H2>
 339 <P>
 340 A meta-DTD can have one or more base architectures in the same way as
 341 a normal DTD.  Multiple <SAMP>-A</SAMP> options can be used to exploit
 342 this.  For example,
 343 <PRE>
 344 -A <VAR>arch1</VAR> -A <VAR>arch2</VAR>
 345 </PRE>
 346 <P>
 347 will perform architectural processing on the source document to
 348 produce an architectural document conforming to the architecture
 349 <SAMP><VAR>arch1</VAR></SAMP> declared in the source document, and
 350 will then perform architectural processing on this architectural
 351 document to produce an architectural document conforming to the
 352 <SAMP><VAR>arch2</VAR></SAMP> architecture declared in
 353 <SAMP><VAR>arch1</VAR></SAMP>'s meta-DTD.
 354 <P>
 355 A document that is validated against a meta-DTD will automatically
 356 be validated against any base architectures of that meta-DTD.
 357 </BODY>
 358 </HTML>