[Oslc-Automation] Some comments on Actions spec (most from CM perspective)

[John Arwe]

> Comment on section [2] 
> I'm not sure why the domain specific types are here.  Seems like 
> something that would be in CM spec.  In fact, we probably wouldn't 
> define a oslc:StateTransitionAction but instead just call it 
> oslc:Action.  Seems like the parent class is extraneous.  Clients 
> will be looking for oslc_cm:targetState to determine which action to 
pick. 
> What value is there in having this separate type? 

Personally, I've been dubious about oslc:StateTransitionAction for a while 
but I've been letting the rest of it settle a bit before calling it out. 
"Dubious" simply because all write requests... generic PUT, PATCH, POST, 
etc but also all actions which a purist might argue act like POSTs (in 
terms of their effect) with some hypermedia decoration for client 
discovery... are/might be state transition requests.  It's so general that 
I am and have been unclear what it adds beyond oslc:Action; it is entirely 
possible that such a difference exists and simply has not been articulated 
such that I can grasp it, but that's my current state.

Turning it around: if I have some action Foo that I want to expose, I 
would hope that the type definition would tell me whether or not I should 
be using oslc:StateTransitionAction amongst the types.  If, in effect, all 
actions are of types oslc:StateTransitionAction and oslc:Action, that's 
evidence that they're redundant.  If we find a scenario where clients 
cannot run the scenario without oslc:StateTransitionAction (which is 
different than saying it Can be used), that would be evidence that it's 
really needed and might lead to a description that distinguishes it from 
:Action.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140130/07b14ed7/attachment-0003.html>