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

Agenda

* Main agenda items:

• Automation specification visibility
• Determine if we have closure on "in"/"out" parameter discussion
  • See this mailing list entry: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-May/000153.html
  • Additional related topic: Use of oslc:readOnly boolean attribute in an Automation Plan oslc_auto:parameterDefinition
    • Proposal to explicitly state that oslc:readOnly = true for an Automation Plan parameter means that it is an output parameter.
    • Possibly helps the issue with "discoverablility" of oslc_auto:outputParameters, but not entirely - external agents could add others.
• Asynchronous automation scenario - comments or concerns with supporting it?
  • See this mailing list entry for relevant links: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-May/000154.html
• Need for attribute relating an Automation Plan to its most recent result
  • The mailing list thread starts here: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-May/000147.html
  • Useful for consumers to "just get the latest result"
  • Potential burden for providers - assumption that provider can easily get this on a given GET of a plan
  • Can OSLC query satisfy this? - I don't believe so today without additional computation by consumer. True result ordering is a future Core topic.
  • If attribute is present, does it refer to most recently created, updated or completed (oslc_auto:state is oslc_auto:complete).
• Need for sub-domain in Automation Plan - where did the group end up on this?
• Next meeting:
  • 17 May at 10:00 AM Eastern US time

Minutes

Attending: Michael Fiedler, John Arwe, Dan Berg, Robert Elves, Yih-Shin Tan, Alberto Giammaria, Lucas Panjer

* Primary discussion was of issues listed in agenda

• "in"/"out" parameters
  • Mostly agreed upon as written up in the spec. Need some additional wording that if a parameter is required in 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 inputParameter section (if unmodified during execution) or the outputParameter section (if modified).
  • MichaelFiedler to update the spec
• Proposal to add an attribute relating a plan to its latest result
  • Useful to have, but not critical to scenarios identified so far
  • Query not thought to be a huge burden as an alternative for conumers
  • Re-visit one more time in next meeting
• Review of the synchronous scenario
  • Some comments that the synchronous style feels "un-RESTful".
  • Agreement that the pattern is useful when the provider does not persist/expose results as resources
  • TODO: Talk to Core workgroup and get feedback on whether the proposed synchronous style of interaction was consistent with OSLC