[Oslc-Automation] Actions 2.0 - Dialog RDF

[John Arwe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131121/cb814e17/attachment-0003.html>