WD-xhtml-forms-req-20010404
34.9 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
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
<!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 content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>XForms Requirements </title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
dt.label { display: run-in; }
li p { margin-top: 0.3em;
margin-bottom: 0.3em; }
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head><body>
<div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1>XForms Requirements </h1>
<h2>W3C Working Draft 04 April 2001</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2001/WD-xhtml-forms-req-20010404">http://www.w3.org/TR/2001/WD-xhtml-forms-req-20010404</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/xhtml-forms-req">
http://www.w3.org/TR/xhtml-forms-req</a>
</dd><dt>Previous versions:</dt><dd>
<a href="http://www.w3.org/TR/2000/WD-xhtml-forms-req-20000821">
http://www.w3.org/TR/2000/WD-xhtml-forms-req-20000821</a>
</dd><dt>Editors:</dt>
<dd>Micah Dubinko, Cardiff <a href="mailto:mdubinko@Cardiff.com"><mdubinko@Cardiff.com></a></dd>
<dd>Sebastian Schnitzenbaumer, Mozquito Technologies <a href="mailto:schnitz@mozquito.com"><schintz@mozquito.com></a></dd>
<dd>Malte Wedel, Mozquito Technologies <a href="mailto:malte@mozquito.com"><malte@mozquito.com></a></dd>
<dd>Dave Raggett, W3C <a href="mailto:dsr@w3.org"><dsr@w3.org></a></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright"> Copyright</a> ©2001 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p></div><hr><div>
<h2><a name="abstract">Abstract</a></h2>
<p> Forms were introduced into HTML in 1993. Since then they have gone on
to become a critical part of the Web. The existing mechanisms in HTML for forms
are now outdated, and W3C has started work on developing an effective
replacement. This document outlines the requirements for "XForms", W3C's name
for the next generation of Web forms.</p>
</div><div>
<h2><a name="status">Status of this Document</a></h2>
<p><em>This section describes the status of this document at the time
of its publication. Other documents may supersede this document. The latest
status of this document series is maintained at the W3C.</em></p>
<p>This requirements document incorporates changes made at the recent meeting of the XForms Working Group. This document is a W3C Working Draft for review by W3C members and
other interested parties. It is a draft document and may be updated, replaced,
or obsoleted by other documents at any time. It is inappropriate to use W3C
Working Drafts as reference material or to cite them as other than "work in
progress". A list of current public W3C Working Drafts can be found at
<a href="http://www.w3.org/TR/">http://www.w3.org/TR</a>.</p>
<p>This specification describes requirements for the next generation of
Web forms. This document has been produced as part of the
<a href="http://www.w3.org/MarkUp/Forms">W3C work on XForms</a>,
following the procedures set out for the
<a href="http://www.w3.org/Consortium/Process">W3C Process</a>. The
authors of this document are members of the
<a href="http://www.w3.org/MarkUp/Forms/Group/"> W3C XForms working
group</a> (W3C Members only). This document is for public review, and
comments and discussion are welcomed on the public mailing list <<a href="mailto:www-forms@w3.org">www-forms@w3.org</a>>. To
subscribe, send an email to <<a href="mailto:www-forms-request@w3.org">www-forms-request@w3.org</a>> with
the word <em>subscribe</em> in the subject line (include the word
<em>unsubscribe</em> if you want to unsubscribe). The
<a href="http://lists.w3.org/Archives/Public/www-forms/">archive</a> for the
list is accessible online.</p>
</div>
<div class="toc">
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1 <a href="#reqintro">Introduction (Non-Normative)</a><br> 1.1 <a href="#reqintro-rationale">Rationale</a><br> 1.2 <a href="#reqintro-audience">Target Audience</a><br>2 <a href="#charter-req">Charter and Basic Requirements (Normative)</a><br> 2.1 <a href="#in-xml">Defined in XML, Usable in XML</a><br> 2.2 <a href="#w3c-integration">W3C Integration</a><br> 2.2.1 <a href="#w3c-integration-p3p">P3P</a><br> 2.2.2 <a href="#w3c-integration-schema">XML Schema</a><br> 2.3 <a href="#from-html4">Migration from HTML 4</a><br> 2.4 <a href="#ease-of-authoring">Ease of Authoring</a><br> 2.5 <a href="#separate-p-from-p">Separate Purpose from Presentation</a><br> 2.6 <a href="#device-independence">Device Independence</a><br> 2.7 <a href="#scripting-interfaces">Scripting Interfaces</a><br> 2.8 <a href="#unicode-i18n">Unicode and Internationalization</a><br>3 <a href="#model-req">XForms Model Requirements (Normative)</a><br> 3.1 <a href="#datatypes">Data Types</a><br> 3.2 <a href="#identifiers">Data Type Identifiers</a><br> 3.3 <a href="#input-validations">Input Validations</a><br> 3.4 <a href="#send-xml">Send XML to Server</a><br> 3.5 <a href="#calculations">Calculations and Expressions</a><br> 3.6 <a href="#dependencies">Data Value and Form Control Dependencies</a><br> 3.7 <a href="#arrays">Expandable Form Control Groups (Arrays)</a><br> 3.8 <a href="#security">Security Features</a><br> 3.9 <a href="#confidence-instance">Confidence Scores</a><br>4 <a href="#ui-reqs">User Interface Requirements (Normative)</a><br> 4.1 <a href="#backwards-features">Provide Functional Equivalents of HTML 4 Form Controls</a><br> 4.2 <a href="#forwards-features">New Form Controls</a><br> 4.3 <a href="#multi-page-form">Support Multiple Pages per Form, and Multiple Forms per
Page</a><br> 4.4 <a href="#input-devices">Support More Input Devices</a><br> 4.5 <a href="#layout-alignment">Layout/Alignment</a><br>5 <a href="#future-req">Future Considerations (Non-Normative)</a><br> 5.1 <a href="#custom-controls">Custom Defined Controls</a><br> 5.2 <a href="#gui-enhancement">Further GUI Enhancements</a><br> 5.3 <a href="#voice-enhancement">Voice Enhancements</a><br> 5.4 <a href="#paper-enhancement">Paper Enhancements</a><br> 5.5 <a href="#ambiguities">Representing Ambiguities</a><br> 5.6 <a href="#dsig">Digital Signatures</a><br> 5.7 <a href="#locale">Region Independence</a><br> 5.8 <a href="#http-auth">HTTP Authentication Front-end</a><br> 5.9 <a href="#save-resume">Saving and Resuming</a><br></p>
<h3>Appendices</h3><p class="toc">A <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>B <a href="#biblio">References</a> (Non-Normative)<br></p></div><hr><div class="body">
<div class="div1">
<h2><a name="reqintro"></a>1 Introduction (Non-Normative)</h2>
<p> After careful consideration, the HTML Working Group decided that the
goals for the next generation of forms are incompatible with preserving full
backwards compatibility with browsers designed for earlier versions of HTML. A
forms sub-group was formed within the HTML Working Group, later becoming the
XForms Working Group. It is our objective to provide a clean new forms model
("XForms") based on a set of well-defined requirements. The requirements
described in this document are based on experience with a broad spectrum of
form applications.</p>
<p> This document provides a comprehensive set of requirements for the
W3C's work on XForms. We envisage this work being conducted in several steps,
starting with the development of a core forms module, followed by work on
additional modules for specific features. The Modularization of XHTML provides
a mechanism for defining modules which can be recombined as appropriate for the
capabilities of different platforms.</p>
<div class="div2">
<h3><a name="reqintro-rationale"></a>1.1 Rationale</h3>
<p> Web forms are being used in various contexts as a standardized
mechanism for bidirectional data exchange over the Web. In many occasions, it
is desirable to enable an open data dialog between the recipient of a hypertext
document and the sender. Forms need to provide effective support for various
kinds of data exchange. The design of XForms focuses on the increasing demands
for improved human-computer interaction as well as the interaction mechanisms
between user agents (e.g. browsers) and servers.</p>
<p>The design of XForms focuses on the increasing demands for improved
human-computer interaction as well as the interaction mechanisms between the
browser (user agent) and the server.</p>
<p>To enable Web content developers to meet these challenges XForms
will be designed to cleanly distinguish between form <em>instance
data</em>, form description (called the <em>XForms Model</em>), and form
presentation (called the <em>XForms User Interface</em>). The same form
will be accessible on a full screen display, as a sheet of paper or using a
handheld computer resting on your palm.</p>
<p>To meet the goals for richer presentation XForms will be designed
for integration with other XML tag sets, such as XHTML, SVG for graphics and
SMIL for multimedia forms. You will be able to use style sheet languages such
as CSS and XSL to finely tune the presentation.</p>
<p>As the cost and size of Web servers continues to shrink, single chip
implementations are now practical, and we can soon expect to see all kinds of
devices with embedded servers. XHTML will be used for controlling such devices,
reducing the need for custom device drivers. XForms will be designed to provide
the richer user interface these applications will need.</p>
<p>It is generally best to catch input errors early. This can be
achieved with form logic that works with the user to ensure that the form data
values satisfy the appropriate consistency checks. For phone numbers and
addresses, the checks will vary from one part of the world to another.</p>
<p>Complex forms are best presented as a sequence of sections, one
section at a time. The ability to download the entire sequence in a single file
makes it easy to fill out the form without a real-time connection to the Web
server, and avoids the inevitable delays in reestablishing a connection to the
server for each section.</p>
</div>
<div class="div2">
<h3><a name="reqintro-audience"></a>1.2 Target Audience</h3>
<p>XForms provide considerable benefits compared with classic XHTML
forms. In particular the separation of the purpose from the presentation of a
form enables a separation of concerns such that differing skills can be applied
to the design of a form. These skills may be embodied in a single person or
many depending on both the sophistication of the Form being designed as well as
the skills of individuals involved in the design process.</p>
<p>Individuals familiar with HTML 4 Forms will find XForms both more
powerful as well as simpler. Specifically, XForms will make it simpler to build
forms including the business logic, calculations, and form processing that in
many cases prior to XForms has been done with scripting. The two primary roles
associated with XForms authoring are the design of the purpose of the form as
expressed in an XForms model as well as the design of the user interface and user
interaction.</p>
<p>Server-side programmers are also part of the target audience. In the
past, deploying forms on a Web site involved complex server-side scripting to
accept, validate, and process incoming data. XForms will make this easier by
providing a consistent, XML-based format for incoming data, as well as by
providing a rich validation framework.</p>
<p>Finally, application vendors that produce products that interact
with forms are part of the target audience. A vendor-neutral XForms model will
provide an avenue for interoperability between various forms
implementations.</p>
</div>
</div>
<div class="div1">
<h2><a name="charter-req"></a>2 Charter and Basic Requirements (Normative)</h2>
<div class="div2">
<h3><a name="in-xml"></a>2.1 Defined in XML, Usable in XML</h3>
<p>XForms will be an application of XML 1.0 plus Namespaces. It will be
possible to define a rich form, including validations, dependencies, and basic
calculations without the use of a scripting language. As an application of XML,
it will be possible to combine XForms with other XML based languages such as
XHTML.</p>
</div>
<div class="div2">
<h3><a name="w3c-integration"></a>2.2 W3C Integration</h3>
<p>The development of XForms will require interaction with many other
W3C Working Groups. In particular, close coordination will be required with the
following two Working Groups:</p>
<div class="div3">
<h4><a name="w3c-integration-p3p"></a>2.2.1 P3P</h4>
<p>The XForms Working Group will work with members of the P3P
Specification Working Group to define functional requirements for integration
of P3P and XForms. Close integration is important to assure that forms designed
with XForms for the purpose of collection of personally-identifiable data allow
the seamless association of privacy policies and preferences with the data
being collected. The P3P specification Working Group will be asked to review
the XForms Requirements and XForms Model specification.</p>
</div>
<div class="div3">
<h4><a name="w3c-integration-schema"></a>2.2.2 XML Schema</h4>
<p>To meet the needs for expressing the XForms Model, the XForms
Working Group will utilize functionality from XML Schema in addition to
developing additional form-specific properties. The XML Schema Working Group
will be asked to review the XForms Requirements and XForms Model
specification.</p>
</div>
</div>
<div class="div2">
<h3><a name="from-html4"></a>2.3 Migration from HTML 4</h3>
<p>XForms should be designed in such a way as to encourage users to
make use of the new capabilities, rather than lingering on existing form
technologies. Likewise, the design should encourage implementors to deploy user
agents that implement XForms.</p>
</div>
<div class="div2">
<h3><a name="ease-of-authoring"></a>2.4 Ease of Authoring</h3>
<p>XForms should be straightforward to author by hand with a simple
text editor, in order to encourage migration from existing HTML forms.</p>
</div>
<div class="div2">
<h3><a name="separate-p-from-p"></a>2.5 Separate Purpose from Presentation</h3>
<p>XForms data values should not be bound to a particular interface
representation. Instead the XForms Model should represent the nature of the
tasks the user is being asked to perform. The "purpose" of a form control may
be the same on various devices, whereas the rendering may vary based on
different capabilities.</p>
</div>
<div class="div2">
<h3><a name="device-independence"></a>2.6 Device Independence</h3>
<p>XForms should express the navigation paths within a form without
implying specific user interface devices such as a mouse or keyboard. The
navigation shouldn't rely on device-specific methods such as use of the
"tab"-key.</p>
<p>It should be possible to express forms event handling for a broad
range of devices. In previous versions of HTML some events were
device-independent (e.g. onfocus, onblur, onchange), while others implied the
availability of device-specific features (e.g. onmouseover, ondblclick). Within
a single form, it should be possible to exploit events specific to different
kinds of Web enabled devices, including conventional browsers, TV sets, set top
boxes, palmtops and mobile phones.</p>
</div>
<div class="div2">
<h3><a name="scripting-interfaces"></a>2.7 Scripting Interfaces</h3>
<p>It should be possible to access and manipulate forms via a scripting
interface. This is needed to allow the construction of specialized forms with
behaviors going beyond the limits of the forms language itself. XForms should
be accessible as part of an XML document, insensitive to changes in the
enclosing document. Additional scripting interfaces specific to forms will be
added.</p>
</div>
<div class="div2">
<h3><a name="unicode-i18n"></a>2.8 Unicode and Internationalization</h3>
<p>XForms should be fit for usage with non-western character sets,
languages, and writing systems, including support for Unicode. It is required
that nonwestern characters be preserved from their initial entry in a form
control until their final destination and vice versa. It should be possible to
provide for entry of data formats that do not force international users to
adapt to western data formats if the corresponding data format is substantially
different in other regions. </p>
</div>
</div>
<div class="div1">
<h2><a name="model-req"></a>3 XForms Model Requirements (Normative)</h2>
<p>XML Forms should be compatible with, build on, and extend (where
necessary) the basic concepts, data structures, and data types defined by XML
Schemas. XForms should address the needs of HTML authors as well as people who
wish to use XForms with data schemas defined in XML Schema.</p>
<div class="div2">
<h3><a name="datatypes"></a>3.1 Data Types</h3>
<p>XForms will provide a set of common data types, and may facilitate
the construction of custom data types.</p>
</div>
<div class="div2">
<h3><a name="identifiers"></a>3.2 Data Type Identifiers</h3>
<p>XForms should include the means to provide globally unique
identifiers for types which can be used to establish that a given type is the
same as used in other forms.</p>
</div>
<div class="div2">
<h3><a name="input-validations"></a>3.3 Input Validations</h3>
<p>XForms should be able to express restrictions on user-entered data,
with enough sophistication to handle common cases, like "telephone number".
XForms should define how the user agent should behave when the user-entered
data conflicts with the restrictions defined by a data type.</p>
</div>
<div class="div2">
<h3><a name="send-xml"></a>3.4 Send XML to Server</h3>
<p>In addition to legacy formats, XForms will be able to send the
submitted form instance data to the server as an XML document.</p>
</div>
<div class="div2">
<h3><a name="calculations"></a>3.5 Calculations and Expressions</h3>
<p>XForms should include simple calculations and expressions based on
form data values. Common tasks like summing multiple data values and
calculating sales tax should be possible. The expression syntax needs to be
simple enough to be easily parsed and processed by a wide variety of user
agents. It should be possible to escape out to a scripting language for
advanced processing.</p>
<p>The XForms Working Group is aware of potential overlap with the XML
Query Working Group in this area, and will review the documents produced by the
XML Query Working Group. The XML Query Group will be asked to review the XForms
Requirements and XForms Model specification.</p>
</div>
<div class="div2">
<h3><a name="dependencies"></a>3.6 Data Value and Form Control Dependencies</h3>
<p>XForms should be able to express dependencies between data values.
It should be possible to constrain a form control so that it can only accept
input if another specific data value has been filled. It should be possible to
bind two or more form controls to the same data value, so that if the data
value is updated, then the related form controls indicate that value.</p>
</div>
<div class="div2">
<h3><a name="arrays"></a>3.7 Expandable Form Control Groups (Arrays)</h3>
<p>For form control groups that support multiple entries, such as a
line item on an order form, it should be possible for the form control to
dynamically expand and contract to permit the addition or removal of further
items. It should be possible to specify the initial, minimum, and maximum
number of entries.</p>
</div>
<div class="div2">
<h3><a name="security"></a>3.8 Security Features</h3>
<p>It should be possible to perform secure, protocol-independent form
transactions.</p>
</div>
<div class="div2">
<h3><a name="confidence-instance"></a>3.9 Confidence Scores</h3>
<p>Some input modalities (for example, speech recognition, handwriting
recognition and optical character recognition) naturally result in
uncertainties. Recognition engines may provide a measure of how confident the
engine was that a given value was correctly recognized. It should be possible to provide a
means for such confidence scores to be included with form instance data. The representation of
ambiguities is something that is potentially harder to deal with and falls
under the section <a href="#future-req"><b>5 Future Considerations (Non-Normative)</b></a>.</p>
</div>
</div>
<div class="div1">
<h2><a name="ui-reqs"></a>4 User Interface Requirements (Normative)</h2>
<div class="div2">
<h3><a name="backwards-features"></a>4.1 Provide Functional Equivalents of HTML 4 Form Controls</h3>
<p>Every form of user interaction defined and commonly implemented in HTML 4 forms should be
possible with XForms.</p>
</div>
<div class="div2">
<h3><a name="forwards-features"></a>4.2 New Form Controls</h3>
<p>Compared to current Web form technology, XForms should define richer
form controls to match the expectations of designers, and to provide richer
functionality for data acquisition. Designers should be given greater control
over the visual appearance of form controls.</p>
</div>
<div class="div2">
<h3><a name="multi-page-form"></a>4.3 Support Multiple Pages per Form, and Multiple Forms per
Page</h3>
<p>It should be possible for a form to be presented as two or more
pages. This requirement permits the form to be treated as a single unit or as
several parts. The form's logic should apply regardless of how it is split
up.</p>
<p>Multiple independent forms should be able to exist within the same
Web page.</p>
</div>
<div class="div2">
<h3><a name="input-devices"></a>4.4 Support More Input Devices</h3>
<p>Forms need to support a wide range of data acquisition techniques in
addition to plain text. For instance, to enable the input of files, such as
audio files, and the input of data streams from devices such as cameras,
microphones and scanners. Also under consideration are pen-based inputs, which
would allow signatures and other simple drawings to be entered directly into a
form equipped with a suitable drawing canvas.</p>
</div>
<div class="div2">
<h3><a name="layout-alignment"></a>4.5 Layout/Alignment</h3>
<p>XForms should have no dependency on a particular presentation
technology, for example XHTML tables.</p>
<p>We will investigate ways of achieving richer form layout and
alignment on a wide variety of devices.</p>
</div>
</div>
<div class="div1">
<h2><a name="future-req"></a>5 Future Considerations (Non-Normative)</h2>
<p>XForms will be designed with the following features in mind, however
these areas will not be addressed in the first release.</p>
<div class="div2">
<h3><a name="custom-controls"></a>5.1 Custom Defined Controls</h3>
<p>There should be a way to define new form controls (perhaps using
other markup languages such as SVG, perhaps with bitmap images) offering a
custom look and feel but integrated into the forms model so that they
internally behave and react like a standard form control.</p>
</div>
<div class="div2">
<h3><a name="gui-enhancement"></a>5.2 Further GUI Enhancements</h3>
<p>Further research into various additional graphical elements that
will be useful as a part of XForms.</p>
</div>
<div class="div2">
<h3><a name="voice-enhancement"></a>5.3 Voice Enhancements</h3>
<p>Further research into ways to make XForms more useful to aural user
agents.</p>
</div>
<div class="div2">
<h3><a name="paper-enhancement"></a>5.4 Paper Enhancements</h3>
<p>Further research into ways to make XForms more useful to paper
processing and OCR user agents.</p>
</div>
<div class="div2">
<h3><a name="ambiguities"></a>5.5 Representing Ambiguities</h3>
<p>Some input modalities (for example, speech recognition, handwriting
recognition and optical character recognition) naturally result in
uncertainties and ambiguities. Did the user say "Boston" or "Austin" for the
destination city? Study is needed into ways to represent such ambiguities in
form instance data, and to make this available to servers when processing the
form data.</p>
</div>
<div class="div2">
<h3><a name="dsig"></a>5.6 Digital Signatures</h3>
<p>Further research into what is needed to apply digital signatures to
form presentation and data, possibly including the preservation of the form
presentation exactly as the user experienced it.</p>
</div>
<div class="div2">
<h3><a name="locale"></a>5.7 Region Independence</h3>
<p>Forms designed for international access should to
be able validate such data values taking the user's locale into account.
Additionally, in forms designed for international access, labels, sizes and
input constraints for data values should be able to adapt to the locale.</p>
</div>
<div class="div2">
<h3><a name="http-auth"></a>5.8 HTTP Authentication Front-end</h3>
<p>Current user agents typically implement HTTP authentication with
a pop-up window requesting name and password. It should be possible for XForms
to be used as a front end for HTTP authentication.</p>
</div>
<div class="div2">
<h3><a name="save-resume"></a>5.9 Saving and Resuming</h3>
<p>There needs to be a generalized way of preserving the changes the
user has made to a form. This will make it possible for a user to save the
form, and at a later time, to resume filling it out, perhaps from a different
machine and perhaps with a different user interface. The ability to treat forms
as persistent objects encapsulating state and behavior is needed for workflow
applications where forms are passed from one user to another. It should be
possible to merge independent updates to persistent forms in ways specific to
individual applications.</p>
</div></div>
</div>
<div class="back">
<div class="div1">
<h2><a name="acknowledgments"></a>A Acknowledgements (Non-Normative)</h2>
<p>This document was written with the participation of the XForms Working
Group:</p>
<ul>
<li>
Steven Pemberton
, CWI
(<i>co-chair</i>)
</li><li>
Sebastian Schnitzenbaumer
, Mozquito Technologies
(<i>co-chair</i>)
</li><li>
Micah Dubinko
, Cardiff
</li>
<li>Driss Eddaifi
, Ecole Mohammadia d'Ingénieurs
</li>
<li>Najib Tounsi
, Ecole Mohammadia d'Ingénieurs
</li>
<li>Michalis Petropoulos
, Enosys Markets, Inc.
</li>
<li>
Peter Stark
, Ericsson
</li>
<li>
Frank Boumphrey
, HTML Writer's Guild
</li>
<li>
Dave Raggett
, W3C
</li>
<li>
Roland Merrick
, IBM
</li><li>
T. V. Raman
, IBM
</li><li>Linda Bucksay Welsh
, Intel</li>
<li>
Gavin McKenzie
, JetForm Corporation
</li>
<li>
Rob McDougall
, JetForm Corporation
</li>
<li>
Ray Waldin
, Lexica, LLC
</li>
<li>
Tantek Çelik
, Microsoft
</li>
<li>
Alex Hopmann
, Microsoft
</li>
<li>Dave Hyatt
, Netscape/AOL
</li>
<li>
Eric Pollmann
, Netscape/AOL
</li><li>Tom Butcher
, OpenDesign
</li>
<li>
K. P. Lee
, Phillips
</li>
<li>
Roli Wendorf
, Phillips
</li>
<li>
Ted Wugofski
, Openwave
</li>
<li>
David Cleary
, Progress Software
</li>
<li>
Mike Mansell
, PureEdge
</li>
<li>
Dave Manning
, PureEdge
</li><li>Josef Dietl
, Mozquito Technologies
</li>
<li>Michael Fergusson
, Softquad
</li>
<li>
Zoe Lacroix
, SurroMed, Inc.
</li>
<li>
Leigh Klotz
, Xerox
</li>
</ul>
<p>The XForms Working Group has benefited in its work from the
participation and contributions of Invited Experts:</p>
<ul>
<li>
Tom Schnetlage
, University of Berkeley
</li>
<li>
Dan Gillman
, Federal Bureau of Labor Stastistics
</li>
<li>
Eliot Christian
, U.S. Geological Survey
</li>
<li>
Ashok Malhotra
, XML Schema and XML Query Working Groups (and
IBM)
</li>
</ul>
</div>
<div class="div1">
<h2><a name="biblio"></a>B References (Non-Normative)</h2>
<dl>
<dt class="label"><a name="ref-authform"></a>AUTHFORM</dt><dd>
<a href="http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html"><cite>User
Agent Authentication Form Elements</cite></a>, Scott Lawrence, Jim Gettys, Paul
Leach, 3 September 1998. Available at:
http://www.w3.org/MarkUp/Group/Contrib/Lawrence/authform-980903.html</dd>
<dt class="label"><a name="ref-FML"></a>FML</dt><dd>
<a href="http://www.mozquito.com/documentation/spec_xhtml-fml.html"><cite>Forms Markup
Language (FML) 1.0</cite></a>, Sebastian Schnitzenbaumer, Malte Wedel, Muditha
Gunatilake, Josef Dietl, 9 September 1999. Available at:
http://www.mozquito.com/documentation/spec_xhtml-fml.html</dd>
<dt class="label"><a name="ref-FORMSHEET"></a>FORMSHEET</dt><dd>
<a href="http://www.hpl.hp.co.uk/people/ak/doc/XForm.html"><cite>Formsheets
and the XML Forms Language</cite></a>, Anders Kristensen, 11 May 1999.
Available at: http://www.hpl.hp.co.uk/people/ak/doc/XForm.html</dd>
<dt class="label"><a name="ref-FUTUREFORMS"></a>FUTUREFORMS</dt><dd>
<a href="http://www.w3.org/MarkUp/Group/WD-forms-ng.html"><cite>The Future of
HTML Forms</cite></a>, Dave Raggett, 16 January 1999. Available at:
http://www.w3.org/MarkUp/Group/WD-forms-ng.html</dd>
<dt class="label"><a name="ref-XFA"></a>XFA</dt><dd>
<a href="http://www.w3.org/1999/05/XFA/xfa-formcalc.html"><cite>XFA-Template
Version 1.0</cite></a>, Gavin McKenzie, 14 June 1999. Available at:
http://www.w3.org/1999/05/XFA/xfa-formcalc.html</dd>
<dt class="label"><a name="ref-XFDL"></a>XFDL</dt><dd>
<a href="http://www.w3.org/TR/NOTE-XFDL"><cite>Extensible Forms Description
Language (XFDL) 4.0</cite></a>, John Boyer, Tim Bray, Maureen Gordon, 2
September 1998. Available at: http://www.w3.org/TR/NOTE-XFDL</dd>
</dl>
</div>
</div>
</body></html>