[Oslc-Automation] Actions 2.0 - Dialog RDF

[Martin P Pain]

> 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've just found this email when looking back through this thread.
The example in the Actions doc I just sent out includes a link from a 
dialog to the creation factory (or in that case any other request) that 
the result should go to.
It would be worth seeing if we can converge the two to avoid duplication 
while also "keeping the simple case simple" where it is a creation factory 
that it's pointing to (as would be the vast majority of cases - all of the 
ones where the dialog isn't inside an action plus most of the ones where 
it is).



Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
21/11/2013 13:38:21:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Date: 21/11/2013 13:38
> Subject: Re: [Oslc-Automation] Actions 2.0 - Dialog RDF
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> 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 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131213/d7fb2e0b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131213/d7fb2e0b/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131213/d7fb2e0b/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131213/d7fb2e0b/attachment.gif>