[occi-wg] Categories and Collections
andre at merzky.net
Thu Oct 7 03:52:33 CDT 2010
Quoting [alexander.papaspyrou at 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
> 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... :-)
> 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  in section 18.104.22.168. 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
> >>>  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 at 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 at ogf.org
> >>> http://www.ogf.org/mailman/listinfo/occi-wg
> >> _______________________________________________
> >> occi-wg mailing list
> >> occi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/occi-wg
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> occi-wg mailing list
> occi-wg at ogf.org
Nothing is ever easy.
More information about the occi-wg