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

[Steve K Speicher]

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-automation at open-services.net
> Cc: oslc-cm at open-services.net
> Date: 02/26/2014 11:33 AM
> Subject: Re: [oslc-cm] [Oslc-Automation] Some comments on Actions spec 
(most
> from CM perspective)
> Sent by: "Oslc-Cm" <oslc-cm-bounces at open-services.net>
> 
> > 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. 
> 

That was my original comment [1] and Martin seemed to acknowledge its 
limited usefulness [2].

If I were a CM client, looking for a particular Action, I wouldn't look 
for rdf:type at all.  I would navigate oslc:action from a change request, 
or if it had some oslc_cm: domain predicate, to a resource which had the 
properties I was interested in: namely oslc_[cm|auto]:desiredState to pick 
the right action and other terms to know where and what to POST.  The 
object of :desiredState tells me all I need to know which one to pick.

So from a client/server interaction, I don't need the sub type.  From a 
query/reporting point of view, I don't have any queries I can think of. 
Brainstorming on it: show me all in-progress change requests that have 
oslc:StateTransitionActions.  Not sure I see a use case or need for it. 
Seems like oslc:Action and :desiredState would be enough.  I see you have 
oslc:UpdateAction, which doesn't really help the CM clients either (as not 
sure I'd even look at the type unless I REALLY wanted to validate 
everything I fetch).

So I've propose to remove oslc:StateTransitionAction from the Action spec. 
 It could be added back later if a clear need arises.

[1] - 
http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000635.html
[2] - 
http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000636.html

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net



> 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 
> _______________________________________________
> Oslc-Cm mailing list
> Oslc-Cm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140227/99da3298/attachment-0003.html>