Re: [occi-wg] JSON Rendering

18 Apr 2012


      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>
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> 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] 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>:
...
...
...
...
...
...
...
...
...
...
...
On Thu, 5 Apr 2012 09:21:52 +0000, "Feldhaus, Florian"
...
...
...
...
<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> 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