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

Hi,

I have nothing against changing the default, but removing the separator attribute from XForms because some implementation(s) can't implement it, that isn't the right approach in my opinion. There are other features in the spec that for example Chiba can't implement but it wouldn't be correct to drop those too, in my opinion.

Regards,

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com<mailto:Nick_Van_den_Bleeken@inventivegroup.com>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: maandag 2 maart 2009 5:16
To: Mark Birbeck
Cc: Erik Bruchez; Forms WG
Subject: 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<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)



--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--