Categories and Collections
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible. http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section. Andy andy.edmonds.be
Looks fine to me. We could, BTW, take the same approach we took for tags also for navigation (i.e. defining a mandatory category for navigation in the normative core spec). Just an idea... -Alexander Am 03.10.2010 um 17:16 schrieb Andy Edmonds:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be <ATT00001..txt>
Nice work Andy! A few comments: - Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection? - The section on Navigation refer to Links and Actions, is this the Core base types referred to? The Core Link type has little to do with paging from my point of view. The Link Header in HTTP on the other hand can be used for _both_ representing Core Links and paging. I see how Core Actions can be used to express paging but the way Actions are rendered in HTTP using Link Headers has again little to do with the Link base type. Please see "Actions and the Link Header" at the end of [1] for a full description of this terminology confusion. - When the http://schemas.ogf.org/occi/core# was introduced I thought it a good idea to have it reserved for Categories defining the OCCI base types (i.e. Resource, Link, Action). Although not necessary I think keeping this distinction make the spec a bit easier to understand. The current definition of Categories is: The Category type represent the classification mechanism used by OCCI. It MUST be implemented. From a system point of view a Category is used for two different classification purposes. See also section 4.3 "Type System". 1. Taxonomy. A Category is used to assign static type information to each resource type inheriting Kind or a descendant of Kind. This use of Categories denotes the OCCI "static type system". A unique Category MUST be assigned to every descendant of Kind. See the section 4.1.2.1 "Hierarchy". 2. Folksonomy. A Category can be used to assign tags to resource instances via a mix-in like model. A Category mix-in MUST NOT be related to an OCCI base type (or any descendent of Kind) and MUST NOT be the unique identifier thereof. Example use cases are collections, location information and templates for virtual machine provisioning. Collections play nicely with 2, the "folksonomy" use of Categories. My point is that maybe we should have different schemes for Category use case 1 and 2, that is for Categories defined in Core. What do you think? It is not terribly important though. I.e. use a different scheme for the "tag" Category. I will annotate the wiki page as well. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
Hey Ralf, I've placed my replies inline... Cheers! -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, October 04, 2010 5:42 PM To: Andy Edmonds; occi-wg Subject: Re: [occi-wg] Categories and Collections Nice work Andy! A few comments: - Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection? AE: I'll get some examples added asap. - The section on Navigation refer to Links and Actions, is this the Core base types referred to? The Core Link type has little to do with paging from my point of view. The Link Header in HTTP on the other hand can be used for _both_ representing Core Links and paging. I see how Core Actions can be used to express paging but the way Actions are rendered in HTTP using Link Headers has again little to do with the Link base type. Please see "Actions and the Link Header" at the end of [1] for a full description of this terminology confusion. AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. [1] http://www.ogf.org/Public_Comment_Docs/Documents/2010-01/occi-core.pdf - When the http://schemas.ogf.org/occi/core# was introduced I thought it a good idea to have it reserved for Categories defining the OCCI base types (i.e. Resource, Link, Action). Although not necessary I think keeping this distinction make the spec a bit easier to understand. The current definition of Categories is: The Category type represent the classification mechanism used by OCCI. It MUST be implemented. From a system point of view a Category is used for two different classification purposes. See also section 4.3 "Type System". 1. Taxonomy. A Category is used to assign static type information to each resource type inheriting Kind or a descendant of Kind. This use of Categories denotes the OCCI "static type system". A unique Category MUST be assigned to every descendant of Kind. See the section 4.1.2.1 "Hierarchy". 2. Folksonomy. A Category can be used to assign tags to resource instances via a mix-in like model. A Category mix-in MUST NOT be related to an OCCI base type (or any descendent of Kind) and MUST NOT be the unique identifier thereof. Example use cases are collections, location information and templates for virtual machine provisioning. Collections play nicely with 2, the "folksonomy" use of Categories. My point is that maybe we should have different schemes for Category use case 1 and 2, that is for Categories defined in Core. What do you think? It is not terribly important though. I.e. use a different scheme for the "tag" Category. AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? I will annotate the wiki page as well. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
_______________________________________________ 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.
I'd probably keep the "core" namespace for categories. This ensures that (a) we don't have unnecessary namespace clutter and (b) that we can declare this very namespace as reserved for occi core normative extensions. -Alexander Am 04.10.2010 um 22:56 schrieb Edmonds, AndrewX:
Hey Ralf, I've placed my replies inline...
Cheers!
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, October 04, 2010 5:42 PM To: Andy Edmonds; occi-wg Subject: Re: [occi-wg] Categories and Collections
Nice work Andy!
A few comments:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap.
- The section on Navigation refer to Links and Actions, is this the Core base types referred to? The Core Link type has little to do with paging from my point of view. The Link Header in HTTP on the other hand can be used for _both_ representing Core Links and paging. I see how Core Actions can be used to express paging but the way Actions are rendered in HTTP using Link Headers has again little to do with the Link base type. Please see "Actions and the Link Header" at the end of [1] for a full description of this terminology confusion.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior.
[1] http://www.ogf.org/Public_Comment_Docs/Documents/2010-01/occi-core.pdf
- When the http://schemas.ogf.org/occi/core# was introduced I thought it a good idea to have it reserved for Categories defining the OCCI base types (i.e. Resource, Link, Action). Although not necessary I think keeping this distinction make the spec a bit easier to understand. The current definition of Categories is:
The Category type represent the classification mechanism used by OCCI. It MUST be implemented. From a system point of view a Category is used for two different classification purposes. See also section 4.3 "Type System".
1. Taxonomy. A Category is used to assign static type information to each resource type inheriting Kind or a descendant of Kind. This use of Categories denotes the OCCI "static type system". A unique Category MUST be assigned to every descendant of Kind. See the section 4.1.2.1 "Hierarchy". 2. Folksonomy. A Category can be used to assign tags to resource instances via a mix-in like model. A Category mix-in MUST NOT be related to an OCCI base type (or any descendent of Kind) and MUST NOT be the unique identifier thereof. Example use cases are collections, location information and templates for virtual machine provisioning.
Collections play nicely with 2, the "folksonomy" use of Categories. My point is that maybe we should have different schemes for Category use case 1 and 2, that is for Categories defined in Core. What do you think? It is not terribly important though. I.e. use a different scheme for the "tag" Category.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags?
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg <smime.p7s><ATT00001..txt><ATT00002..txt>
I agree. -----Original Message----- From: alexander.papaspyrou@tu-dortmund.de [mailto:alexander.papaspyrou@tu-dortmund.de] Sent: Wednesday, October 06, 2010 9:36 AM To: Edmonds, AndrewX Cc: ralf@nyren.net; occi-wg@ogf.org Subject: Re: [occi-wg] Categories and Collections I'd probably keep the "core" namespace for categories. This ensures that (a) we don't have unnecessary namespace clutter and (b) that we can declare this very namespace as reserved for occi core normative extensions. -Alexander Am 04.10.2010 um 22:56 schrieb Edmonds, AndrewX:
Hey Ralf, I've placed my replies inline...
Cheers!
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, October 04, 2010 5:42 PM To: Andy Edmonds; occi-wg Subject: Re: [occi-wg] Categories and Collections
Nice work Andy!
A few comments:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap.
- The section on Navigation refer to Links and Actions, is this the Core base types referred to? The Core Link type has little to do with paging from my point of view. The Link Header in HTTP on the other hand can be used for _both_ representing Core Links and paging. I see how Core Actions
can be used to express paging but the way Actions are rendered in HTTP using Link Headers has again little to do with the Link base type. Please
see "Actions and the Link Header" at the end of [1] for a full description
of this terminology confusion.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior.
[1] http://www.ogf.org/Public_Comment_Docs/Documents/2010-01/occi-core.pdf
- When the http://schemas.ogf.org/occi/core# was introduced I thought it a
good idea to have it reserved for Categories defining the OCCI base types
(i.e. Resource, Link, Action). Although not necessary I think keeping this
distinction make the spec a bit easier to understand. The current definition of Categories is:
The Category type represent the classification mechanism used by OCCI. It
MUST be implemented. From a system point of view a Category is used for two different classification purposes. See also section 4.3 "Type System".
1. Taxonomy. A Category is used to assign static type information to each
resource type inheriting Kind or a descendant of Kind. This use of Categories denotes the OCCI "static type system". A unique Category MUST be assigned to every descendant of Kind. See the section 4.1.2.1 "Hierarchy". 2. Folksonomy. A Category can be used to assign tags to resource instances
via a mix-in like model. A Category mix-in MUST NOT be related to an OCCI
base type (or any descendent of Kind) and MUST NOT be the unique identifier thereof. Example use cases are collections, location information and templates for virtual machine provisioning.
Collections play nicely with 2, the "folksonomy" use of Categories. My point is that maybe we should have different schemes for Category use case
1 and 2, that is for Categories defined in Core. What do you think? It is
not terribly important though. I.e. use a different scheme for the "tag" Category.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags?
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg <smime.p7s><ATT00001..txt><ATT00002..txt>
------------------------------------------------------------- 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.
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap.
Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior.
Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers. Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags?
We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future? Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections? regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Great work adding tags into the collections. Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions. We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability. -gary On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
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
Good point - add something like "MUST only be used to relay informative metadata" to the section on tags? Andy On 7 Oct 2010, at 09:46, Gary Mazz <garymazzaferro@gmail.com> wrote:
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
-gary
On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Quoting [Gary Mazz] (Oct 07 2010):
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
+1 One should check the use cases if this limitation is practical though. -- Nothing is ever easy.
Although I see the threat Gary sketched, I don't think this is a serious problem. OCCI core is clearly designed in a way that you use a category for describing the specifics of a resource. That is, for infrastructure, there will be the ominous ComputeResource category which defines certain attributes for this very type of "thing". Of course a provider can come up with the stupid idea to leave the "os" field in such a category empty, and rather attach a tag called "SuperOperatingSystemOneDotFive" to it, but this really bends over the spec in a way that you can safely assume the implementor *wants* to break things... Just my thoughts, though... -Alexander Am 07.10.2010 um 09:46 schrieb Gary Mazz:
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
-gary
On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Quoting [alexander.papaspyrou@tu-dortmund.de] (Oct 07 2010):
Although I see the threat Gary sketched, I don't think this is a serious problem. OCCI core is clearly designed in a way that you use a category for describing the specifics of a resource. That is, for infrastructure, there will be the ominous ComputeResource category which defines certain attributes for this very type of "thing".
Of course a provider can come up with the stupid idea to leave the "os" field in such a category empty, and rather attach a tag called "SuperOperatingSystemOneDotFive" to it, but this really bends over the spec in a way that you can safely assume the implementor *wants* to break things...
You may be right here - but, IMVHO, a spec should make it *hard* to break interop. In particular if your target implementors which have a vested interest in claiming standards compliance, but also have an interest in binding useres to their own solutions / infrastructure.
Just my thoughts, though...
Same here... :-) Andre.
-Alexander
Am 07.10.2010 um 09:46 schrieb Gary Mazz:
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
-gary
On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
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
_______________________________________________ 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
-- Nothing is ever easy.
Heh. True enough :-) Am 07.10.2010 um 10:52 schrieb Andre Merzky:
Quoting [alexander.papaspyrou@tu-dortmund.de] (Oct 07 2010):
Although I see the threat Gary sketched, I don't think this is a serious problem. OCCI core is clearly designed in a way that you use a category for describing the specifics of a resource. That is, for infrastructure, there will be the ominous ComputeResource category which defines certain attributes for this very type of "thing".
Of course a provider can come up with the stupid idea to leave the "os" field in such a category empty, and rather attach a tag called "SuperOperatingSystemOneDotFive" to it, but this really bends over the spec in a way that you can safely assume the implementor *wants* to break things...
You may be right here - but, IMVHO, a spec should make it *hard* to break interop. In particular if your target implementors which have a vested interest in claiming standards compliance, but also have an interest in binding useres to their own solutions / infrastructure.
Maybe we have to spell out the purpose of the different elements more explicitly. I really can't come up with a different/better approach... I would however welcome input on this from our AD / OGF veteran ;-)
Am 07.10.2010 um 09:46 schrieb Gary Mazz:
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
-gary
On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible.
http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections
If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section.
Andy andy.edmonds.be
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
_______________________________________________ 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
-- Nothing is ever easy.
Quoting [alexander.papaspyrou@tu-dortmund.de] (Oct 07 2010):
You may be right here - but, IMVHO, a spec should make it *hard* to break interop. In particular if your target implementors which have a vested interest in claiming standards compliance, but also have an interest in binding useres to their own solutions / infrastructure.
Maybe we have to spell out the purpose of the different elements more explicitly. I really can't come up with a different/better approach... I would however welcome input on this from our AD / OGF veteran ;-)
LOL I am likely missing most of the technical details in question, but in general terms, yes, I'd advice to be be as specific as possible in the (core) spec, to foster interop, without excluding known and expected use cases. Specific (i.e. well defined) extension points, as the tags seem to be, are always useful for the *unexpected* use cases, which will appear w/o any doubt - but they should be reserved for those, and not collide with the previously defined elements. That really is just my private opinion, and very general, too - not sure how well it applies to the problem at hand. Best, Andre.
Am 07.10.2010 um 09:46 schrieb Gary Mazz:
Great work adding tags into the collections.
Adding tags may be two edged sword. They allow "folksonomy" a path into occi, but tags may be used by providers to represent technical aspects of their infrastructure. This could be catastrophic for interoperability. For example, a provider elects to use tags to represent an OS instead of a template. As/if this practice continues, we may end up with tags de jour, crippling interoperability and devaluing formalized extensions.
We can minimize the impact by limiting tag usage to informative metadata, not impacting resource provisioning or operations. This would encourage providers to use extensions and provide a taxonomy for extension impacting interoperability.
-gary
On 10/6/2010 4:11 AM, Ralf Nyren wrote:
- Could we have some HTTP-rendering examples of how to add/remove Kind instances to/from a collection other than the defining collection?
AE: I'll get some examples added asap. Good, I just want to make sure the add/remove collection tag thing does not end up with the same problems as we had with Links in the past.
AE: Ooops my mistake - Actions should not have been mentioned (I'll make that edit). Paging through collections should be accomplished using Links (e.g. in HTTP header renderings) as you point out. A beginning example can be found here [1] in section 1.4.3.1. We need to make sure that the current incarnation of Links can accommodate this behavior. Implementing navigation using Link Headers should be easy, we can grab that part directly from the RFC and it will not conflict with the OCCI specific use of Link Headers.
Regarding confusing terminology could we be _very_ consistent on using "Link Header" when we refer to RFC5988 and just "Link" when referring to the OCCI base type? I think we should at least consider renaming the OCCI Link base type to something else because the current situation will confuse people.
AE: we could use something like "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags? We could but Alex point of keeping the namespace clean is also important. Not sure which is best. Will there be only one Category for the collection stuff or will there be more (defined by Core) in the future?
Speaking of user defined collections. How is the mix-in attribute occi.core.tag supposed to work when a user adds a Resource instance to 2 or more collections?
regards, Ralf
I will annotate the wiki page as well.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds<andy@edmonds.be> wrote:
> Hey all, > I've placed a write up of how categories and collections related to each > other. Also there is how one can interact with collections. I've tried > to > keep the description as non-rendering-specific as possible. > > http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections > > If there are comments etc please annotate the wiki page at the > appropriate > place or place your questions in the "Open Issues" section. > > Andy > andy.edmonds.be _______________________________________________ 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
_______________________________________________ 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
-- Nothing is ever easy.
-- Nothing is ever easy.
I’ve updated the page detailing some aspects of the HTTP Header rendering specifics of multipart requests. These allow a client request multiple resources per atomic request. I’ll get on to working in suggestions and replying to all of your useful comments J Andy From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andy Edmonds Sent: Sunday, October 03, 2010 5:17 PM To: occi-wg Subject: [occi-wg] Categories and Collections Hey all, I've placed a write up of how categories and collections related to each other. Also there is how one can interact with collections. I've tried to keep the description as non-rendering-specific as possible. http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Collections If there are comments etc please annotate the wiki page at the appropriate place or place your questions in the "Open Issues" section. Andy andy.edmonds.be ------------------------------------------------------------- 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.
participants (7)
-
alexander.papaspyrou＠tu-dortmund.de -
Andre Merzky -
Andy Edmonds -
Andy Edmonds -
Edmonds, AndrewX -
Gary Mazz -
Ralf Nyren