Subject: [OAUTH-WG] XML Encoding

From: Justin Richer <[email-masked]>
Date: Mon, 27 Sep 2010 15:36:43 -0400

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