RE: Apple's XForms CFR Response

 Call for Review: XForms 1.0 Is a W3C Proposed Recommendation

Wanda Cox
AC Representative for Apple

------------------------------------------------------------------------

Decision for XForms 1.0

   As representative of the above Member, I suggest that the XForms 1.0
   Specification

     ( X)  be returned for further work due to substantial issues

   Comments:

Apple Computer and Opera Software have reviewed the the XForms
specification. We believe forms are vital to the web and the submitted
review is based on a desire to see forms enhance future web devices
and web pages. The XForms WG has worked hard to develop XForms, and
they have made extensive efforts to reuse other W3C Recommendations.
However, after a thorough review of the specification, we do not
believe XForms is a technology appropriate for the Web.

XForms is hard to author. Comparing XForms examples with their
equivalents in, for instance, HTML forms, shows that the status quo is
significantly simpler to write and maintain than the XForms
equivalents. Since the main reason for the popularity of existing Web
technologies has been their ease of authoring, we feel this is a
serious problem.

XForms has too many dependencies. In addition to XForms itself, an
XForms implementation needs to support XML with namespaces, XML
Schema, XPath, XML Events, DOM Events, DOM Core, CSS, a stylesheet
linking technology (e.g. the XML Stylesheet PI), and a host language
(e.g. XHTML or SVG). In particular, its dependency on XML Schema is
of great concern to us.

XForms does not address the need for a rich user interface markup
language. For example, it provides no way to indicate which button in
a form should be the default button, and it does not allow for the
possibility of the caption and form control elements being separated
(as supported by the <label> element in XHTML), which makes it harder
to style.

In addition to the above, we have also found specific claims made in
the specification that we feel are untrue, some of which are directly
related to the three major points listed above:


Claim 1: The separation of the data being collected from the markup of
the controls collecting the individual values makes XForms more
tractable by making it clear what is being submitted where.

Counterclaim: It actually makes it _harder_ to tell what is going on,
since the form control elements and instance model elements must be in
different parts of the document in XForms documents. In HTML forms,
there is no ambiguity as to what is submitted: The form controls are
direct descendants of the relevant form element, and submit exactly
what their attributes claim to submit.


Claim 2: XForms, while designed to be integrated into XHTML, is no
longer restricted only to be a part of that language, but may be
integrated into any suitable markup language.

Counterclaim: This appears to be an attempt at solving a problem that
does not exist: Nothing stops authors from using XHTML1 form elements
in non-XHTML documents _today_, in deployed browsers. Unfortunately,
the solution adopted by XForms of introducing yet another namespace to
the W3C fold merely results in extra confusion in the common case: an
XHTML document that uses XForms is forced to use at _least_ two
namespaces, typically more, despite evidence that typical Web authors
find namespaces confusing and hard to use.


Claim 3: XForms has striven to improve authoring.

Counterclaim: XForms is, in our experience, orders of magnitude harder
to author than HTML forms. For example, compare


http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0003/example1.xhtml

...with:

   http://www.w3.org/TR/xforms/sliceG.html#xforms-in-xhtml-00

The two files implement basically the same form, yet the HTML one is
significantly shorter, only uses one namespace (as opposed to 5 for
the XForms equivalent), and does not involve multiple layers of
indirection.

Note that the HTML example here, much like the XForms one, uses some
externally defined functions that are not considered part of the
markup as they are not typically redeveloped for each form but can be
re-used across projects. We would be interested in seeing these
commonly used functions be standardised.


Claim 4: XForms has striven to improve internationalization.

Counterclaim: Progress with defining IRIs has removed the i18n problem
from HTML forms. (Indeed XForms refers to the relevant TAG finding
that discusses this. [TAG Finding 7])


Claim 5: XForms has striven to improve accessibility and usability.

Counterclaim: By making it harder for authors to select specific form
controls, accessibility and usability are in fact reduced. HTML forms
already have the <legend> element (equivalent to xforms:caption) and
the title attribute (for tooltips). It would be trivial to extend HTML
forms to include links to further help information in a consistent
way.


Claim 6: XForms has striven to improve device independence.

Counterclaim: By depending on so many specs, XForms has increased the
requirements for implementations to the point where few devices can
even attempt an implementation.


