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

Agenda

* Main agenda items:

• Review minutes from AutomationMeetings201207111
• Specification issues to resolve prior to entering convergence
  • Review of guidance on cancelation and state consistency: AutoSpecificationV2#Automation_Specification_Guidanc
  • Need for Automation "type" designation.
    • Description of proposals: AutomationTypeIssue
      • Pros/cons of oslc:domain and oslc:usage approaches. oslc:usage seems most inline with current Core - does it satisfy the scenarios?
    • Proposal from PaulMcMahan is here
    • Suggestion from SteveSpeicher to use oslc:usage is here
• 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, 26 July at 10AM Eastern US (tentative) - John Arwe will chair.

Minutes

Attending: John Arwe, Charles Rankin, Jing Qiang, Vaibhav Srivastava

• Meeting minutes from 20120711 accepted without changes
• Specification issues to resolve prior to entering convergence (updated after meeting - we are already in convergence, per AutomationMeetings20120614 minutes).
  • Review of guidance on cancelation - no comments
  • Review of guidance on state consistency - no comments; JA did fix some formatting issues noted in prior meeting
  • Need for Automation "type" designation.
    • Unanimous consensus that oslc:usage approach is best option, including from Paul via listserv
    • Request that Core add it to Service (Arwe will queue that request to Core mailing list), so that clients are not required to compute Service's effective value from its contained resources.
    • While vocabularly re-use rules and its semantics appear to allow us to simply compose it in, listing it explicitly in Service would more clearly set expectations and most people expect a consistent set of usage values across all of a Service's constituent resources.
    • Need to talk about converse case (generic automation provider) and which URI it should expose, in Guidance.
    • Accept the AutomationTypeIssue URIs under the Proposals heading as the starter set.
• Suggestions for additional topics in the Guidance section of the specification
  • 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.
• Specification review comments or other issues
  • Charles: what is current state of output parameters on AutomationResult. ...all read... need to clarify some.
    • Is current text on output parameter is intended to be limiting or not. I.e. if a provider like BuildForge puts a copy of all input parameters there, not only changed ones, is it "broken"?
    • Are there scenarios where it's important that ONLY the changed parameters are output? If not, why don't we optimize for the common case and at least allow, potentially require, all parameters (changed or not) to appear as output parameters. Will be simpler for a client that just wants to know where to find the CURRENT values of all parameters to get them from a single predictable place.
    • Will post email to listserv to generate discussion
• Next meeting: should we have it, cancel, ...
  • Keeping it for now since few people on today and minimal listserv discussion since agenda posted, will re-assess next week. Vaibhav has a conflict.