XForms WG's reply to Opera and Apple's XForms CFR Response

Thank you for your comments. These would have made excellent last call
comments, or even CR comments, especially as we explicitely asked for
comments on the mobile profile, which your comments largely seem to
address. We are disappointed though that you have left it so late.

But still, your comments contain much that is apparently based on
misunderstandings about how XForms works, so we will try to address
your review here.

We should point out that the XForms specification is addressed at
implementors, and is not an XForms tutorial, so it is much denser
than user-oriented documentation. For information about how to use
XForms, rather than how to implement it, please refer to one of the
XForms books now available.

AUTHORING

We disagree that authoring XForms is significantly harder for
equivalent forms in HTML. Take for example a simple search form in
HTML. In the body you have:

         Find <input type="text" name="q" />
         <input type="submit" value="Go" />

surrounded at some point by

    <form action="http://example.com/search" method="get">
    ...
    </form>

In XForms in the body you have

      <input ref="q"><label>Find</label></input>
      <submit submission="s"><label>Go</label></submit>

with the following in the head:

  <model><submission action="http://example.com/search" method="get"
id="s"/>
  </model>

although you may add <instance><data><q/></data></instance> in there
if you want. So far so good: in terms of authorability, more or less
the same.

But now if we want to change it to prevent someone submitting if they
have typed nothing in, in XForms all we have to do is put this in the
model:

    <bind nodeset="q" required="true()"/>

while to do the same in HTML you have to add this to the form:

  <form action="http://example.com/search" method="get"
          onsubmit="return isnonempty(document.getElementById('q'));">

  <script type="text/javascript">
  function isnonempty(e) {
      if (e.value.length>0) return true;
      else {
       e.style="background-color: red";
       // or alert("search string must be nonempty"); or whatever
       return false;
      }
  }
  </script>

and hope that the user hasn't switched Javascript off in the browser
(if it is there at all). We would claim that this is harder, not
easier than XForms.

And suppose you only want to search for integers (perhaps it is a
search for numbered bugs in a database). In XForms you add to the
<bind> element above:

    type="xsd:integer"