Claim 7: Submitted data being strongly typed speeds up form filling
since it reduces the need for round trips to the server for
validation.

Counterclaim: Forms _today_ regularly have script-based client-side
type checking that do not require server round trips. In addition,
irrespective of any client side validation, servers will still have to
validate all data for security and sanity reasons, so there is no
decrease on the load on the server.


Claim 8: XML submission obviates the need for custom server-side logic
to marshal the submitted data to the application back-end.

Counterclaim: This assumues a priori that the application back-end
uses an XML input method. Applications could just as easily be written
to accept multipart/form-data, or could simply convert
multipart/form-data into an XML form. Secondly, it would be easy to
introduce a new form encoding (enctype) for XML submission in HTML,
without any changes to the HTML spec itself.


Claim 9: Existing schema re-use obviates duplication, and ensures that
updating the validation rules as a result of a change in the
underlying business logic does not require re-authoring validation
constraints within the XForms application.

Counterclaim: This makes the dubious fundamental assumption that the
business logic uses XML Schema as its basis. For sites written in
server-side JavaScript, the same argument could be made for current
HTML forms.


Claim 10: XForms has less use of scripting, and thus a reduction in
the need for imperative scripts for event handlers.

Counterclaim: XPath is close to a procedural scripting language in its
own right, so the claim that there is less scripting is arguable.
Since authors are more familiar with imperative scripting than
declarative XPath expressions, this results in greater difficulty for
authors, not less. Furthermore, XForms <action> syntax can easily be
viewed as a very basic programing language with angle brackets.
Inventing a new script-like language when existing languages such as
ECMAScript are widely used by authors simply forces authors to learn
yet another language, making authoring more difficult.


Claim 11: XForms splits the instance model and typing information from
the interface.

Counterclaim: This is not true. The user interface elements are still
used, to a large extent, to give the possible values, e.g. in
enumerated sets. If this claim were true, there would only be one form
element, not eleven, and the actual control shown and the values shown
or made available would be derived from the type and instance data.


In conclusion, we do not believe XForms should proceed to W3C
Recommendation stage.


Despite the above, however, we do agree that HTML forms have problems
that need addressing. In particular:

   * The requirement that all form controls must be structurally
     nested within <form> elements means that it is impossible to
     create multiple forms side by side, as for example having each
     column or row in a table be its own form.

   * HTML forms are severely limited in terms of typing information.
     The need for date types, patterned text field entry, marking
     fields as required, and other similar extensions is clearly shown
     by any e-commerce Web site.

   * The current POST submission formats, both multipart/form-data and
     application/x-www-form-urlencoded, have issues. The latter is not
     defined for file upload; the former is non-trivial to parse and
     does not fit well with the modern, XML-biased, toolset.

   * Common idioms, such as cloning form controls, propagating values,
     implementing dependencies and validating values could easily be
     simplified by providing utility interfaces.

We would like to see alternative proposals, for example in the form of
an XHTML module, that address these concerns without introducing the
aforementioned problems from which XForms suffers.


References:

[TAG Finding 7] "TAG Finding: URIs, Addressability, and the use of
HTTP GET", Dan Connolly, 2002. http://www.w3.org/2001/tag/doc/get7


------------------------------------------------------------------------

Usage

   My organization:

   Please indicate which options match your choice:
     * [_] produces products addressed by this specification
     * [_] expects to produce products conforming to this specification
       (your details below)
     * [_] expects to produce content conforming to this specification
       (your details below)
     * [_] expects to use products conforming to this specification
(your
       details below)
     * [_] does not expect to produce or use products or content
       addressed by this specification

   Comments (or a URI pointing to it):

------------------------------------------------------------------------

Patent Claims

   Patent claims applicable to these specifications should be disclosed
   according W3C's [43]Current Patent Practice Note

     [43] http://www.w3.org/TR/patent-practice

   Please indicate which option matches your choice:
     * (X) To the best of my knowledge, my organization does not have
       patents that may be essential technology for implementing these
       specifications.
     * (_) We have disclosed to [44]patent-issues@w3.org following the
       procedure described in section 3 of the [45]Current Patent
       Practice Note

     [44] mailto:patent-issues@w3.org
     [45] http://www.w3.org/TR/patent-practice

------------------------------------------------------------------------