[occi-wg] JSON Rendering

Wed Apr 18 03:19:55 EDT 2012

What about:
 - Monday 2012-04-23 at 16:00 CET (14:00 UTC)
or
 - Tuesday 2012-04-24 at 16:00 CET (14:00 UTC)
?

regards, Ralf

On Tue, 17 Apr 2012 22:15:05 +0200, Jamie Marshall <ijm667 at hotmail.com>
wrote:
> 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