(We won't bother to show the code necessary to do the same in Javascript.)

For HTML Forms there is pretty much a one-to-one correspondance with
the equivalent XForms. It is exactly when the HTML Form gets more
complicated, with validation and so on, that XForms becomes easier.

The tax authority in a major Western country is already piloting the
use of XForms. Forms with 5000 bind elements we are told, expressing
the relationships between the fields; they use a department-wide
schema for the data typing. You know the sorts of form: "How many
children do you have?" and not asking further if the answer is 0, and
asking for each child otherwise. Ever tried doing that in Javascript? We
have, and we know what we prefer. We can't make that sort of form fun,
but we can make it easier.

DEPENDENCIES

We don't apologize for having dependencies on XML and Namespaces. They
come with the territory! Likewise for the DOM.

Unlike what you suggest, there is no requirement for CSS support, or
the XML Stylesheet PI, nor Schema support if you want to implement the
mobile profile.

So that leaves us with XPath. It is true that there is no mobile
profile for XPath (which you could propose to W3C as an interesting
work item if you are interested). On the other hand, there is no
requirement for Javascript or other scripting language in XForms, so
you win some and you lose some.

We could have developed an alternative to XPath (and a data typing
language as an alternative to Schema), as indeed we started to do in
the beginning, but we decided to use existing components, partly
because it eased our task by not reinventing the wheel, and partly
because the groups that were already doing such things intimated to us
in timely comments that it would be a good thing if we did;
implementors have told us has eased their life greatly as well, by
being able to use off-the-shelf components.

One implementor states that XPath adds 80k to his implementation
(i.e. that is the footprint of XPath in his implementation), which,
while we recognise that there are situations where every k counts, we
don't consider an unnecessarily great burden.

ADDRESSING THE NEED FOR A RICH USER INTERFACE MARKUP LANGUAGE

We believe that we have addressed the needs for a rich user interface
language. We have precisely defined the controls so that they reflect
their intent and not their external representation (for instance, that
a control selects one from a list of options, rather than specifying
how it is done, with radio buttons, or drop downs, or whatever). This
gives amazing advantages, and we can only direct you to the Oracle
implementation for a stunning demonstration of the *same form* being
rendered on a PC screen, a mobile device, a voice browser, and even an
instant messenger client, without change. Try doing that with
Javascript...

WHETHER XFORMS IS EASIER FOR LOCATING WHAT IS SUBMITTED

Start your stopwatch now, go to google.com and by no more than looking
at the source, work out what values it returns. Hint:

    <model><data>
        <q/><hl>en</hl><lr/><ie>UTF-8</ie><oe>utf-8</oe>
    </data></model>

(your actual values may differ).

WHETHER XFORMS SHOULD HAVE ITS OWN NAMESPACE

There are members of the XForms Working group who strongly agree with
you on this one. There are members of the XForms Working group who
strongly DISagree with you on this one. We humbly invite you to a
meeting of the XForms Working Group to convince us.

However, the XForms and HTML Working Groups are currently working on a
technique to minimise the authoring problems involved with mixed
namespace documents.

WHETHER XHTML1 FORMS ELEMENTS ARE SUITABLE FOR OTHER NAMESPACES

While we agree that XHTML1 forms elements could be squeezed into many
other markup languages, they weren't designed to be, and so the result
wouldn't always be pretty, and you would probably have to make some
compromises. Do you know any examples of this being done? XForms on
the other hand is already being used in a number of other projects,
for instance SVG+XForms.

WHETHER XFORMS HAS STRIVEN TO IMPROVE INTERNATIONALISATION

Your example doesn't seem to counter this claim. We *have* striven to
improve internationalisation. It may be that HTML Forms have also got
better in the meantime. Good.

We would direct you to the impressive multilingual example on
www.formsplayer.com that allows you to change the language used in the
form from English to Welsh without reloading the form, as an example
of the advantages of the XForms approach.

ON DEVICE INDEPENDENCE

Again, we would direct you to Oracle's demonstration of the same
XForms running on a very diverse set of platforms to answer the
question of whether XForms has addressed device independence.

ACCESSIBILITY AND USABILITY

Again the argument that HTML Forms could be improved isn't an argument
against XForms already having done it. Amongst the design team of
XForms is one of the Web's top accessibility experts, who is himself
blind. If you don't believe that XForms is more accessible that HTML,
we recommend you go and talk to him.

STRONG TYPING REDUCES THE NEED FOR ROUND TRIPS

We are glad that you agree that strong typing reduces the need for
server round trips. This in itself reduces the load on servers, as
well as immensely improving the user experience. You are absolutely
right that strong typing does not relinquish the server of the
responsibility of validating the input: after all, the server does not
even know that the data has come from an XForms user agent.

USING XML AS SUBMISSION FORMAT

It is obviously true that submitting an XML form assumes that the
server accepts XML. But it is our observation that that is steadily
more the case, and if it does, that XForms simplifies the process of
submission. But still, if a server doesn't yet accept XML, XForms
still allows you to submit in legacy formats.

ON SCHEMA REUSE

If you think that it is a dubious claim that companies are using XML
and XML Schema in their business logic, then you need to get out and
talk to some companies. Even if there are companies using Javascript
for their business logic, you won't be able to plug it in to an HTML
Form and expect it to work.

But that notwithstanding, XForms does not require you to use XML
Schemas; it is just that if you have them available, you can use them,
and it makes your life so very much easier, both for consistency
between forms as for typing of values in Forms. If you don't have the
schemas you can specify the types of your individual values, and it
works just as well.

REDUCTION OF SCRIPTING

Most people who will write XForms will have authored spreadsheets and
understood the simple precepts of selecting an element with a
selector, and using simple expressions to calculate values. We think
that this is very far from being a procedural scripting language.

In any case, most XForms that are equivalent to current-day HTML forms
will only use very simple selectors like "q" in the example above, and
no one will be even aware they are using XPath.

A great advantage of the declarative approach is that it is trivially
easy to keep relationships between values and controls up to date,
such as the sum of the individual prices of things you have
bought. With scripting you have to keep track of such relationships
yourself, and if one value changes make sure that the related values
are updated.

A final advantage of the declarative approach is that in XForms the
relationships are between values, and independent of the user
interface elements; this makes the XForms model reusable: you can use
it in a different Form without any reprogramming. With a Javascript
approach, the scripting is tied to the controls, and so if you add new
controls, you have to add extra scripting.

SPLITTING THE INSTANCE AND TYPES FROM THE INTERFACE

It is true that some XForms controls contain data typing
information. This is to allow authors who don't wish to use data
typing or to supply a model element, to continue to be able to the
things they are used to in HTML Forms.

It is incorrect to say that if we hadn't done this there would only be
one form element: there are different things you can do with the same
data type that need to be distinguished, such as selecting one from a
list, or selecting many from a list.

Separation of the data values from the forms controls vastly eases the
task of populating forms with external data, and even allows one form
on a page to cause another form on the page to be populated.

THE NEED FOR IMPROVEMENTS ON HTML FORMS

To paraphrase you:
"Despite the above, however, we do agree that HTML forms have problems
that need addressing:
    Support for multi-form documents
    Data types
    Modern, easy-to-parse submission format
    Propagating values, dependencies, and validation"

We agree! And that was the basis of XForms, using where possible
existing XML idioms rather than reinventing the wheel.

We have looked at your sketch of how Forms could be done using
Javascript instead of declarative markup, and it reminded us rather of
JSS, an early proposal of how you could do styling using Javascript
rather than CSS ("who needs another parser?", etc).

It is our feeling that HTML Forms have been done the Javascript way
for the last decade, and it exactly that that we are trying to fix!
One of us has an email with a "+" character in it, and one in maybe
five websites refuses to accept input from him because their type
validation is wrong. This is not a problem with the browser, or the
definition of HTML Forms, but with each individual website that does
validation using scripting, and so to fix it you have to write to each
individual webmaster and hope they will fix it (many won't by the
way).

As illustrated above, we firmly believe that declarative style is
preferable in fundamental ways to procedural style for many computing
tasks, and that this explains for instance the success of
spreadsheets.

We thank Opera and Apple for showing such interest in XForms, even at
this late stage, and look forward to them joining the group to help us
refine the mobile profile of XForms to more closely match their needs.

Steven Pemberton
For the Forms Working Group

Received on Friday, 12 September 2003 20:47:18 UTC