Subject: Re: [Json] [apps-discuss] proposal: adding profile support to JSON

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 6 Nov 2013 16:41:02 +0100

On Wednesday, November 06, 2013 3:21 PM, Mark Baker wrote:
> We agree that a document containing some OPDS extensions is still an
> Atom document that can be delivered as application/atom+xml, I
> believe. You appear to suggest that there's value in exposing the
> existence of those OPDS extensions using an additional external
> metadata protocol element. I believe that this is at best an
> optimization, since the consumer can easily detect the existence of
> the extension by inspecting the content (and understanding the
> extensibility model of the host format). But at worst, it's a recipe
> for interop problems; does the meaning of the document change if the
> profile is declared vs not? What if the v2 profile URI is declared and
> the document contains a v1 extension? etc..

As you say, in XML you can leverage namespacing to create fully
self-descriptive messages without requiring another media type. In this
thread, however, we are talking about JSON which doesn't support
namespacing. So, how would you (or any of the numerous JSON APIs out there)
signal the semantics of such "extensions" in a JSON document without minting
a new media type?

--
Markus Lanthaler
@markuslanthaler

---

From: Erik Wilde <[email-masked]>
Date: Wed, 06 Nov 2013 10:51:17 -0800

hello markus.

thanks for the feedback.

> signal the semantics of such "extensions" in a JSON document without minting

i think there are several ways in which you can do this. if your JSON 
format supports generic linking somehow somewhere in the format, then 
you can simply add a "profile" link. if it doesn't, you might have a 
specific profile identifier in the format, similar to HTML's 
head/@profile. but that's of course assuming you already *have* some 
processing model in place that's used for the representation, so we 
might have a chicken-and-egg problem here.

maybe that points to the fact that in practice, profiles make more sense 
on more meaningful media types (such as adding profiles to Atom or HTML 
that signify certain ways of how these formats are constrained), and 
less so on very generic ones. on the other hand, I-JSON may be a good 
example for how even something as generic as plain JSON might benefit 
from profiles being exposable on the media type level.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 6 Nov 2013 20:10:40 +0100

> format supports generic linking somehow somewhere in the format, then

I was specifically talking about application/json.

> might have a chicken-and-egg problem here.

Right, to signal it you could use a HTTP Link header, but that wouldn't work for conneg.

> from profiles being exposable on the media type level.

I think quite the contrary is the case. IMO generic media types such as JSON or vanilla XML are the ones benefitting most of this.

--
Markus Lanthaler
@markuslanthaler