[occi-wg] JSON Rendering

Tue Apr 17 16:15:05 EDT 2012

Monday, Tuesday and Friday, at any time, are my best days, Wednesday is quite busy and Thursday is out of the question.SincerelyJamie

From: florian.feldhaus at gwdg.de
To: ralf at nyren.net
Date: Tue, 17 Apr 2012 19:59:07 +0000
CC: occi-wg at ogf.org
Subject: Re: [occi-wg] JSON Rendering

I would also like to participate. What date / time would be best for you? For me every day of the week would work.

--Florian

Am 17.04.2012 um 21:34 schrieb Ralf Nyren:

> Good idea, next week should be ok.
> /Ralf
> 
> On Tue, 17 Apr 2012 17:51:04 +0200, Edmonds, AndrewX <andrewx.edmonds at intel.com> wrote:
> 
>> Suggestion: are people free for a confcall say next week to review and finalise the JSON work needed to be completed?
>> 
>> Andy
>> 
>> -----Original Message-----
>> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of alexander.papaspyrou at tu-dortmund.de
>> Sent: Thursday, April 05, 2012 3:46 PM
>> To: ralf at nyren.net
>> Cc: occi-wg at ogf.org
>> Subject: Re: [occi-wg] JSON Rendering
>> 
>> +1 from me on the separation path. Let's get it proper before it cannot be separated anymore.
>> 
>> -A.
>> 
>> Am 05.04.2012 um 16:43 schrieb "Ralf Nyren" <ralf at nyren.net>:
>> 
>>> 
>>> On Thu, 5 Apr 2012 09:21:52 +0000, "Feldhaus, Florian"
>>> <florian.feldhaus at gwdg.de> wrote:
>>>> Hi,
>>>> 
>>>> how do we proceed?
>>> 
>>> The best thing IMO would be to create a version 1.2 of the HTTP
>>> Rendering doc and update it so that it is a clear separation between
>>> Protocol and Data Format. The existing text/occi, text/occi and the
>>> JSON data formats would then be pluggable modules to this spec.
>>> 
>>> The quick way is to continue writing the JSON rendering as a
>>> standalone HTTP-based OCCI rendering which happens to be quite similar
>>> to the HTTP Rendering. Saves time but causes lots of duplication.
>>> 
>>>> Following a some responses to your comments:
>>>> 
>>>> Am 04.04.2012 um 10:59 schrieb Ralf Nyren:
>>>> 
>>>>> On Tue, 03 Apr 2012 14:31:24 +0200, Feldhaus, Florian
>>>>> <florian.feldhaus at gwdg.de> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> once again I would like to reiterate the JSON rendering. First a
>>>>>> short overview what Alexander and I think are the main points we
>>>>>> should
>>>>>> address:
>>>>>> - remove all HTTP Rendering specific parts from the JSON rendering
>>>>> 
>>>>> Remember that an OCCI rendering (as currently specified) includes
>>> _both_
>>>>> protocol and data format at the moment.
>>>> 
>>>> That's only partly true. A "pure" JSON rendering can already exist
>>>> independently from the HTTP Rendering without any trouble in rendering.
>>> 
>>> No. Yes.
>>> 
>>> Probably a misunderstanding here. An OCCI Rendering is defined as a
>>> way to manipulate the Core Model. So in theory you could have 2
>>> different HTTP-based OCCI Renderings with different semantics where
>>> one happen to be using XML as the data format and the othe JSON for
>>> example. This is not nice but within the definition.
>>> 
>>> So to be complete an OCCI Rendering must both define the protocol and
>>> whatever data format is used by that protocol.
>>> 
>>> This does not prevent us from having a single OCCI HTTP Protocol
>>> Rendering with pluggable data formats.
>>> 
>>>>> I like the idea of having a common HTTP Protocol rendering spec
>>>>> which the JSON rendering could be built upon though.
>>>> 
>>>> I second this and would like to move forward. Any comments on the
>>>> best strategy? Do we need to create a version 1.2 for the HTTP rendering?
>>> 
>>> I believe so yes. It would be mostly backwards compatible though.
>>> 
>>>>> However, the current HTTP rendering doc lacks things like e.g.
>>>>> request parameters in URL which I would say is necessary to have a
>>>>> sane JSON rendering.
>>>> 
>>>> I don't think so. The rendering should be independently of the
>>>> transport protocol. If I ask your server to send me a file by mail
>>>> containing the JSON rendering of all resources, that should work as well.
>>> 
>>> We are probably using different terminology here. I am referring to an
>>> OCCI "rendering". Your statement is 100% true for an OCCI data format.
>>> However, a data format is not enough to create an OCCI Rendering.
>>> 
>>>>>> - consider using RFC 5988 "Web Linking" for collection information
>>>>>> (e.g. index, next, previous,…)
>>>>> 
>>>>> Gary and I had an email conversation which resulted in a solution
>>>>> where all info necessary for pagination would end up in the request URL. I.e.
>>>>> basically eliminating the need for using special headers (such as
>>>>> RFC 5988).
>>>>> 
>>>>> The request parameters to a collection simply allow you to specify
>>>>> the amount of resource instances you want returned either _before_
>>>>> or
>>> _after_
>>>>> a specific occi.core.id.
>>>> 
>>>> Do you have some examples? IMHO this should go to the revised HTTP
>>>> rendering document.
>>> 
>>> The mail thread was on occi-wg so should be in the archives.
>>> 
>>> Agree that it would be best to put this into a 1.2 version of the HTTP
>>> Rendering doc.
>>> 
>>>>>> Examples:
>>>>>> http://pastebin.com/ZK9Uf0K1 (Entities)
>>>>> 
>>>>> Nice, I like that you keep the "attributes" hash now ;)
>>>>> 
>>>>> How do you render Link attributes for the links tied to an OCCI
>>> Resource?
>>>> 
>>>> In the example you can see Links are rendered as a hash containing
>>>> href and kind. The only really necessary part is the href location.
>>> Everything
>>>> else is optional and could be retrieved by the client using separate
>>> HTTP
>>>> requests. It would also be possible to omit the hash and just render
>>>> all link hrefs in an array. To allow for a slim rendering and also
>>>> allow for additional information to be send to the client, I would
>>>> suggest that we specify a hash with at least the href and optional
>>>> all other parameters valid for the link. We could even go so far as
>>>> to use the link rendering for rendering link attributes within resources.
>>> 
>>> After many long discussions it was decided to have inline rendering of
>>> Link attributes in the OCCI HTTP Rendering. I think the same should
>>> apply to JSON.
>>> 
>>>>>> To keep the mail short, a detailed discussion can be found in the
>>>>>> attached text document.
>>>>> 
>>>>> Just picking out one thread:
>>>>> 
>>>>>> resources and links should be represented differently. The entry
>>>>>> "links" is unique for resources and the entries "target" and "source"
>>>>>> are unique for links.
>>>>> 
>>>>> Sounds goods. So the top-level hash of the collection format would
>>>>> have one hash "resources" and another hash "links" then?
>>>>> I mean, we still have to cover the case where the client asks for
>>>>> "everything" at the top-level URL and thus gets both Resources and
>>> Links
>>>>> in the response.
>>>> 
>>>> I would suggest to have a content-type for entities. It should
>>>> contain a hash with "links" and "resources". Both then are arrays of hashes.
>>> 
>>> I rather have a single array, it plays much better with the collection
>>> concept of REST.
>>> 
>>>>>> In OCCI Core the attribute names should be changed from
>>>>>> occi.core.source and occi.core.target to just source and target, as
>>> both
>>>>>> are representing connections to other resources from within the
>>>>>> OCCI model (similar to links in resources, or kind in entity).
>>>>> 
>>>>> occi.core.source and occi.core.target was named simply source/target
>>>>> up until just before the OCCI HTTP Rendering doc was published.
>>>>> 
>>>>> The fundamental problem here is that we have two different sorts of
>>>>> "attributes".
>>>>> 1. Attributes as part of the OCCI Core model. These include both
>>>>> Entity.id, Entity.title, Resource.summary, Resource.links,
>>>>> Link.target, Link.source, etc 2. Attributes as exposed by an OCCI
>>>>> rendering. The HTTP Rendering exposes id, title, summary as
>>>>> attributes as well as target and source.
>>>>> However the Resource.links attribute is not exposed as an attribute...
>>>>> 
>>>>> There is no clear distinction here which IMO leads to confusion.
>>> 
>>> No comments on the above?
>>> 
>>>>> Also remember that a subclass of OCCI Link may have Link.target
>>> pointing
>>>>> at some arbitrary external object.
>>>> 
>>>> In my opinion, source and target always point to resources, even if
>>>> they lie outside the OCCI model. They contain complex data types like
>>>> kind or mixin and not primitive data types like id, title or summary.
>>> 
>>> So, to link to a VNC console you would have the vnc:// URL where? In a
>>> VNC console Resource object?
>>> 
>>> /Ralf
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/occi-wg
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>> 
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.

_______________________________________________
occi-wg mailing list
occi-wg at ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120417/c1779dd0/attachment-0001.html>