XForms and RESTful Web Services

By Philip Fennell
August 19, 2008 | Comments: 3

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" 

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.

You might also be interested in:



FWIW Orbeon Forms has some support for the xforms:header element. And the Working Group is currently discussion the issue of the Accept header.



That's two pieces of good news, thanks.



I brought your concerns about xf:header from the Mozilla dev-tech-xforms list to the Forms Working Group, and, and we spent some time discussing it.

You're make a number of valid points in your posting:

  • The feature is currently underspecified, leading to non-interoperable beahvior

  • What works for HTTP submission/@replace='instance' doesn't work great for HTTP submission/@replace='all' and vice versa.

  • The restful services use case requires not only header setting (RFC 5023 APP, for example) but also finer-grained author control of content negotiation.

  • Form authors should have enough control to do what they need done, but the user agent should also have enough control to do what the author expects it to.

    We can fix the underspecification issue if we know which behavior is right, and if we simply move the responsibility of header serialization to the HTTP section of the submission documentation (where we can also note how HTTP RFC 2616 serializes multiple values with the same name). This change would not be a substantial change or feature addition, and would not slow down the progress of the XForms 1.1 Candidate Recommendation document.

    However, as you and Aaron Reed point out, we can't make the feature meet its design goals without expecting the host processor to know the differenence between replace='instance' vs. replace='all' and without some magic surrounding particular headers, such as Accept.

    Therefore, the Forms Working Group has reluctantly come the conclusion that we need to re-design the header feature. Thus, the result of our Candidate Recommendation feedback from implementors is that we need a change. Unfortunately, this may affect the timing of the next phase of Proposed Recommendation, because of steps that must be followed in the W3C process, but we're convinced its worth it.

    The simplest proposal we have is the following:

    • Define header ordering as
      1. Document order of xf:header elements
      2. Order of nodes in the each individual xf:header/@ref result (noting that XPath 1.0 does not guarantee order when union operations are present)
      3. Docuement Order of value elements within each xf:header

    • Let the submission protocol serialization (HTTP in this case) decide how to combine multiple headers, with the order of headers defined as above. If header values or names cannot be serialized (perhaps due to unquotable characters in the value or inexpressible names in the key), then serialization will get an exception

    • Change xf:header to add an attribute controlling replace vs. append behavior. Possible choices: replace="true|false", append="true|false", combine="replace|append". Decide whether this behavior controls only the pre-existing header values, or whether it also applies to multiple value garnered during form processing.

    • Note in the submission section that processors are not required to combine specified values with pre-existing or known-but-unset fields if doing so would be a security problem. Decide whether this should signal an error or not.

      I invite you and others who are interested in this issue to come back to www-forms with some ideas this week on whether these measures are sufficient to answer the use case, implementation, and author viewpoint concerns. Please weigh in on the options, or provide others if these aren't right.


      Popular Topics


      Or, visit our complete archives.

      Recommended for You

      Got a Question?