This post originated from an RSS feed registered with Java Buzz by Bill de hÓra. Original Post: HTML5 obs Feed Title: Bill de hÓra Feed URL: http://www.dehora.net/journal/atom.xml Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8 Latest Java Buzz Posts Latest Java Buzz Posts by Bill de hÓra Latest Posts From Bill de hÓra

As for all this debate about platforms - that's what markets are for. Platforms are market makers. Standards are different - they're forcing functions for markets. not market makers. Let's look at some HTML5 spec text for forms instead.

From the draft on extended form controls:

"The HTTP specification defines various methods that can be used with HTTP URIs. Four of these may be used as values of the method attribute: get, post, put, and delete. In this specification, these method names are applied to other protocols as well. This section defines how they should be interpreted."

The enormity of the consequences of HTML only allowing GET and POST cannot be overstated IMO.  It's maybe the most damaging technical decision in the web standards space - ever.  I see HTML forms as a root cause for the WS-* "everything goes over POST" debacle, a billion dollar industry mistake, at best.

What it gets wrong:

"If the specified method is not one of get, post, put, or delete then it is treated as get in the tables below."

Fail, on two counts. First a markup format that has impliciit defaults, ie, acquires values through the absence of specific markup tends to suck - example, I spent a few hours this week trying to figure out whether OpenSearch is compatible with RFC5005 - I'm not 100% sure but I suspect not - and it's because of impliciit markup. Specs in markup of the form "when the X is not present, assume a Y with value Z" are an antipattern. I have no idea how much time  I've spent dealing with ill-advised attempts at acquisition semantics in XML, (aka "default values"), or in the Atom case, trying to argue them out over the years. But I think, a lot.  Second, just allow the uniform interface and move on. Subsetting a uniform interface is - silly. I remember the Atompub WG seriously consider not using PUT and DELETE because lots of deployed infrastructure didn't support them. As of 2008, I still have to recommend X-HTTTP-MethodOverride as an option for protocols. Forms are not a special case of the Web's interface, imvho. Yes, I'm saying OPTIONS and MKCOL are valid values for the method attribute.

What would be nice - some text on server side validation. What happenss today is that  servers often send back 200 Ok with validation errors. Server side validation is so common, I'd expect the 200 "Ok, but invalid" issue could get a mention. But maybe I missed it. Anyway, since the request was not ok, the 422 (Unprocessable Entity) would be a viable option for a failed validation.