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