Some interesting pointers in the post above about what XForms 1.1 might look like. The idea of XForms that speak ATOM has to open up some interesting possibities around document change, syndication, notification and lightweight workflow.
Is a complete standards-based stack emerging for lightweight document flows? Are the docheads going to get their revenge over the RPC uber alles community? Why glue everything together with WS-* Web Services?
I freely admit I am not quite sure what the implications of XForms 1.1 are yet, but I will dig in as its ratified and keep you posted. Hey community – can you spare an insight, or a link of explanation?
My only nudge-the idea of allowing XForms processors to ignore some headers is a good idea. The web is always more powerful when its a bit sloppy.
Here, then, are excerpts from John Boyer’s intriguing post:
* We’re adding context information to the xforms-submit-done event so that an XForm can access the http return code.
* We’re adding support for the DELETE method, which is more reasonable can be done now that the return code will be available. One practical result of this is that you will be able to write an XForms that speaks ATOM.
* We’re allowing run-time modification of the submission URL. We’ll be adding a child element called resource to the submission element, and it will be able to use a single-node binding or value attribute to construct a URL that includes data from an XForms instance.
* We’re allowing the ability to set content headers for the submission so that, among other things, an XForm can speak WebDAV. We’ll be adding a child element called header that will take a name attribute as well as single-node binding, value attribute, or content for the value of the header. You will be able to put as many headers as you want. The main detail to be fleshed out is out to say that user agents/XForms processors may choose to ignore some of the header settings.