Re: [occi-wg] JSON Rendering

2 May 2012


      So if you can add those to the current trunk versions, that'd be awesome!

Andy
andy.edmonds.be


On Wed, May 2, 2012 at 7:01 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
...
Hi,
I build the latest version with line numbers
-gary
On 4/18/2012 8:33 AM, Jamie Marshall wrote:
thanks Florian, that sounds like a good idea to me.
Jamie
...
From: florian.feldhaus@gwdg.de
To: ijm667@hotmail.com
CC: ralf@nyren.net; occi-wg@ogf.org
Subject: Re: [occi-wg] JSON Rendering
Date: Wed, 18 Apr 2012 14:10:14 +0000
Ok, if no one complains we'll do it on monday 16:00 CET (14:00 UTC). I
suggest we use Skype. If there are no objections, I will log into the
occi.wg Skype Account and coordinate the call from there.
Cheers,
Florian
Am 18.04.2012 um 10:41 schrieb Jamie Marshall:
...
Both are good for me.
Jamie
...
To: ijm667@hotmail.com
Subject: RE: [occi-wg] JSON Rendering
Date: Wed, 18 Apr 2012 09:19:55 +0200
From: ralf@nyren.net
CC: florian.feldhaus@gwdg.de; occi-wg@ogf.org
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@hotmail.com> <ijm667@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@gwdg.de
...
To: ralf@nyren.net
...
Date: Tue, 17 Apr 2012 19:59:07 +0000
...
CC: occi-wg@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@intel.com> <andrewx.edmonds@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@ogf.org [mailto:occi-wg-bounces@ogf.org<occi-wg-bounces@ogf.org>]
On
...
...
> Behalf Of alexander.papaspyrou@tu-dortmund.de
...
...
> Sent: Thursday, April 05, 2012 3:46 PM
...
...
> To: ralf@nyren.net
...
...
> Cc: occi-wg@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@nyren.net><ralf@nyren.net>
:
...
...
>
...
...
>>
...
...
>> On Thu, 5 Apr 2012 09:21:52 +0000, "Feldhaus, Florian"
...
...
>> <florian.feldhaus@gwdg.de> <florian.feldhaus@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@gwdg.de> <florian.feldhaus@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@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@ogf.org
...
https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________
occi-wg mailing listocci-wg@ogf.orghttps://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/occi-wg

Re: [occi-wg] JSON Rendering

Andy Edmonds