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

Agenda

* Main agenda items:

• Review minutes from AutomationMeetings201207119
  • oslc:usage for identifying automation "sub-types"
    • Suggestion: Add: Advertising what category of automation a provider/creation factory/query capability/dialog falls into. Recommend at least one, and fewer are better (just enough, and no more). Use the automation namespace uri as the "generic automation provider" URI, and say that is equivalent to omitting the value when the Service's oslc:domain predicate's value is Automation.
    • TODO: MichaelFiedler to update spec to reflect agreed-upon language
• Specification issues to resolve prior to entering convergence
  • Revisit oslc_auto:outputParameter attribute on the Request and Result
    • name of the attribute - proposed new name on the mailing list: oslc_auto:executionVariable
    • behavior of the attribute in the Result
      • is oslc_auto:outputParameter a copy of ALL input parameters, changed input parameters or new parameters created during execution? We've discussed all in the past and the current spec language indicates new/changed and not unchanged oslc_auto:inputParamaters
    • See mailing list thread starting here: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-July/000241.html
    • Also, ability for consumers to determine which parameters must be supplied (http://open-services.net/pipermail/oslc-automation_open-services.net/2012-July/000255.html)
  • should oslc_auto:state be read-write or read/only to allow automation agents to update it.
    • Agents could be considered part of the provider implementation and allowed to update.
    • See mailing list thread starting here: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-July/000248.html
• Suggestions for additional topics in the Guidance section of the specification
• Specification review comments or other issues
• Next meeting: should we have it, cancel, ...
  • Thursday, 9 August at 10AM Eastern US

Minutes

Attending: Michael Fiedler, Paul McMahan? , Charles Rankin, Jing Qiang, Steve Speicher

• Reviewed previous minutes
  • New wording for sub-types based on oslc:usage accepted without further comment. MichaelFiedler will update the spec.
• Specification issues
  • First discussion was around oslc_auto:state being specified as read-only.
    • Mailing list discussion centered around read-only being correct for most client implementations - most workers not part of provider implementation and should not have control over state
    • Don't want to force read/write if it is not the common case
    • Implementations can deviate from read-only if it makes sense. Could make it unspecified, but that seems weaker.
    • Workgroup agreed to this description in principle.
  • Followup to mailing list discussion around oslc_auto:outputParameter in the Automation Result
    • name of the attribute: will raise this as an issue on the mailing list and solicit alternate suggestions
    • behavior of oslc_auto:outputParameter
      • Agreement to widen the scope of outputParameter to include the final list of all parameters used during execution, whether unmodified, modified or created during execution
        • Satisfies auditability needs
        • Provides all parameters used during execution
        • No guarantee of how "live" the values are. Depending on the service provider, values may change during execution or not. Once result reaches a completed state, the values must not change.
    • MichaelFiedler will update spec to reflect this discussion.
  • Implementations
    • PaulMcMahan gave some details on Rational Quality Manager plans
    • High level overview of other plans which are known.