Re: [xri] XRD and JSON

[Will Norris <willnorris@google.com>]

JsonML does a far better job than some other similar utilities I've seen, so that is certainly nice.  And for it's stated goals of providing a compact format for transporting XML, it works great.  But that kind of misses the point of using JSON, which is to provide an natural representation of the object, not just a document.  For example, I tried using JsonML on the XRD for my Gmail account, and it provided a "dumb" interpretation of the content... that is, a simple list of the elements:

[ "Subject", "acct:wnorris@gmail.com" ],

[ "Alias", "http://www.google.com/profiles/wnorris" ],

[ "Link", { "href": "...", "rel": "..." } ],

[ "Link", { "href": "...", "rel": "..." } ]

and so on.  In order to do anything useful with this, you still need to map it into your logical object.  What Google is looking for is a format that already resembles the logical object....

{

  "Subject": "acct:wnorris@gmail.com",

  "Aliases": [ "http://www.google.com/profiles/wnorris" ]

  "Links": [

      { "href": "...", "rel": "..." },

      { "href": "...", "rel": "..." },

  ]

}

or something similar to that.... I don't remember the exact model Joseph and I came up with.  I think that most consumers of this data will likely lean toward one format or the other, but probably not a mix of both.  While being able to perform a lossless transform between the two is nice in theory, I'm not sure how realistic the need is.

As for XAuth, I'm not as close to that as some others here... I only found out about it a week or so before it launched, so I haven't had the chance to fully think through what it means in terms of XRD and service discovery in general.  But yes I believe you could treat some of the data as opaque, and leave it for the consumers to interpret.  But one of the goals it to keep it relatively lightweight, so as to give consumers very quick and easy access to the providers of some particular service for the user.  It's effectively an XRD for the user that lives in the browser, instead of at some endpoint.  And because all of this is being done with javascript, a good JSON model is a big desire.

-will

On Wed, Apr 21, 2010 at 5:06 PM, John Bradley <jbradley@mac.com> wrote:

I prefer something like this that could do a loss less transform.

Publishing the XLST and related information for using a jasonML representation of XRD should be a separate doc.

I am not excited about having a separate jason spec for XRD.

Given that XAuth tokens are opaque?  Is there a reason for transforming them to jason?

One would hope that a RP could use the same XRD processing no matter how it receives the XRD.

Can you explain the Google use case?

John B.

On 2010-04-21, at 7:47 PM, Scott Cantor wrote:

>> As Joseph mentioned in his email to the xri-comment list, Google is
>> wanting a JSON representation for XRD, at least initially for use with
>> XAuth[1].  He and I came up with something last week that is actually
>> pretty decent.  The next question though is, is this anything that this
>> TC cares to address?  If so, what form would it take?  An appendix to
>> the existing spec, a separate specification, something else?  If the TC
>> is not interested, then Google will probably just publish something
>> separately, but I wanted to check here first.
>

> I found a transform that's lossless in converting between typical XML and
> JSON that strikes me as a hell of a lot more effective than constantly
> reinventing the wheel on every XML grammar.
>
> http://jsonml.org/XML/
>

>> (Of course signing is a big problem for any JSON document, but that's a
>> separate issue altogether)
>

> My initial impressions were that the transform to JSON and back is
> potentially signature-safe, which was impressive.
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>