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

All,

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.

-Erik

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: 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://www.formsplayer.com/> | 
> http://internet-apps.blogspot.com <http://internet-apps.blogspot.com/>
> 
>  standards. innovation.
> 
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

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