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


I don't have a very strong opinion on this. We could go both ways.

On one hand, if we can be compatible with HTML, sure, why not be 
compatible. And agreed, name/value pairs are here to stay. If anything 
they are likely to outlast SOAP.

On the other hand, <xforms:submission> is not the HTML <form> element, 
and you will have to learn <xforms:submission> anyway. The day we 
specify an HTML-compatible <form> element, then we can specify the 
default too. Also, I rarely see people not using the @method attribute 
in HTML forms and relying on the default. This tells me there is not 
that a strong case for compatibility or even for using a default value 
at all, especially if the default is not very intuitive. I usually 
prefer explicit to implicit.

The bottom line is that I would rather lean towards "no default", but if 
the rest of the WG leans the other way I won't object.


John Boyer wrote:
> 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:  
> Blog:
> *"Mark Birbeck" <>*
> Sent by:
> 10/10/2007 01:20 AM
> To
> 	John Boyer/CanWest/IBM@IBMCA
> cc
>, "Forms WG" <>, 
> 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
> | +44 (0) 20 7689 9232
> <> | 
> <>
>  standards. innovation.

Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Wednesday, 10 October 2007 21:24:20 UTC