• Typo updates to the specification - patent non-assert covenant coming soon
  • please continue reviews

• Parameter roles and naming for each artifact - email thread: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-April/000135.html
  • Automation Request
    • 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:
  • Scenarios: http://open-services.net/bin/view/Main/SynchronousScenarios
  • 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)
• Next meeting:
  • 10 May, 1PM Eastern US

Minutes:

Attending: Michael Fiedler, David Liu, Jing Qian, John Arwe, Steve Speicher, Paul McMahan? , Vaibhav Srivastava

* Specification discussion

• "in"/"out" parameters: Proposal is to make parameterDefinition (Automation Plan), inputParameter (Automation Request/Automation Result) and outputParameter the proposed final names. Add additional wording to the spec to describe the roles of these attributes and the restrictions on them.
• Synchronous Scenario
  • walked through the scenario and discussed implications for both consumers and service providers of a client setting the new oslc_auto:clientSupportsSynchInteractionStyle attribute.
  • ok for service provider to use 200 response on POST to indicate response contains the Automation Result? General agreement that it was ok in light of the consumer opting-in, but want to solicit additional review
  • Next step: TODO: Michael Fiedler to update the spec with the proposed wording changes for review

* Next meeting:

• 10 May, 1PM Eastern US