Time: 1PM Eastern US (Daylight Savings) (contact MichaelFiedler if you'd like to participate)

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

Agenda

* Reoccurring agenda items:

• Recap of previous meeting AutomationMeetings20120405
• Update on action items

* Main agenda items:

• Draft Spec discussion: AutoSpecificationV2
  • Specification Issues
  • Resource samples
  • Spec completeness issues/Readiness for reviews
• Implementation plans
• Next meeting:
  • 19 April, 10AM Eastern US

Minutes

Attending: Michael Fiedler, Paul McMahan? , Charles Rankin, Steve Speicher, Jing Qian, Pramod Chandoria, Dan Berg

* Discussed Spec issues

• Discussed whether state and verdict should be read only. No, they should not. There are current scenarios in test (perhaps other) domains which require agents/external actors to be able to set the state and verdict.
• DELETE
  • Need to make DELETE symmetric with other operations - should not be stronger (SHOULD) when other operations are a MAY
• support Accept types
  • make application/json a SHOULD to communicate a preference over application/xml for non-RDF formates
• Resumed the extended discussion on what the minimum requirements for an automation service provider are
  • Does relaxing MUST on Query Capability and Automation Result PUT make sense? What are the implications for consumers not expecting this behavior
    • Two view points
      1. The Query Capability should always be there, no matter how minimal, to allow automation consumers to have consistent interaction patterns with providers
      2. If the provider really does not support query, don't bother with Query Capabilities at all. Worse to falsely advertise something that is of no value to the consumer
    • Question seems to boil down to whether scenarios not requiring query are in scope for V1
    • Provisionally, make query a SHOULD and see what additional comments we get.
    • New issue for discussion: Should links between Automation Request and Automation Result be bi-directional?
    • MUST on PUT of automation result seems overly stringent. Agreement to lower to SHOULD
• oslc:Property discussion.
  • Discussed expected value of oslc:parameterDefinition property. The current Automation Plan sample usage of oslc:parameterDefinition is at odds with the definition of oslc:name in the =oslc:Property= definition.
  • Possible resolutions
    1. Make an explicit statement in the specification that Automation is reusing oslc:Property in a particular way. I.e. with oslc:propertyDefinition as a zero-or-one attribute instead of exactly-one
    2. Keep it as defined currently and provide examples of proper usage of oslc:propertyDefinition where the value is consistent with oslc:name
    3. Create an entirely new resource which copies oslc:Property without oslc:propertyDefinition present.
  • Discussion to continue.

* Next Meeting: April 26th at 1PM Eastern US