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

Martin P Pain martinpain at uk.ibm.com
Thu Jan 30 12:27:04 EST 2014


> 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.

What would you make of this sort of definition?

An resource (action) of type oslc:StateTransitionAction MUST contain an 
oslc:targetState predicate set to the value that the context's "state" 
property will be changed to by executing this action. Actions of this 
type, if successful, MUST change the object of the a triple, whose subject 
is the context resource and whose predicate is the "state" predicate 
defined by the resource's domain, to the value stated in the action 
resource, as part of a state machine[1][2] (which MAY be finite or 
infinite). Consumers MAY list all oslc:StateTransitionActions from a 
particular context together, for example in a drop-down list, as the list 
of valid states that this context resource may go to in its state model.

[1] http://en.wikipedia.org/wiki/Finite-state_machine
[2] http://en.wikipedia.org/wiki/State_transition_system

(Of course, if making this general, we might want to make it explicit in 
the data what the state predicate is in the context resource, which might 
allow multiple state machines per resource as different actions could 
refer to different "state" predicates. This then makes it more complicated 
than the CM example as it currently stands.)

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 
30/01/2014 13:40:07:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Cc: oslc-cm at open-services.net
> Date: 30/01/2014 13:40
> Subject: Re: [Oslc-Automation] Some comments on Actions spec (most 
> from CM perspective)
> Sent by: "Oslc-Automation" <oslc-automation-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. 
> 
> 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-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-cm_open-services.net/attachments/20140130/39a5bd83/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-cm_open-services.net/attachments/20140130/39a5bd83/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-cm_open-services.net/attachments/20140130/39a5bd83/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-cm_open-services.net/attachments/20140130/39a5bd83/attachment.gif>


More information about the Oslc-Cm mailing list