action:request [ a oslc:Dialog ] seems like it would work, and certainly re-uses existing concepts & artifacts in what looks like a completely sensible way.
Are these scenarios heading to a wiki page? I'm a *bit* confused when you say that scenarios B and C are "specific to the Automation profile". It is true that the Automation *spec* defines what usage=template means. Automation is the only spec I'm aware of that overloaded resource creation with additional semantics (flogs self Again for missing that in 2.0 review phase), but I'd hope that we're drafting the usage URI in such a way that another spec Could re-use it if a similar situation arose. Being defined by the Automation spec alone therefore does not tie templates to the Automation profile. Put another way: if we assume that action:request [ a oslc:Dialog ] is the syntax, and the semantic of action:request is "contains instructions for executing the Action", then if a particular set of instructions includes usage=template do we consider that an error (since usage=template conflicts somehow with ... I'm not sure what, but maybe I'm missing something) ? The reason we needed usage=template is that there is a semantic "create means create now" carried by creation factories in general, but *the knowledge that the dialog was for a creation factory* came from following a oslc:creationDialog link in a service provider document, a context/semantic that Actions does not have. I think this is the reason Steve suggested calling these "action dialogs", to clearly distinguish them (and along the way give us the opportunity to define the semantics differently if needed). We could, for example, create usage URIs like "execute immediately" for actions, and require 1:* usage URIs on action dialogs; all URIs on a given dialog must be "compatible" in the same sense that Automation uses to enable logical subclassing of verdicts/states, and a client must not use a dialog unless it understands at least one of those URIs. That allows profiles (defined in Core, or elsewhere) to define dialogs with different semantics without having to worry about (compliant) clients getting unexpected results. One such profile might be called "deferred execution". For the moment, I'll assume that's defined separately from the Automation profile (combining them later if we decide they must be is always easier than untangling things after the fact). What we need for this is actually 2 dialogs: one to create the template, and one that accepts a template as pre-fill (using existing terminology) and executes it immediately (a standard creation dialog that accepts pre-fill; we need to think through what the interaction pattern (responses) should be). We *could* define a single "execute immediately" interaction pattern that works for both cases, I think...strawman off the cuff would be: 200 or 204 = succeeded already; poll the resource being acted upon to find current state. 202 = queued for execution (accepted but not yet completed). HTTP says the response payload contains a "monitor" in this case, but not what a monitor is - left completely open; we could say that the monitor (if you're using our usage URI) SHOULD be an Automation Request, with a Location header (allowed by HTTP, but no meaning assigned to that in HTTP). IF the client wants to know when/if the request completes (and its ultimate status), THEN the client needs to poll the monitor resource (no query, no service provider needed, just GET the Location URI) and use the state/verdict properties in the result per Automation 2.0. The provider is required to clean these up w/o any client DELETE request (my strawman - not the client's fault that the server queues the request, the client wasn't really Trying to create some new resource it would be responsible for). All other status codes exactly as HTTP uses them. Particular implementations might never return the 202, but clients still need to cope with 202. I would not be averse to giving "202 capable" implementations their own usage URI, if the perceived burden on clients is too high. There's an argument to be made that any HTTP client already MUST deal with 202 anyway, possibly by treating it as a generic 2xx, thus ignoring all the polling/monitor specifics, but I'd bet that no all are correctly coded in practice. Automation 2.1 could require that implementations support both Automation Plans as implementations and template dialogs (in which case maybe it is just one Automation profile), or it could treat them separately. Personally I lean toward flexibility. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
