RE: [xri] XRD and JSON

Adding it to the XRD spec is not an option, normative or not. The spec is done.

If you or your employ thinks there is value in interop using a JSON flavor, you should write a spec and pick the best avenue to publish, seek feedback, and finalize. This can be another TC draft (though the overhead vs. benefit is very low), an IETF individual I-D published as informational RFC, or just a spec published on a wiki.

The only important part is making sure you seek wide feedback. After that it’s all silliness.

EHL

From: Will Norris [mailto:willnorris@google.com]
Sent: Thursday, April 22, 2010 12:04 PM
To: Scott Cantor
Cc: John Bradley; XRI TC
Subject: Re: [xri] XRD and JSON

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

xri message