Re: HTML JSON form data

I think I agree with much of Larry's analysis but not his conclusion.

Yes: having multiple encoding standards for the same function in the system 
results in additional platform code, complexity, testing burden, etc. 
However, as Larry says:

 > As far as developers go – Yes, it would be really nice if you could just
 > call JSON.parse of the HTTP POST

Indeed. And that may result in simplification of client- and/or server-code 
for a very large number of applications. There's a lot of JSON data 
floating around and being able to send/receive it without conversion is in 
many cases a significant simplification. This is arguably a significant net 
benefit even if there is some regrettable duplication of function in the 
middleware layers.

Noah

On 6/1/2014 4:41 PM, Larry Masinter wrote:
> 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
>

Received on Monday, 2 June 2014 14:55:29 UTC