[Oslc-Automation] [oslc-cm] Some comments on Actions spec (most from CM perspective)
Martin P Pain
martinpain at uk.ibm.com
Tue Mar 4 06:46:23 EST 2014
In this case, that side-effect is how the consumer chooses which action to
execute (although it may be through a human-readable form in the
dcterms:title, rather than that predicate itself, but it is still the same
information). Therefore when the consumer executes that action, the state
given by that predicate is the consumer's desired state. It's just they're
not setting that predicate itself, they're choosing an action resource
based on the value of that predicate.
Is that still enough of a difference for you to use a different predicate?
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
03/03/2014 20:16:06:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Cc: oslc-cm at open-services.net
> Date: 03/03/2014 20:17
> 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>
>
> > 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: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
>
>
>
>
> 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 callingit
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
> _______________________________________________
> 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/20140304/e6bf3487/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/20140304/e6bf3487/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/20140304/e6bf3487/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/20140304/e6bf3487/attachment.gif>
More information about the Oslc-Automation
mailing list