RE: HTML JSON form data

Let me try again.

Right now, we have two ways of encoding form data, x-urlencoded and multipart/form-data.

It is unlikely that the requirement to implement BOTH encodings, both in browsers and also in web servers.
Sites that expect one or both of those will remain common, so browsers will always need the code to generate.
And browsers that send x-urlencoded or multipart/form-data even when asked for JSON will also take
a long time to go away, so web servers will continue to have to implement decoding of both methods of form data.

Adding a third way of encoding forms for transmission over the internet – no matter how nice
it would have been if we’d done it in the first place – this new way doesn’t decrease the complexity
of the platform.  I know multipart/form-data is verbose but it’s what we have.

As far as developers go – Yes, it would be really nice if you could just call JSON.parse of the HTTP POST
body, instead of some ugly multipart/form-data parser, but no real implementation can get away
from having the parser for the ugly stuff too.


Ø  Can you cite specific technical issues which you believe are higher priority and a rubric for why that's true?

Maybe there’s some idea that later someone might be able to come up with a transition plan where mulitpart/form-data and x-urlencoded will go away, and JSON form data will become universal. and this is a first step on that plan, but even then, most of the issues in the multipart/form-data document STILL need to be resolved, with or without JSON form data; encoding of non-ASCII file names; determining document charset and its effect on form data submission


Ø  complexity isn't already being borne by many in the form of pervasive library code

Complexity of implementations != complexity of platform.

When the interface is complicated, it FORCES the implementations to be complicated.


Ø  “blessing any encoding without describing the mechanism by which it works is anti-extensibility and therefore robs all users of power and generality”

I really don’t know what that means or how it applies here. Can you explain?  I’m not talking about blessing anything, just about fixing what we have.

Larry
--
http://larry.masinter.net


From: Alex Russell [mailto:slightlyoff@google.com]
Sent: Friday, May 30, 2014 3:18 PM
To: Larry Masinter
Cc: www-tag@w3.org; Robin Berjon (robin@w3.org)
Subject: Re: HTML JSON form data

Hi Larry,

Can you cite specific technical issues which you believe are higher priority and a rubric for why that's true? Or can you cite data to suggest that this complexity isn't already being borne by many in the form of pervasive library code (e.g., I know we had a dojo.formToJson() method for nearly identical functionality because it was so commonly requested and Form serialization is welded-shut in the platform).

If anything, it seems the technical argument here should be that blessing any encoding without describing the mechanism by which it works is anti-extensibility and therefore robs all users of power and generality.

Regards
On Fri, May 30, 2014 at 12:06 AM, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>> wrote:
This is a good example of adding new features without paying attention to fixing what’s already there in need of clean up.
The result is an even more complex platform and more unreliability, not less.


From: Larry Masinter
Sent: Thursday, May 29, 2014 11:25 PM
To: 'public-html@w3.org<mailto:public-html@w3.org>'
Subject: Re: Extension specification proposal: JSON form submission

Although form submission in JSON might have been nicer than what we have, I see no prospect of ever getting rid of either x-url-encoded or mulipart/form-data.   Before you put a lot of effort into adding something new that will just add to complexity and implementation burden, could you please give some serious attention to the mulipart/form-data spec?

https://github.com/masinter/multipart-form-data


Including test framework. Review, update, pull requests.

Larry
--
http://larry.masinter.net