Totally non-conformant JSON hack

Fscking JSON. Sigh.

As more and more APIs move from XML to JSON, I think we need to make
sure that the XML technology stack evolves so that we can easily
interact with those services.

The medium/long-term solution to this problem, I think, is to amend
the XML data model (as the XSLT WG is doing for the XSLT 3.0 (and the
XQuery WG *is not* doing for XQuery 3.0, sigh.)) so that JSON data can
be encoded directly. (The XSLT WG is adding the notion of "maps" to
the data model.)

In the short term, I've added a experimental "transparent-json"
extension to XML Calabash.

If transparent-json is true:

1. Any application/json data returned from p:http-request is
automatically converted to XML. (Using the same (conformant)
conversion that I introduced in p:unescape-markup[*] a while back.)

2. Any data sent by p:http-request that has a content-type of
application/json is encoded as JSON text before transmission.

3. If application/json data (or a document with a c:json root element)
is sent to p:store, it's written out as JSON text.

4. If a p:document element fails to load XML, XML Calabash tries to
parse the data as JSON and returns an XML representation of that if it
succeeds. (This is the worst part of the hack, but it's hard to tell
what the MIME type of a random file is.)

I have very mixed feelings about this sort of hack. As a standards
guy, it's clearly a violation of the spec and a source of
interoperability failures. As a user who's bloody frustrated by the
state of web APIs, it just quietly makes my life easier and better.

Comments, suggestions, flames, demands for my immediate resignation,
all most humbly accepted.

                                        Be seeing you,
                                          norm

[*] I moved the <json> element and its children into the c: namespace.
Sorry if that trips you up. My bad.

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com