PROPOPED RESOLUTION, was Re: Quick proposal: method="get" be default on submission element

Hmm. That's quite convincing to me, Mark.

Does anyone object to a resolution to set the submission method default to 
"get"?

Please respond with objections by Friday, Oct. 12, 2007, 11:59PM in your 
timezone.

If no objections, it'll be resolved and done; if any objections, then 
we'll discuss on next week's telecon.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Mark Birbeck" <mark.birbeck@formsPlayer.com> 
Sent by: public-forms-request@w3.org
10/10/2007 01:20 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
ebruchez@orbeon.com, "Forms WG" <public-forms@w3.org>, 
public-forms-request@w3.org
Subject
Re: Quick proposal: method="get" be default on submission element







Hi John,

Obviously there is no right or wrong here, since we're expressing
opinions. But...

> I tend to prefer language design in which the default expresses what 
people
> are most likely to do, rather than a default imposed by historical 
precedent...

You could just as well argue that the most useful default values are
actually those that would be used by new authors. Advanced users are
not going to be overly worried about having to write @method="post",
or whatever. But a new author coming from HTML might find carefully
chosen default values a useful way of getting up to speed.

So the notion of "what people are most likely to do" would depend on
who these "people" are.


> ...particularly when the historical precedent imposes exactly the mess 
we were
> trying to get out of with the new language (flat tag-value pair data 
structures, in
> this case).

I just booked some flights and bought some books using this historical
mess, so even if a little untidy, it has its uses. :)

But more broadly I think we need to be wary of trying to tidy
everything up so that it fits into our world view. XForms solves lots
of problems, such as having a mark-up language to define forms, and
being able to handle XML natively. But we don't have to also insist
that everyone changes their server-side processing to use XML. XForms
allows us to manipulate XML (i.e., not name/value pairs) but still
send the information as a GET request (perhaps with name/value pairs),
which to me is an ideal solution.

This is even more important given the success of RESTful approaches
and the niche use of SOAP; GET is not going away any time soon.


> It seems reasonable to say that submission with an expressed 
method="get" still
> lets us talk to legacy non-XML systems.

With respect, we do have to be wary of everything looking like a nail
when carrying a hammer. :) Why is a non-XML system a 'legacy' system?
Early versions of the XForms spec made the mistake of trying to
deprecate GET, which was luckily removed. But even then the spec
didn't feature DELETE, which now has luckily been added. We could have
avoided both glaring omissions if we had been looking more closely at
what it is that people are doing *now* with web architecture, and then
looked at where XForms could fit into that broader architecture.


> Even in the light of syntactic softening we want for XForms 1.2, it does 
not
> seem to be a big problem.  An unexpressed XForms submission implied by
> an HTML form would have an expressed method="get" because that is the
> HTML default.  It is no different than saying the HTML form tag's action 
attribute
> implies a resource attribute on submission (because the action attribute 
of
> submission is deprecated).

It's true, that could be done.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.