[occi-wg] JSON Rendering proposal, rev 2

Thu Mar 1 08:52:08 EST 2012

Hi Gary, Ralf,

Am 29.02.2012 um 18:32 schrieb Gary Mazz:

> On 2/29/2012 4:11 AM, Ralf Nyren wrote:
>> On Wed, 29 Feb 2012 09:36:50 +0100, <alexander.papaspyrou at tu-dortmund.de> wrote:
>> 
>>> Besides that, there is no reason forcing to use JSON over HTTP, if they don't want to: replacing the "href" by an URI (and maybe renaming it to "location" would allow for broader use of the JSON data rendering; and everything else is pretty agnostic of HTTP and friends.
>> 
>> Ok, renaming "href" back to "uri" then. Good proof you actually read the details :D
>> (mind-note to add other small obscure changes in next rev just to see if people notice...)
>> 
>> 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.

Yup, agreed. That's also what RFC5988 uses.

> 
>> 
>>> And btw.: HTTP gives us all we need to do the protocol part; the RESTfulness lies in there, anyway. Therefore, the interaction part should be described there, agnostic of the content-type (after all, that's what HTTP is about). That way, people could implement the HTTP protocol rendering once, and reuse it for several OCCI data renderings.
>> 
>> Agreed on that. Support my proposal on an OCCI HTTP Protocol doc above :)
>> 
>>>> - Try to make the single-instance format more lightweight and not duplicating any information available through the discovery interface. Thanks Jamie.
>>> 
>>> That actually I like very much. It might be nice to think about a shallow/deep rendering option on the protocol level, but that's just a thought.
>> 
>> If you are referring to all the white-space in the examples it is just there for readability. I should put in a note that a server/client should remove all unnecessary white-space for real communication.
>> 
>> If not, please elaborate.
> 
> I'm interested in this as well.

Nope. I meant whether, for JSON, one might want to get a resource with its dependencies, rendered inline. Thinking about it overnight however led to the conclusion that I'd better be ignored when proposing such things...

>>>> - Use the "marker" concept from OpenStack for pagination as suggested by Andy.
>>> 
>>> This is also something that should be taken care of in the protocol, rather than the data format. Why on earth would people want to see this if the protocol they use only delivers batches of things? And in fact, looking at the spec, it has been done on the HTTP level, anyway.
>> 
>> It is done both on the HTTP level (query parameters) and in the payload :-\
>> 
>> Is it just the "next" and "limit" members you want removed from the collection format? Anything else you deem to be protocol stuff?
>> 
>> 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.
> 
> 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.

I think the link header is a nice approach for this. They also allow for indexes, anyway.

@Gary: I thought of using them as a means of orientation for pagination. But that would also be something to be done on the HTTP spec level, and not specifically for JSON.

And since we are at it, we should also consider moving queries to the query fragment of URLs.

> 
>>> Frankly, this should be something to be added to the HTTP protocol rendering and made available to all data representations, rather than in a proprietary, JSON-specific way only.
>> 
>> Agreed, with reservation for possible browser problems…

Well, the base HTTP API is beyond what browsers can handle, anyway. 

>> 
>>>> - "range" and "default" attribute properties as requested by Florian.
>>> 
>>> Great idea. We might want to consider pushing this upstream to core.
>> 
>> That was my intention. I have long wanted to have the "default" property into Core since without it a client cannot create custom templates.

Yup. Very good point.

>> Thanks for the feedback Alex. More of this and we might have something to publish in not a too distant future.

Hope so ;-)

-A.

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120301/56372f31/attachment.bin>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120301/56372f31/attachment-0001.bin>