I think I broadly follow what you're saying. I've never been completely comfortable with a generic Automation consumer of usage=template having to find "the Right creation factory (or pre-fill-accepting dialog)" later in time. The discussion makes me wonder if the obvious solution is enough: link them. I.e. add links from a template Dialog to the creation factory(ies) and/or creation dialog(s) that accept its output (the template) as a later-in-time input. Telling consumers instead to just poke around the other action:request links feels like more of the original-same. Do you think that would address what you laid out? Adding that linkage might be sensible for template dialogs in general. Clients are always free to ignore those links and write (gobs of?) code to do it other ways, which is what we require today in 2.1 I think.
I'm not so sure that 202 is incompatible with creation dialogs. We'd have to be precise about the semantics, perhaps more so than we are today. Since it's the browser iframe code invoking HTTP GET on the dialog (and make no mistake, it is HTTP in that flow), the GET would always have a 200 (the dialog is not displayed until that happens). The 202 thought is about how the dialog code running inside the iframe works. That code is making its own HTTP request, so it can see the status code and react as it sees fit... including the 202+polling if it likes. The hard part I see as defining what it means when the dialog returns, if the user is allowed to cancel out of the polling but leave the request queued (in a not-final state). If the dialog code is required to cancel the request before user exits the delegated dialog, otherwise wait for a final state, that seems clean. As a user who loathes modal dialogs however, I wonder if that's practical. Maybe we don't need the 202 if we add the linkage suggested above though. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
