~ubuntu-branches/ubuntu/trusty/openjade1.3/trusty

« back to all changes in this revision

Viewing changes to doc/archform.htm

  • Committer: Bazaar Package Importer
  • Author(s): Yann Dirson
  • Date: 2002-04-09 00:01:50 UTC
  • Revision ID: james.westby@ubuntu.com-20020409000150-r9rkyalxlhvf9ba3
Tags: upstream-1.3.1
ImportĀ upstreamĀ versionĀ 1.3.1

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
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.  SP
 
14
includes such an architecture engine.
 
15
<P>
 
16
Non-markup sensitive applications built using SP 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
 
 
358
<H2><A NAME=hi2diff>Unimplemented features</A></H2>
 
359
<P>
 
360
The following features from the AFDR specification in HyTime 2nd
 
361
edition are not yet implemented:
 
362
<UL>
 
363
<LI>
 
364
use of <CODE>#MAPTOKEN</CODE> in the architectural attribute renamer.
 
365
</UL>
 
366
<P>
 
367
<ADDRESS>
 
368
James Clark<BR>
 
369
jjc@jclark.com
 
370
</ADDRESS>
 
371
</BODY>
 
372
</HTML>