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 '&'
in SGML and XML documents. The recommendation to use semi-colons
actually goes back to HTML 4:


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:


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.



On Sat, Feb 28, 2009 at 6:44 PM, Erik Bruchez <> 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]
>> The default for the separator attribute specified at the beginning of
>> Section 11 [2] is semicolon rather than ampersand.
>> [2]
>> 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]
>> 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:
>> Blog:
>> Blog RSS feed:
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Mark Birbeck, webBackplane

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

Received on Sunday, 1 March 2009 20:59:42 UTC