[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 [email protected] wrote on 06/18/2012 02:04:31 PM: > From: Michael F Fiedler/Durham/IBM@IBMUS > To: [email protected] > Date: 06/18/2012 02:08 PM > Subject: [Oslc-Automation] Automation spec updated based on > synchronous/asynchronous discussion - plus 1 issue > Sent by: [email protected] > > 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 > [email protected] > 919-254-4170_______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
