[occi-wg] JSON Rendering proposal, rev 2

[Ralf Nyren]

On Wed, 29 Feb 2012 18:32:18 +0100, Gary Mazz <garymazzaferro at gmail.com>  
wrote:

> Based on the traditional nature of the http client/server protocol,  
> saying the media type is json should be sufficient. If at some time in  
> the future, request queuing on a connection is supported, depending on  
> method implemented it should be revisited.

Not convinced. Let's say I want to write a nice litte firefox plugin which  
can render OCCI JSON formats nicely. If the media-type does not tell that  
the content is OCCI-json and not some arbitrary json, such a plugin would  
be hard to get working.

The JSON rendering is exposed over HTTP. Any HTTP client is able to issue  
valid requests. If the payload returned is marked as "occi-stuff" it is  
much easier to have support in a wider range of clients.

Whether to have just application/occi+json or multiple media-types for  
json is a different topic though.

>> What to call the category identifier? I used "rel" now based on the  
>> HTTP way of doing things. Any better naming suggestions, "type" ? [1]
>
> A little perspective on 'rel'. This is an artifact based on the HTML5  
> and RDFa rendering that haven't yet matured.  I would suggest we keep  
> the 'rel' in case the there is a huge shift to semantic  approaches for  
> cloud computing.

Sure, keep "rel" then. Other thoughts, someone?

>> I guess we could put the "next" link in a Link header and actually use  
>> RFC5988 as it was meant to be used (as opposed to how we abused it in  
>> text/occi rendering). We have to verify if browsers would choke on this  
>> though and it makes life a bit harder for JavaScript implementations  
>> which would need to parse the Link headers. Other ideas?
>>
> This is a query capability and should not be part of any portion of the  
> format or http protocol.

Where to put it then? The whole point of the "marker" concept is to return  
a link to the next "page" in the response. That link has to go somewhere...

> I think there is some confusion about document structure and  
> presentation with the occi model. Granted, this has been clearly vetted  
> withing the group.  We should keep this discussion in terms of a query.  
> The "marker" as suggested is essentially acting as an arbitrary index or  
> iteration context in application.  We should be clear on the use cases  
> and whether the "marker/iterator'  applies to occi entities, json  
> entities and payload size. There are very separate concerns that seem to  
> be getting integrated as some levels.

The marker applies to resource instances (Entity sub-type instances ;) but  
on a HTTP protocol level. Makes sense?

/Ralf