Re: [xri] XRD and JSON

[Will Norris <willnorris@google.com>]

you either have:

  1) a no-brainer method of switching between XML and JSON like JsonML, and then have to do some work to get the JSON into the right logical object, or

  2) a no-brainer JSON format that can be used as-is, and you have to do a little work to switch between the XML and JSON formats

It's just a matter of which one you want to optimize for.

Signatures are of course an issue, and I don't really have an answer for that.  The immediate use-case we're looking at wouldn't necessarily need signatures, though.

-will

On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <jbradley@mac.com> wrote:

I am still trying to understand the use case.

Having multiple discovery formats each requiring separate processing is not optimal.

Being able to transform from one to the other may have advantages.

I am speculating that the Google wants a discovery format that can be entirely parsed with JS inside the browser.

I am not personally religious about XML. 

If a JSON  format that can be transformed into the equivalent XML XRD can be specified that may be a useful work product for the TC.

My main concerns are around signatures if this starts being used on the server as well as in the browser.

The Google seems to have decided this week that going outside the existing standards development process is more efficient.

I would prefer that this not result in competing discovery standards.

It is worth discussing, but at the end of the day Google may need to do what it needs to do.

John B.

On 2010-04-22, at 3:04 PM, Will Norris wrote:

On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <cantor.2@osu.edu> wrote:

> 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.

I think the document is the natural representation. A simple layer of code
addresses whatever limitations might exist in the language that's purporting
to be too difficult to use the document in.

But as a matter of specification, the problem you have is that, like SAML,
there's an explicit characterization of the notion of an XRD as being XML.
If it's not XML, it's not an XRD. I have not seen a simple way around that.

A separate specification can be created to establish an interchange format
in some other encoding with a different label attached to it, but if the
goal here was to allow for non-XML representations of an XRD, it would
require some fairly big changes that I'm pretty comfortable saying nobody
wants to take on.

certainly, I wasn't meaning to suggest a departure of any kind from how XRD is defined today.  I've been quite upfront from the beginning of my involvement with this TC that I view XRD (as it's specified) solely as an XML format, and if you want something else, then do it yourself.  Well, now Google is sort of doing it ourselves, and we figured that if others end up wanting to do the same, it might be good to have agreement on what that JSON format looks like.  That could just be a whitepaper, a best practice guide, or whatever.  It certainly doesn't have to be a product of this TC, I just thought I would see if it was anything folks had any interest in it.

-will