[occi-wg] Categories and Collections
alexander.papaspyrou at tu-dortmund.de
alexander.papaspyrou at tu-dortmund.de
Thu Oct 7 03:57:30 CDT 2010
Heh. True enough :-)
Am 07.10.2010 um 10:52 schrieb Andre Merzky:
> 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
>> "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 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20101007/ca8aee8e/attachment-0001.bin
More information about the occi-wg
mailing list