index.html
98.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="EN"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>XForms for HTML </title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
.xmlverb-default { color: #333333; background-color: #ffffff; font-family: monospace }
.xmlverb-element-name { color: #990000 }
.xmlverb-element-nsprefix { color: #666600 }
.xmlverb-attr-name { color: #660000 }
.xmlverb-attr-content { color: #000099; font-weight: bold }
.xmlverb-ns-name { color: #666600 }
.xmlverb-ns-uri { color: #330099 }
.xmlverb-text { color: #000000; font-weight: bold }
.xmlverb-comment { color: #006600; font-style: italic }
.xmlverb-pi-name { color: #006600; font-style: italic }
.xmlverb-pi-content { color: #006666; font-style: italic }
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p>
<h1><a name="title" id="title"></a>XForms for HTML </h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 19 December 2008</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2008/WD-XForms-for-HTML-20081219/">http://www.w3.org/TR/2008/WD-XForms-for-HTML-20081219/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/XForms-for-HTML/"> http://www.w3.org/TR/XForms-for-HTML/</a>
</dd><dt><br>Editor:</dt><dd>John M. Boyer, IBM</dd><dt><br></dt></dl><p>This document is also available in these non-normative formats:
<a href="index-diff.html">diff-marked HTML</a>
.</p><p>The English version of this specification is the only normative version. Non-normative <a href="http://www.w3.org/MarkUp/Forms/Translation/">translations</a> may also be available.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/index.php"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>XForms for HTML provides a set of attributes and script methods that can be used by the tags or elements of an HTML or XHTML web page to simplify the integration of data-intensive interactive processing capabilities from XForms. The semantics of the attributes are mapped to the rich XForms model-view-controller-connector architecture, thereby allowing web application authors a smoother, selective migration path to the higher-order behaviors available from the full element markup available in modules of XForms.</p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</h2><p>
<em>This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the latest
revision of this technical report can be found in the
<a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em>
</p><p>This document is a
<a href="http://www.w3.org/Consortium/Process-20010719/tr.html#RecsW3C">Working Draft</a>
of the W3C. This document has been produced by the
<a href="http://www.w3.org/MarkUp/Forms/">W3C Forms Working Group</a> as part of the
<a href="http://www.w3.org/2002/Forms/Activity">Forms Activity</a> within the
<a href="http://www.w3.org/Interaction/">W3C Interaction Domain</a>.
The authors of this document are the W3C Forms Working Group participants.
</p><p>This document is a first public working draft of a specification that is designed to satisfy the W3C charter requirement
for the <a href="http://www.w3.org/MarkUp/Forms/">W3C Forms Working Group</a> to create a specification for forms
on the web that blends web author and web page consumability requirements manifest in <a href="http://www.w3.org/TR/2006/WD-web-forms-2-20060821/">Web Forms 2.0</a> with the data-rich web application features and overall architecture of <a href="http://www.w3.org/TR/2007/CR-xforms11-20071129/">XForms</a>.
</p><p>Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
</p><p>Comments on this document are welcome.
Please send discussion comments to <a href="mailto:www-forms-editor@w3.org">www-forms@w3.org</a>.
Please send formal comment about this document to the public editor mailing list
<a href="mailto:www-forms-editor@w3.org">www-forms-editor@w3.org</a>.
(<a href="http://lists.w3.org/Archives/Public/www-forms-editor/">archive</a>).
</p><p> This document was produced by a group operating under the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>.
W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/32219/status">public
list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes
instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual
believes contains Essential Claim(s) must disclose the information in accordance with
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.
</p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#intro-reading">Introduction</a><br>
2 <a href="#form-containment">Form Containment</a><br>
3 <a href="#default-data-instance">Default Data Instance</a><br>
3.1 <a href="#default-data-instance-name">The name Attribute</a><br>
3.2 <a href="#default-data-instance-initialvalues">Initializing Generated Data Nodes</a><br>
3.3 <a href="#default-data-instance-startsize">The startsize Attribute</a><br>
3.4 <a href="#default-data-instance-number">The number Attribute</a><br>
4 <a href="#runtime-form-control-operations">Runtime Operations on Form Controls</a><br>
4.1 <a href="#get-set-value">Getting and Setting the Value of a Form Control</a><br>
4.2 <a href="#setfocus">Setting the Focus to a Form Control</a><br>
4.3 <a href="#idref-resolution">Finding Runtime Form Controls by ID</a><br>
4.4 <a href="#repeat-dynamism">Dynamically Changing the Size of a Repeat Form Control</a><br>
5 <a href="#declarative-execution-model">Declarative Execution Model for Data Instances</a><br>
5.1 <a href="#declarative-data-validation">Declarative Validation</a><br>
5.2 <a href="#declarative-data-access">Declarative Data Access with the readonly Attribute</a><br>
5.3 <a href="#declarative-data-calculation">Declarative Calculation</a><br>
5.4 <a href="#declarative-data-relevance">Declarative Relevance</a><br>
5.5 <a href="#declarative-xpath-expression-context">Declarative XPath Expression Context</a><br>
6 <a href="#data-submission">Data Submissions</a><br>
7 <a href="#declarative-form-control-properties">Declarative Form Control Properties</a><br>
8 <a href="#conformance">Conformance</a><br>
</p>
<h3><a name="mainsection" id="mainsection"></a>Appendices</h3><p class="toc">A <a href="#terms">Glossary Of Terms</a><br>
B <a href="#references">References</a><br>
B.1 <a href="#references-norm">Normative References</a><br>
C <a href="#acks">Acknowledgements</a> (Non-Normative)<br>
D <a href="#prod-notes">Production Notes</a> (Non-Normative)<br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="intro-reading" id="intro-reading"></a>1 Introduction</h2><p>This document uses the terms <b>must</b>, <b>must not</b>,
<b>required</b>, <b>shall</b>, <b>shall not</b>,
<b>recommended</b>, <b>should</b>, <b>should not</b>,
<b>may</b>, and <b>optional</b> in accord with <a href="#ref-rfc-2119">[RFC 2119]</a>. </p><p>This document describes XForms for HTML, which provides a set of attributes and script methods encompassing a useful subset of XForms functionality and mapping that functionality to syntactic constructs that are familiar to authors of HTML and XHTML web pages. The intent of this module is to simplify the means by which web page authors gain access to the rich functionality available from the hybrid execution model of XForms, which combines declarative constructs with event-driven imperative processing. These attributes and script methods increase the initial consumability of XForms by allowing injection of rich semantics directly into the host language markup. In turn, the behaviors of the attributes and script methods are mapped to the XForms model-view-controller-connector architecture so that applications manifest behaviors consistent with having used XForms markup elements. This allows authors to gradually address greater application complexity as it arises in the software lifecycle by opportunistically, i.e. as the need arises, switching from the attributes and script methods of this specification to the corresponding XForms markup elements. This gradual adoption strategy is being further supported by the modularization of XForms into components that can be consumed incrementally by authors and implementers.</p><p>The XForms for HTML attributes are offered to HTML and XHTML web pages as a set of local attributes. Other consuming host language markup languages <b>may</b> adopt these attributes as global attributes in the XForms namespace (<code>http://www.w3.org/2002/xforms</code>). </p><p>Host language processors <b>should</b> be, but are not required to be, namespace aware. For clarity, this specification describes integration with explicitly declared XForms elements by using the prefix <code>xf</code> to indicate the XForms namespace (http://www.w3.org/2002/xforms) being applied to those elements. A host language processor <b>may</b> adopt the XForms elements into its own namespace for ease of authoring.</p></div><div class="div1">
<h2><a name="form-containment" id="form-containment"></a>2 Form Containment</h2><p>Each form within an HTML or XHTML web page is denoted by a <code>form</code> element and its content.</p><p>A form can contain an explicitly declared XForms model using the <code><xf:model></code>
element. If a form contains more than one <code><xf:model></code>, then all but the first <code><xf:model></code>
in the form <b>must</b> be ignored by implementations conformant to this specification.</p><p>If a form does not contain an <code><xf:model></code> element, then an implicit
<code><xf:model></code> element is generated and associated with the form element.
With regard to event flow and document serialization, the generated <code><xf:model></code>
element is considered to be prepended before the first child element of the form element.
The generated <code><xf:model></code> element is required as it is used by the XForms
processor as the target of model events. The generated <code><xf:model></code> element
has no <code>id</code> attribute.</p></div><div class="div1">
<h2><a name="default-data-instance" id="default-data-instance"></a>3 Default Data Instance</h2><p>This section describes the management of data instances in a form as well as the basic attributes
that can be used to generate or bind to a default data instance based on element structure in the host
language markup.</p><p>A form can contain any number of explicitly declared data instances using the
<code><xf:instance></code> element. </p><p>If a form also contains an explicitly declared <code><xf:model></code> element, then any
<code><xf:instance></code> elements in the form that are not children of the
<code><xf:model></code> element <b>must</b> be ignored by implementations conformant to
this specification. An author who adds <code><xf:model></code> element to a form
is advised to place any preexisting <code><xf:instance></code> elements within it.</p><p>The default data instance of the form is indicated by the <code>instance</code> attribute on
the <code>form</code> element, or its default. If the <code>instance</code> attribute indicates the ID
of an <code><xf:instance></code> element, then the indicated <code><xf:instance></code>
provides the default data instance of the form. Otherwise, the <code>instance</code> attribute
is absent, empty or does not indicate the ID of an <code><xf:instance></code> element.
In these cases an implicit default data instance is generated for the form based on the attributes
defined in this section that appear on elements or tags within the content of the form element. </p><p>The implicit default data instance is known as the <b>generated data instance</b>.
The generated data instance is created as the first element child of the form's XForms model.
The process of creating the generated data instance is known as <b>data instance generation</b>.
Regardless of whether the model is generated or declared, the process of data instance generation
occurs before the <code>xforms-model-construct</code> event occurs for the model. </p><div class="note"><p class="prefix"><b>Note:</b></p><p>If a form contains no elements or tags that have a <code>name</code> attribute, then a
generated data instance is not created for the form's XForms model.</p></div><p>If the <code><xf:model></code> element is explicitly declared for a form, and it contains no declared
<code><xf:instance></code> element and the form does not contain any elements bearing the
<code>name</code> attribute, then a default data instance is constructed for the <code><xf:model></code>
according to the method described in the <code>xforms-model-construct-done</code> event.
A default data instance constructed in this manner is defined to be a <b>constructed data instance</b>,
not a generated data instance. Therefore, the initializations described below for the generated data instance
are not applicable to the constructed data instance.</p><p>The following attributes are pertinent to the data instance generation process and the creation of
form controls within a form.</p><table border="1" summary="Attributes pertinent to data instance generation"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">instance</td><td rowspan="1" colspan="1">IDREF or empty</td><td rowspan="1" colspan="1">Used on a <code>form</code> element to indicate the default data instance, which is the data
instance to which form controls bind with the <code>name</code> attribute. If the <code>instance</code> attribute
indicates the ID of an <code><xf:instance></code> in the form, then that <code><xf:instance></code> is used
as the default data instance of the form. Otherwise, the default data instance for the form is the
generated data instance.</td></tr><tr><td rowspan="1" colspan="1">name</td><td rowspan="1" colspan="1">xsd:QName</td><td rowspan="1" colspan="1">The element bearing the attribute is a form control bound to the data node or nodes
that match the attribute value.</td></tr><tr><td rowspan="1" colspan="1">value</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">When used in combination with <code>name</code> (in other words, when used on a form control),
this attribute helps to provides an initial value when generating a node in the generated data instance.</td></tr><tr><td rowspan="1" colspan="1">type</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">This attribute is used on a form control to help determine how the <code>value</code> attribute
contributes to the initialization of the generated data instance. This specification defines data
initialization behavior only for case-insensitive value matches to the string <code>"radio"</code> and
<code>"checkbox"</code>. </td></tr><tr><td rowspan="1" colspan="1">checked</td><td rowspan="1" colspan="1"><code>true</code> (also <code>TRUE</code>, <code>checked</code> or <code>CHECKED</code>), or <code>false</code> (also <code>FALSE</code>)</td><td rowspan="1" colspan="1">This attribute is used on a form control to help determine whether the <code>value</code> attribute
contributes to the initialization of the generated data instance. In HTML, if the attribute value is not specified,
then the existence of the attribute is construed as a true result, and its absence is construed as a false result.</td></tr><tr><td rowspan="1" colspan="1">startsize</td><td rowspan="1" colspan="1">xsd:nonNegativeInteger</td><td rowspan="1" colspan="1">This attribute indicates that the form control bearing this a repeat form control. The content of the form
control is to be treated as a template. The template and the named data node are to be repeated any number of times
during document execution. During default data instance generation, the number given by the attribute value determines
the number of data nodes to initially generate and the number of copies of the template content to generate.</td></tr><tr><td rowspan="1" colspan="1">number</td><td rowspan="1" colspan="1">xsd:nonNegativeInteger</td><td rowspan="1" colspan="1">This attribute indicates how many copies of the template of a repeat form control
<b>should</b> be presented to the user at any given time. The user interface processor <b>should</b> provide
a scrolling mechanism to allow the user to change the set of template copies being presented.</td></tr></tbody></table><p>An element or tag that bears the <code>name</code> attribute is called a <b>form control</b>.
A form control that also bears a <code>startsize</code> attribute is called a <b>repeat form control</b>.
Content within a repeat form control is treated as a template which can be generated multiple times
corresponding to a number of data nodes matched by the <code>name</code> attribute value of the
repeat form control. The template elements that bear a <code>name</code> attribute are not form controls,
but the elements generated from the template in response to repeated data nodes are form controls if
they bear the <code>name</code> attribute, and they are known as <b>generated form controls</b>.</p><p>A form control that contains a form control or is a repeat form control is known as a
<b>container form control</b>. The <b>child form control list</b> of a container form control
is an ordered list of form controls for which the container form control is the nearest ancestor form control.
The position of a form control in a child form control list is based on document order for non-generated
form controls, and on document order of the template form control combined with generation order for
generated form controls. The <b>focus order</b> of all form controls in a form is based on depth
depth-first pre-order visitation of form controls and the order sequence of child form control lists of
the container form controls.</p><p>If a <code>form</code> element does not bear the <code>name</code> attribute, then the default for
the <code>name</code> on the <code>form</code> element is <code>data</code>. The default for <code>name</code>
only applies on a <code>form</code> element, and this default has two effects.
First, it provides a name for the root element of the generated data instance.
Second, whether or not the <code>form</code> element explicitly declares the <code>name</code> attribute,
the <code>form</code> element is a container form control for all form controls within its content.
See <a href="#default-data-instance-name"><b>3.1 The name Attribute</b></a> for further details on how the data instance is
generated in response to the <code>name</code> and <code>startsize</code> attributes.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The <code>name</code> attribute can be used on the <code>form</code> element to assign a namespace qualified
name to the root element of the generated data instance.</p></div><div class="exampleOuter"><p>Given the following markup:</p><div class="exampleInner"><pre><form xmlns:my="http://example.org" name="my:form" ... >
...
</form></pre></div><p>The following generated instance is produced:</p><div class="exampleInner"><pre><xf:instance>
<my:form xmlns="" xmlns:my="http://example.org">
...
</my:form>
</xf:instance></pre></div><p>In the second example below, the namespace prefix <code>my</code> is not defined in the namespace
context of the <code>form</code> element:</p><div class="exampleInner"><pre><form name="my:form" ... >
...
</form></pre></div><p>And as a result, the root element node is named <code>data</code>
and placed in the empty namespace:</p><div class="exampleInner"><pre><xf:instance>
<data xmlns="">
...
</data>
</xf:instance></pre></div><p>In the third example below, an unprefixed name is given in the <code>name</code> attribute:</p><div class="exampleInner"><pre><form name="mydata"... >
...
</form></pre></div><p>And as a result, the root element node is named <code>mydata</code>
and placed in the empty namespace:</p><div class="exampleInner"><pre><xf:instance>
<mydata xmlns="">
...
</mydata>
</xf:instance></pre></div><p>In the fourth example below, the <code>name</code> attribute is omitted:</p><div class="exampleInner"><pre><form ... >
...
</form></pre></div><p>And as a resulting generated data instance uses the default name of <code>data</code>:</p><div class="exampleInner"><pre><xf:instance>
<data xmlns="">
...
</data>
</xf:instance></pre></div></div><p>If the <code>startsize</code> attribute appears on a <code>form</code> element, it <b>must</b> be ignored because the
default data instance of a form <b>must</b> be singly rooted. For the same reason, if a <code>number</code>
attribute appears on a <code>form</code> element, then it <b>must</b> be ignored. Finally, the attributes <code>value</code>,
and <code>checked</code> are ignored if they appear on a <code>form</code> element because it is a container form control.</p><div class="div2">
<h3><a name="default-data-instance-name" id="default-data-instance-name"></a>3.1 The name Attribute</h3><p>Data instance generation for a form is based on the <code>name</code> attributes on the elements or tags
within the form.</p><p>On the <code>form</code> element, if the <code>name</code> attribute is absent, then the default value is <code>data</code>.
The <code>name</code> attribute does not have a default except for <code>form</code> elements. If the <code>name</code>
attribute appears on an element or tag that is not a <code>form</code> element, then that element or tag is a form control within the
nearest ancestor <code>form</code> element.</p><p>If the <code>name</code> attribute value contains a <a href="http://www.w3.org/TR/REC-xml-names/#NT-PrefixedName">PrefixedName</a>, but the namespace prefix is not in the
namespace context of the element bearing the <code>name</code> attribute, then the <code>name</code>
attribute is ignored. On a <code>form</code> element, this causes the default value to be used. On any element
other than a <code>form</code> element, this causes the element to not be a form control.</p><p>During data instance generation, a data node is generated based on the <code>name</code> of each
form control. The QName of a generated data instance node is equal to the attribute value of the
<code>name</code> attribute on the form control bound to the data node. The data node for the <code>form</code> element
is created as the root element of the generated data instance. For each descendant form control in a form, the
data node is created as a child element of the data node created for the nearest ancestor container form control,
and the position of the data node is equal to the position of the form control in the child form control list of the
nearest ancestor container form control. This method creates a generated data instance whose structure matches
the user interface structure within the markup. This generation method is amended for simple repetition in Section
<a href="#default-data-instance-startsize"><b>3.3 The startsize Attribute</b></a>. </p><p>The root element of the generated data instance always bears the declaration <code>xmlns=""</code>.
The root element of the generated data instance will also bear the correct namespace prefix definition
if the the data node has a <a href="http://www.w3.org/TR/REC-xml-names/#NT-PrefixedName">PrefixedName</a>. For any descendant nodes of the generated
data instance root element, if the node is not a <a href="http://www.w3.org/TR/REC-xml-names/#NT-PrefixedName">PrefixedName</a>, then no namespace qualifiers are added
when the node is initially generated. Otherwise, if the non-root node has a
<a href="http://www.w3.org/TR/REC-xml-names/#NT-PrefixedName">PrefixedName</a>, then a namespace prefix declaration
node <b>must</b> be added for the prefix of the non-root node. However, the following <b>namespace
prefix promotion method</b> is used:</p><ol class="enumar"><li><p>The nearest ancestor is obtained in the generated data instance that has the matching namespace prefix
defined.</p></li><li><p>If no such ancestor is found, then the namespace prefix declaration is added to the root element
of the generated data instance.</p></li><li><p>If the nearest ancestor is found with a namespace prefix declaration for the prefix needed by the node being
generated, and the namespace URI of the ancestor node's prefix declarationmatches the namespace URI of
the prefix needed for the data node being generated, then no new namespace prefix declaration is
added because the declaration at the ancestor node will be inherited into the namespace context
of the newly generated node.</p></li><li><p>If the nearest ancestor namespace prefix declaration for the prefix needed by the node being
generated has a different namespace URI from the one needed for the data node being generated,
a new namespace prefix declaration with the proper namespace URI is added to the farthest ancestor
of the node being generated that is still a descendant of the ancestor with the conflicting namespace
prefix declaration.</p></li></ol><p>This method generally minimizes the number of namespace declarations appearing in the generated data instance,
if the form author chooses to use namespaces in the data.</p><p>Once the data node for a form control is generated, the form control is bound to that data node
as if by an XForms user interface binding. </p><p>If, during data instance generation, a form control is encountered whose <code>name</code>
matches a node already generated, then a new data instance node is not generated since one
already exists. Instead, the form control is simply bound to the preexisting data instance node.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Duplicated names do not result in repeated data with the same name because XForms for HTML
offers an attribute and run-time form operations for handling dynamic data repetition. </p></div><p>When the form control also has the <code>startsize</code> attribute, then the form control is a repeat
form control, so it is simultaneously bound to all data nodes that match the <code>name</code> attribute value
that appear as children of the data node bound to the nearest ancestor container form control of the
repeat form control. Section <a href="#default-data-instance-startsize"><b>3.3 The startsize Attribute</b></a> describes how multiple
nodes corresponding to the name of a repeat form control are generated, and Section
<a href="#repeat-dynamism"><b>4.4 Dynamically Changing the Size of a Repeat Form Control</b></a> describes run-time operations for increasing and decreasing the
number of data nodes associated with a repeat form control.</p></div><div class="div2">
<h3><a name="default-data-instance-initialvalues" id="default-data-instance-initialvalues"></a>3.2 Initializing Generated Data Nodes</h3><p>During data instance generation, the <code>value</code>, <code>type</code>, and <code>checked</code>
attributes are used to help determine initial values for the data nodes being generated on behalf of form control
with a <code>name</code> attribute. Additional semantics can be assigned to these attributes beyond the behaviors
described in this section. </p><p>This specification defines no processing for <code>value</code>, <code>type</code>, <code>checked</code>
when they appear on container form controls, which also includes the <code>form</code> element and repeat form controls.
A form control that is not a container form control is called a <b>core form control</b>. </p><p>When a data instance node is generated on behalf of a core form control, the node is also given
an initial value of either empty string or a copy of the <code>value</code> attribute value using the
the following method:</p><ol class="enumar"><li><p>If the <code>type</code> attribute value has a case-insensitive match to
the value <code>radio</code> or <code>checkbox</code>, then the initial value
of the data node is obtained from the <code>value</code> attribute if it is given
and if the <code>checked</code> attribute produces a true result, and otherwise the
initial value of the data node is the empty string.
</p></li><li><p>If the <code>type</code> attribute is not given or does not have a case-insensitive
match to the value <code>radio</code> or <code>checkbox</code>,
then the initial value of the data node is obtained from the <code>value</code> attribute if it
is given, and otherwise the initial value of the data node is the empty string.
</p></li></ol><p>If, during data instance generation, a core form control is encountered whose <code>name</code>
matches a data node already generated, then the <code>value</code> attribute, if given, is used to
amend the initial value of the preexisting data node using the following method:</p><ol class="enumar"><li><p>If the <code>type</code> attribute value has a case-insensitive match to
the value <code>radio</code>, then the initial value of the data node is replaced
with a copy of the <code>value</code> attribute value. </p></li><li><p>If the <code>type</code> attribute value has a case-insensitive match to
the value <code>checkbox</code>, then the <code>value</code> attribute value is
appended to the initial value of the data node, with a separating space if the
data node was not an empty string.
</p></li><li><p>Otherwise, the <code>value</code> attribute is regarded as a duplicate initializer and
is ignored.
</p></li></ol><div class="exampleOuter"><p>Given the following HTML form:</p><div class="exampleInner"><pre>
<form action="preferences.asp" method="get">
<label for="name">Name: </label>
<input type="text" name="name" value="John Q. Public" />
<br />
<fieldset name="region">
<label for="city">City: </label>
<input type="text" name="city" value="Victoria" />
<br />
<label for="country">Country: </label>
<input type="text" name="country" value="Canada" />
<br />
</fieldset>
<label for="favorite">Choose your favorite music type: </label>
<input type="radio" name="favorite" value="rock"> Rock<br>
<input type="radio" name="favorite" value="pop" checked> Pop<br>
<input type="radio" name="favorite" value="alternative"> Alternative<br>
<input type="radio" name="favorite" value="classical"> Classical<br>
<label for="prefs">Choose all the music types you enjoy: </label>
<input type="checkbox" name="prefs" value="rock" checked> Rock<br>
<input type="checkbox" name="prefs" value="pop" checked> Pop<br>
<input type="checkbox" name="prefs" value="alternative"> Alternative<br>
<input type="checkbox" name="prefs" value="classical" checked> Classical<br>
<input type="submit" value="Submit" />
</form>
</pre></div><p>the data instance is generated and initialized as follows:</p><div class="exampleInner"><pre>
<xf:instance>
<data xmlns="">
<name>John Q. Public</name>
<region>
<city>Victoria</city>
<country>Canada</country>
</region>
<favorite>pop</favorite>
<prefs>rock pop classical</prefs>
</data>
</xf:instance>
</pre></div></div><p>Implementations that perform run-time document serialization <b>must</b> preserve the original
<code>value</code> attribute values in the document serialization.
Implementations of run-time document serialization <b>must</b> preserve
run-time values by writing the declared default data instance into the content of the form element
(i.e. using an <code><xf:instance></code> element indicated by an <code>instance</code> attribute on the <code>form</code> element).
This technique helps minimize alteration of the host document markup during serialization, and it
preserves repeated data.</p></div><div class="div2">
<h3><a name="default-data-instance-startsize" id="default-data-instance-startsize"></a>3.3 The startsize Attribute</h3><p>When the <code>startsize</code> attribute is used in combination with the <code>name</code> attribute,
the element bearing the attributes becomes a repeat form control. If the attribute value is not
a non-negative integer, then the value <code>1</code> is used.</p><p>If the <code>name</code> attribute matches preexisting data nodes, then the repeat form control is
bound to the data nodes without generating any new data instance nodes. Otherwise, the data instance
generation process for the repeat form control and the form controls it contains is repeated zero or more
time according to the number in the <code>startsize</code> attribute. </p><p>Once the data instances of the forms are initialized, the repeat form control treats its content as a template
and generates a copy of the template once for each node bound to the repeat form control. A template instance
is called a <b>repeat object</b>, and the data node for which a repeat object is created is called the
<b>generator node</b>. The form controls in each repeat object are bound to the nodes in the
data subtree rooted by the generator node.</p><div class="exampleOuter"><p>Suppose the following table appeared as a child element of a form.</p><div class="exampleInner"><pre>
<table summary="List of items to purchase" name="order">
<thead>
<tr>
<th>Product Name</th>
<th>Unit Cost</th>
<th>Quantity</th>
<th>Product Total</th>
</tr>
</thead>
<tbody name="item" id="item" startsize="1">
<tr>
<td>
...
</td>
<td>
<label for="unitprice" class="within_table">Unit Price</label>
<input name="unitprice" type="text" value="0" ... />
</td>
<td>
<label for="quantity" class="within_table">Product Quantity</label>
<input name="quantity" type="text" value="1" ... />
</td>
<td>
...
</td>
</tr>
</tbody>
</table>
</pre></div><p>The result of data instance generation would be the following:</p><div class="exampleInner"><pre>
<xf:instance>
<data xmlns="">
...
<order>
<item>
...
<unitprice>0</unitprice>
<quantity>1</quantity>
...
</item>
</order>
...
</data>
</xf:instance>
</pre></div></div></div><div class="div2">
<h3><a name="default-data-instance-number" id="default-data-instance-number"></a>3.4 The number Attribute</h3><p>A hint to the processor about the maximum number of repeat objects to present
within a repeat form control before using a secondary presentation mechanism, such as
scrolling.</p></div></div><div class="div1">
<h2><a name="runtime-form-control-operations" id="runtime-form-control-operations"></a>4 Runtime Operations on Form Controls</h2><div class="div2">
<h3><a name="get-set-value" id="get-set-value"></a>4.1 Getting and Setting the Value of a Form Control</h3><p>Each form control has the possibility of rendering a formatted version of the textual content
stored in the data node bound to the form control. For example, a data value of <code>1234.567</code>
could be presented in the form control as <code>$1,234.57</code>.</p><p>Each form control has an associated <code>value</code> property that contains the current textual content
being rendered by the form control. This property can be examined by script that seeks the formatted data
value of the form control, and a raw data value can be formatted by script and assigned to this property.</p><p>Each form control is augmented with methods <code>getValue()</code> and <code>setValue(string)</code>.
The <code>getValue()</code> method returns the underlying raw data value, which is textual content of the data
node bound to the form control. The <code>setValue()</code> method is used to assign a raw data value
to the data node bound to the form control. The <code>setValue()</code> method assigns the raw data value to the
<code>value</code> property and then it behaves as if it has invoked an XForms <code>setValue</code> action to send
the raw data value to the XForms data instance. Thus, this operation respects the readonly setting of a data node,
and it invokes the XForms model update sequence (recalculate, revalidate, refresh).</p><div class="exampleOuter"><p>In this example, the form control identified as X is set to the value "1234.567":</p><div class="exampleInner"><pre>onClick="document.getElementById('X').setValue('1234.567') "</pre></div></div><div class="note"><p class="prefix"><b>Note:</b></p><p>Once a raw data value assignment has been made with the <code>setValue()</code> method,
the XForms model update sequence includes dispatching the <code>xforms-value-changed</code>
event to the form control bound to the data node changed by <code>setValue()</code>. An author
could write an event handler for this event to run script that invokes <code>getValue()</code>, performs
formatting operations on the raw data, and then assigns the formatted string to the <code>value</code>
property of the form control.</p></div><p>When end-user input into a form control is committed to the <code>value</code> property, a
change event also occurs. The XForms for HTML processor attaches a handler function to the change event
that invokes the <code>setValue()</code> method for the form control.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>If an author uses the <code>value</code> property to handle formatted text on a form control that
is not readonly, then the author also has to deal with conversion of end-user input from formatted text
to raw data. Such an author must overload the base <code>setValue()</code> method of the form
control described above so that the author's script code can convert the user input to raw data and then
invoke the prototypical <code>setValue()</code> method.</p></div></div><div class="div2">
<h3><a name="setfocus" id="setfocus"></a>4.2 Setting the Focus to a Form Control</h3><p>All form controls are augmented with a method <code>focus()</code>. When invoked, the web page navigates to the form control for which the method has been invoked. In the case of a container form control, the <code>focus()</code> method of the first form control in its child form control list is invoked. In the case of a repeat form control, the <code>focus()</code> method is invoked on the first form control in the child form control list of the currently indexed repeat object (see <a href="#repeat-dynamism"><b>4.4 Dynamically Changing the Size of a Repeat Form Control</b></a> for further details about repeat index management).</p></div><div class="div2">
<h3><a name="idref-resolution" id="idref-resolution"></a>4.3 Finding Runtime Form Controls by ID</h3><p>It is possible for a form control in a repeat object to have numerous counterparts in other repeat objects, all identifiable under the ID given to the template for the form control. The <code>document.getElementById()</code> method is insufficient for finding these repeated form controls.</p><p>The document and all repeat form controls are augmented with a method called <code>getRuntimeElementById()</code>, which receives a string containing an IDREF and returns either the identified element or null. The method searches within the scope of the object on which the method was invoked. In the case of a document, the document is searched. In the case of a repeat form control, the repeat object corresponding to the repeat index is searched. If the identified element is found within the ID space of the object, then it is returned. Otherwise, for each repeat form control in the scope of the invoking object, the <code>getRuntimeElementById()</code> method is invoked until a matching element is found or until all repeat form controls have been interrogated. If a match is found, it is returned. Otherwise null is returned.</p></div><div class="div2">
<h3><a name="repeat-dynamism" id="repeat-dynamism"></a>4.4 Dynamically Changing the Size of a Repeat Form Control</h3><p>A repeat form control has additional associated semantics so that it can be
dynamically increased or decreased in size.</p><p>Upon initialization, each repeat form control takes a snapshot of its initial content and the
corresponding data generated for one repeat object. These are to be used as templates for
data and user interface operations needed when increasing or decreasing the size of the
repeat form control.</p><p>Each repeat form control maintains an <b>index</b> of a repeat object that will be the
object of dynamic operations that increase or decrease the size of the repeat form control.
The initial index of a repeat control is <code>1</code>.
When the user changes the focus to a form control in a repeat object, the index of the repeat form
control is automatically changed to indicate the repeat object that contains the focus.
If the number of repeat objects associated with the repeat form control is decreased to zero,
the repeat index becomes equal to zero.</p><p>Each repeat form control has an associated operation called <code>increaseSize()</code>.
When invoked, this operation inserts a new copy of the template data and template user interface content
after the location indicated by the current index of the repeat form control. The index of the repeat
form control is then increased by <code>1</code>. Notification of the completion of the
insertion of data is signaled by dispatching the <code>xforms-insert</code> event (see <a href="#ref-xforms-1.1">[XForms 1.1]</a>)
to the default data instance element, which can also be observed at the containing <code>form</code> element. </p><p>Each repeat form control has an associated operation called <code>decreaseSize(boolean allowEmpty)</code>.
If the index of the repeat form control is equal to zero, the decrease operation has no effect.
When invoked, this operation deletes the data and user interface content corresponding to the
location indicated by the current index of the repeat form control. Notification of the completion of the
deletion of data is signaled by dispatching the <code>xforms-delete</code> event (see <a href="#ref-xforms-1.1">[XForms 1.1]</a>)
to the default data instance element, which can also be observed at the containing <code>form</code> element.</p><p>After the deletion phase of the <code>decreaseSize()</code> operation, if the
number of repeat objects still associated with the repeat form control is less than the index of the
repeat form control, then the index of the repeat form control is decreased by <code>1</code>.
If the index of the repeat form control becomes equal to zero and the value of the parameter
<code>allowEmpty</code> is boolean <code>false</code>, then the <code>increaseSize()</code>
operation defined above is performed on the repeat form control.</p><div class="exampleOuter"><p>In the example of <a href="#default-data-instance-startsize"><b>3.3 The startsize Attribute</b></a>, the <code>id</code> attribute
allows the following code to invoke the <code>increaseSize()</code> operation:</p><div class="exampleInner"><pre>onClick="document.getElementById('item').increaseSize()"</pre></div><p>Similarly, the <code>decreaseSize()</code> operation can be invoked as follows:</p><div class="exampleInner"><pre>onClick="document.getElementById('item').decreaseSize(false)"</pre></div></div><div class="note"><p class="prefix"><b>Note:</b></p><p>If a repeat form control, or any form control, is within a repeat object, then <code>getRuntimeElementById()</code> will be needed to find the form control (see <a href="#idref-resolution"><b>4.3 Finding Runtime Form Controls by ID</b></a>).</p></div><p>When data is inserted or deleted by the <code>increaseSize()</code> or <code>decreaseSize()</code>
operation, the computational dependencies that comprise the calculation system and properties
described in <a href="#declarative-execution-model"><b>5 Declarative Execution Model for Data Instances</b></a> are rebuilt to accommodate the newly inserted or
deleted data, then the expressions for calculated values and properties are reevaluated, and the results
are used to refresh the user interface. This sequence of operations is aligned with the behaviors of
<a href="#ref-xforms-1.1">[XForms 1.1]</a> after performing an <code>insert</code> or <code>delete</code> action.</p></div></div><div class="div1">
<h2><a name="declarative-execution-model" id="declarative-execution-model"></a>5 Declarative Execution Model for Data Instances</h2><div class="div2">
<h3><a name="declarative-data-validation" id="declarative-data-validation"></a>5.1 Declarative Validation</h3><p>This section describes attributes for declarative validation of data. These attributes can be applied to
a form control and provide validity information for the data node associated with the form control.</p><table border="1" summary="Data Validation Attributes"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">datatype</td><td rowspan="1" colspan="1">xsd:QName</td><td rowspan="1" colspan="1">This attribute indicates a datatype to be used for validating the data associated with the form control that bears this attribute. Available values for this attribute are as defined for the <code>type</code> attribute in <a href="#ref-xforms-1.1">[XForms 1.1]</a> (see the Datatypes section). An unprefixed attribute value is interpreted as a reference to a datatype in the XForms namespace. The default is <code>xsd:string</code>, except when provided by another form control of the same name. This attribute is not applicable to and <b>must</b> be ignored when used on container form controls. </td></tr><tr><td rowspan="1" colspan="1">required</td><td rowspan="1" colspan="1">Either an XPath expression or one of the following reserved words: <code>true</code> (also <code>TRUE</code>, <code>required</code>, or <code>REQUIRED</code>) or <code>false</code> (also <code>FALSE</code>). </td><td rowspan="1" colspan="1">This attribute indicates whether or not the end-user must provide a non-empty string. The default is <code>false</code>, except when provided by another form control of the same name. When the attribute is expressed, the result is true if the attribute value is one of the <code>true</code> keywords or if it is an XPath expression that evaluates to a boolean result of <code>true</code>. In HTML, if the attribute value is not specified, then the existence of the attribute is construed as a true result, and its absence is construed as a false result. When the <code>required</code> attribute value is an XPath expression, and it is evaluated, the result is converted to a boolean. Also, the XPath expression is dynamically reevaluated when any of the data values on which it depends are changed. This attribute is not applicable to and <b>must</b> be ignored when used on container form controls. </td></tr><tr><td rowspan="1" colspan="1">constraint</td><td rowspan="1" colspan="1">An XPath expression</td><td rowspan="1" colspan="1">This attribute provides an expression, the boolean result of which indicates whether or not the data node bound to the form control is valid. The default is <code>true</code>, except when provided by another form control of the same name. When the <code>constraint</code> expression is evaluated, the result is converted to a boolean. Also, the expression is dynamically reevaluated when any of the data values on which it depends are changed. This attribute is not applicable to and <b>must</b> be ignored when used on container form controls. </td></tr></tbody></table><p>When two or more form controls share a name, they are bound to the same node of data. All of the form controls bound to the same data node <b>must</b> either use the default for each of these attributes or express exactly the same attribute value for each of these attributes. Implementation behavior is undefined when this requirement is not satisfied. The <code>true</code> keywords are considered equivalent, as are the <code>false</code> keywords. For example, if one form control has a <code>required</code> of <code>true</code>, a second form control with the same name can have no <code>required</code> attribute or it could express a <code>required</code> of <code>true</code> or <code>TRUE</code> (or <code>required</code> or <code>REQUIRED</code>), but implementation behavior is undefined if the second form control expresses a <code>required</code> that contains either an expression or one of <code>false</code> and <code>FALSE</code>.</p><p>The data associated with a form control is <b>valid</b> if it meets the validity criteria set forth by the XForms model. Using only XForms for HTML attributes in this section, the data bound to a form control is valid if it meets the validity criteria of all three of the validation attributes in this section, and it is <b>invalid</b> if it fails to meet the criterion of any one of the three attributes. The criterion for an attribute is implicitly satisfied if the attribute is not specified. A form control is valid if it is bound to a valid data node and invalid otherwise.</p><p>The form controls <b>shall</b> receive validity notification events in a manner aligned with <a href="#ref-xforms-1.1">[XForms 1.1]</a>. Specifically, the form control <b>shall</b> receive the event <code>xforms-valid</code> if the value of the data node to which the form control is bound changes and the data is valid, or if the data value does not change but the validity of the data changes to valid. The form control <b>shall</b> receive the event <code>xforms-invalid</code> if the value of the data node to which the form control is bound changes and the data is invalid, or if the data value does not change but the validity of the data changes to invalid. The change of a data value by any means, including by data entry into a form control, has the possible side effect of producing validity change events (<code>xforms-valid</code> and <code>xforms-invalid</code> events) on form controls bound to the data as well as form controls whose validity is dependent upon the changed data value. After a data value change, the effects on validity of all data nodes is assessed, and then the <code>xforms-valid</code> and <code>xforms-invalid</code> events are dispatched to the affected form controls.</p><div class="exampleOuter"><p>The age and years of education are required integers, and the years of education
cannot exceed the age of a person.</p><div class="exampleInner"><pre>
<label for="age">Age: </label>
<input type="text" name="age" required datatype="integer"/>
<br />
<label for="education">Years of education: </label>
<input type="text" name="education" required="true" datatype="integer" constraint="age >= education" />
<br />
</pre></div></div><p>Implementations of form controls <b>should</b> select user interface elements most appropriate to the expressed <code>datatype</code> and the rendition device. For example, a form control bound to a data node with a <code>datatype</code> of <code>date</code> or <code>xsd:date</code> <b>should</b> be presented on a desktop computer screen as a calendar date selection control. Similarly, a check box <b>should</b> be presented on a computer screen for a form control bound to a data node with a <code>datatype</code> of <code>boolean</code> or <code>xsd:boolean</code>. Similarly, a form control bound to a data node with the datatype <code>card-number</code> <b>should</b> be able to both render and accept grouping separators for long credit card, debit card and identity card numbers.</p></div><div class="div2">
<h3><a name="declarative-data-access" id="declarative-data-access"></a>5.2 Declarative Data Access with the readonly Attribute</h3><p>This section describes an attribute for declarative access control of data (read only versus read/write). </p><table border="1" summary="Data Access Control Attribute"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">readonly</td><td rowspan="1" colspan="1">Either an XPath expression or one of the following reserved words: <code>true</code> (also <code>TRUE</code>, <code>readonly</code> or <code>READONLY</code>) or <code>false</code> (also <code>FALSE</code>).</td><td rowspan="1" colspan="1">This attribute indicates whether or not access to the data node value associated with the form control is read only or read/write. The default is <code>true</code> if any ancestor data node is readonly or if the data node is calculated (see <a href="#declarative-data-calculation"><b>5.3 Declarative Calculation</b></a>). Otherwise, the default is <code>false</code>, except when provided by another form control of the same name. When the attribute is expressed, the result is true if the attribute value is one of the <code>true</code> keywords or an XPath expression that evaluates to a boolean result of <code>true</code>. In HTML, if the attribute value is not specified, then the existence of the attribute is construed as a true result, and its absence is construed as a false result. When the <code>readonly</code> attribute value is an XPath expression, and it is evaluated, the result is converted to a boolean. Also, the XPath expression is dynamically reevaluated when any of the data values on which it depends are changed. This attribute can be used on container form controls.</td></tr></tbody></table><p>When two or more form controls share a name, they are bound to the same node of data. All of the form controls bound to the same data node <b>must</b> either use the default for <code>readonly</code> or express the same logical attribute value. Implementation behavior is undefined when this requirement is not satisfied. For example, if one form control has a <code>readonly</code> of <code>true</code>, a second form control with the same name can have no <code>readonly</code> attribute or it could express a <code>readonly</code> with a value equal to one of the <code>true</code> keywords, but implementation behavior is undefined if the second form control expresses a <code>readonly</code> that contains either an XPath expression or one of the <code>false</code> keywords.</p><p>The form controls <b>shall</b> receive data access notification events in a manner aligned with <a href="#ref-xforms-1.1">[XForms 1.1]</a>. Specifically, the form control <b>shall</b> receive the event <code>xforms-readonly</code> if the value of the data node to which the form control is bound changes and the data node is readonly, or if the data value does not change but the result of the <code>readonly</code>expression changes to <code>true</code>. The form control <b>shall</b> receive the event <code>xforms-readwrite</code> if the value of the data node to which the form control is bound changes and the data node is not readonly, or if the data value does not change but the result of the <code>readonly</code> expression changes to <code>false</code>. The change of a data value by any means, including by data entry into a form control, has the possible side effect of producing data access notification events (<code>xforms-readonly</code> and <code>xforms-readwrite</code> events) on form controls bound to the data as well as form controls whose data access property is dependent upon the changed data value. After a data value change, the effects on data access properties of all data nodes is assessed, and then the <code>xforms-readonly</code> and <code>xforms-readwrite</code> events are dispatched to the affected form controls.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The data access property of a data node can change due to reevaluation of a <code>readonly</code> attribute attached to the data node or to any any ancestor of the data node.</p></div><div class="exampleOuter"><p>This example shows how a section of the document can be conditionally readonly. In this case, a hidden input is used to create a data node that can be used to store an indication of whether or not the current user is a manager, and that information is used to control whether the user can modify the manager section of the document.</p><div class="exampleInner"><pre>
<input type="hidden" name="isManager" value="false" />
<fieldset name="managerSection" readonly=" isManager='false' ">
...
</fieldset>
</pre></div></div><p>If a data node is readonly, then the implementation <b>must</b> suppress all mutations of the content and attributes of the data node except changes by the declarative calculation engine (see <a href="#declarative-data-calculation"><b>5.3 Declarative Calculation</b></a>). This restriction applies to insertion, deletion and modification of descendant nodes of any kind (e.g. text, element, and attribute nodes).</p></div><div class="div2">
<h3><a name="declarative-data-calculation" id="declarative-data-calculation"></a>5.3 Declarative Calculation</h3><p>This section describes an attribute for declarative data value calculations. </p><table border="1" summary="Data Value Calculation Attribute"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">calculate</td><td rowspan="1" colspan="1">XPath expression</td><td rowspan="1" colspan="1">This attribute provides an expression that determines the value (string content) of the data node bound to the form control that bears this attribute. The expression is dynamically reevaluated when any of the data values on which it depends are changed, and the form control value is changed to match. This attribute is not applicable to and ignored when used on container form controls.</td></tr></tbody></table><p>When two or more form controls share a name, they are bound to the same node of data. All of the form controls bound to the same data node <b>must</b> either express no <code>calculate</code> attribute or, if the <code>calculate</code> attribute appears, it <b>must</b> contain the same expression as any other form control that expresses <code>calculate</code> and is bound to the same data node. Implementation behavior is undefined when this requirement is not satisfied. </p><p>During form initialization, a system of computational dependencies is constructed for the calculated data nodes, as described in <a href="#ref-xforms-1.1">[XForms 1.1]</a>. This dependency system is rebuilt after structural modifications of the data instance, including after <code>increaseSize()</code> and <code>decreaseSize()</code> operations (see <a href="#repeat-dynamism"><b>4.4 Dynamically Changing the Size of a Repeat Form Control</b></a> and after submission data instance replacement (see <a href="#data-submission"><b>6 Data Submissions</b></a>). After data value modifications, such as by user interaction with a form control, the dependency system is used to determine which dependent <code>calculate</code> expressions need to be reevaluated, the results of which are reflected in the data and the user interface.</p><p>The form controls <b>shall</b> receive value change notification events in a manner aligned with <a href="#ref-xforms-1.1">[XForms 1.1]</a>. Specifically, the form control <b>shall</b> receive the event <code>xforms-value-changed</code> if the value of the data node to which the form control is bound changes. This could occur for a number of reasons, including due to the action of the form control, due to reevaluation of a <code>calculate</code>, or due to a script modification of the data. After a data value change, the effects on all dependent <code>calculate</code> formulae are assessed, and then the <code>xforms-value-changed</code> events are dispatched to the affected form controls.</p><div class="exampleOuter"><p>The classic compounded interest loan calculation:</p><div class="exampleInner"><pre>
<label for="principal">Amount to borrow: </label>
<input type="text" name="principal" required datatype="decimal" constraint="principal > 0" />
<br />
<label for="duration">Duration of loan in years: </label>
<input type="text" name="duration" required="required" datatype="positiveInteger" />
<br />
<label for="interest">Yearly interest rate (compounded monthly): </label>
<input type="text" name="interest" required="true" datatype="decimal" constraint="interest >= 0"/>
<br />
<input type="hidden" name="rate" calculate="interest div 1200.0" />
<label for="payment">Monthly Payment: </label>
<input type="text" name="payment"
calculate="if(principal > 0 and interest > 0,
principal * rate div (1.0 - power(1.0 + rate, -duration*12)), 0)" />
</pre></div></div><p>By default, if a data node is calculated, then it is also readonly. The readonly property
of a calculated form control can be set to false so that the calculated value can be overridden,
as shown in the following example.</p><div class="exampleOuter"><p>This example shows a calculation that only changes the value of a form control if
it contains a certain threshold value (empty in this case).</p><div class="exampleInner"><pre>
<label for="qty">Quantity: </label>
<input type="text" name="qty" readonly="false" calculate="if(qty>=0, qty, 0)"/>
<br />
</pre></div></div></div><div class="div2">
<h3><a name="declarative-data-relevance" id="declarative-data-relevance"></a>5.4 Declarative Relevance</h3><p>This section describes an attribute for declarative definition of data relevance. </p><table border="1" summary="Data Relevance Attribute"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">relevant</td><td rowspan="1" colspan="1">An XPath expression</td><td rowspan="1" colspan="1">This attribute indicates whether or not the data node associated with the form control is relevant. The default is <code>false</code> if any ancestor data node is non-relevant. Otherwise, the default is <code>true</code>, except when provided by another form control of the same name. When the attribute is expressed, the result is true if the XPath expression evaluates to a boolean result of <code>true</code>. When the <code>relevant</code> attribute value is evaluated, the result is converted to a boolean. Also, the XPath expression is dynamically reevaluated when any of the data values on which it depends are changed. This attribute can be used on container form controls.</td></tr></tbody></table><p>When two or more form controls share a name, they are bound to the same node of data. All of the form controls bound to the same data node <b>must</b> either use the default for <code>relevant</code> or express exactly the same attribute value. Implementation behavior is undefined when this requirement is not satisfied. </p><p>The form controls <b>shall</b> receive data relevance notification events in a manner aligned with <a href="#ref-xforms-1.1">[XForms 1.1]</a>. Specifically, the form control <b>shall</b> receive the event <code>xforms-enabled</code> if the value of the data node to which the form control is bound changes and the data node is relevant, or if the data value does not change but the result of the <code>relevant</code>expression changes to <code>true</code>. The form control <b>shall</b> receive the event <code>xforms-disabled</code> if the value of the data node to which the form control is bound changes and the data node is not relevant, or if the data value does not change but the result of the <code>relevant</code> expression changes to <code>false</code>. The change of a data value by any means, including by data entry into a form control, has the possible side effect of producing data relevance notification events (<code>xforms-enabled</code> and <code>xforms-disabled</code> events) on form controls bound to the data as well as form controls whose data relevance property is dependent upon the changed data value. After a data value change, the effects on data relevance properties of all data nodes is assessed, and then the <code>xforms-enabled</code> and <code>xforms-disabled</code> events are dispatched to the affected form controls.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The relevance of a data node can change due to reevaluation of a <code>relevant</code> attribute attached to the data node or to any ancestor of the data node.</p></div><div class="exampleOuter"><p>A section of the document that is conditionally non-relevant (hidden or disabled, depending on styling).</p><div class="exampleInner"><pre>
<fieldset name="guardianSection" relevant="applicantAge &lt; 18">
...
</fieldset>
</pre></div></div></div><div class="div2">
<h3><a name="declarative-xpath-expression-context" id="declarative-xpath-expression-context"></a>5.5 Declarative XPath Expression Context</h3><p>Some attributes of this section contain XPath expressions. These attributes are attached to form controls.
The evaluation context node is the one bound to the nearest ancestor form control, which is the
parent data node of the data node bound to the form control that bears the attribute containing
the XPath expression. The evaluation context size and position are also based on the size of the
nodeset that contains the evaluation context node and the position of the context node in that nodeset.
This allows the data nodes bound to form controls at the same logical level
(i.e. sibling form controls) to be referenced in the XPath expression using the name of the form control.
The data nodes at other logical levels are accessible by normal XPath means, for example by using
a <code>/</code> (slash) to access children of a node and <code>..</code> (dot dot) to access the parent.
The function library includes all functions defined by XPath 1.0 and by <a href="#ref-xforms-1.1">[XForms 1.1]</a>.</p><div class="exampleOuter"><p>In the purchase order example of Section <a href="#default-data-instance-startsize"><b>3.3 The startsize Attribute</b></a>, the product of the
<code>quantity</code> and <code>unitprice</code> can be calculated for each table row by filling in the
fourth <code>td</code> as follows:</p><div class="exampleInner"><pre><td>
<input name="lineTotal" calculate="quantity * unitprice" />
<td>
</pre></div><p>A calculation over a table column is exemplified by the following purchase order subtotal calculation:</p><div class="exampleInner"><pre><input name="subtotal" calculate="sum(item/lineTotal)" /> </pre></div></div></div></div><div class="div1">
<h2><a name="data-submission" id="data-submission"></a>6 Data Submissions</h2><p>This section describes the attributes that control server communications. The classic URL encoded format
is available by default, but data submission in XML and JSON formats is also available. In addition, data submission
can be used to update the current page, not just to replace a web page. Lastly, attributes are available that
connect data validation and relevance to the preprocessing of data submission.</p><p>These attributes can be used on the <code>form</code> element to control the main form submission, and they can also be used on submit elements, such as an <code>input</code> tag with a <code>type</code> of <code>submit</code>, to control customized submissions within the form. </p><p>The element or tag that configures the submission <b>shall</b> receive XForms submission events, including <code>xforms-submit</code>, <code>xforms-submit-serialize</code>, <code>xforms-submit-done</code> and <code>xforms-submit-error</code>, in a manner aligned with <a href="#ref-xforms-1.1">[XForms 1.1]</a>. </p><p>The element or tag that configures the submission <b>shall</b> be augmented with a method
named <code>processResult()</code>, which performs the submission result processing as defined under the
<code>xforms-submit</code> event in <a href="#ref-xforms-1.1">[XForms 1.1]</a>.
For JSON submissions, the callback parameter of the JSON service must be set to this method of the submit form control
in order to ensure correct completion of submission processing.</p><table border="1" summary="Data Submission Attributes"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">serialization</td><td rowspan="1" colspan="1"><code>application/www-url-encoded</code>, <code>application/xml</code>, or <code>application/javascript</code></td><td rowspan="1" colspan="1">This attribute indicates the serialization format of the data instance to be submitted to the server. The default is <code>application/www-url-encoded</code>. </td></tr><tr><td rowspan="1" colspan="1">source</td><td rowspan="1" colspan="1">XPath expression</td><td rowspan="1" colspan="1">This attribute indicates the portion of the form's data instance that is to be serialized for submission. By default, the entire data instance of the form is serialized for submission. If the attribute is given, then it is evaluated in the XPath context of the containing form, i.e. relative to the document element of the form's data instance. No data is selected for serialization unless the expression produces a nodeset. The first node of the resultant nodeset indicates the data instance subtree that is to be serialized for submission.</td></tr><tr><td rowspan="1" colspan="1">replace</td><td rowspan="1" colspan="1"><code>all</code>, <code>none</code>, <code>instance</code>, or <code>text</code></td><td rowspan="1" colspan="1">This attribute indicates how the result of a submission will be handled. The default is <code>all</code>. If the setting is <code>all</code>, then the web page is replaced with the submission result. In the case of the setting <code>none</code>, the submission result is discarded. If the setting is <code>instance</code> or <code>text</code>, then some or all of a data instance inthe form is replaced with the submission result. The portion of the data to be replaced is controlled by the <code>target</code> attribute, or its default. If the setting is <code>instance</code>, then a target node from a data instance is replaced with the submission result. If the setting is <code>text</code>, then the content of the target node from a data instance is replaced with a text encoded form of the submission result.</td></tr><tr><td rowspan="1" colspan="1">target</td><td rowspan="1" colspan="1">XPath expression</td><td rowspan="1" colspan="1">This attribute indicates the portion of a data instance in the form that is to be replaced with the result of submission. By default, the entire data instance of the form is replaced (if the <code>replace</code> attribute setting is <code>instance</code> or <code>text</code>). If the attribute is given, then it is evaluated in the XPath context of the containing form, i.e. relative to the document element of the form's data instance. No data is selected for replacement unless the expression produces a nodeset. The first node of the resultant nodeset indicates the data instance node that is the target of the replacement.</td></tr><tr><td rowspan="1" colspan="1">action</td><td rowspan="1" colspan="1">xsd:anyURI</td><td rowspan="1" colspan="1">This attribute indicates the URL of the submission, either directly by the attribute value or indirectly by data reference if the URI scheme is <code>xpath</code>. If the form of the <code>action</code> attribute value is <code>xpath:expression</code>, then the expression is evaluated in the context of the containing form, and the string result of the expression is interpreted as the submission URL. Note that the expression could indicate a calculated data node bound to a hidden input element, thus providing flexibility in authoring the dynamic construction of the submission URL. The element or tag that bears this attribute <b>shall</b> be the target of XForms submission events related to the submission.</td></tr><tr><td rowspan="1" colspan="1">validate</td><td rowspan="1" colspan="1">xsd:boolean</td><td rowspan="1" colspan="1">This attribute indicates whether submission will be terminated with an <code>xforms-submit-error</code> event if any of the data nodes being submitted are invalid (see definition in <a href="#declarative-data-validation"><b>5.1 Declarative Validation</b></a>). The default is <code>true</code>.</td></tr><tr><td rowspan="1" colspan="1">prune</td><td rowspan="1" colspan="1">xsd:boolean</td><td rowspan="1" colspan="1">This attribute indicates whether non-relevant data nodes will be pruned from the submission data before validation and serialization. The default is <code>true</code>. </td></tr><tr><td rowspan="1" colspan="1">method</td><td rowspan="1" colspan="1"><code>get</code>, <code>post</code>, <code>put</code>, <code>delete</code>, <code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>DELETE</code>, or any other xsd:string</td><td rowspan="1" colspan="1">Indicates a protocol-specific submission operation to be performed. The intent of this attribute is to be aligned with submission operations of the HTTP protocol. </td></tr><tr><td rowspan="1" colspan="1">submission</td><td rowspan="1" colspan="1">xsd:IDREF</td><td rowspan="1" colspan="1">In lieu of using the submission attributes defined above, a form element or submit element can use this attribute to delegate control of submission to an identified XForms submission element.</td></tr></tbody></table><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The working group is particularly interested in feedback on the <code>action</code> attribute. XForms still supports using <code>action</code>, but authors are encouraged to use use the <code>resource</code> attribute instead for specifying the URI of a submission. Is this preferable in XForms for HTML? Specifically, does using <code>action</code> on a form control cause problems in any well-known web applications?</td></tr></table><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The working group is particularly interested in feedback on the <code>source</code> attribute. It is intended to be equivalent to the <code>ref</code> attribute on an XForms submission, which identifies the subtree of data being submitted. However, since <code>ref</code> can also be used on a form control to bind the form control to XForms instance data, an alternative attribute name is needed. The chosen name does not conflict with the <code>src</code> attribute and is consistent with the name of the <code>target</code> attribute. Are there good reasons for not using the name <code>source</code> for this attribute, and are there any better alternatives? </td></tr></table><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The working group is particularly interested in feedback on the <code>target</code> attribute. When used in combination with replacing instance data within the web page, this attribute indicates the portion of data to replace with the submission results. This seems consistent with the use of <code>target</code> to indicate a portion of a document to replace in the page refresh case. It is also consistent with the attribute of the same name in an XForms submission. Still, are there good reasons for not using the name <code>target</code> for this attribute, and are there any better alternatives?</td></tr></table><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">The working group is particularly interested in feedback on the <code>prune</code> and <code>validate</code> attributes. These are simple boolean attributes that indicate whether or not certain submission data preprocessing steps occur. The <code>prune</code> attribute is synonymous with the <code>relevant</code> attribute on an XForms submission, but an alternate attribute name was needed because the <code>relevant</code> attribute on a form control expresses a formula for indicating whether or not the node of data bound to the form control is relevant to presentation in the user interface and submission, so the same attribute name cannot be used to indicate whether or not a submission initiated by a form control should perform pruning of non-relevant data nodes from the submission data. The <code>validate</code> attribute performs the same function as the attribute of the same name on an XForms submission, namely that it ensures validity constraints on the pruned data are met before proceeding with submission. Would it be better to use a single attribute for configuring all preprocessing, e.g. <code>preprocess="validate: true; relevant: false;"</code>, rather than using separate attributes? </td></tr></table><div class="exampleOuter"><p>The following markup posts XML for the data instance of the form:</p><div class="exampleInner"><pre><form serialization="application/xml" method="post" ... >
...
</form></pre></div></div><div class="exampleOuter"><p>The following markup saves the XML for the data instance of the form to a server:</p><div class="exampleInner"><pre><form ... >
...
<input type="submit" serialization="application/xml" method="post" replace="none"
validate="false" prune="false" action="http://example.org/save" >
...
</form></pre></div></div><div class="exampleOuter"><p>The following markup enables a submit element to posts XML for a portion of the data instance
and uses the result to replace another portion of the data:</p><div class="exampleInner"><pre><form ... >
<fieldset name="employee">
<input type="text" name="name" ... >
...
</fieldset>
<input type="submit" serialization="application/xml" method="post" replace="instance"
source="employee/name" target="employee" action="http://example.org/lookup" >
...
</form></pre></div></div></div><div class="div1">
<h2><a name="declarative-form-control-properties" id="declarative-form-control-properties"></a>7 Declarative Form Control Properties</h2><p>This section describes additional attributes for form controls. This includes metadata mechanisms common to all form controls, such providing label, alert, hint and help text. This also includes additional mechanisms for selection controls.</p><table border="1" summary="Additional Form Control Attributes"><thead><tr><th rowspan="1" colspan="1">Attributes</th><th rowspan="1" colspan="1">Content Model</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">label</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">This attribute provides a shorthand to creating a label tag or element for a form control. This attribute provides a behavior consistent with creating a label pseudoelement before the form control element with a <code>for</code> attribute that indicates the form control. A web page author <b>must</b> be allowed to style the alert message for a form control to <code>display: none</code> at all times, since the author could use an alternate means of presenting the alert message for the form control in response to the <code>xforms-invalid</code> event. Note: The <code>xforms-invalid</code> event does not occur on form initialization, but rather only after initialization when validity changes or when the value changes and is invalid.</td></tr><tr><td rowspan="1" colspan="1">alert</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">This attribute provides a message text for presentation when a form control becomes invalid. This attribute provides a behavior consistent with creating a pseudoelement after the form control element. By default, the alert pseudoelement is styled <code>display: none</code> when a form control is valid and <code>display: inline; color: red</code> when the form control is invalid. </td></tr><tr><td rowspan="1" colspan="1">hint</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">This attribute provides text for an ephemeral hint message for the user interface component associated with a markup element or tag. The user agent decides the conditions under which the hint message is displayed and hidden. For example, on a desktop web browser, the hint <b>may</b> be presented when a form control receives the input focus or when the user gestures at the form control with a pointing device, and the hint <b>may</b> be hidden after a few seconds or upon user input such as by keyboard or further non-trivial pointing device movement.</td></tr><tr><td rowspan="1" colspan="1">help</td><td rowspan="1" colspan="1">xsd:string</td><td rowspan="1" colspan="1">This attribute provides text for a help message for the user interface component associated with a markup element or tag. The user agent decides the conditions under which the help message is displayed and hidden. For example, on a desktop web browser, the help <b>may</b> be presented when the user requests help using a keyboard or pointing device activation mechanism. If the help message is visually presented, the user agent <b>should</b> allow the end-user to control when the visual message is hidden once it has been displayed.</td></tr><tr><td rowspan="1" colspan="1">selection</td><td rowspan="1" colspan="1"><code>closed</code>, <code>open</code></td><td rowspan="1" colspan="1">This attribute is specific to the <code>select</code> form control. The default is <code>closed</code>. When the setting is <code>closed</code>, then only the choices indicated by the selection form control can be chosen. When the setting is <code>open</code>, the end-user <b>must</b> be permitted to provide input other than the choices indicated by the selection form control. For example, on a desktop web browser, the end-user <b>should</b> be presented with a combobox, or the union of the <code>select</code> control with a text <code>input</code> control.</td></tr><tr><td rowspan="1" colspan="1">multiple</td><td rowspan="1" colspan="1"><code>true</code> (also <code>TRUE</code>, ) or <code>false</code> (also <code>FALSE</code>), <code>multiple</code>, <code>MULTIPLE</code></td><td rowspan="1" colspan="1">This attribute is specific to the <code>select</code> form control. The default is <code>false</code>. When the setting is any value other than <code>false</code> or <code>FALSE</code>, then the selection control allows multiple selections. All selected choices are represented in the data instance node using a space-separated list. When the setting is <code>false</code> or <code>FALSE</code>, or when the attribute is not given, then the <code>select</code> represents a single selection form control in which the selection of any choice replaces the data instance node value with the value corrresponding to the new choice.</td></tr><tr><td rowspan="1" colspan="1">appearance</td><td rowspan="1" colspan="1"><code>minimal</code>, <code>compact</code>, <code>full</code>, or any space-separated list of QName values</td><td rowspan="1" colspan="1">This attribute allows user agent appearance customizations. The special keywords <code>minimal</code>, <code>compact</code> and <code>full</code> are applicable to <code>select</code> controls. When the keyword <code>minimal</code> is included, the <code>select</code> form control <b>should</b> provide a user interface mechanism to activate and deactivate the choice list. For example, on a desktop web browser, the minimal <code>select</code> form control <b>should</b> provide a dropdown list of choices. When the keyword <code>compact</code> is included, the <code>select</code> form control <b>should</b> provide a single user interface element for the choice list. For example, on a desktop web browser, the compact <code>select</code> form control <b>should</b> provide a single or multiple selection list box. When the keyword <code>full</code> is included, the <code>select</code> form control <b>should</b> provide distinct user interface elements for each item of the choice list. For example, on a desktop web browser, the full <code>select</code> form control <b>should</b> provide a set of radio buttons for a single selection or a set of checkboxes for a multiselection control.</td></tr></tbody></table></div><div class="div1">
<h2><a name="conformance" id="conformance"></a>8 Conformance</h2><p>This section describes implementation conformance for the various features of an XForms for HTML processor.</p><p>All features described in this specification are <b>required</b> to implement, except where the description of the feature has explicitly used the terms of <a href="#ref-rfc-2119">[RFC 2119]</a> to indicate otherwise and except as noted below in this section.</p><p>The ability to process explicitly declared <code><xf:model></code> elements is <b>optional</b>.</p><p>The ability to process explicitly declared <code><xf:instance></code> elements is <b>recommended</b>.</p><p>Support of PrefixedName values in the <code>name</code> attribute, and all related behaviors, is <b>recommended</b>. </p><p>Support of full XPath expressions is <b>recommended</b>. Implementations that do not support full XPath <b>must</b> support a profile of XPath including the following:</p><ul><li><p>Matching nodes by unprefixed name, using slash (<code>/</code>) for child navigation and using <code>..</code> for parent navigation</p></li><li><p>All arithmetic and logical operators</p></li><li><p>All functions defined by XPath 1.0 and all functions defined by <a href="#ref-xforms-1.1">[XForms 1.1]</a> except the following <b>optional</b> functions: <code>event()</code>, <code>digest()</code>, <code>hmac()</code>, and the two parameter version of <code>id()</code>.</p></li></ul><p>Support of the <code>submission</code> attribute is <b>optional</b>.</p></div></div><div class="back"><div class="div1">
<h2><a name="terms" id="terms"></a>A Glossary Of Terms</h2><dl><dt class="label">Child Form Control List</dt><dd><p>A list maintained by a container form control indicating the form controls for which the containner form control is the nearest ancestor form control. </p></dd><dt class="label">Constructed Data Instance</dt><dd><p>A data instance that is implicitly generated for a form when the form contains no form controls declared with the <code>wfa:name</code> attribute and when the form contains a declared XForms <code>model</code> with no default data instance. </p></dd><dt class="label">Container Form Control</dt><dd><p>A form control whose associated element or tag has one or more descendant elements or tags that are associated with form controls. </p></dd><dt class="label">Core Form Control</dt><dd><p>A form control with no child form controls. Typically, a core form control binds to a leaf node of a data instance, i.e. data with a textual content model, to either present or allow editing of the textual content. </p></dd><dt class="label">Data Instance Generation</dt><dd><p>The process by which the generated data instance is created. </p></dd><dt class="label">Focus Order</dt><dd><p>The navigation order imparted to form controls by a form. </p></dd><dt class="label">Form</dt><dd><p>An aggregation of run-time objects that operate together to collect and manage data. </p></dd><dt class="label">Form Element</dt><dd><p>An element or tag with an associated form.</p></dd><dt class="label">Form Control</dt><dd><p>A run-time object that associates a data instance node with an element or tag of markup. </p></dd><dt class="label">Generated Data Instance</dt><dd><p>The data instance that is implicitly generated for a form based on the named form controls it contains. The generated data instance does not exist for a form that has a declared default data instance. </p></dd><dt class="label">Generated Form Control</dt><dd><p>A form control generated from the template of a repeat object.</p></dd><dt class="label">Generator Node</dt><dd><p>The data instance node from a repeat nodeset that is associated with a generated copy of a repeat object template. </p></dd><dt class="label">Index (of a repeat form control)</dt><dd><p>An integer associated with the repeat form control that indicates which repeat object will be the object of dynamic interaction operations such as <code>increaseSize()</code>, <code>decreaseSize()</code> and <code>focus()</code>. </p></dd><dt class="label">Invalid</dt><dd><p>A form control is invalid if it is not valid. </p></dd><dt class="label">Namespace Prefix Promotion Method</dt><dd><p>A method of managing the declaration of namespaces in the generated data instance. </p></dd><dt class="label">Repeat Form Control</dt><dd><p>A form control that has the <code>startsize</code> attribute to indicate that its content is a template to be generated a number of times corresponding either to the <code>startsize</code> during data instance generation or to the number of data nodes associated with the repeat form control's name otherwise. </p></dd><dt class="label">Repeat Object</dt><dd><p>A generated copy of the repeat form control template. </p></dd><dt class="label">Valid</dt><dd><p>A form control is valid if the data node to which it is bound meets all validity tests available from the XForms engine. The principal validity tests defined by XForms for HTML are provided by the <code>constraint</code>, <code>required</code> and <code>datatype</code> attributes.</p></dd></dl></div><div class="div1">
<h2><a name="references" id="references"></a>B References</h2><div class="div2">
<h3><a name="references-norm" id="references-norm"></a>B.1 Normative References</h3><dl><dt class="label"><a name="ref-rfc-2119" id="ref-rfc-2119"></a>RFC 2119</dt><dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</cite></a>, S. Bradner, 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.</dd><dt class="label"><a name="ref-xforms-1.1" id="ref-xforms-1.1"></a>XForms 1.1</dt><dd>
<a href="http://www.w3.org/TR/2007/CR-xforms11-20071129/"><cite>XForms 1.1</cite></a>, John M. Boyer, 2007.
W3C Candidate Recommendation available at: http://www.w3.org/TR/2007/CR-xforms11-20071129/.</dd><dt class="label"><a name="ref-xml-events" id="ref-xml-events"></a>XML Events</dt><dd> <a href="http://www.w3.org/TR/2003/REC-xml-events-20031014/"><cite>XML Events - An events syntax for XML</cite></a>, Steven Pemberton, T. V. Raman, Shane P. McCarron, 2003. W3C Recommendation available at: http://www.w3.org/TR/2003/REC-xml-events-20031014/.</dd><dt class="label"><a name="ref-xpath-1.0" id="ref-xpath-1.0"></a>XPath 1.0</dt><dd> <a href="http://www.w3.org/TR/1999/REC-xpath-19991116"><cite>XML Path Language (XPath) Version 1.0</cite></a>, James Clark, Steve DeRose, 1999. W3C Recommendation available at: http://www.w3.org/TR/1999/REC-xpath-19991116.</dd><dt class="label"><a name="ref-xschema-1" id="ref-xschema-1"></a>XML Schema part 1</dt><dd> <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1: Structures</cite></a>, Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2004. W3C Recommendation available at: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.</dd><dt class="label"><a name="ref-xschema-2" id="ref-xschema-2"></a>XML Schema part 2</dt><dd> <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes</cite></a>, Paul V. Biron, Ashok Malhotra, 2004. W3C Recommendation available at: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.</dd></dl></div></div><div class="div1">
<h2><a name="acks" id="acks"></a>C Acknowledgements (Non-Normative)</h2><p>This document was produced with the participation of Forms Working Group participants.
Current participants include:</p><ul><li>John M. Boyer, IBM (<i>Chair, Editor</i>) </li><li>Steven Pemberton, W3C/CWI (<i>Activity Lead, W3C Team Contact</i>) </li><li>Ulrich Nicolas Lissé, DreamLab</li><li>Sebastian Schnitzenbaumer, DreamLab (<i>Co-chair until 2003</i>) </li><li>Joern Turner, DreamLab</li><li>T. V. Raman, Google</li><li>Keith Wells, IBM</li><li>Charlie Wiecha, IBM</li><li>Nick Van den Bleeken, Inventive Designers n.v.</li><li>Erik Bruchez, Orbeon</li><li>Mark Seaborne, PicoForms</li><li>Kenneth Sklander, PicoForms</li><li>Susan Borgrink, Progeny Systems</li><li>Rafael Benito Ruiz de Villa, SATEC</li><li>Rogelio Pérez Cano, SATEC</li><li>Mark Birbeck, x-port.net Ltd. (<i>Invited Expert</i>) </li><li>Leigh L. Klotz, Jr., Xerox Corporation</li></ul></div><div class="div1">
<h2><a name="prod-notes" id="prod-notes"></a>D Production Notes (Non-Normative)</h2><p>This document was encoded in the XMLspec DTD v2.6. The XML sources were transformed using diffspec and xmlspec stylesheets, version 2.6. The XML Schema portion of the Appendix was rendered into HTML with the <a href="http://www.informatik.hu-berlin.de/~obecker/XSLT/">xmlverbatim XSLT</a> stylesheet (used with permission). The primary tool used for editing was XMLSpy. The XML was transformed using the XSLT processor in Java 6. The editor(s) use the W3C CVS repository and the W3C IRC server for collaborative authoring.</p></div></div></body></html>