RE: Badgerfish Specification


Thank you for the link and the contact.

Here's some background on why we asked:

XForms 1.1 provides an XML element "submission" which allows for specifying in a declarative way the selection and validation of an XML instance and subsequently serialization through a protocol to a resource, followed by the inverse steps for any received response.  Submission itself is mediated by DOM events (submit, submit-done, serialiation, etc.)  One common use case is the selection of all nodes in the instance document and serialization as XML through HTTP POST, followed by replacement of the entire document with an HTML reply. Another is serialization as parameters in an HTTP GET, followed by replacement of a second instance with the XML response.

Here's what we'd like to do for XForms 1.2:

We'd like to add JSON serialization and response parsing to the facilities that XForms submission offers. The internal data model would remain an XML instance,. which in XForms is an XPath data model, not necessarily a DOM.  We realize there are other use cases for  JSON, such as the use of Javascript notation by form authors for navigational access expressions, but we consider that functionality orthogonal to this current task.  

The primary goal of this task is to enable XForms submission to work with existing web resources which accept or produce JSON, and to enable it to be losslessly stored in the XForms data model. We believe it's necessary to specify which JSON to XML mapping to use.  One of the proposals we are examining calls for the use of a well-known name to express which serialization convention.  Your Badgerfish is an obvious candidate, and there are others which serve different needs.  

Here's one way we're thinking of specifying which convention is in use:

A pair of attributes for serialization deserialization, whose values are XML QNames (or CURIES), something like this:

... xmlns:sklar="" ...
<submission method="get" resource="" deserialiation="sklar:badgerfish"

We might also consider it a success if this mechanism let implementations provide to authors serialization in YAML, Pyx, and other lossless or partially lossless formats.  (We're also considering offering, as en escape hatch for JSON, a conversion to/from one of the verbose 100% lossless formats, followed by an author-specified XSLT transformation, which would in principle allow any convention to be used, though laboriously.)
In addition to publishing the serialization and deserialization attributes for our own xf:submission element, we're also considering publishing a W3C Note or possibly Working Draft listing some of the canonical serialization formats which we'd ask XForms implementations to support, and possibly describing them in a normative way if a standard reference cannot be found.  

We'd be interested in any comments you have on this approach, or suggestions for taxonomies other than those already easily found on the web.
Please feel free to respond directly, or to contact me or Charlie Wiecha (who is currently exploring this area).  

Thank you,

-----Original Message-----
From: David Sklar [] 
Sent: Friday, March 26, 2010 9:21 AM
To: Klotz, Leigh
Subject: Re: Badgerfish Specification

Hi, Leigh and Forms Working group. You can find the Badgerfish JSON convention at the following URL now:



On 3/26/10 7:36 AM, Leigh L. Klotz, Jr. wrote:
> Dear Mr. Sklar,
> I'm writing you on behalf of the W3C Forms Working group, to ask if 
> you have a new location for your Badgerfish JSON convention which used 
> to be at
> Thank you,
> Leigh Klotz
> Forms Working Group co-chair

Received on Tuesday, 30 March 2010 16:15:23 UTC