[Oslc-Automation] Reusing Cm's Actions for teardown/operations

[Charles Rankin]

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
08/30/2013 07:25:18 AM:

> From: Martin P Pain <martinpain at uk.ibm.com>
>
> The problem that I see right now for AutomationPlan being an 
> implementation of an action is that the POST behaviour seems to be 
> defined on the predicate, not on the Action resource type.

I'm not reading it that way. The example in the CM draft spec shows

<http://example.com/bugs/1234> oslc_cm:action <
http://example.com/bugs/action/resolve>

And the POST goes to <http://example.com/bugs/action/resolve> which is the 
object of the triple, unless I'm misreading the spec of misunderstanding 
what you were getting at.

> If we 
> suggested they move that so that the action predicate can in theory 
> point to anything, then on inspection of its target if it's an 
> Action resource you can POST to it, if it's an AutomationPlan (or 
> our other intermediate resource) you can submit a request. (And 
> providers could multi-type it and support both... but we're still 
> getting into multiple ways of doing things. Although you could look 
> at the Action approach as a way of saying "you can use the classic 
> REST HTTP primatives")

I agree with you and John that I don't really like two ways of doing 
things.

For the moment, let's assume that John's suggestion that it is a naked 
POST to the URL that wins out.  Then, what if you didn't (necessarily) 
post to the Action Resource itself, but the Action Resource contained a 
reference to the URL that you did POST to?  Finally (and this is a change 
to what we've been talking about), what if for automation the URL 
reference (inside the Action in the Automation Result) wasn't to an 
Automation Plan, but was to an Automation Request (at least in the OSLC 
Automation space)?

So for OSLC automation, it might look like (in part) something like this 
(pardon me butchering syntax, hopefully the intent comes through)

  <http://example.com/results/result1>
    oslc:action <http://example.com/action/action1>

  <http://example.com/action/action1>
    oslc_auto:usage oslc_auto:teardown
    oslc:actionInvocation <
http://example.com/requests/request1?whatever-is-needed-to-naked-post>

With this, you could also have the Action Resources be inline anonymous 
nodes, at least in the OSLC Automation case.

For OSLC CM, they could have the action be self-referential, like this

  <http://example.com/bugs/bug1>
    oslc:action <http://example.com/action/bugs/resolve>

  <http://example.com/action/bugs/resolve>
    oslc:actionInvocation <
http://example.com/action/bugs/resolve?whatever-is-needed-to-naked-post>

Here you couldn't have inline anonymous nodes, but CM wasn't looking to do 
that anyway.

Note, when referencing an "action" from an Automation Plan, I think you'd 
still point to the Automation Plan.

Charles Rankin
IBM Watson System Test
101/4L-002 T/L 966-2386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130830/39201c4c/attachment-0003.html>