Re: XForms - "Suspend and resume support"

In a message dated 05/05/2003 20:28:08 GMT Daylight Time, 
steven.pemberton@cwi.nl writes:


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

Steven,

I think there is a level of usage of HTML forms that you are simply ignoring 
here. As I pointed out later in my post I agree that there is a case to be 
made that XForms may not be more complex than equivalent functionality 
produced by HTML and JavaScript.

I like XForms because of how it effectively uses declarative programming. But 
I don't underestimate how that can cause difficulty for non-XML-geeks. I have 
seen similar difficulties with SVG where people coming from JavaScript 
backgrounds just don't "get" SVG's declarative animation.

It seems to me to undermine your argument when you ignore the fact that many 
non-enterprise HTML forms users are much less ambitious. For them XForms is a 
substantive step up in complexity, if they choose to even attempt it.

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

The talk I was referring to was:

http://www.w3.org/2003/Talks/tp-steven-web/

The slide HTML document (in 2010) stuck in my mind. It is that kind of 
complexity that poses a real problem. It isn't, at least as I use the term 
usability, a usability problem but a complexity problem.

 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.

But many HTML forms users don't know either XPath or W3C XML Schema. For them 
XForms (at least when hand coded) is a major step up in complexity.

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

The fact that something is reusable doesn't make it less complex to learn.

> 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 I was starting from scratch today (which I am not) I would rather invest 
the time in learning XML technologies. The HTML/JavaScript coder also is not 
starting from scratch but for him/her the XML technologies learning curve is 
fairly intimidating.

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

I think "barely more complex" is a highly rose-tinted viewpoint.

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

Although we disagree (frequently?) on specifics I am happy to put on record 
that XForms is a very interesting and important technology.

We started with a set of
> requirements, and did our best to meet those requirements.
> 
<grin/> It's probably best if we don't go there, just now.


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

Sure. But if an HTML forms coder doesn't use those aspects then feels forced 
in XForms to use them, then from that coder's perspective XForms *is* more 
complex. Before they could produce a working form, with XForms it will take 
them some time to get up to speed.

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

I think that is a very sensible suggestion / conclusion. I will be interested 
to see how that is expressed in the PR.

Interestingly, it's what InfoPath does. The InfoPath client can Save a form 
and as a separate process submit a form.

 That is to say any XForms
> user agent can do save-restore now for XForms, without us having to change
> XForms.

I think you mean *may* do a save-restore. At present X-Smiles can't do it, 
although I gather a new build will be released in the next few days and that 
may change.


 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...
> 
Perhaps there will be a way to allow both approaches to be supported.

Andrew Watt