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

Martin P Pain martinpain at uk.ibm.com
Thu Feb 27 11:49:20 EST 2014


Looking back through the thread history, my final thoughts were in this 
email:
http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000644.html

In that email (modified by John's reply) I say that, if we use 
oslc_auto:desiredState (for the sake of reuse) and change its type 
description to be:

    The intended (domain- or provider-dependant) value of a 
    resource's (domain-dependant) 'state' property after some (future,
    present or past) process, transition or change. It is expected
    that this will be a resource reference to a definition of a valid
    state on the service provider.   For example, in the OSLC
    Automation domain this is used to indicate the desired state of
    the Automation Request based on values defined in the OSLC
    Automation specification and, optionally, by the service provider.

then "we would have purpose for oslc:StateTransitionAction (as it 
defines the state-machine type of actions)".

What I meant is that oslc_auto:desiredAction could be used to indicate the 
state transition that could be a side-effect of some other process, but 
the rdf:type value oslc:StateTransitionAction indicates that it is only 
about changing the state, or that the target state defines _everything_ 
that the action does, not that state change is merely a side-effect.

e.g. the difference between these two actions:

<1>
  # other properties would go here
  oslc:action [
    a oslc:StateTransitionAction, oslc:Action ;
    oslc_auto:desiredState x:Suspended ;
    dcterms:title "Suspend work on this item" ;
    # bindings would go here
  ]
  oslc:action [
    a reporting:FlagAsInappropriateAction, oslc:Action ;
    oslc_auto:desiredState x:Suspended ;
    dcterms:title "Flag as inappropriate" ;
    # bindings would go here
  ]
.

The former is explicitly about moving the outer resource (e.g. a work 
item) to a "suspended" state. The second has another effect (kicking off 
some investigation process into the appropriateness of whatever the 
resource represents) but also has a side effect of changing the state to 
"suspended" (e.g. it executes the first action as part of its own 
execution).

However, I accept that the desiredState property on the latter action 
doesn't have much use, because as a client you probably don't care, you 
just care about the action type.

I'm not overly opposed to removing oslc:StateTransitionAction, but I just 
wanted to clarify where I got to on that thread.

Steve, any changes on your position from this email? If not, don't worry 
about going in to detail.

If Steve doesn't reply with any changes, does anyone want to second his 
proposal? As long as this email has been taken into account, I won't 
object.



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
27/02/2014 16:20:39:

> From: Steve K Speicher <sspeiche at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Cc: oslc-cm at open-services.net
> Date: 27/02/2014 16:22
> Subject: Re: [Oslc-Automation] [oslc-cm] Some comments on Actions 
> spec (most from CM perspective)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > 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 
(interms of 
> > their effect) with some hypermedia decoration for client discovery... 
are/
> > might be state transition requests.  It's so general that I am andhave 
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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140227/d1b87a30/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140227/d1b87a30/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140227/d1b87a30/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140227/d1b87a30/attachment.gif>


More information about the Oslc-Automation mailing list