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 - make the JSON rendering slim and remove everything which is not a representation of the OCCI model - consider using RFC 5988 "Web Linking" for collection information (e.g. index, next, previous,…) Examples: http://pastebin.com/ZK9Uf0K1 (Entities) http://pastebin.com/cKGw9pz6 (Categories) To keep the mail short, a detailed discussion can be found in the attached text document. Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
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. I like the idea of having a common HTTP Protocol rendering spec which the JSON rendering could be built upon 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. Updating the HTTP rendering doc to have a clear separation between protocol and data format would address this of course.
- make the JSON rendering slim and remove everything which is not a representation of the OCCI model
You mean the pagination links etc? Or something else as well?
- 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.
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?
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.
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. Also remember that a subclass of OCCI Link may have Link.target pointing at some arbitrary external object. regards, Ralf
Hi, how do we proceed? 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.
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?
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.
Updating the HTTP rendering doc to have a clear separation between protocol and data format would address this of course.
- make the JSON rendering slim and remove everything which is not a representation of the OCCI model
You mean the pagination links etc? Or something else as well?
I meant the HTTP rendering parts, the pagination links and the rendering itself being reasonably slim.
- 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.
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.
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.
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.
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.
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
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.
Also remember that a subclass of OCCI Link may have Link.target
No comments on the above? 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
+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
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.
I would be very interested in participating in this meeting. SincerelyJamie
From: andrewx.edmonds@intel.com To: alexander.papaspyrou@tu-dortmund.de; ralf@nyren.net; florian.feldhaus@gwdg.de Date: Tue, 17 Apr 2012 15:51:04 +0000 CC: occi-wg@ogf.org Subject: Re: [occi-wg] JSON Rendering
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
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.
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.
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
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
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: 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
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
-------------------------------------------------------------
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
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
-------------------------------------------------------------
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
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>
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
-------------------------------------------------------------
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
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>
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
> -------------------------------------------------------------
> 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
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
> -------------------------------------------------------------
> 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
_______________________________________________ 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
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@gmail.com <mailto: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 <mailto:florian.feldhaus@gwdg.de> > To: ijm667@hotmail.com <mailto:ijm667@hotmail.com> > CC: ralf@nyren.net <mailto:ralf@nyren.net>; occi-wg@ogf.org <mailto: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 <mailto:ijm667@hotmail.com> > > > Subject: RE: [occi-wg] JSON Rendering > > > Date: Wed, 18 Apr 2012 09:19:55 +0200 > > > From: ralf@nyren.net <mailto:ralf@nyren.net> > > > CC: florian.feldhaus@gwdg.de <mailto:florian.feldhaus@gwdg.de>; occi-wg@ogf.org <mailto: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> <mailto: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 <mailto:florian.feldhaus@gwdg.de> > > > > > > > To: ralf@nyren.net <mailto:ralf@nyren.net> > > > > > > > Date: Tue, 17 Apr 2012 19:59:07 +0000 > > > > > > > CC: occi-wg@ogf.org <mailto: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> <mailto: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> [mailto:occi-wg-bounces@ogf.org] On > > > > > > >>> Behalf Of alexander.papaspyrou@tu-dortmund.de <mailto:alexander.papaspyrou@tu-dortmund.de> > > > > > > >>> Sent: Thursday, April 05, 2012 3:46 PM > > > > > > >>> To: ralf@nyren.net <mailto:ralf@nyren.net> > > > > > > >>> Cc: occi-wg@ogf.org <mailto: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> <mailto:ralf@nyren.net>: > > > > > > >>> > > > > > > >>>> > > > > > > >>>> On Thu, 5 Apr 2012 09:21:52 +0000, "Feldhaus, Florian" > > > > > > >>>> <florian.feldhaus@gwdg.de> <mailto: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> <mailto: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 <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@ogf.org <mailto: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 <mailto:occi-wg@ogf.org> > > > > > > > https://www.ogf.org/mailman/listinfo/occi-wg >
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected.... - In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the tables should follow the JSON - presumably. I like the usage of the pattern attribute...that will help with client side validation :) - Michael B.
Hi All, I haven't been able to correct these anomalies with the document. I never like Latex... Sorry :) On 5/2/2012 9:25 PM, Michael Behrens wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the tables should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
Looks like Florian commited a work-in-progress version. There are still content from the previous version which has not been updated. The media type of the discovery interface serialization for example. I would find it easier to read if we described the serialization of each OCCI type (Kind, Mixin, Resource, Link, Action) in a separate subsection for each one. Then a final section could described the actual JSON format sent on the wire which is a combination of the serialization of the OCCI types. It would follow the same pattern as how the HTTP doc uses ABNF to describe the individual headers and then shows how they are put together. For the JSON example structures it would be nice to drop the example content and just write the JSON type in italics. Instead of: "title": "My example title", just specify: "title": *string* (where *xxx* means italic) This way it would be very clear what part of the JSON is static keywords and what is variable content. regards, Ralf On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens <michael.behrens@r2ad.com> wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the tables should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
I agree with separate sections.. I think.. I need to see a simple example.. The resource, link and category are 3 different views and need to be defined in detail. -gary On 5/3/2012 2:10 AM, Ralf Nyren wrote:
Looks like Florian commited a work-in-progress version. There are still content from the previous version which has not been updated. The media type of the discovery interface serialization for example.
I would find it easier to read if we described the serialization of each OCCI type (Kind, Mixin, Resource, Link, Action) in a separate subsection for each one.
Then a final section could described the actual JSON format sent on the wire which is a combination of the serialization of the OCCI types. It would follow the same pattern as how the HTTP doc uses ABNF to describe the individual headers and then shows how they are put together.
For the JSON example structures it would be nice to drop the example content and just write the JSON type in italics. Instead of: "title": "My example title", just specify: "title": *string* (where *xxx* means italic)
This way it would be very clear what part of the JSON is static keywords and what is variable content.
regards, Ralf
On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens <michael.behrens@r2ad.com> wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the tables should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Thu, 03 May 2012 02:24:15 -0600, Gary Mazz <garymazzaferro@gmail.com> wrote:
I agree with separate sections.. I think.. I need to see a simple example..
\section{OCCI Kind} { "scheme": *string*, "term": *string*", ... } \section{OCCI Link} { "kind": *string*, "source": *string*, "target": *string*, "attributes": *object*, ... }
The resource, link and category are 3 different views and need to be defined in detail.
+2 for detailed definition! /Ralf
-gary
On 5/3/2012 2:10 AM, Ralf Nyren wrote:
Looks like Florian commited a work-in-progress version. There are still content from the previous version which has not been updated. The media type of the discovery interface serialization for example.
I would find it easier to read if we described the serialization of
OCCI type (Kind, Mixin, Resource, Link, Action) in a separate subsection for each one.
Then a final section could described the actual JSON format sent on the wire which is a combination of the serialization of the OCCI types. It would follow the same pattern as how the HTTP doc uses ABNF to describe the individual headers and then shows how they are put together.
For the JSON example structures it would be nice to drop the example content and just write the JSON type in italics. Instead of: "title": "My example title", just specify: "title": *string* (where *xxx* means italic)
This way it would be very clear what part of the JSON is static keywords and what is variable content.
regards, Ralf
On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens <michael.behrens@r2ad.com> wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the
each tables
should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
I'll take a shot at it later today. At least the ABNF -gary On 5/3/2012 3:30 AM, Ralf Nyren wrote:
On Thu, 03 May 2012 02:24:15 -0600, Gary Mazz<garymazzaferro@gmail.com> wrote:
I agree with separate sections.. I think.. I need to see a simple example..
\section{OCCI Kind}
{ "scheme": *string*, "term": *string*", ... }
\section{OCCI Link}
{ "kind": *string*, "source": *string*, "target": *string*, "attributes": *object*, ... }
The resource, link and category are 3 different views and need to be defined in detail. +2 for detailed definition!
/Ralf
-gary
Looks like Florian commited a work-in-progress version. There are still content from the previous version which has not been updated. The media type of the discovery interface serialization for example.
I would find it easier to read if we described the serialization of each OCCI type (Kind, Mixin, Resource, Link, Action) in a separate subsection for each one.
Then a final section could described the actual JSON format sent on the wire which is a combination of the serialization of the OCCI types. It would follow the same pattern as how the HTTP doc uses ABNF to describe the individual headers and then shows how they are put together.
For the JSON example structures it would be nice to drop the example content and just write the JSON type in italics. Instead of: "title": "My example title", just specify: "title": *string* (where *xxx* means italic)
This way it would be very clear what part of the JSON is static keywords and what is variable content.
regards, Ralf
On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens <michael.behrens@r2ad.com> wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the
On 5/3/2012 2:10 AM, Ralf Nyren wrote: tables
should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi, I've been ill the last week and haven't had much time (or better, concentration) to work on the JSON Spec. I would like to pick up the work today at 16:00 CET. I will be only in Skype (account: freddich) and would be glad to discuss the details while updating the document. Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 ----------------------------------------------------------------------------------- Am 03.05.2012 um 12:12 schrieb Gary Mazz:
I'll take a shot at it later today. At least the ABNF
-gary
On 5/3/2012 3:30 AM, Ralf Nyren wrote:
On Thu, 03 May 2012 02:24:15 -0600, Gary Mazz<garymazzaferro@gmail.com> wrote:
I agree with separate sections.. I think.. I need to see a simple example..
\section{OCCI Kind}
{ "scheme": *string*, "term": *string*", ... }
\section{OCCI Link}
{ "kind": *string*, "source": *string*, "target": *string*, "attributes": *object*, ... }
The resource, link and category are 3 different views and need to be defined in detail. +2 for detailed definition!
/Ralf
-gary
Looks like Florian commited a work-in-progress version. There are still content from the previous version which has not been updated. The media type of the discovery interface serialization for example.
I would find it easier to read if we described the serialization of each OCCI type (Kind, Mixin, Resource, Link, Action) in a separate subsection for each one.
Then a final section could described the actual JSON format sent on the wire which is a combination of the serialization of the OCCI types. It would follow the same pattern as how the HTTP doc uses ABNF to describe the individual headers and then shows how they are put together.
For the JSON example structures it would be nice to drop the example content and just write the JSON type in italics. Instead of: "title": "My example title", just specify: "title": *string* (where *xxx* means italic)
This way it would be very clear what part of the JSON is static keywords and what is variable content.
regards, Ralf
On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens <michael.behrens@r2ad.com> wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the
On 5/3/2012 2:10 AM, Ralf Nyren wrote: tables
should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi, I've been looking at the details of the JSON and noticed the use of "rel", "kind", "related", "actions" and "scheme". These tags are all using XSD schemes as values. XSD has no meaning to JSON. I think this is a defect. I'm proposing three (3) options: Option 1) adopt JSON schema Option 2) adopt JSON-LD (linked data) that will permit us to move into the semantic web. Option 3) adopt JSON schema & adopt JSON-LD (linked data). With Option 1, JSON schema is in flux right now, and they are just thinking about proposing draft 4. There may be some risk with the scheme changing out from underneath us. But, it does buy us a validation strategy that we need. There are a few JSON schema validators (two ?) out there already. With Option 2, the scheme value becomes a JSON object with 2 properties: @id and @context. @id becomes the name and @context is a semantic definition on a server or in a knowledge base. We do not get validation with this option. Option 3 combines Option 1 and Option 2. There are really two concerns proposed to address a problem. A more robust solution would be incorporate both options cheers, gary On 5/2/2012 9:25 PM, Michael Behrens wrote:
In reviewing the latest sent out...here a few nit-noids...which Gary may have already corrected....
- In section 5.1, I see two JSON examples....looks like a second one starts on line 113. Perhaps a description of the second one would help separate the two. Or am I reading it wrong? - in that JSON, there are some extra spaces showing up after "http: ". Lines 88, 90, 91, 97 - Line 106, missing comma at end of line (I think) - Looks like the JSON in section 5.2 is split up - perhaps the tables should follow the JSON - presumably.
I like the usage of the pattern attribute...that will help with client side validation :)
- Michael B.
Hi, I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification. The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization. To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON. The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity. I propose we associate CRUD with category actions. The ABNF is represented below: * DeclarativeJSON = CRUD ; OCCI* * CRUD = CREATE / RETRIEVE / UPDATE / DELETE * *The definitions:* scheme : http://schemas.ogf.org/occi/core/category/action term : CREATE mutable : true required: false type : string scheme : http://schemas.ogf.org/occi/core/category/action term : RETRIEVE mutable : true required: false type : string scheme : http://schemas.ogf.org/occi/core/category/action term : UPDATE mutable : true required: false type : string scheme : http://schemas.ogf.org/occi/core/category/action term : DELETE mutable : true required: false type : string We would have three (3) presentations: 1) The JSON "actions" encapsulating Resources, 2) Resources showing inherited CRUD in JSON "actions" 3) In classes' JSON "actions" Examples Below: *1) The JSON "actions" encapsulating Resources:* { "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" "resources":[.......] ], [ "title": "CRUD Delete Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#DELETE" "resources":[.......] ] } *2) Resources showing inherited CRUD in JSON "actions"*: { "links": [ { "title": "My disk", "target": "http://myservice.tld/storage/456", "rel": [ "http://schemas.ogf.org/occi/infrastructure#storage" ], "kind": "http://schemas.ogf.org/occi/infrastructure#storagelink" "attributes": { "occi.storagelink.deviceid": "ide:0:1" }, "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" ] } ] } *3) In Classes' JSON "actions":* { "kinds": [ { "term": "compute",155 "scheme": "http://schemas.ogf.org/occi/infrastructure#", "title": "Compute Resource", "related": [ "http://schemas.ogf.org/occi/core#resource" ], "attributes": { "occi": { "compute": { "hostname": { "mutable": true, "required": false, "type": "string", "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*" }, "state": { "mutable": false, "required": false, "type": "string", "pattern": "inactive|active|suspended|failed", "default": "inactive" }, ... } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", "http://schemas.ogf.org/occi/infrastructure/compute/action#start", "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", "http://schemas.ogf.org/occi/infrastructure/compute/action#restart", "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" ], "location": "/compute/" }, ... ], "mixins": [ { "term": "medium", "scheme": "http://example.com/templates/resource#", "title": "Medium VM", "related": [ "http://schemas.ogf.org/occi/infrastructure#resource_tpl", "http://schemas.ogf.org/occi/infrastructure#compute" ], "attributes": { "occi": { "compute": { "speed": { "type": "number", "default": 2.8 } } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", ], }, ... ], "actions": [ { "term": "stop", "scheme": "http://schemas.ogf.org/occi/infrastructure/compute/action#", "title": "Stop Compute instance", "attributes": { "method": { "mutable": true, "required": false, "type": "string", "pattern": "graceful|acpioff|poweroff", "default": "poweroff" } } }, { "term": "CREATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "CREATE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "RETRIEVE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVECompute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "UPDATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVECompute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "DELETE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "DELETECompute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, ... ] } -gary
Hi Gary, that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately. Cheers, Florian Am 03.05.2012 um 09:43 schrieb Gary Mazz:
Hi,
I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization.
To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity.
I propose we associate CRUD with category actions.
The ABNF is represented below:
DeclarativeJSON = CRUD ; OCCI CRUD = CREATE / RETRIEVE / UPDATE / DELETE The definitions:
scheme : http://schemas.ogf.org/occi/core/category/action term : CREATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : RETRIEVE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : UPDATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : DELETE mutable : true required: false type : string
We would have three (3) presentations: 1) The JSON "actions" encapsulating Resources, 2) Resources showing inherited CRUD in JSON "actions" 3) In classes' JSON "actions" Examples Below: 1) The JSON "actions" encapsulating Resources: { "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" "resources":[.......] ], [ "title": "CRUD Delete Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#DELETE" "resources":[.......] ] }
2) Resources showing inherited CRUD in JSON "actions": { "links": [ { "title": "My disk", "target": "http://myservice.tld/storage/456", "rel": [ "http://schemas.ogf.org/occi/infrastructure#storage" ], "kind": "http://schemas.ogf.org/occi/infrastructure#storagelink" "attributes": { "occi.storagelink.deviceid": "ide:0:1" }, "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" ] } ] }
3) In Classes' JSON "actions": { "kinds": [ { "term": "compute",155 "scheme": "http://schemas.ogf.org/occi/infrastructure#", "title": "Compute Resource", "related": [ "http://schemas.ogf.org/occi/core#resource" ], "attributes": { "occi": { "compute": { "hostname": { "mutable": true, "required": false, "type": "string", "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*" }, "state": { "mutable": false, "required": false, "type": "string", "pattern": "inactive|active|suspended|failed", "default": "inactive" }, ... } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", "http://schemas.ogf.org/occi/infrastructure/compute/action#start", "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", "http://schemas.ogf.org/occi/infrastructure/compute/action#restart", "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" ], "location": "/compute/" }, ... ], "mixins": [ { "term": "medium", "scheme": "http://example.com/templates/resource#", "title": "Medium VM", "related": [ "http://schemas.ogf.org/occi/infrastructure#resource_tpl", "http://schemas.ogf.org/occi/infrastructure#compute" ], "attributes": { "occi": { "compute": { "speed": { "type": "number", "default": 2.8 } } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", ], }, ... ], "actions": [ { "term": "stop", "scheme": "http://schemas.ogf.org/occi/infrastructure/compute/action#", "title": "Stop Compute instance", "attributes": { "method": { "mutable": true, "required": false, "type": "string", "pattern": "graceful|acpioff|poweroff", "default": "poweroff" } } }, { "term": "CREATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "CREATE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "RETRIEVE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "UPDATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "DELETE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "DELETE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, ... ] }
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hello All, I agree with you Florian, CRUD is really just another set of words for the same things as REST which is the same thing as HTTP 1.1 anyway.The verbs were put in place way back so we can use them as is. ( in my honest opinion ) SincerelyJamie From: florian.feldhaus@gwdg.de To: garymazzaferro@gmail.com Date: Thu, 3 May 2012 12:10:24 +0000 CC: occi-wg@ogf.org Subject: Re: [occi-wg] JSON Rendering Proposal to add CRUD Verb Hi Gary, that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately. Cheers, Florian Am 03.05.2012 um 09:43 schrieb Gary Mazz:
Hi,
I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization.
To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity.
I propose we associate CRUD with category actions.
The ABNF is represented below:
DeclarativeJSON = CRUD ; OCCI CRUD = CREATE / RETRIEVE / UPDATE / DELETE The definitions:
scheme : http://schemas.ogf.org/occi/core/category/action term : CREATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : RETRIEVE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : UPDATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : DELETE mutable : true required: false type : string
We would have three (3) presentations: 1) The JSON "actions" encapsulating Resources, 2) Resources showing inherited CRUD in JSON "actions" 3) In classes' JSON "actions" Examples Below: 1) The JSON "actions" encapsulating Resources: { "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" "resources":[.......] ], [ "title": "CRUD Delete Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#DELETE" "resources":[.......] ] }
2) Resources showing inherited CRUD in JSON "actions": { "links": [ { "title": "My disk", "target": "http://myservice.tld/storage/456", "rel": [ "http://schemas.ogf.org/occi/infrastructure#storage" ], "kind": "http://schemas.ogf.org/occi/infrastructure#storagelink" "attributes": { "occi.storagelink.deviceid": "ide:0:1" }, "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" ] } ] }
3) In Classes' JSON "actions": { "kinds": [ { "term": "compute",155 "scheme": "http://schemas.ogf.org/occi/infrastructure#", "title": "Compute Resource", "related": [ "http://schemas.ogf.org/occi/core#resource" ], "attributes": { "occi": { "compute": { "hostname": { "mutable": true, "required": false, "type": "string", "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*" }, "state": { "mutable": false, "required": false, "type": "string", "pattern": "inactive|active|suspended|failed", "default": "inactive" }, ... } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", "http://schemas.ogf.org/occi/infrastructure/compute/action#start", "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", "http://schemas.ogf.org/occi/infrastructure/compute/action#restart", "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" ], "location": "/compute/" }, ... ], "mixins": [ { "term": "medium", "scheme": "http://example.com/templates/resource#", "title": "Medium VM", "related": [ "http://schemas.ogf.org/occi/infrastructure#resource_tpl", "http://schemas.ogf.org/occi/infrastructure#compute" ], "attributes": { "occi": { "compute": { "speed": { "type": "number", "default": 2.8 } } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", ], }, ... ], "actions": [ { "term": "stop", "scheme": "http://schemas.ogf.org/occi/infrastructure/compute/action#", "title": "Stop Compute instance", "attributes": { "method": { "mutable": true, "required": false, "type": "string", "pattern": "graceful|acpioff|poweroff", "default": "poweroff" } } }, { "term": "CREATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "CREATE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "RETRIEVE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "UPDATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "DELETE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "DELETE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, ... ] }
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
I'd also agree with Florian and Jamie. The idea is interesting, however I would not propose that it go into the JSON spec as I feel that a dedicated spec on using OCCI with message-based protocol (e.g. AMQP) could be authored. That spec would be somewhat like the HTTP rendering spec only for, say, AMQP, where you can use the meta-data section to supply information like http headers or indeed the type of HTTP-like operation (CRUD). The URI of the resource could then just be a specific message exchange. Andy andy.edmonds.be On Thu, May 3, 2012 at 3:13 PM, Jamie Marshall <ijm667@hotmail.com> wrote:
Hello All,
I agree with you Florian, CRUD is really just another set of words for the same things as REST which is the same thing as HTTP 1.1 anyway. The verbs were put in place way back so we can use them as is. ( in my honest opinion )
Sincerely Jamie
From: florian.feldhaus@gwdg.de To: garymazzaferro@gmail.com Date: Thu, 3 May 2012 12:10:24 +0000 CC: occi-wg@ogf.org Subject: Re: [occi-wg] JSON Rendering Proposal to add CRUD Verb
Hi Gary,
that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately.
Cheers, Florian
Am 03.05.2012 um 09:43 schrieb Gary Mazz:
Hi,
I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization.
To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity.
I propose we associate CRUD with category actions.
The ABNF is represented below:
DeclarativeJSON = CRUD ; OCCI CRUD = CREATE / RETRIEVE / UPDATE / DELETE The definitions:
term : CREATE mutable : true required: false type : string
term : RETRIEVE mutable : true required: false type : string
term : UPDATE mutable : true required: false type : string
term : DELETE mutable : true required: false type : string
We would have three (3) presentations: 1) The JSON "actions" encapsulating Resources,
2) Resources showing inherited CRUD in JSON "actions" 3) In classes' JSON "actions" Examples Below: 1) The JSON "actions" encapsulating Resources: {
"actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE"
"resources":[.......] ], [ "title": "CRUD Delete Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#DELETE"
"resources":[.......] ] }
2) Resources showing inherited CRUD in JSON "actions": { "links": [ { "title": "My disk",
"target": "http://myservice.tld/storage/456", "rel": [ "http://schemas.ogf.org/occi/infrastructure#storage" ],
"kind": "http://schemas.ogf.org/occi/infrastructure#storagelink" "attributes": { "occi.storagelink.deviceid": "ide:0:1" },
"actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE"
] } ] }
3) In Classes' JSON "actions": { "kinds": [ { "term": "compute",155 "scheme": "http://schemas.ogf.org/occi/infrastructure#",
"title": "Compute Resource", "related": [ "http://schemas.ogf.org/occi/core#resource"
], "attributes": { "occi": { "compute": { "hostname": { "mutable": true,
"required": false, "type": "string", "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*"
}, "state": { "mutable": false, "required": false, "type": "string",
"pattern": "inactive|active|suspended|failed", "default": "inactive" }, ...
} } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE",
"http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE",
"http://schemas.ogf.org/occi/core/category/action#DELETE", "http://schemas.ogf.org/occi/infrastructure/compute/action#start",
"http://schemas.ogf.org/occi/infrastructure/compute/action#stop", "http://schemas.ogf.org/occi/infrastructure/compute/action#restart",
"http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" ], "location": "/compute/"
}, ... ], "mixins": [ { "term": "medium", "scheme": "http://example.com/templates/resource#",
"title": "Medium VM", "related": [ "http://schemas.ogf.org/occi/infrastructure#resource_tpl",
"http://schemas.ogf.org/occi/infrastructure#compute" ], "attributes": {
"occi": { "compute": { "speed": { "type": "number", "default": 2.8
} } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE",
"http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE",
"http://schemas.ogf.org/occi/core/category/action#DELETE", ], }, ...
], "actions": [ { "term": "stop", "scheme": "http://schemas.ogf.org/occi/infrastructure/compute/action#",
"title": "Stop Compute instance", "attributes": { "method": { "mutable": true, "required": false,
"type": "string", "pattern": "graceful|acpioff|poweroff", "default": "poweroff" }
} }, { "term": "CREATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#",
"title": "CREATE Compute instance", "attributes": { "method": { "mutable": false, "required": false,
"type": "string", } } }, { "term": "RETRIEVE", "scheme": "http://schemas.ogf.org/occi/core/category/action#",
"title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false,
"type": "string", } } }, { "term": "UPDATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#",
"title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false,
"type": "string", } } }, { "term": "DELETE", "scheme": "http://schemas.ogf.org/occi/core/category/action#",
"title": "DELETE Compute instance", "attributes": { "method": { "mutable": false, "required": false,
"type": "string", } } }, ... ] }
-gary
_______________________________________________
occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi, This is an interesting more interesting approach.. that opens up a larger new world for OCCI. My motivation for bringing CRUD into the JSON spec was trying to avoid creating more specifications. I felt that adding the higher order life-cycle verbs as a proposal to the JSON was a good way to vet ideas and if accepted, gain the advantage of compact form. I also believe this has ramifications to other projections, text, HTTP anything else down the line. In my view, the higher order life-cycle verbs (CRUD) should be treated no differently than other life-cycle verbs associated with Mixins and Kinds. Until now, we have not had the opportunity to include higher order life-cycle verbs (associated with Categories) in any OCCI works. There is an impression that CRUD is only applicable to protocols. I don't agree with that assertion. CRUD may be implemented across different medias. Naturally, the semantic may require some adjustment supporting media characteristics. OCCI already supports Actions for resources inherited from Category, Kind and Mixin. The Actions are mutable, extensible and replaceable at the provider's discretion. The same is true for life-cycle states. Using that precedence, I placed the higher order life-cycle verbs (CRUD) in the OCCI Action type. Before I wrote the brief proposal, I reviewed the OCCI Core specification and the OCCI Infrastructure specification. Neither of these documents suggest or infer limiting the scope of Actions to any specific verbs, life-cycle models, Mixins or Kinds. The OCCI HTTP specification shows examples of verbs as part of the resource name space. */ie rel="http://schemas.ogf.org/occi/infrastructure/compute/action#start"/* However, there is no requirement that any verb must be part of a resource name space. The Action name space is only required to be associated with a Category, Kind or Mixin. I would like to continue this discussion, but change venue. Lets try to discuss the aspects of higher order life-cycle verbs in terms of an extension to the OCCI Infrastructure specification. If accepted it will have implications, similar to the ones identified in the CRUD JSON proposal, to OCCI JSON, OCCI HTTP and any future OCCI render specifications. It may pave the way for an opportunity to create a "JSON document" specification for OCCI. cheers, gary On 5/3/2012 7:53 AM, Andy Edmonds wrote:
I'd also agree with Florian and Jamie.
The idea is interesting, however I would not propose that it go into the JSON spec as I feel that a dedicated spec on using OCCI with message-based protocol (e.g. AMQP) could be authored. That spec would be somewhat like the HTTP rendering spec only for, say, AMQP, where you can use the meta-data section to supply information like http headers or indeed the type of HTTP-like operation (CRUD). The URI of the resource could then just be a specific message exchange.
Andy andy.edmonds.be <http://andy.edmonds.be>
On Thu, May 3, 2012 at 3:13 PM, Jamie Marshall <ijm667@hotmail.com <mailto:ijm667@hotmail.com>> wrote:
Hello All,
I agree with you Florian, CRUD is really just another set of words for the same things as REST which is the same thing as HTTP 1.1 anyway. The verbs were put in place way back so we can use them as is. ( in my honest opinion )
Sincerely Jamie
From: florian.feldhaus@gwdg.de <mailto:florian.feldhaus@gwdg.de> To: garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com> Date: Thu, 3 May 2012 12:10:24 +0000 CC: occi-wg@ogf.org <mailto:occi-wg@ogf.org> Subject: Re: [occi-wg] JSON Rendering Proposal to add CRUD Verb
Hi Gary,
that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately.
Cheers, Florian
Am 03.05.2012 um 09:43 schrieb Gary Mazz:
> Hi, > > I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
> > The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization. > > To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
> > The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity. > > > I propose we associate CRUD with category actions.
> > The ABNF is represented below: > > DeclarativeJSON = CRUD ; OCCI > CRUD = CREATE / RETRIEVE / UPDATE / DELETE > The definitions: > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : CREATE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : RETRIEVE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : UPDATE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : DELETE > mutable : true > required: false > type : string > > We would have three (3) presentations: > 1) The JSON "actions" encapsulating Resources,
> 2) Resources showing inherited CRUD in JSON "actions" > 3) In classes' JSON "actions" > Examples Below: > 1) The JSON "actions" encapsulating Resources: > {
> "actions": [ > "title": "CRUD Create Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#CREATE"
> "resources":[.......] > ], > [ > "title": "CRUD Delete Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#DELETE"
> "resources":[.......] > ] > } > > 2) Resources showing inherited CRUD in JSON "actions": > { > "links": [ > { > "title": "My disk",
> "target":"http://myservice.tld/storage/456", > "rel": ["http://schemas.ogf.org/occi/infrastructure#storage" ],
> "kind":"http://schemas.ogf.org/occi/infrastructure#storagelink" > "attributes": { "occi.storagelink.deviceid": "ide:0:1" },
> "actions": [ > "title": "CRUD Create Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#CREATE"
> ] > } > ] > } > > 3) In Classes' JSON "actions": > { > "kinds": [ > { > "term": "compute",155 "scheme":"http://schemas.ogf.org/occi/infrastructure#",
> "title": "Compute Resource", > "related": [ > "http://schemas.ogf.org/occi/core#resource"
> ], > "attributes": { > "occi": { > "compute": { > "hostname": { > "mutable": true,
> "required": false, > "type": "string", > "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*"
> }, > "state": { > "mutable": false, > "required": false, > "type": "string",
> "pattern": "inactive|active|suspended|failed", > "default": "inactive" > }, > ...
> } > } > }, > "actions": [ > "http://schemas.ogf.org/occi/core/category/action#CREATE",
> "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", > "http://schemas.ogf.org/occi/core/category/action#UPDATE",
> "http://schemas.ogf.org/occi/core/category/action#DELETE", > "http://schemas.ogf.org/occi/infrastructure/compute/action#start",
> "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", > "http://schemas.ogf.org/occi/infrastructure/compute/action#restart",
> "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" > ], > "location": "/compute/"
> }, > ... > ], > "mixins": [ > { > "term": "medium", > "scheme":"http://example.com/templates/resource#",
> "title": "Medium VM", > "related": [ > "http://schemas.ogf.org/occi/infrastructure#resource_tpl",
> "http://schemas.ogf.org/occi/infrastructure#compute" > ], > "attributes": {
> "occi": { > "compute": { > "speed": { > "type": "number", > "default": 2.8
> } > } > } > }, > "actions": [ > "http://schemas.ogf.org/occi/core/category/action#CREATE",
> "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", > "http://schemas.ogf.org/occi/core/category/action#UPDATE",
> "http://schemas.ogf.org/occi/core/category/action#DELETE", > ], > }, > ...
> ], > "actions": [ > { > "term": "stop", > "scheme":"http://schemas.ogf.org/occi/infrastructure/compute/action#",
> "title": "Stop Compute instance", > "attributes": { > "method": { > "mutable": true, > "required": false,
> "type": "string", > "pattern": "graceful|acpioff|poweroff", > "default": "poweroff" > }
> } > }, > { > "term": "CREATE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "CREATE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "RETRIEVE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "RETRIEVE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "UPDATE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "RETRIEVE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "DELETE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "DELETE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > ... > ] > } > > > -gary > > _______________________________________________
> occi-wg mailing list > occi-wg@ogf.org <mailto:occi-wg@ogf.org> > https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
Agreed... If aligned with core or infrastructure, we need to discuss that point. Infrastructure focuses on resources... As Florian said, the crud verbs include getter and setters. That means it exposes the internals of the Entity. I wanted to avoid decoupling OCCI from CRUD and State Transfer. and use them with different media types. ie a text file. However if we did decouple OCCI from CRUD and State Transfer, then we would be free to define semantic sugar like copy, clone, move, clear, bind, serialize for other media types. cheers, gary On 5/3/2012 9:23 PM, Michael Behrens wrote:
Being aligned with the core is a plus. One would have to document which method (action or protocol) would have precedence, in cases where needed.
Gary Mazz wrote:
Hi,
This is an interesting more interesting approach.. that opens up a larger new world for OCCI.
My motivation for bringing CRUD into the JSON spec was trying to avoid creating more specifications. I felt that adding the higher order life-cycle verbs as a proposal to the JSON was a good way to vet ideas and if accepted, gain the advantage of compact form. I also believe this has ramifications to other projections, text, HTTP anything else down the line.
In my view, the higher order life-cycle verbs (CRUD) should be treated no differently than other life-cycle verbs associated with Mixins and Kinds. Until now, we have not had the opportunity to include higher order life-cycle verbs (associated with Categories) in any OCCI works.
There is an impression that CRUD is only applicable to protocols. I don't agree with that assertion. CRUD may be implemented across different medias. Naturally, the semantic may require some adjustment supporting media characteristics.
OCCI already supports Actions for resources inherited from Category, Kind and Mixin. The Actions are mutable, extensible and replaceable at the provider's discretion. The same is true for life-cycle states.
Using that precedence, I placed the higher order life-cycle verbs (CRUD) in the OCCI Action type. Before I wrote the brief proposal, I reviewed the OCCI Core specification and the OCCI Infrastructure specification. Neither of these documents suggest or infer limiting the scope of Actions to any specific verbs, life-cycle models, Mixins or Kinds.
The OCCI HTTP specification shows examples of verbs as part of the resource name space. */ie rel="http://schemas.ogf.org/occi/infrastructure/compute/action#start"/* However, there is no requirement that any verb must be part of a resource name space. The Action name space is only required to be associated with a Category, Kind or Mixin.
I would like to continue this discussion, but change venue.
Lets try to discuss the aspects of higher order life-cycle verbs in terms of an extension to the OCCI Infrastructure specification. If accepted it will have implications, similar to the ones identified in the CRUD JSON proposal, to OCCI JSON, OCCI HTTP and any future OCCI render specifications. It may pave the way for an opportunity to create a "JSON document" specification for OCCI.
cheers, gary
On 5/3/2012 7:53 AM, Andy Edmonds wrote:
I'd also agree with Florian and Jamie.
The idea is interesting, however I would not propose that it go into the JSON spec as I feel that a dedicated spec on using OCCI with message-based protocol (e.g. AMQP) could be authored. That spec would be somewhat like the HTTP rendering spec only for, say, AMQP, where you can use the meta-data section to supply information like http headers or indeed the type of HTTP-like operation (CRUD). The URI of the resource could then just be a specific message exchange.
Andy andy.edmonds.be <http://andy.edmonds.be>
On Thu, May 3, 2012 at 3:13 PM, Jamie Marshall <ijm667@hotmail.com <mailto:ijm667@hotmail.com>> wrote:
Hello All,
I agree with you Florian, CRUD is really just another set of words for the same things as REST which is the same thing as HTTP 1.1 anyway. The verbs were put in place way back so we can use them as is. ( in my honest opinion )
Sincerely Jamie
From: florian.feldhaus@gwdg.de <mailto:florian.feldhaus@gwdg.de> To: garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com> Date: Thu, 3 May 2012 12:10:24 +0000 CC: occi-wg@ogf.org <mailto:occi-wg@ogf.org> Subject: Re: [occi-wg] JSON Rendering Proposal to add CRUD Verb
Hi Gary,
that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately.
Cheers, Florian
Am 03.05.2012 um 09:43 schrieb Gary Mazz:
> Hi, > > I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
> > The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization. > > To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
> > The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity. > > > I propose we associate CRUD with category actions.
> > The ABNF is represented below: > > DeclarativeJSON = CRUD ; OCCI > CRUD = CREATE / RETRIEVE / UPDATE / DELETE > The definitions: > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : CREATE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : RETRIEVE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : UPDATE > mutable : true > required: false > type : string > > scheme :http://schemas.ogf.org/occi/core/category/action
> term : DELETE > mutable : true > required: false > type : string > > We would have three (3) presentations: > 1) The JSON "actions" encapsulating Resources,
> 2) Resources showing inherited CRUD in JSON "actions" > 3) In classes' JSON "actions" > Examples Below: > 1) The JSON "actions" encapsulating Resources: > {
> "actions": [ > "title": "CRUD Create Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#CREATE"
> "resources":[.......] > ], > [ > "title": "CRUD Delete Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#DELETE"
> "resources":[.......] > ] > } > > 2) Resources showing inherited CRUD in JSON "actions": > { > "links": [ > { > "title": "My disk",
> "target":"http://myservice.tld/storage/456", > "rel": ["http://schemas.ogf.org/occi/infrastructure#storage" ],
> "kind":"http://schemas.ogf.org/occi/infrastructure#storagelink" > "attributes": { "occi.storagelink.deviceid": "ide:0:1" },
> "actions": [ > "title": "CRUD Create Operation", > "rel":"http://schemas.ogf.org/occi/core/category/action#CREATE"
> ] > } > ] > } > > 3) In Classes' JSON "actions": > { > "kinds": [ > { > "term": "compute",155 "scheme":"http://schemas.ogf.org/occi/infrastructure#",
> "title": "Compute Resource", > "related": [ > "http://schemas.ogf.org/occi/core#resource"
> ], > "attributes": { > "occi": { > "compute": { > "hostname": { > "mutable": true,
> "required": false, > "type": "string", > "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*"
> }, > "state": { > "mutable": false, > "required": false, > "type": "string",
> "pattern": "inactive|active|suspended|failed", > "default": "inactive" > }, > ...
> } > } > }, > "actions": [ > "http://schemas.ogf.org/occi/core/category/action#CREATE",
> "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", > "http://schemas.ogf.org/occi/core/category/action#UPDATE",
> "http://schemas.ogf.org/occi/core/category/action#DELETE", > "http://schemas.ogf.org/occi/infrastructure/compute/action#start",
> "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", > "http://schemas.ogf.org/occi/infrastructure/compute/action#restart",
> "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" > ], > "location": "/compute/"
> }, > ... > ], > "mixins": [ > { > "term": "medium", > "scheme":"http://example.com/templates/resource#",
> "title": "Medium VM", > "related": [ > "http://schemas.ogf.org/occi/infrastructure#resource_tpl",
> "http://schemas.ogf.org/occi/infrastructure#compute" > ], > "attributes": {
> "occi": { > "compute": { > "speed": { > "type": "number", > "default": 2.8
> } > } > } > }, > "actions": [ > "http://schemas.ogf.org/occi/core/category/action#CREATE",
> "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", > "http://schemas.ogf.org/occi/core/category/action#UPDATE",
> "http://schemas.ogf.org/occi/core/category/action#DELETE", > ], > }, > ...
> ], > "actions": [ > { > "term": "stop", > "scheme":"http://schemas.ogf.org/occi/infrastructure/compute/action#",
> "title": "Stop Compute instance", > "attributes": { > "method": { > "mutable": true, > "required": false,
> "type": "string", > "pattern": "graceful|acpioff|poweroff", > "default": "poweroff" > }
> } > }, > { > "term": "CREATE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "CREATE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "RETRIEVE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "RETRIEVE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "UPDATE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "RETRIEVE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > { > "term": "DELETE", > "scheme":"http://schemas.ogf.org/occi/core/category/action#",
> "title": "DELETE Compute instance", > "attributes": { > "method": { > "mutable": false, > "required": false,
> "type": "string", > } > } > }, > ... > ] > } > > > -gary > > _______________________________________________
> occi-wg mailing list > occi-wg@ogf.org <mailto:occi-wg@ogf.org> > https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org <mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hmmm How can you define crud in a file ? and other transports that do not support crud operations ? I don't think its fundamental at all.. "Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately." Exactly my point... What do you do with transports that do not expose those operations ? "don't need to be implemented separately. " They already are implemented separately and that's the problem. The base actions, the fundamental tenets of existent are not defined in the model or the projections while other actions are... -g On 5/3/2012 6:10 AM, Feldhaus, Florian wrote:
Hi Gary,
that's an interesting idea, but from my point of view it may be a bit over the top. CRUD really is such a basic thing, that I don't think we need a dedicated action for it. I usually see the actions as being some kind of methods for the OCCI entities. Then create would be the initialize method and delete the destroy method. Both don't have to be implemented, because they are already implemented in some base class. Read and update are just getters and setters for the attributes and usually don't need to be implemented separately.
Cheers, Florian
Am 03.05.2012 um 09:43 schrieb Gary Mazz:
Hi,
I have a proposal for an addition to the OCCI JSON specification. This proposal is not limited to the JSON specification and may also impact the OCCI Core specification.
The JSON specification has nearly fully decoupled OCCI information from the HTTP protocol. OCCI information represented in JSON is a complete object (frame) serialization.
To use the JSON as a declarative document (script) or take advantage of agnostic transports (i.e. a messaging bus or workflow system) , we need a way to define CRUD operations in the JSON.
The OCCI scheme has actions associated with category. The CRUD actions are inherited by Kind and Mixin, which means inherited by Entity.
I propose we associate CRUD with category actions.
The ABNF is represented below:
DeclarativeJSON = CRUD ; OCCI CRUD = CREATE / RETRIEVE / UPDATE / DELETE The definitions:
scheme : http://schemas.ogf.org/occi/core/category/action term : CREATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : RETRIEVE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : UPDATE mutable : true required: false type : string
scheme : http://schemas.ogf.org/occi/core/category/action term : DELETE mutable : true required: false type : string
We would have three (3) presentations: 1) The JSON "actions" encapsulating Resources, 2) Resources showing inherited CRUD in JSON "actions" 3) In classes' JSON "actions" Examples Below: 1) The JSON "actions" encapsulating Resources: { "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" "resources":[.......] ], [ "title": "CRUD Delete Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#DELETE" "resources":[.......] ] }
2) Resources showing inherited CRUD in JSON "actions": { "links": [ { "title": "My disk", "target": "http://myservice.tld/storage/456", "rel": [ "http://schemas.ogf.org/occi/infrastructure#storage" ], "kind": "http://schemas.ogf.org/occi/infrastructure#storagelink" "attributes": { "occi.storagelink.deviceid": "ide:0:1" }, "actions": [ "title": "CRUD Create Operation", "rel": "http://schemas.ogf.org/occi/core/category/action#CREATE" ] } ] }
3) In Classes' JSON "actions": { "kinds": [ { "term": "compute",155 "scheme": "http://schemas.ogf.org/occi/infrastructure#", "title": "Compute Resource", "related": [ "http://schemas.ogf.org/occi/core#resource" ], "attributes": { "occi": { "compute": { "hostname": { "mutable": true, "required": false, "type": "string", "pattern": "(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*" }, "state": { "mutable": false, "required": false, "type": "string", "pattern": "inactive|active|suspended|failed", "default": "inactive" }, ... } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", "http://schemas.ogf.org/occi/infrastructure/compute/action#start", "http://schemas.ogf.org/occi/infrastructure/compute/action#stop", "http://schemas.ogf.org/occi/infrastructure/compute/action#restart", "http://schemas.ogf.org/occi/infrastructure/compute/action#suspend" ], "location": "/compute/" }, ... ], "mixins": [ { "term": "medium", "scheme": "http://example.com/templates/resource#", "title": "Medium VM", "related": [ "http://schemas.ogf.org/occi/infrastructure#resource_tpl", "http://schemas.ogf.org/occi/infrastructure#compute" ], "attributes": { "occi": { "compute": { "speed": { "type": "number", "default": 2.8 } } } }, "actions": [ "http://schemas.ogf.org/occi/core/category/action#CREATE", "http://schemas.ogf.org/occi/core/category/action#RETRIEVE", "http://schemas.ogf.org/occi/core/category/action#UPDATE", "http://schemas.ogf.org/occi/core/category/action#DELETE", ], }, ... ], "actions": [ { "term": "stop", "scheme": "http://schemas.ogf.org/occi/infrastructure/compute/action#", "title": "Stop Compute instance", "attributes": { "method": { "mutable": true, "required": false, "type": "string", "pattern": "graceful|acpioff|poweroff", "default": "poweroff" } } }, { "term": "CREATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "CREATE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "RETRIEVE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "UPDATE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "RETRIEVE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, { "term": "DELETE", "scheme": "http://schemas.ogf.org/occi/core/category/action#", "title": "DELETE Compute instance", "attributes": { "method": { "mutable": false, "required": false, "type": "string", } } }, ... ] }
-gary
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Ralph, The use cases and attribute definitions for console are located at https://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Consoles%3bj... I wrote these up in Oct, 2010. These use cases also identify a need for credential management. The console can be added as a mixin... I think the console, a virtualized hardware artifact should have been integrated into the core model a long time ago. -gary On 4/5/2012 8:12 AM, Ralf Nyren wrote:
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
Hi, Is there a latest version of the spec with the edits ? cheers gary On 4/3/2012 6:31 AM, Feldhaus, Florian 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 - make the JSON rendering slim and remove everything which is not a representation of the OCCI model - consider using RFC 5988 "Web Linking" for collection information (e.g. index, next, previous,...)
Examples: http://pastebin.com/ZK9Uf0K1 (Entities) http://pastebin.com/cKGw9pz6 (Categories)
To keep the mail short, a detailed discussion can be found in the attached text document.
Cheers, Florian
------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen
Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus@gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
participants (8)
-
alexander.papaspyrou＠tu-dortmund.de -
Andy Edmonds -
Edmonds, AndrewX -
Feldhaus, Florian -
Gary Mazz -
Jamie Marshall -
Michael Behrens -
Ralf Nyren