[occi-wg] JSON Rendering
Gary Mazz
garymazzaferro at gmail.com
Wed May 2 14:03:25 EDT 2012
I just noticed there are some issues with the table headers duplicated i
the wrong spots.. I'll have to fix them first
On 5/2/2012 11:13 AM, Andy Edmonds wrote:
> So if you can add those to the current trunk versions, that'd be awesome!
>
> Andy
> andy.edmonds.be <http://andy.edmonds.be>
>
>
> On Wed, May 2, 2012 at 7:01 PM, Gary Mazz <garymazzaferro at gmail.com
> <mailto:garymazzaferro at 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 at gwdg.de <mailto:florian.feldhaus at gwdg.de>
>> > To: ijm667 at hotmail.com <mailto:ijm667 at hotmail.com>
>> > CC: ralf at nyren.net <mailto:ralf at nyren.net>; occi-wg at ogf.org
>> <mailto:occi-wg at 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 at hotmail.com <mailto:ijm667 at hotmail.com>
>> > > > Subject: RE: [occi-wg] JSON Rendering
>> > > > Date: Wed, 18 Apr 2012 09:19:55 +0200
>> > > > From: ralf at nyren.net <mailto:ralf at nyren.net>
>> > > > CC: florian.feldhaus at gwdg.de
>> <mailto:florian.feldhaus at gwdg.de>; occi-wg at ogf.org
>> <mailto:occi-wg at 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 at hotmail.com> <mailto: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
>> <mailto:florian.feldhaus at gwdg.de>
>> > > >
>> > > > > To: ralf at nyren.net <mailto:ralf at nyren.net>
>> > > >
>> > > > > Date: Tue, 17 Apr 2012 19:59:07 +0000
>> > > >
>> > > > > CC: occi-wg at ogf.org <mailto: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>
>> <mailto: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> [mailto:occi-wg-bounces at ogf.org] On
>> > > >
>> > > > >>> Behalf Of alexander.papaspyrou at tu-dortmund.de
>> <mailto:alexander.papaspyrou at tu-dortmund.de>
>> > > >
>> > > > >>> Sent: Thursday, April 05, 2012 3:46 PM
>> > > >
>> > > > >>> To: ralf at nyren.net <mailto:ralf at nyren.net>
>> > > >
>> > > > >>> Cc: occi-wg at ogf.org <mailto: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> <mailto:ralf at nyren.net>:
>> > > >
>> > > > >>>
>> > > >
>> > > > >>>>
>> > > >
>> > > > >>>> On Thu, 5 Apr 2012 09:21:52 +0000, "Feldhaus, Florian"
>> > > >
>> > > > >>>> <florian.feldhaus at gwdg.de>
>> <mailto: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>
>> <mailto: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 <http://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 <mailto: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 <mailto:occi-wg at ogf.org>
>> > > >
>> > > > > https://www.ogf.org/mailman/listinfo/occi-wg
>> >
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/occi-wg
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org <mailto: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/20120502/5bba424f/attachment-0001.html>
More information about the occi-wg
mailing list