[occi-wg] Categories and Collections

[Andre Merzky]

Quoting [alexander.papaspyrou at 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 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
> >> http://www.ogf.org/mailman/listinfo/occi-wg
> > 
> > 
> > 
> > 
> > -- 
> > Nothing is ever easy.
> 





-- 
Nothing is ever easy.