Martin, I don't think you're missing any Automation discussion. Those of us directly involved with the product in question did have reasonably complete discussions, as you might imagine. I'll try and catch the list up some with those (now that the product is available, some of the non-technical hurdles go away).
I parse the problem into a couple of parts. 1: Automation 2.0 did something non-standard (in the sense of "unusual with respect to prevailing usage patterns") when it coupled creation of a resource with execution of an action ... an action BTW that results in a second resource coming into being, although I certainly grant that if they have the same URL it's only 1 resource but has 2 types. However, we were intentionally treating the multityping case as an option not a requirement. I was there, I didn't see this except in hindsight, so bad me (but at least I had company ;-) ). 2: Core 2.0 provides no way for a client to introspect pre-fill support on a creation factory, yet the interaction pattern in question is completely dependent (semantically) on the "template" being used. So any implementation in this situation is dependent upon tight coupling (non-standard out of band information) to know about pre-fill support. Our product doesn't want to be tightly coupled; defeats the purpose. Clear omission in Core 2. One way to assess the complexity of a solution is "how much new spec work is required?", and this is to some degree bound to "...and where would that work occur?". The first is a proxy for adoption complexity (what new concepts/implementations do clients need to worry about), the second is a function of how generally reusable are the problems/solutions. Had Automation 2.0 originally addressed its "create + run" requirement by explicitly _adding to_ the standard interaction pattern, so the "run" implication was simply an Automation-defined extension on a standard create request (essentially setting the initial state to "runnable" rather than requiring a subsequent PUT/PATCH to do so, a perfectly valid optimization), we would not be here. We'd fix this in Core by making the pre-fill support explicitly introspectable and be done with it... we might have even done that for Automation only first (but I suspect the WG leads would have realized it's a general Core problem and fixed it there, as we did with allowing usage on Services). So to net that out: two new terms (one in Automation, one in Core) and you're done. Existing/new clients that wanted to know about pre-fill support for other reasons get a general solution to their general problem, existing clients that don't care don't change at all. Automation clients (the ones that want this "create-runnable" binding vs not) have to do a bit more work. Since none of the other existing domains have asserted a need to do templates, keeping the solution Automation-specific for now is not obviously crazy talk. If they were to arise, we might decide that the solution is better placed in Core. I did ask during our internal discussions if anyone involved saw a strong potential for re-using it elsewhere, no one did. It's completely fine to repeat discussion that in Automation with a wider audience, like you. Providers didn't exactly jump at the prospect of persisting the created "templates" on the grounds that they'd have no way to know when to delete them (i.e. fears of "memory" leaks); once I pointed out that they could be garbage collected, and that in fact this is no different than a robust server would need to do for any other resource it manages, those fears died down. The original proposal added templateDialogs, with a new behavior on the delegated dialog interface. That is clearly, from a run-time perspective, more efficient and optimized. It's also more new concepts for an implementer to learn, and more to decide whether or not to support. The same question about function placement occurs. If this were added to Core, then it ups the consumption complexity of every domain (not just Automation); if left in Automation, we face the distasteful prospect of moving it later since we eschew "hard" cross-domain spec dependencies should a similar need arise elsewhere (which is completely different than vocabulary reuse, to be clear... stable vocabulary reuse is A Good Thing regardless of the vocabulary's source). An added question at the spec level is whether or not a change of this magnitude could be done in Core 2.0; to me that answer is no (too big, and we've been talking about drafting 3.0 for months, and now LDP is getting mature enough that 3.0 is going to become real). If it can't be done in Core 2, are we willing to tie Automation.next to Core 3.0 which could be a year away? The template function was needed by June (last month), so an obvious "no" in their eyes. With the simpler version, fixing 2: seems absolutely doable in Core 2 (just like we did with usage) and as you point out we can use a custom state for the moment to get us the rest of the way on 1:. Product schedule was a forcing function. I agree these are not mutually exclusive, too. We have to be sure, if we do both, that it's worth the adopter complexity. Any time there is >1 way to accomplish the same thing, people naturally ask "how do I know which is right [better for my case]". If we punt on the answer, as we 'often' do, too much choice is worse for them. For our products, using the more-KISS but less optimized approach was deemed good-enough (the template-creation flow is rare compared to making requests that use the template), so once they got to that point it became a question of "so who's going to invest the time to spec out the templateDialog, the delegated dialog flow, implement it several times (necessary to put it anywhere), and make the argument for inclusion in Core 2?" Response: crickets chirping. > This would allow the consumer to create a template and save it itself (not on the provider); ...(both of these put the consumer in control) Both options accomplish this. The difference is whether or not the provider has any obligation to persist what was created and if so how the rest of its lifecycle is managed. Creation => persistence has been a standard responsibility since before OSLC's days, in most circles. Atom normalized this in REST circles. That doesn't mean we Must re-use that pattern in this case, but we should be aware when we are consciously trying to define new patterns vs re-use widely used existing ones, and the implication of that choice on adoption. Implementers adopt as a means to an end, not as the end. If the means it more painful than the end, not much adoption. > or to create a resource in "don't execute yet" state on the provider and then change that state when it's ready (both of these put the consumer in control); This option actually fails to accomplish the desired result, because it is only useful for a single execution. What the schedulers want to do is create a "template" once and then re-use it multiple times. You might think of it as creating a consumer-scoped Automation Plan. Thinking about it this way does make me wonder who _should_ be persisting them. Products playing a role analogous to provider don't persist the "templates" today, but maybe they should. I can see both sides of the issue. > or for the provider to expose the scheduling settings in the creation dialog and control the "don't execute yet" state on its own (this is where the provider's in control - and is possible in v2, ... Consumers (several of ours at least) will deal with multiple providers when creating templates, so they show a list of potential providers to the user for selection. They need proactive introspection so they can weed out "Automation 2.0 but not template-capable" providers from that selection list, as users expect. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
