Re: 11.5: why submission/@separator?

The example is wrong -- it's a separator, not a terminator.  Thank you.

We originally proposed having only ";" and not having an option, but
comments on a previous draft pointed out (and research confirmed) that
many current web servers do not in fact support ";" as a separator.

For example, try this link:
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Xforms+implementations%22
and now try this link:
http://www.google.com/search?hl=en;ie=UTF-8;oe=UTF-8;q=%22Xforms+implementations%22

Since we have a requirement to support legacy formats, and since it
appears that "&" is required for interoperability, we added the option
for force its use.

Leigh.

On Thu, 2002-09-05 at 07:03, Joe Schaefer wrote:
> 
> Looking at section 11.5 of the current draft, I get the 
> impression that the separator character for the 
> application/x-www-form-urlencoded serialization is under
> the control of the form author.
> 
> How much freedom does the author have in the choice of 
> separator?  Is it restricted to either "&" or ";", or can 
> it be chosen arbitrarily?  Section 3.3.3 indicates that
> the default is ";", but doesn't indicate any other 
> restrictions.
> 
> What concerns me is that a server-side parser might have
> "trouble" figuring out the separator from the form submission
> data.  For HTTP POST data, it's possible for the client to include
> the separator within the Content-type header (just as the 
> multipart/form-data encoding would).  However, this header isn't 
> available for an HTTP GET.
> 
> IMO, leaving the choice of separator up to the forms author
> is a mistake.  Most common "legacy" parsers already know
> how to handle "&" and ";" as separators; I can't think of
> any good reason why someone would need to use a different
> character.
> 
> btw- "separator" is probably a misnomer here, since the 
> draft's description (e.g. 11.5) indicates the character is 
> being used as a "terminator".
> 
> -- 
> Joe Schaefer

Received on Thursday, 5 September 2002 13:36:18 UTC