I've got XML-based protocols here that we want to protect with OAuth, and so having to deal with a JSON blob is less than optimal for us. Ages ago, we decided to make JSON be the One True Encoding for the core spec, and I commented that I was fine with that if we had a way to represent things in other encodings in an appropriate way.
In spite of the recent flurry of activity over signatures, I want to dust this one off. There are a few ways one can translate JSON to XML or vice versa; over the weekend, I came across this interesting article: http://answers.oreilly.com/topic/279-how-to-convert-json-to-xml-in-java/ And while it doesn't seem to have any specification guiding it (that I could find), it does have what I consider to be a reasonable way to represent the JSON objects as XML documents using a few simple rules that I could distill from this software's behavior. This is all pretty close to what I was thinking of proposing anyway, but if there's an existing spec/draft out there for this, someone please point me to it. 0) No namespacing (as in JSON) 1) All objects are element nodes at the root of a tree or subtree 2) All members of an object are sub-element nodes of the object element, with the name of the member as the node name 3) Strings and numbers values are encoded as CDATA within a an element 4) Members have an optional "type" attribute to help differentiate strings and numbers 5) Lists are represented by repeated elements with the list name, as available, with each member of the list as one repeated instance and list order being preserved by document order There are a couple things missing to make it really useful for us. First, "default" naming scheme for anonymous objects and lists as allowed by JSON. In particular, the root node needs a name, though we could easily use "oauth" here and call it a day. If extensions start making use of list and object parameter values, then we get into trouble. So far, we haven't really seen anyone doing that yet. Second, having some kind of "implied namespace" at the root would be helpful in letting this XML blob play along nicely with other XML blobs -- but I'm certainly happy to punt on that issue. If there's interest in this, and it hasn't already been covered in another draft we can just profile, I'm willing to start work on a draft myself here and present it to the WG as an item. I'm also looking for any co-conspirators who are crufty enough to still be using XML. -- Justin _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
