Michael, Thanks for the feedback. We certainly need to document all the actions we specify and will use a registry for that such that future functionality (I'll again use the example of being able to "teleport" a resource from one location to another) can be catered for. Regarding the "class" extension attribute on the link relations - its purpose is to group relations into different classes - e.g. actions vs pagination vs interfaces, etc. I used "class" because it's already specified elsewhere and its meaning is well understood - "type" on the other hand should be a content-type in which case type="action" would be illegal sfaict. I'll suggest "class" to Mark for possible inclusion in the Web Linking draft but regardless we can define our own extensions as we see fit (which is useful for things like local interface identifiers - e.g. "eth0" or "sda"). Sam On Wed, Oct 21, 2009 at 5:59 AM, Michael Behrens <michael.behrens@r2ad.com>wrote:

Sam, I presume that interested clients would parse for the value of the "rel" parameter in order to know the purpose of the link. If so, then I think that all the life-cycle values should also be listed in table 2 - Link Relations. I inserted the type="action" in the example below - I did not see "class" as a link-parameter in the draft-nottingham draft on web-linking. Also, I presume the title parameter would be optional.

< Link: </us-east/webapp/vm01;start>;< rel="http://purl.org/occi/action/start";

type="action"< title="Start"

Good discussion on this thread!....looking forward to the telecons and the future F2F (good idea Andre!).

PS: We are going to be implementing a small portion of the spec soon - initially will be coding up the GET verb. We'll share our experiences as soon as we can. I'll be coding up the client - so it should be able to hit our implementation and others too.

-- Michael Behrens