[Oslc-Automation] Automation spec updated based on synchronous/asynchronous discussion - plus 1 issue

[John Arwe]

[1] > An automation result is "finished" when it has an oslc_auto:state 
predicate with an object of oslc_auto:complete or oslc_auto:canceled or an 
oslc_auto:verdict property with a value other than oslc_auto:incomplete. 

s/value/object/  ... for internal sentence consistency as well as 
precision.  I see we do say "property value" in other places, maybe it's 
time to choose one and use it consistently.

It seems odd/almost perverse that we have a state=complete and 
verdict=incomplete.  Since state=1:*, why do we need to drag verdict into 
this?
I see from the state/verdict enumeration description that incomplete has a 
"rather odd" description.
The additional property values for oslc_auto:verdict are:
-    http://open-services.net/ns/auto#incomplete = - used to indicate an 
automation result is in a state where no other verdict applies.  Usually 
used when a result is in a state other than =oslc_auto:complete. 

What is the value we gain from having an explicit "incomplete" verdict, 
distinct from simply not asserting one of the others ... is this so we can 
meet the requirement that each instance always has at least one oslc_auto 
verdict value (i.e. something to interop on)?  If covering that case 
really helps, we could at least name it something less likely to be 
conflated with state (strawman: no-verdict).


[4] I'd be careful about using w3.org URLs for IETF RFCs... [5] is the 
IETF URL, I see no obvious differences there or in the errata; [6] which 
is the replacement-in-process has some smallish differences around 
caching.
[5] http://tools.ietf.org/html/rfc2616#section-9.5
[6] 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.5

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario


oslc-automation-bounces at open-services.net wrote on 06/18/2012 02:04:31 PM:

> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-automation at open-services.net
> Date: 06/18/2012 02:08 PM
> Subject: [Oslc-Automation] Automation spec updated based on 
> synchronous/asynchronous discussion - plus 1 issue
> Sent by: oslc-automation-bounces at open-services.net
> 
> The Automation specification has been updated with the proposed 
> language (Option 4) describing asynchronous and synchronous 
> interactions and comments are requested from the community. 
> Sections to review are the description of service provider 
> capabilities [1], query capabilities [2] and the HTTP method table 
> [3] which has reverted to its previous content.
> 
> One issue was raised around status codes and the Location header for
> the synchronous case.   In this case the Automation Result is 
> returned in the POST response to the Automation Request and there 
> may not be a reference-able artifact created by the POST.   The HTTP
> spec [4] states that in this case the status code is expected to be 
> 200, not 201.  Do we need to state anything explicit in the 
> specification regarding this?  or do we just default to HTTP norms 
> of behavior? 
> 
> [1] - http://open-services.net/bin/view/Main/
> AutoSpecificationV2#Automation_Service_Provider_Capa
> [2] - http://open-services.net/bin/view/Main/
> AutoSpecificationV2#Query_Capabilities
> [3] - http://open-services.net/bin/view/Main/
> AutoSpecificationV2#Automation_Service_Provider_HTTP
> 
> 
> [4] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
> 
> Regards,
> Mike
> 
> Michael Fiedler
> IBM Rational Software
> fiedler at us.ibm.com
> 919-254-4170_______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120618/a9f2212d/attachment-0003.html>