Re: separator default for urlencoded-post versus application/x-www-form-urlencoded

Hi Mark,

Getting rid of it altogether would be the best.  It seems hard to believe 
that there would be some expectation of a different separator for a 
urlencoded-post.

There is the concern about getting rid of something in the CR 
(implementation) phase, but it is quite appropriate if we show that there 
is some impediment to implementability, so here it is:

In the replace all submission case, a javascript implementation could 
support the separator only at the cost of relative URIs in the document 
being returned, which by every reasonable definition of the web means it 
is not implementable in practice.  Instead, to keep relative URIs 
resolving, the javascript implementation would reasonably construct a form 
containing inputs for each of the tag/value parameters, then invoke 
submit() on that form.  And, in that case, the separator attribute is not 
implementable because we have no control over what the browser will use 
for a separator.  It uses the ampersand, and we get no choice there.

Hopefully, this will provide sufficient rationale to not just correct the 
default but instead remove the attribute entirely.

Thank you,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
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
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Mark Birbeck <mark.birbeck@webbackplane.com>
To:
Erik Bruchez <ebruchez@orbeon.com>
Cc:
Forms WG <public-forms@w3.org>
Date:
03/01/2009 01:00 PM
Subject:
Re: separator default for urlencoded-post versus 
application/x-www-form-urlencoded



Hi John/Erik,

This is a strange bit of DNA we have in XForms. :)

Not only can the default be changed, but I would argue that we could
even consider getting rid of the @separator attribute altogether.

First, to set the context; yes, as Erik says, it's to do with '&amp;'
in SGML and XML documents. The recommendation to use semi-colons
actually goes back to HTML 4:

  <http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2>

But note that this guidance was issued in relation to using URIs in
attributes. The idea was that if you place a link that contains query
parameters, such as:

  http://host/?x=1&y=2

into an attribute like @href, then because '&' is also used for entity
references, the author would have to do this:

  <a href="http://host/?x=1&amp;y=2">link</a>

Since that's a pain, the HTML 4 recommendation simply says that
servers could support a semi-colon as well, and authors would then be
able to use a much simpler format:

  <a href="http://host/?x=1;y=2">link</a>

But note that HTML 4 *doesn't* say that semi-colons should be used in
preference to the ampersand. And there is no suggestion that
"application/x-www-form-urlencoded" should be changed to use
semi-colons rather than ampersands. And in fact, if you look at the
processing rules for HTML forms in the HTML 4 specification, you'll
see that it's the ampersand that is used, not the semi-colon.

So when it comes to XForms, there was no need to have xf:submission do
anything other than the same as HTML forms. The point was always to
allow a submission to behave the same as an HTML form, so having a
separator that can be set to a variety of values is really of little
use, since we never actually see the ampersand in the mark-up; as with
HTML forms, the encoding for form submission and serialisation happens
behind the scenes.

Of course, there is a parallel with this HTML 4 'proposal' in XForms,
and that is with attributes such as @resource. The recommendation in
HTML 4 can be extrapolated to XForms to say that if a server were to
support semi-colons, then an author could write this:

  <xf:load resource="http://host/?x=1;y=2" />

rather than this:

  <xf:load resource="http://host/?x=1&amp;y=2" />

But as you can see, that has nothing to do with form submission.

It's an odd situation to be in, but it now seems to me that we might
not have actually needed the @separator attribute at all!

Note that some server-side languages allow the separator to be
configured, such as PHP. So you could say that there may be use-cases
where it's useful, and therefore, since we already have it, we might
as well keep it.

That's fair enough, but even then, I don't think there is a problem
with changing the default value to ampersand.

Regards,

Mark

On Sat, Feb 28, 2009 at 6:44 PM, Erik Bruchez <ebruchez@orbeon.com> wrote:
> John,
>
> This has always bothered me. My guess is that this was introduced to 
remove
> the need of escaping "&" to "&amp;" in attributes, but I might be wrong.
>
> There is nothing that prevents a server from using ";" instead of "&" as 
the
> separator for parameters, but the standard today is definitely "&" and 
there
> is no coming back.
>
> I don't know which applications would use the default value of ";" 
specified
> by XForms at the moment. This means that there is probably not a big 
risk in
> changing this default.
>
> -Erik
>
> On Feb 28, 2009, at 10:35 AM, John Boyer wrote:
>
>>
>> The section for form-urlencoded submission [1] indicates that it uses 
the
>> separator character specified by the submission element.
>>
>> [1]
>> 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#serialize-urlencode

>>
>> The default for the separator attribute specified at the beginning of
>> Section 11 [2] is semicolon rather than ampersand.
>>
>> [2]
>> 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#submit-submission-element

>>
>> Why is this?
>>
>> Either the default should be ampersand, or possibly it was meant to be
>> used only on a urlencoded-post?
>>
>> Or possibly the default was meant to be semi-colon for urlencoded-post 
and
>> ampersand otherwise?  For method="get" is there ever a reason to have a
>> separator other than ampersand?
>>
>> This default setting appears ever since the attribute was added way 
back
>> in 2002 [3], but the attribute appeared in the same working draft as 
did the
>> urlencoded-post.
>>
>> [3] http://www.w3.org/TR/2002/WD-xforms-20020821/
>>
>> John M. Boyer, Ph.D.
>> STSM, Interactive Documents and Web 2.0 Applications
>> 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
>> Blog RSS feed:
>> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>>
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)