Copyright © 2004 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use , and software licensing rules apply.
XForms is an XML application that represents the next generation of forms for the Web. This document specifies the requirements for XForms 1.1.
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 W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C Working Group Note , made available by the W3C XForms Working Group as part of the XForms Activity within the W3C Interaction Domain . The authors of this document are the XForms Working Group participants.
This document will not be the final version - the Working Group may update the document when changes deemed necessary and appropriate as they develop XForms 1.1. Changes between this version and the previous version are illustrated in a diff-marked version .
Comments on this document are welcome. You may email comments to the appropriate public mailing list for the XForms Working Group: www-forms-editor@w3.org ( Archive ). Discussion of these issues will take place on the public mailing list www-forms@w3.org ( Archive ). Please note that comments that you make will be publicly archived and available, do not send information you would not want to see distributed, such as private data.
Publication as a Working Group Note 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.
XForms 1.1 will build upon the solid foundation set forth by XForms 1.0 - the Next Generation of Web Forms. This version makes incremental improvements over version 1.0 to provide expanded behaviors for the existing and established XForms Model-View-Controller Framework and by embracing SOAP . This version also makes adjustments to XForms to facilitate its adoption in other host languages.
Requirement: Support SOAP as a new method of submission.
In
XForms
1.0,
the
submission
element
allows
sending
part
of
any
instance
to
the
server,
but
there
is
no
reciprocal
functionality
for
handling
the
returned
data.
In
particular,
there
is
no
ability
to
pass
partial
instance
data
back
and
forth
between
client
and
server
based
on
conditions
expressed
via
XForms
model
properties
and/or
triggered
by
user
interactions.
Requirement:
Allow
the
submission
element
to
specify
that
the
returned
data
can
go
in
any
instance,
not
just
the
instance
from
which
the
submitted
data
was
drawn.
Requirement:
Allow
the
submission
element
to
specify
that
the
returned
data
can
be
used
to
replace
a
node
in
the
instance
data.
A
use
case
would
be
submitting
an
element
containing
a
UK
postal
code
and
having
the
returned
data
replace
an
instance
subtree
containing
an
address.
Some intended applications of XForms may require the ability to let the host document to have control over the XML data submitted to the server. A use case would be a document-centric system in which an entire XML document, not just the XML data is submitted.
Requirement:
Allow
the
submission
element
to
delegate
submission
serialization
to
the
host
document's
processor.
In
XForms
1.0,
a
repeat
element
creates
the
user
interface
elements
in
its
content
once
for
each
node
in
the
collection
indicated
by
its
nodeset
attribute.
If
the
nodeset
expression
results
in
an
empty
collection,
then
no
user
interface
elements
are
created.
To
dynamically
add
user
interface
elements
as
more
data
becomes
available,
insert
is
used
to
add
another
node
to
the
collection
to
which
the
repeat
nodeset
is
bound.
However,
the
insert
element
in
XForms
1.0
requires
that
the
collection
contain
a
prototypical
node
in
the
initial
instance
data
that
is
to
be
duplicated
in
the
collection.
Due
to
this
architecture,
it
is
not
possible
to
use
insert
on
a
repeat
collection
that
is
initially
empty.
The
use
case
for
an
initially
empty
collection
is
a
shopping
cart
application,
where
the
user
expects
to
start
with
an
empty
shopping
cart.
Secondly,
it
is
also
more
difficult
to
express
forms
in
which
the
data
content
is
derived
not
from
the
prototypical
instance
but
from
other
instance
data
obtained
after
initialization.
Each
leaf
node
in
the
subtree
rooted
by
the
new
node
in
the
repeat
collection
must
currently
be
filled
with
a
separate
invocation
of
setvalue
even
if
the
desired
subtree
structure
exists
elsewhere
in
instance
data.
Requirement: Allow a method for copying a subtree of instance data (identified by a single apex element node) and pasting the subtree copy into an identified instance element node. The method must provide a facility for indicating where to put the subtree copy in the children of the target node (e.g. first, last, after a given child).
Requirement: Let email address be a primitive (recognized) XForms datatype for schema data validation.
A
document
containing
an
XForms
model
can
be
associated
with
externally
defined
XML
data
using
linking
attributes
of
the
instance
element,
but
there
is
no
way
to
associate
XML
data
with
externally
defined
documents
that
contain
a
compatible
XForms
model.
A
use
case
would
be
to
allow
XForms
processors
to
edit
XML
obtained
from
the
local
computer
or
server,
and
to
return
the
edited
XML
to
the
local
computer
or
server.
Requirement: A method of associating XML data with a container document that places the XML data in the document on load and persists the association in the XML data when it is submitted or saved.
Applications that require mathematical exponentiation (raising X to the power Y) are not possible in XForms 1.0, such as the compounded interest calculation for a periodic loan payment.
Requirement: Allow the ability to calculate X Y in XForms computational expressions.
In
some
forms,
it
is
necessary
to
perform
a
simple
table
lookup
based
on
user
input.
For
example,
suppose
a
form
contains
an
element
conversionTable
that
provides
conversion
rates
for
various
currencies
to
the
user's
local
currency.
Based
on
the
conversion
selected
by
the
user,
the
appropriate
exchange
rate
would
be
used
in
a
calculation.
XPath
provides
the
ability
to
perform
this
type
of
search
using
predicates.
To
continue
the
above
example,
suppose
each
child
of
conversionTable
is
a
rate
element
with
the
exchange
rate
as
content
and
a
currency
attribute.
Further,
let
a
separate
instance
element
called
currency
provide
the
storage
for
the
currency
selected
by
the
user,
and
let
amount
contain
the
amount
to
convert.
The
converted
amount
could
then
be
obtained
using
the
following
XPath:
/root/amount
*
/root/conversionTable/rate[@currency=/root/currency]
.
The problem with this approach is that it uses absolute referencing to obtain the currency value selected by the user. If the converted amount, amount, and currency elements were moved to a deeper point in the instance data, then the XPath would have to be rewritten.
Requirement: Allow an XPath expression to perform a table search using a key whose value is referenced relative to the initial context node of the XPath expression.
A
selection
user
interface
element
may
be
bound
to
instance
data
in
one
model
as
the
target
for
the
result
of
a
selection,
but
the
choices
may
be
obtained
from
a
different
model
via
an
itemset
.
XForms
1.0
does
not
define
a
behavior
if
the
nodeset
to
which
the
itemset
is
bound
changes
unless
the
nodeset
is
in
instance
data
of
the
same
model
as
the
target
node
that
receives
the
result
of
a
selection.
Requirement:
Synchronize
the
refresh
of
an
itemset
and
its
containing
selection
user
interface
element,
even
if
the
two
are
bound
to
nodes
in
separate
XForms
models.
To increase widespread adoption of XForms in web applications, it is necessary to reduce the difficulty of authoring XForms in XHTML, which is currently hindered by the incessant need to flip between the host language namespace and the XForms namespace when authoring the user interface component of a form.
Requirement: Simplify Authoring XForms in XHTML2.
To facilitate the adoption of XForms in other XML tag sets, which is stated as a key goal in the XForms 1.0 requirements , the conformance levels for implementations of XForms elements outside of the XForms model will be modified (because those elements must often be more closely integrated with the host language).
Requirement: Let the XForms user interface related elements and attributes be recommended.
There
are
many
use
cases
in
which
a
behavior
should
be
followed
by
closing
the
containing
document
(which
may
cause
the
user
agent
to
close
if
appropriate).
For
example,
in
XForms
1.0
the
replace="all"
setting
on
a
submission
can
be
considered
to
close
the
containing
document
as
the
user
agent
displays
the
new
document
with
the
result
data
of
the
submission.
A
more
general
facility
is
required
to
notify
the
user
agent
of
the
need
to
close
the
containing
document
at
any
time,
for
example
in
response
to
a
trigger
activation
or
other
event.
Requirement: Increased ability for XForms markup to indicate the need to close the containing document.
This document was produced with the participation of current XForms Working Group participants: