The Automation meetings alternate times each meeting to accommodate the global team.

Agenda

* Main agenda items:

• Determine if we have closure on "in"/"out" parameter discussion
  • Specification updated to state (see the Automation Plan resource).
    • If a parameter is required by an Automation Plan ( oslc:occurs is exactly-one or one-or-many), then it is guaranteed to appear in the Automation Result, either in the oslc_auto:inputParameter section (if unmodified during execution) or the oslc_auto:outputParameter section (if modified).
• Asynchronous automation scenario - feedback from the OSLC Core workgroup
  • Scenario seems very useful, both as an optimization and for providers not able to expose results as resources, whether due to persistence or architecture.
  • Need to consider recovery/error handling. If bad things happen when creating requests, how does client know if the execution actually occurred
    • Suggestion: Service providers can only offer synchronous style for plans where multiple identical requests can be created and return the same results - idempotent.
  • Attribute on request for client to opt-in to the synchronous style seems unnecessarily confusing
    • Suggestion #1: Is it really much of a burden for a client to be prepared to accept a 200 in response to a POST and just deal with the result in the response? Make both styles "standard" for Automation.
    • Suggestion #2: Client just "knows" (perhaps outside of the OSLC spec or perhaps via service provider attribute) which style a service provider uses
      • Does not consider the case where a service provider wants to use synch/asynch flexibly, maybe even within the same plan. But that might be too complex
• Need for sub-domain in Automation Plan - where did the group end up on this?
• Next meeting:
  • 24 May at 1:00PM Eastern US time

Minutes

Attending: Michael Fiedler, David Liu, Charles Rankin, Alberto Giammaria, Steve Speicher, Jing Qian, Sheehan Anderson, Paul McMahan? , Yi-Shin Tan

* Continuing discussion of AutoSpecificationV2 issues

• Reviewed the language on parameters in the automation artifacts - agreement that the definitions are now ready for external review.
• Discussion of synchronous scenario
  • Error handling: Is the synch scenario unique for error handling? Suggestion from core that consumers of synchronous providers need to be able to re-submit requests if an error occurs and that synchronous automations need to be idempotent
    • Synch scenario is not necessarily different. Asynchronous automation requests could still error on request creation without returning Location header or other valid response and still cause the automation to initiate on the provider and produce a result.
  • Responses to a POST of an Automation Request in the synchronous case
    • Automation Results are a MUST in the response for synchronous interactions
    • Are Automation Requests a MUST in the response? Or do we just state that Requests MAY be in the response and consumers SHOULD be prepared for the possibility content beyond the Result in the response in the asynch case?
  • Indications in automation artifacts that the synchronous style is supported by the provider and consumer
    • Option 1: As currently documented in the spec - consumers creating Automation Requests set oslc_auto: clientSupportsSynchAutoStyle to true to indicate they are capable of handling the synchronous style of interaction.
    • Option 2: No additional attributes on the automation artifacts - consumers must be prepared to handle synchronous and asynchronous styles of interaction. The thought behind this is that being prepared to handle the two types of responses (200 with/Result vs. 201/204) is not a large burden. The counter is that consumers geared towards asynch expecting to be able to query all results will not be able to do so easily.
    • Option 3: Include attributes on both the Automation Plan and Automation Request to allow consumers and service providers to indicate their capabilities with respect to synchronous interactions. The thought behind this is to allow providers and consumers to discover if they are interacting with a compatible actor
  • TODO: MichaelFiedler to write up proposed wording for Option 2 and 3.