[oslc-cm] [Oslc-Automation] Some comments on Actions spec (most from CM perspective)
John Arwe
johnarwe at us.ibm.com
Mon Mar 3 15:16:06 EST 2014
> oslc_auto:desiredAction could be used to indicate the state transition
that could be a side-effect of some other process
Maybe this depends on how we're reading "desired", and we're reading it
differently. I read "desired" to mean "the client's desired", not a side
effect. Since side effects are essentially unlimited, listing (some known
subset of) them doesn't obviously buy me anything. Using "intended" in
the definition sounds the same (client's intent is how I read it).
If there is some need for listing side effects, let's get that on the
table ... and use a predicate that sounds less intent-ful.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Martin P Pain <martinpain at uk.ibm.com>
To: Steve K Speicher/Raleigh/IBM at IBMUS,
Cc: oslc-automation at open-services.net, oslc-cm at open-services.net,
Oslc-Automation <oslc-automation-bounces at open-services.net>
Date: 02/27/2014 11:50 AM
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>
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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140303/8c043281/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/20140303/8c043281/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/20140303/8c043281/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/20140303/8c043281/attachment.gif>
More information about the Oslc-Cm
mailing list