XForms and RESTful Web Services

There was one thing missing from XForms 1.0 that would have made all the difference when trying to access RESTful Web Services - the ability to control HTTP headers when making instance data requests and submissions. What compounded the problem was that many of the implementations either inappropriately (in my opinion) set the HTTP Accept header to */* or just adopted the string used by the host browser. This made it nigh-on impossible to request, in a RESTful fashion, an XML representation of the resource you wish to edit, i.e. opaque URLs and server-side content negotiation.

In the XForms 1.1 Candidate Recommendation however, there is a section that doesn't exactly give away its importance. That section is 11.8 The header Element and the significance of the xf:header element, along with its attributes and children, is that it gives you the power to control the HTTP headers of your submission requests.

Now If you are at all familiar with the work of the W3C Forms Working Group you won't be surprised to discover that it doesn't stop with just setting the HTTP headers. They have thought about how you set them and had the foresight to provide optional attributes that take an XPath expression, thereby allowing you to set headers and their values based upon instance data. Is that cool or what?

I have not checked-out any of the server-side XForms implementations but as for browser plug-ins; FormsPlayer already supports this, the Mozilla XForms plug-in will support it in the next release (you can try it out now with the nightly builds) and as for PicoForms their online forum is unavailable so I don't know where they are at.

Now, browsers and their plug-ins being what they are, there are differences between implementations.

<xf:submission action="../concepts" encoding="utf-8" 
        id="loadConcepts" 
        ref="instance('conceptsList')"
        method="get" 
        replace="instance">
    <xf:header>
        <xf:name>Accept</xf:name>
        <xf:value>application/sparql-results+xml</xf:value>
    </xf:header>
</xf:submission>

In the above example, the submission request uses the xf:header element to set the value of the HTTP Accept header to application/sparql-results+xml. In the case of FormsPlayer, that results in Internet Explorer's default Accept header being overwritten. On the other hand the Mozilla plug-in takes the stance that the Accept header allows multiple values and therefore appends the new value to the end of the header.

For me, I'd have expected the former but can also understand the logic of the latter. However, you could look at it this way, an XForms binding instruction will, likely as not, be defined for one particular representation therefore, saying you'll accept more than one representation doesn't seem very practical in this context. This might lead you to conclude that the overwrite behavior is appropriate. But, there is a twist. When you set replace="all" in an xf:submission, the response will replace the entire page (conventional web forms stylie) thereby returning control to the parent browser. In this case you may wish to open-up the response to a range of media-types thus making the append behavior desirable.

Aaron Reed, a developer heavily involved with the Mozilla XForms project, and I chewed this one over on the www-forms@w3.org e-mail list and I now agree with him that the append strategy is the most sensible of the two. He goes further and suggests that an additional attribute allowing the choice of replace or append would cover the scenarios described above. We'll have to see what the W3C Forms Working Group come up with.