> 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>
> > >
> > > 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
>