a) what name? One proposal is oslc:parameter, but need to make sure that parameters with same name have the same usage. Important for final vocabulary.
b) on a GET of an Automation Request, which parameters show up? Only those provided on Request creation? or include those implicitly added by the provider?
Automation Result
a) naming of "in" and "out" parameters
b) Proposal: indicate that the "in" parameters are an exact copy (alternatively, a point-in-time copy) of the parameters specified in the AutomationRequest?
c) Question on discoverability of "out" parameters: Do the Automaton scenarios include any requirement for the ability to introspect Plan A and find out what output parameters A will bind during execution, so that a later step in the chain could use A's output-only parameter as in input?
Proposal to add synchronous automation scenario and supporting language to the spec:
Spec changes - see PDF attached to newsgroup e-mail. Summary:
Descriptive paragraphs describing the difference between asynchronous and synchronous styles. Recommendation that providers SHOULD support asynch and MAY support synch. 201 or 204 response to Auto Request is an indicatory to client that asynchronous style is in use. 200 indicates asynch
New boolean attribute on Automation Request: clientSupportsSynchInteractionStyle. A zero-or-one attribute for the client to hint to the service provider that it can handle synch style Automation Request interaction
Shore up the loosening of the Query Capability statement by making query a MUST for asynchronous style service providers
Update HTTP method tables to distinguish which methods required for each style.
Need for additional meta-attribute to indicate which automation sub-domain a service provider has services for (e.g. test, deploy, build)
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Contributions are governed by our Terms of Use Ideas, requests, problems regarding this site? Send feedback