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:
* Main agenda items:
- Draft Spec discussion: AutoSpecificationV2
- 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
- The Query Capability should always be there, no matter how minimal, to allow automation consumers to have consistent interaction patterns with providers
- 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
- 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
- Keep it as defined currently and provide examples of proper usage of
oslc:propertyDefinition
where the value is consistent with oslc:name
- Create an entirely new resource which copies
oslc:Property
without oslc:propertyDefinition
present.
- Discussion to continue.
* Next Meeting: April 26th at 1PM Eastern US