[occi-wg] Categorization via link relations

[Sam Johnston]

Mike,

This was mentioned on the call today (during which I was unable to speak
despite calling in twice - presumably something at my end) and I definitely
agree with Alexis in that we shouldn't create new technology where we don't
absolutely have to. I wrote the Web
Categories<http://tools.ietf.org/html/draft-johnston-http-category-header-00>Internet-Draft
for OCCI because there didn't appear to be any existing
mechanism for this, but eventually came to the realisation (like you) that
it would be possible to convey this information via the Link: header. What's
possible and what's sensible aren't always the same thing though and I'd
argue that there's not much difference in terms of handling effort as you'll
most likely be dealing with raw headers anyway (remember we need schemes so
even if there was some intelligence to the handling of links we'd have to
bypass it for this).

A greater concern for me is the handling of properties/attributes. Rather
than give people carte blanche in terms of encouraging them to mint their
own headers for each additional property, I think it makes a lot more sense
to have e.g. a "Property" header which acts like a kind of server-side
cookie (and is modelled after Set-Cookie[2]). This is what is currently
documented and all the examples I've thrown at it all work nicely thus far.

Sam

On Sat, Jan 16, 2010 at 8:53 AM, Mike Kelly <mike at mykanjo.co.uk> wrote:

> Hi Sam,
>
> A reason for sticking to Link headers could be to keep 'consistency' in the
> protocol's hypertext mechanisms? Another reason is that tools for handling
> Link headers, client and server side, are likely to have broader
> availability.
> Cheers,
> Mike
>
>
> Sam Johnston wrote:
>
>> Mike,
>>
>> Thanks for taking the time to look at our specifications. The categories
>> are dealt with in a separate IETF Internet-Draft (
>> http://tools.ietf.org/html/draft-johnston-http-category-header-00) but
>> it's true that they could be layered on top of the Link: header. I hadn't
>> considered this option at the time but it does make some sense. OTOH we need
>> to sensibly layer properties/attributes on top of HTTP headers so we'll
>> probably be blazing our own trail there anyway (using Property:/Attribute:
>> headers modelled after Set-Cookie[2]:).
>>
>> Sam
>>
>> On Fri, Jan 8, 2010 at 8:23 PM, Mike Kelly <mike at mykanjo.co.uk <mailto:
>> mike at mykanjo.co.uk>> wrote:
>>
>>    I really like the protocol, you've done a great job
>>
>>    I have a question: Why is Category given a unique header, and not
>>    simply
>>    treated as another type of link relation for a resource?
>>
>>    i.e.
>>
>>    Category: compute;
>>     scheme="http://purl.org/occi/kind/";
>>     label="Compute Resource"
>>
>>    ..  could that actually be written as:
>>
>>    Link: <http://occi.org/kinds/compute>;
>>     rel=<http://purl.org/occi/kind>;
>>     title="Compute Resource"
>>
>>    Cheers,
>>    Mike
>>    _______________________________________________
>>    occi-wg mailing list
>>    occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>>
>>    http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100120/4b984709/attachment.html