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

This is a personal reply. While I make reference to Opera and Apple below,
I am not speaking on their behalf.

On Sat, 13 Sep 2003, Steven Pemberton wrote:
>
> 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:
>
>     <form action="http://example.com/search" method="get">
>      ...
>          Find <input type="text" name="q" />
>          <input type="submit" value="Go" />
>      ...
>     </form>
>
> In XForms [...] you have
>
>   <model>
>     <submission action="http://example.com/search" method="get" id="s"/>
>   </model>
>     ...
>         <input ref="q"><label>Find</label></input>
>         <submit submission="s"><label>Go</label></submit>
>
> So far so good: in terms of authorability, more or less the same.

Maybe the authors you speak to are more intelligent than those I speak
to, but as far as my Web author friends are concerned, the HTML
version above is orders of magnitude simpler than the XForms example.

Indirection is very hard for day-to-day Web authors to grasp. The fact
that different parts of the form are spread over different parts of
the document is confusing. The fact that the "ref" and "submission"
attributes aren't simply names, but actually hide the whole of XPath,
is a booby trap which will lead to author confusion. And so on.

(Note also that the above omits to mention that the HTML version only
has one (or zero, in HTML4) namespaces, while the XForms version has at
least two.)


> 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 [...]

So extend HTML. Then you would just need to add:

   required="required"

...to the relevant element. No indirection. Again, no hidden XPath
expressions (well, not that well hidden this time -- "true()"?).


> and hope that the user hasn't switched Javascript off in the browser
> (if it is there at all).

You can't browse the Web without JavaScript nowadays. JavaScript (or
rather, ECMA-262 and the DOM) is a core part of the Web technologies a
browser must support to be useful, just like HTML or HTTP.


> 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"

...make that three namespaces...


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

So don't do it using JavaScript. Just change 'type="text"' to
'type="integer"' and extend the HTML spec to allow that.


> 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.

And that's great -- but it's not anywhere near typical for the Web.
Your typical form on the Web is a quiz about your last relationship,
or a form to enter credit card details in order to purchase a book.
I'm sure that there is a very real niche market for technologies like
XForms. What I debate (and what Apple and Opera debated in their vote)
is whether such a technology is suitable for the Web.

HTML is a general purpose markup language designed for representing
documents for a wide range of purposes across the world-wide Web. To
this end it does not attempt to be all things to all people, supplying
every possible markup idiom, but to supply a generally useful set of
elements. [1]

Why does XForms not follow similar goals?


> 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.

Forms without styling are unlikely to be popular with Web authors
(just look at the number of pages that style form controls now,
despite the non-interoperable support from UAs). And we did not find
the mobile profile despite our best efforts -- it seems to have
vanished while exiting CR, despite the PR still referring to it in
places.


> 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.

Unfortunately, Opera are not writing an XForms browser which could
optionally have JS support -- they are writing a Web browser which
could optionally have XForms support. Now there is only room on a
mobile device for one of JavaScript and XPath. Since JavaScript is
required to browse existing content, it isn't optional. This means
XPath is not an option.

As you say, you win some and you lose some. In this particular case,
lack of XPath support means that XForms is a non-starter.


> 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.

As I understand it, 80k is way beyond the acceptable amount that could
be added to a UA on a mobile device.


> 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?

I've seen XHTML form controls embedded inside XUL documents rendered with
Mozilla. But I'm not generally aware of any XML documents being used on
the Web in the real world, so no, I know of no real life examples.


> 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.

You mean like the example of an XHTML form doing exactly the same
thing that was included in the Apple and Opera comments?


> 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.

This point confuses me -- I was under the impression that XForms said,
within the model, how many items a value could take. Can XForms not
express this constraint without form elements?


> 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).

This parallel is actually quite apt -- just like JSS went over the top
and was replaced by CSS with DOM+JS for animation, XForms has gone
over the top in the other direction. I think the correct way to go for
strongly typed forms is HTML with DOM+JS for the more complex dynamic
constraints.

There will always be some contraint that a declarative system cannot
express and for which you need to fall back on scripting. XForms has
gone to one extreme, reinventing the entire forms system and allowing
even the rarest of constructs to be written declaratively, and current
HTML forms hit the other extreme, with virtually no typing at all and
all constraints having to be addressed by scripting.

I believe the majority of the Web needs a middle ground, where the
simplicity of HTML forms is leveraged but supplemented by some
declarative ways of expressing the most common idoms, such as
"required field" or "email address", but where the more complex
relationships are still expressed by imperative script backed by some
utility DOM interfaces.


> 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.

XForms will not change that. Server side type checking is still
required, and is very likely to still be wrong.

The following is a valid e-mail address:

   "test address/"@example.org

How many XForms systems accept it? On the server side?

(Note that any server that doesn't do any type checking at all, e.g.
accepts an e-mail address with no "@" sign if you bypass the
client-side checking, is automatically disqualified from this check,
since it is leaving itself exposed to all kinds of malicious attacks
and is therefore not an improvement either.)


We welcome your input on our (very much work-in-progress) proposal to
extend HTML forms to provide what we believe authors are asking for,
without introducing the complexity of XForms:

   http://lists.w3.org/Archives/Member/w3c-archive/2003Sep/att-0014/hfp.html

It has only been under development for a few weeks, but I think it
offers typical Web authors something closer to what they are looking
for than XForms. For example, when I showed it to one of the people
behind http://www.voidwars.com/, a quite advanced Web-based game that
makes heavy use of forms, he responded with "wow, that's exactly what
I need!" whereas when I asked him about XForms, he admitted being
frankly scared.


-- References --
[1] With apologies to http://www.w3.org/TR/xhtml2/

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 14 September 2003 16:54:28 UTC