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