Re: XForms - "Suspend and resume support"

> gordongano99@yahoo.com writes:
> > We've already had several complaints that XForms 1.0 is way more
> > complicated to understand than HTML forms.

<AndrewWatt2001@aol.com> replies:
> Yes, it is.

XForms 1.0 in its totality is indeed harder to learn than HTML Forms, but it
does a lot more without resorting to scripting. I would claim that it is a
lot *less* complicated than HTML Forms if you include in the comparison the
scripting you have to do in order to achieve the things that are in XForms.

> Ironically Steven Pemberton made a presentation at the W3C meeting a few
> weeks back complaining about increasing complexity in W3C specifications.
> Strangely he seemed oblivious to the relative complexity that XForms
> introduces.

It is not at all ironic, for two reasons. Firstly because my presentation
was not about complexity, but about usability. Secondly because the XForms
group designed XForms using existing technologies like XML, XPath and
Schema. This principle is a good one, because you then don't have to learn
two different methods of doing something, such as addressing elements of an
XML instance. If you already know XPath because of XSLT, then you are up and
running. If you don't, well indeed you have to learn it, but then you have
learnt something that it going to come in handy in other places too. Another
advantage is that implementers can use off-the-shelf components.

But having made a decision to work in that way, you are then obliged to
combine
them in the way that XML demands, which indeed adds some complexity. We
could have designed a free-standing, non-XML application, using all-new
technologies, but that was not our aim.

> He could, quite sensibly, claim that to produce an HTML form that does
> (through scripting) what an XForms form can do would be more complex than
> an
> XForms form. But many HTML forms are much simpler and less ambitous than
> that. So, de facto, for many non-XML developers there is a significant
> increase in complexity.

That is indeed what I would claim, but I would disagree with the conclusion.
HTML Forms+Scripting (which is even what Google uses on its homepage) is
much more complex and harder to learn than XForms. If you only use the bits
of XForms that match one-to-one with the facilities of HTML Forms without
scripting, then the result is barely more complex (namespaces being the
greatest difference).

Try writing a small example in both HTML Forms and XForms, for instance to
do a Google search. There is barely any difference. Now add a restriction
that you can only submit if the search string is non-empty. All of a sudden
XForms is *much* simpler to use.

> > Trying to add everything necessary to make XForms compete with
> > full-featured forms packages will make it even more
> > incomprehensible for simple XHTML uses.
>
> My guess is that the companies represented on the WG want/need a full
> feature
> set. That's where they will make their money in, for example, proprietary
> forms tools, workflow products etc etc. Business forms tools, I guess.

Well, there is a constant tension between people who say they want XForms
simpler, and people who say they want more. The XForms group has attempted
to find a middle path of a sufficiently powerful set that can do the sort of
things that people do nowadays with scripting. We started with a set of
requirements, and did our best to meet those requirements.

> >  (Just trying to make sense of the bubble/capture/target/observer
> > stuff from XML Events is harder than understanding the
> > entirety of HTML forms.)

Aha! But the bubble/capture/target/observer stuff is not from XML Events!
It's all from the DOM; XML Events just describes it to save you the trouble
of having to read the DOM Events spec. And since it's in the DOM, it's also
in HTML 4, but rather than being exposed in markup, you have to do it in
scripting. Even Google's search page (which is in HTML) contains the line
e.cancelBubble=true. So XForms hasn't added any complexity, it is just there
in a different (and I would claim easier to use) and more interoperable
form. Just because you haven't used the bubble/capture stuff in HTML Forms
doesn't mean it's not there. It is.

> > > Is saving / suspend and resume firmly on the agenda
> > > for XForms 2.0?

It is still on the agenda, but what we have concluded is that it is
expressible
as a user-agent property, not an XForms property. That is to say any XForms
user agent can do save-restore now for XForms, without us having to change
XForms. We may add it explicitely in the future depending on the ratio of
people who want us to add more, to people who want us to add less...

Best wishes,

Steven Pemberton

Received on Monday, 5 May 2003 15:27:17 UTC