Hi Charles, What I was meaning by: > the POST behaviour seems to be > defined on the predicate, not on the Action resource type.
is that in the following tuple: > <http://example.com/bugs/1234> oslc_cm:action < http://example.com/bugs/action/resolve> The way that the client knows to POST on the object is because it is the object of an "oslc_cm:action" predicate. Not by performing a GET on it and seeing that it is of type oslc_cm:Action. If we wanted it to be compatible with AutoPlans, we would need the spec to instruct the client to use this introspection to determine what action to perform, not just assume based on the predicate. It's possible that the draft is merely ambiguous right now, but IMO we would need it to be specific, and would need it to instruct consumers to determine the correct behaviour by looking at the rdf:type of the object, not at the predicate. > 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)? I'm not sure CM would be happy with that level of indirection, but it does work much better for us. I'm not sure about the idea of it pointing to an AutomationRequest. If we add the state that we've talked about before of "created, but will not be executed until further notice", then we could do that for teardown, as it will only be executed once. However, for actions such as "stop", "start", "pause", "resume", "clear logs", etc, these might be executed multiple times. Currently my understanding is that an AutoRequest is only ever executed once, but I guess that doesn't have to be the case. But is it unnecessarily complicating things - adding new ideas when we don't need them? As perhaps if you want something "executable", it's an AutoPlan. (But then perhaps all other options are adding complexity too.) Also, I don't know if this was your intention, but I'm not sure we would want to make a naked POST on an AutoRequest execute it. (Although that would get us around the "where's the right creation factory" problem. Or for that matter, we could support this on an AutoPlan too, as long as it doesn't have any requires parameters.) What do you think? Could you clarify your suggestion, taking these thoughts into account? Thanks, Martin From: Charles Rankin <[email protected]> To: [email protected], Date: 30/08/2013 15:32 Subject: Re: [Oslc-Automation] Reusing Cm's Actions for teardown/operations Sent by: "Oslc-Automation" <[email protected]> "Oslc-Automation" <[email protected]> wrote on 08/30/2013 07:25:18 AM: > From: Martin P Pain <[email protected]> > > 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_______________________________________________ Oslc-Automation mailing list [email protected] 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
