Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc! Andy [1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor... ------------------------------------------------------------- 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.
Nice work, it fits in to the current use of categories while making extensibility easier to understand. A few comments/questions: Each category, defined by schema + term, can have a set of associated attributes. What namespace restrictions/rules are imposed on these attributes? Currently Core&Models says provider defined categories must be in a different namespace but no more. Maybe extend this a bit further as to avoid namespace conflicts while combining many categories? I believe earlier revs of the spec said something like: com.example.<category_term>.<attr_name> I do not quite understand the various Content-type headers used in the examples. Are they of any significance to the definition/use of categories? And just a few notes on the examples, sorry if it sounds picky but consistency really helps understanding: - Category: compute; scheme="http://prov.com/occi#"; Scheme should be "http://prov.com/occi/resource#" right? - Link: </compute/123-123-123;start>; type="application/occi-action"; Is the "type" attribute of the Link header something new? If so, how it is defined? - In Link header: rel="category http://prov.com/occi#action" Is the format rel="category XXX" something new as well? regards, Ralf On Fri, 13 Aug 2010 11:10:18 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://www.ogf.org/mailman/listinfo/occi-wg
Ralf, Am 13.08.2010 um 11:59 schrieb Ralf Lyren:
Each category, defined by schema + term, can have a set of associated attributes. What namespace restrictions/rules are imposed on these attributes? Currently Core&Models says provider defined categories must be in a different namespace but no more. Maybe extend this a bit further as to avoid namespace conflicts while combining many categories? I believe earlier revs of the spec said something like: com.example.<category_term>.<attr_name>
I don't recall that this ever has been discussed, but it certainly is a very good idea.
I do not quite understand the various Content-type headers used in the examples. Are they of any significance to the definition/use of categories?
No. They are just supposed to make it easier to spot the type within the core model. So, the MIME types would be something like application/occi-resource (for the Resource class from core) application/occi-link (for the Link class from core) ... (whatever else is defined as a class in core) That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
And just a few notes on the examples, sorry if it sounds picky but consistency really helps understanding:
- Category: compute; scheme="http://prov.com/occi#"; Scheme should be "http://prov.com/occi/resource#" right?
The URIs we used just served as example. For a category with term "foo" and scheme "bar", you would have Category: foo; scheme="bar";
- Link: </compute/123-123-123;start>; type="application/occi-action"; Is the "type" attribute of the Link header something new? If so, how it is defined?
We have been discussing yesterday whether the type attribute is necessary at all. Probably this has not found its way into the Wiki.
- In Link header: rel="category http://prov.com/occi#action" Is the format rel="category XXX" something new as well?
Yes. We tried to stick as much as possible to the IETF nottingham Link draft [1], not adding any additional vendor-specific extensions. HTH. Best, Alexander [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-04
On Fri, 13 Aug 2010 11:10:18 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
Alexander, On Fri, 13 Aug 2010 13:36:56 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
com.example.<category_term>.<attr_name>
I don't recall that this ever has been discussed, but it certainly is a very good idea.
The old (svn r164) docbook spec said: "Attributes defined by this standard reside at the root but anyone can define a new attribute by allocating a unique namespace based on their reversed Internet domain (e.g. “com.example.attribute”). I think such a namespace policy for attributes would be useful for the examples in the spec and related documents as well. An example is much easier to understand if the contents is well defined.
I do not quite understand the various Content-type headers used in the examples. Are they of any significance to the definition/use of categories?
No. They are just supposed to make it easier to spot the type within the core model. So, the MIME types would be something like
application/occi-resource (for the Resource class from core) application/occi-link (for the Link class from core) ... (whatever else is defined as a class in core)
That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
- In Link header: rel="category http://prov.com/occi#action" Is the format rel="category XXX" something new as well?
Yes. We tried to stick as much as possible to the IETF nottingham Link draft [1], not adding any additional vendor-specific extensions.
Hmm... reading the RFC-to-be version (from August 2010) I do not find "category" to be a registered relation type. Defined in some other document? regards, Ralf
Hey Ralf, Inline... On 13 Aug 2010, at 13:34, Ralf Nyren wrote:
Alexander,
On Fri, 13 Aug 2010 13:36:56 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
com.example.<category_term>.<attr_name>
I don't recall that this ever has been discussed, but it certainly is a very good idea.
The old (svn r164) docbook spec said: "Attributes defined by this standard reside at the root but anyone can define a new attribute by allocating a unique namespace based on their reversed Internet domain (e.g. “com.example.attribute”).
I think such a namespace policy for attributes would be useful for the examples in the spec and related documents as well. An example is much easier to understand if the contents is well defined.
AE: yep I agree with all of this - @Ralf would you be willing to place this up on the wiki under a page named something along the lines of "Extensions"
I do not quite understand the various Content-type headers used in the examples. Are they of any significance to the definition/use of categories?
No. They are just supposed to make it easier to spot the type within the core model. So, the MIME types would be something like
application/occi-resource (for the Resource class from core) application/occi-link (for the Link class from core) ... (whatever else is defined as a class in core)
That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
IMO, header and body are explicitly linked by content type - e.g. HTML - content type is specified as HTML in the header and the body will reflect this. It doesn't make sense to specify HTML as the content type in the header and then send a JPEG ;-)
- In Link header: rel="category http://prov.com/occi#action" Is the format rel="category XXX" something new as well?
Yes. We tried to stick as much as possible to the IETF nottingham Link draft [1], not adding any additional vendor-specific extensions.
Hmm... reading the RFC-to-be version (from August 2010) I do not find "category" to be a registered relation type. Defined in some other document?
"category" is not a registered rel type but can be. Do note that what is in the Category wiki page are merely explorations at this stage and so hence some vague aspects.
regards, Ralf _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
I think such a namespace policy for attributes would be useful for the examples in the spec and related documents as well. An example is much easier to understand if the contents is well defined.
AE: yep I agree with all of this - @Ralf would you be willing to place this up on the wiki under a page named something along the lines of "Extensions"
Will do.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
IMO, header and body are explicitly linked by content type - e.g. HTML - content type is specified as HTML in the header and the body will reflect this. It doesn't make sense to specify HTML as the content type in the header and then send a JPEG ;-)
Ah, but you misunderstand. In the examples you are using only headers (no body) and thus, IMO, the content-type is irrelevant. regards, Ralf
Am 13.08.2010 um 14:34 schrieb Ralf Nyren:
Alexander,
On Fri, 13 Aug 2010 13:36:56 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
com.example.<category_term>.<attr_name>
I don't recall that this ever has been discussed, but it certainly is a very good idea.
The old (svn r164) docbook spec said: "Attributes defined by this standard reside at the root but anyone can define a new attribute by allocating a unique namespace based on their reversed Internet domain (e.g. “com.example.attribute”).
I think such a namespace policy for attributes would be useful for the examples in the spec and related documents as well. An example is much easier to understand if the contents is well defined.
Agreed. This was just a quick and dirty thing. As soon as things merge into the "real" pages (core, infra or http), we have to take care of that.
I do not quite understand the various Content-type headers used in the examples. Are they of any significance to the definition/use of categories?
No. They are just supposed to make it easier to spot the type within the core model. So, the MIME types would be something like
application/occi-resource (for the Resource class from core) application/occi-link (for the Link class from core) ... (whatever else is defined as a class in core)
That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
Well, we will have to discuss this. I think that it would be good to use the content type for indicating what kind of type from the core model is currently shown; on the other hand, you are right: the MIME type indicates the content of the HTTP request/response.
- In Link header: rel="category http://prov.com/occi#action" Is the format rel="category XXX" something new as well?
Yes. We tried to stick as much as possible to the IETF nottingham Link draft [1], not adding any additional vendor-specific extensions.
Hmm... reading the RFC-to-be version (from August 2010) I do not find "category" to be a registered relation type. Defined in some other document?
No, but the "rel" item allows the registration of new terms ("category") in a defined manner. -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
Agreed. This was just a quick and dirty thing. As soon as things merge into the "real" pages (core, infra or http), we have to take care of that.
Ok, sorry for being picky. It just that I have come to read many different OCCI examples from various documents where the examples seem to always vary in some small aspects and it is hard to tell what is significant and what is not.
That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
Well, we will have to discuss this. I think that it would be good to use the content type for indicating what kind of type from the core model is currently shown; on the other hand, you are right: the MIME type indicates the content of the HTTP request/response.
I disagree, but we will have to discuss this of course. In older versions of the spec there are examples showing responses in application/ovf format. I think it is flexible to allow the response to a request to be returned in multiple formats. You should always provide the headers of course but the body could be plain/text, application/json, or whatever the client put in its Accept: header.
No, but the "rel" item allows the registration of new terms ("category") in a defined manner.
Ah, indeed. So what semantic difference would the use of "category" have in this case? Link: <...>; rel="http://scheme/xxx" vs Link: <...>; rel="category http://scheme/xxx" I.e. what are you trying to achieve here? regards, Ralf
Inline... On 13 Aug 2010, at 15:01, Ralf Nyren wrote:
Agreed. This was just a quick and dirty thing. As soon as things merge into the "real" pages (core, infra or http), we have to take care of that.
Ok, sorry for being picky. It just that I have come to read many different OCCI examples from various documents where the examples seem to always vary in some small aspects and it is hard to tell what is significant and what is not.
You are totally right to be so and it's very welcomed :-) Just bear in mind that the canonical documents are those currently on the wiki. Those that are found on google code are not and serve only as a past record.
That way, you don't have to analyze the details of a REST resource, but just look at the MIME type delivered by the OCCI container.
If just for the purpose of the example I can somewhat agree. Otherwise I would say the Content-type header only reflect the body and not what kind of information you happen to have in the header.
Well, we will have to discuss this. I think that it would be good to use the content type for indicating what kind of type from the core model is currently shown; on the other hand, you are right: the MIME type indicates the content of the HTTP request/response.
I disagree, but we will have to discuss this of course. In older versions of the spec there are examples showing responses in application/ovf format. I think it is flexible to allow the response to a request to be returned in multiple formats. You should always provide the headers of course but the body could be plain/text, application/json, or whatever the client put in its Accept: header.
Good and fair point. Maintaining the capability to send content types like OVF is highly desirable.
No, but the "rel" item allows the registration of new terms ("category") in a defined manner.
Ah, indeed. So what semantic difference would the use of "category" have in this case? Link: <...>; rel="http://scheme/xxx" vs Link: <...>; rel="category http://scheme/xxx"
I.e. what are you trying to achieve here?
Here the want was to indicate the Link's target type and that it was a defined by a Category with a canonical schema could be identified by the URI.
regards, Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi, Great write and example.. I have a couple of comments not covered by Ralf Nyren's emails. 1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms 2) The role of the "rel" attribute is undefined in the specification. In one example it is used as a Link attribute indicating the Link's Resource relative position in a sequence. In the GET response example, 'rel' is repurposed to extend the catagory of the Link. Rel will also be used in the RDFa representation possibly with a role differing from the examples. This will ultimately add to confusion for both the HTTP and RDFa implementations. I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme. -gary Edmonds, AndrewX wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://www.ogf.org/mailman/listinfo/occi-wg
RE: 2) It's not repurposed by OCCI rather the web linking specification [1]. The attribute "rel" is defined by the web linking specification. See page 6 of [1]. HTH, Andy [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-10 -----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: Monday, August 16, 2010 6:24 AM To: Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Categories and Types Hi, Great write and example.. I have a couple of comments not covered by Ralf Nyren's emails. 1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms 2) The role of the "rel" attribute is undefined in the specification. In one example it is used as a Link attribute indicating the Link's Resource relative position in a sequence. In the GET response example, 'rel' is repurposed to extend the catagory of the Link. Rel will also be used in the RDFa representation possibly with a role differing from the examples. This will ultimately add to confusion for both the HTTP and RDFa implementations. I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme. -gary Edmonds, AndrewX wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://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.
Hi, I'm not concerned about using "rel" per se, it the relationships considered permissible by OCCI which is the concern. Additionally, we need to express the elements of the we intend to use for OCCI. Application of method through examples is a good first step, but requires further definition in the specifications. Simply referencing RFCs may not be adequate to ensure and sustain interoperability. Referencing the section 6.2.2 in Rfc [1], it defines a registry of relationships for the 'rel' attribute. Outside of the ordered sequences, we seem to be defining new relationships or at least relationships undefined by the rfc [1]. The out of specification [1] relationships we need to define in the OCCI specification. I think we need to have a discussion on occi extensibility; method and form. BTW, I'm running into the similar issues with the console proposal. I have both credentials and security identifiers (SIDs) that fall into the extensibility issue. cheers, gary Edmonds, AndrewX wrote:
RE: 2)
It's not repurposed by OCCI rather the web linking specification [1]. The attribute "rel" is defined by the web linking specification. See page 6 of [1].
HTH,
Andy
[1] http://tools.ietf.org/html/draft-nottingham-http-link-header-10
-----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: Monday, August 16, 2010 6:24 AM To: Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Categories and Types
Hi,
Great write and example..
I have a couple of comments not covered by Ralf Nyren's emails.
1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms
2) The role of the "rel" attribute is undefined in the specification. In one example it is used as a Link attribute indicating the Link's Resource relative position in a sequence. In the GET response example, 'rel' is repurposed to extend the catagory of the Link. Rel will also be used in the RDFa representation possibly with a role differing from the examples. This will ultimately add to confusion for both the HTTP and RDFa implementations.
I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme.
-gary
Edmonds, AndrewX wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://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.
Good idea on extensibility - Ralf already started on this (at least on the ML). Do you have time to take that input and comments and form a wiki page on it? -----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: Monday, August 16, 2010 3:18 PM To: Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Categories and Types Hi, I'm not concerned about using "rel" per se, it the relationships considered permissible by OCCI which is the concern. Additionally, we need to express the elements of the we intend to use for OCCI. Application of method through examples is a good first step, but requires further definition in the specifications. Simply referencing RFCs may not be adequate to ensure and sustain interoperability. Referencing the section 6.2.2 in Rfc [1], it defines a registry of relationships for the 'rel' attribute. Outside of the ordered sequences, we seem to be defining new relationships or at least relationships undefined by the rfc [1]. The out of specification [1] relationships we need to define in the OCCI specification. I think we need to have a discussion on occi extensibility; method and form. BTW, I'm running into the similar issues with the console proposal. I have both credentials and security identifiers (SIDs) that fall into the extensibility issue. cheers, gary Edmonds, AndrewX wrote:
RE: 2)
It's not repurposed by OCCI rather the web linking specification [1]. The attribute "rel" is defined by the web linking specification. See page 6 of [1].
HTH,
Andy
[1] http://tools.ietf.org/html/draft-nottingham-http-link-header-10
-----Original Message----- From: Gary Mazz [mailto:garymazzaferro@gmail.com] Sent: Monday, August 16, 2010 6:24 AM To: Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Categories and Types
Hi,
Great write and example..
I have a couple of comments not covered by Ralf Nyren's emails.
1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms
2) The role of the "rel" attribute is undefined in the specification. In one example it is used as a Link attribute indicating the Link's Resource relative position in a sequence. In the GET response example, 'rel' is repurposed to extend the catagory of the Link. Rel will also be used in the RDFa representation possibly with a role differing from the examples. This will ultimately add to confusion for both the HTTP and RDFa implementations.
I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme.
-gary
Edmonds, AndrewX wrote:
Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc!
Andy
[1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Categor...
------------------------------------------------------------- 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 http://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.
------------------------------------------------------------- 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.
On Mon, 16 Aug 2010 07:23:35 +0200, Gary Mazz <garymazzaferro@gmail.com> wrote:
1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms
I am not sure I understand, could you give a simple example perhaps?
I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme.
As far as I understand we have, depending how you see things, a single namespace for attributes. If we go with the latest proposal and say that a Category can define a set of attributes we indeed need a policy on how these names should be constructed. Without to much thought put into this I would suggest a policy maybe like this: <reverse_domain>.<category_term>.<attribute> Any reverse domain starting with "occi" would be forbidden and only used be standard OCCI attributes. Another alternative could be: ext.<reverse_domain>.<category>.<attribute> Example: Let's say a provider need a few extra attributes to describe a compute resource, in this case the desired boot priority. GET /compute/vm01 Category: compute; scheme="http://schemas.ogf.org/occi/resource#"; title="Compute Resource" Category: compute; scheme="http://provider.com/occi/resource#"; title="Vendor Compute Resource Extensions" Attribute: occi.compute.memory="2.0" Attribute: occi.compute.speed="3.8" Attribute: com.provider.compute.boot_priority="harddisk,cdrom" Would that make sense? regards, Ralf
I've created a wiki page that captures this input and which can be added to. http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Extending Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, August 16, 2010 4:11 PM To: Gary Mazz; Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Categories and Types On Mon, 16 Aug 2010 07:23:35 +0200, Gary Mazz <garymazzaferro@gmail.com> wrote:
1) The use of multiple schemes and multiple attributes, permissible in headers may cause significant rendering and referential issues in the body. I'm fairly confident most parsers will have problems with this approach. If this scheme is also intended for a body, I'll create and example to examine the doms
I am not sure I understand, could you give a simple example perhaps?
I think before we start producing examples using extensions, we should define the types of extension permitted and define where they are placed in the model scheme.
As far as I understand we have, depending how you see things, a single namespace for attributes. If we go with the latest proposal and say that a Category can define a set of attributes we indeed need a policy on how these names should be constructed. Without to much thought put into this I would suggest a policy maybe like this: <reverse_domain>.<category_term>.<attribute> Any reverse domain starting with "occi" would be forbidden and only used be standard OCCI attributes. Another alternative could be: ext.<reverse_domain>.<category>.<attribute> Example: Let's say a provider need a few extra attributes to describe a compute resource, in this case the desired boot priority. GET /compute/vm01 Category: compute; scheme="http://schemas.ogf.org/occi/resource#"; title="Compute Resource" Category: compute; scheme="http://provider.com/occi/resource#"; title="Vendor Compute Resource Extensions" Attribute: occi.compute.memory="2.0" Attribute: occi.compute.speed="3.8" Attribute: com.provider.compute.boot_priority="harddisk,cdrom" Would that make sense? regards, Ralf ------------------------------------------------------------- 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.
Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1]. I think we need to revisit the reasons why we have linking in the first place. 1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. 2) We also realized we would need to integrate vendor proprietary implementations. 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones. This was all decided prior to the introduction of the occi http header implementation. During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope. This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa. *The Proposal:* *Name Changes:* I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors. *New Definitions:* *Reference: *A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities. ** *Association: *A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi. ** *Logic Rules: **Reference: * *Rule 1: *All References are part of the occi name space. *Rule 2: *One occi element is represented by one Reference. * Association: * *Rule 1: *Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. *Rule 2: *Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. * Rule 3:* Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. *Rule 4:* The URI is mandatory for an Association. *Rule 5:* An occi Title attribute is mandatory for an Association. *Rule 6:* An occi Summary attribute is optional for an Association. *Header Implementation Details:* Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field. *Header Implementation Benefit:* 1) Reduces Link attribute parsing complexity 2) Reduces provides better clarity of the information's purpose * HTML5/RDFa Implementation Details:* TBD I'll follow up with examples if there is interest cheers, gary [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Hi, I think using different terms for the different layers (entity model vs. http/html representation) is a practical thing:) There's one point though I couldn't catch in the proposal. The following rule is not intuitive for me: "Rule 2: One occi element is represented by one Reference." What does 'one' and 'represent' mean here? * By the classical term a reference is made from one entity to another hence a reference doesn't represent entites rather relationships between them. * Also by the classical term different references could be given to the same entity. That is supported by roles which specifie the entity roles within the relationship. Currently the OCCI entity model is simple enough so that Resources specify their roles. However when thinking of extension this might not be true... the same entity could play different roles... I might missed something..., so could you please clarify the above rule?:) Cheers, Gyula ________________________________ Feladó: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> [occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. augusztus 17. 12:04 Címzett: Edmonds, AndrewX Másolatot kap: occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: [occi-wg] Yet Another (non)Link Proposal Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1]. I think we need to revisit the reasons why we have linking in the first place. 1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. 2) We also realized we would need to integrate vendor proprietary implementations. 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones. This was all decided prior to the introduction of the occi http header implementation. During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope. This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa. The Proposal: Name Changes: I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors. New Definitions: Reference: A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities. Association: A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi. Logic Rules: Reference: Rule 1: All References are part of the occi name space. Rule 2: One occi element is represented by one Reference. Association: Rule 1: Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. Rule 2: Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. Rule 3: Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. Rule 4: The URI is mandatory for an Association. Rule 5: An occi Title attribute is mandatory for an Association. Rule 6: An occi Summary attribute is optional for an Association. Header Implementation Details: Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field. Header Implementation Benefit: 1) Reduces Link attribute parsing complexity 2) Reduces provides better clarity of the information's purpose HTML5/RDFa Implementation Details: TBD I'll follow up with examples if there is interest cheers, gary [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Hi Csom, Thanks for the response answered inline Csom Gyula wrote:
Hi, I think using different terms for the different layers (entity model vs. http/html representation) is a practical thing:) There's one point though I couldn't catch in the proposal. The following rule is not intuitive for me:
"Rule 2: One occi element is represented by one Reference."
What does 'one' and 'represent' mean here?
In this definition, I meant only one (1) occi element can be represented in a Reference field. In other proposals you could place multiple occi elements in the link field. This is not the case here.
* By the classical term a reference is made from one entity to another hence a reference doesn't represent entites rather relationships between them.
You make a good point and identify an hole in the proposal language. I was making the assumption that References and Associations exist as part of a Category, similar to the current link feild. That assumption should be clearly defined as a Rule. So, the occi element including the Reference is implicitly one end point of the the relationship and the occi entity contained in the Reference is the other end point of the relationship. This is also true of Associations. I'll clean that up today.
* Also by the classical term different references could be given to the same entity. That is supported by roles which specifie the entity roles within the relationship. Currently the OCCI entity model is simple enough so that Resources specify their roles. However when thinking of extension this might not be true... the same entity could play different roles...
I might missed something..., so could you please clarify the above rule?:)
Extension are directed at Associations. The role of the Association is defined by the extension and not the occi definition of the extension "end point"/"point of presence". The fact that some URI is placed in the Association field, already defines the relationship to the occi element as an extension. I took that approach to limit the number of explicitly defined roles and relationships. By placing the the relationship with the extension, it allows extension greater flexibly in terms of definition. We find a similar scenario with examining the 'rel' attribute definitions in the IETF Link Header Proposal. There are some rel attribute definitions that are significant for occi, while others are irrelevant and some occi relationships are not described at all in the 'rel' registry. I wanted to avoid that scenario. I hope I cleared up your questions.
Cheers, Gyula
________________________________ Feladó: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> [occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. augusztus 17. 12:04 Címzett: Edmonds, AndrewX Másolatot kap: occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: [occi-wg] Yet Another (non)Link Proposal
Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1].
I think we need to revisit the reasons why we have linking in the first place.
1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. 2) We also realized we would need to integrate vendor proprietary implementations. 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones.
This was all decided prior to the introduction of the occi http header implementation.
During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope.
This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa.
The Proposal:
Name Changes: I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors.
New Definitions:
Reference: A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities.
Association: A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi.
Logic Rules: Reference: Rule 1: All References are part of the occi name space. Rule 2: One occi element is represented by one Reference.
Association: Rule 1: Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. Rule 2: Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. Rule 3: Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. Rule 4: The URI is mandatory for an Association. Rule 5: An occi Title attribute is mandatory for an Association. Rule 6: An occi Summary attribute is optional for an Association.
Header Implementation Details: Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field.
Header Implementation Benefit: 1) Reduces Link attribute parsing complexity 2) Reduces provides better clarity of the information's purpose
HTML5/RDFa Implementation Details: TBD
I'll follow up with examples if there is interest
cheers, gary
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Hi! Thanks for your response! I've got the point: Rule2 below declares a multiplicity constraint (ie. one and only one... resource could be referenced). However regarding extension/association, it is not yet clear where and how you expose the roles. As stated below the role is specified by the extension, the question is how:) Lets take a theoraticel example (emphasis put on theoratical:)). I want to introduce n-tier semantics to OCCI through custom associations so that I define the following ones: * frontend references to a compute playing the frontend role (ie. UI) * application references to a compute playing the application server role * and finally db references to a compute acting as a database server For some reason application server (the entity) is linked to both the front end and db tier. Hence it (the entity) will have 2 associations referencing to the same resource type (Compute) but with different roles ('front end' and 'db'). So my extension has to differentiate between these associations somehow. After all the question is: where and how can i declare these roles when I define the above 3 custom associations? is there a 'role' an attribute of the Association? or is association a named element and its name declares its role? rel attribute should be used? any extension must include only one association (to a given entity)? or some other technique? Gyula ________________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com] Küldve: 2010. augusztus 17. 15:36 Címzett: Csom Gyula Másolatot kap: Edmonds, AndrewX; occi-wg@ogf.org Tárgy: Re: [occi-wg] Yet Another (non)Link Proposal Hi Csom, Thanks for the response answered inline Csom Gyula wrote:
Hi, I think using different terms for the different layers (entity model vs. http/html representation) is a practical thing:) There's one point though I couldn't catch in the proposal. The following rule is not intuitive for me:
"Rule 2: One occi element is represented by one Reference."
What does 'one' and 'represent' mean here?
In this definition, I meant only one (1) occi element can be represented in a Reference field. In other proposals you could place multiple occi elements in the link field. This is not the case here.
* By the classical term a reference is made from one entity to another hence a reference doesn't represent entites rather relationships between them.
You make a good point and identify an hole in the proposal language. I was making the assumption that References and Associations exist as part of a Category, similar to the current link feild. That assumption should be clearly defined as a Rule. So, the occi element including the Reference is implicitly one end point of the the relationship and the occi entity contained in the Reference is the other end point of the relationship. This is also true of Associations. I'll clean that up today.
* Also by the classical term different references could be given to the same entity. That is supported by roles which specifie the entity roles within the relationship. Currently the OCCI entity model is simple enough so that Resources specify their roles. However when thinking of extension this might not be true... the same entity could play different roles...
I might missed something..., so could you please clarify the above rule?:)
Extension are directed at Associations. The role of the Association is defined by the extension and not the occi definition of the extension "end point"/"point of presence". The fact that some URI is placed in the Association field, already defines the relationship to the occi element as an extension. I took that approach to limit the number of explicitly defined roles and relationships. By placing the the relationship with the extension, it allows extension greater flexibly in terms of definition. We find a similar scenario with examining the 'rel' attribute definitions in the IETF Link Header Proposal. There are some rel attribute definitions that are significant for occi, while others are irrelevant and some occi relationships are not described at all in the 'rel' registry. I wanted to avoid that scenario. I hope I cleared up your questions.
Cheers, Gyula
________________________________ Feladó: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> [occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. augusztus 17. 12:04 Címzett: Edmonds, AndrewX Másolatot kap: occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: [occi-wg] Yet Another (non)Link Proposal
Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1].
I think we need to revisit the reasons why we have linking in the first place.
1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. 2) We also realized we would need to integrate vendor proprietary implementations. 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones.
This was all decided prior to the introduction of the occi http header implementation.
During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope.
This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa.
The Proposal:
Name Changes: I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors.
New Definitions:
Reference: A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities.
Association: A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi.
Logic Rules: Reference: Rule 1: All References are part of the occi name space. Rule 2: One occi element is represented by one Reference.
Association: Rule 1: Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. Rule 2: Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. Rule 3: Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. Rule 4: The URI is mandatory for an Association. Rule 5: An occi Title attribute is mandatory for an Association. Rule 6: An occi Summary attribute is optional for an Association.
Header Implementation Details: Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field.
Header Implementation Benefit: 1) Reduces Link attribute parsing complexity 2) Reduces provides better clarity of the information's purpose
HTML5/RDFa Implementation Details: TBD
I'll follow up with examples if there is interest
cheers, gary
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Forgot some stuff... Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1]. I think we need to revisit the reasons why we have linking in the first place. 1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. 2) We also realized we would need to integrate vendor proprietary implementations. 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones. This was all decided prior to the introduction of the occi http header implementation. During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope. This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa. *The Proposal:* *Name Changes:* I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors. *New Definitions:* *Reference: *A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities. *Association: *A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi. *Logic Rules: **Reference: * *Rule 1: *All References are part of the occi name space. *Rule 2: *One occi element is represented by one Reference. *Rule 3:* The URI is mandatory for a Reference. *Rule 4:* An occi Title attribute is mandatory for a Reference. *Rule 5:* An occi Summary attribute is optional for a Reference. *Rule 6:* The 'rel' is is used to indicate position in ordered series. *Rule 7:* The 'rel' is optional for a Reference. * Association: * *Rule 1: *Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. *Rule 2: *Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. * Rule 3:* Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. *Rule 4:* The URI is mandatory for an Association. *Rule 5:* An occi Title attribute is mandatory for an Association. *Rule 6:* An occi Summary attribute is optional for an Association. *Header Implementation Details:* Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field. *Header Implementation Benefit:* 1) Reduces Link attribute parsing complexity 2) Reduces provides better clarity of the information's purpose * HTML5/RDFa Implementation Details:* TBD I'll follow up with examples if there is interest cheers, gary [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
participants (6)
-
Alexander Papaspyrou -
Andy Edmonds -
Csom Gyula -
Edmonds, AndrewX -
Gary Mazz -
Ralf Nyren