This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
AutomationHome
>
AutomationMeetings
>
AutomationMeetings20120412
(19 Apr 2012,
MichaelFiedler
)
(raw view)
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 * [[AutoSpecificationV2Issues][Specification Issues]] * [[AutoSpecificationV2Samples][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 1 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 [[AutoSpecificationV2Samples][Automation Plan sample]] usage of =oslc:parameterDefinition= is at odds with the definition of =oslc:name= in the [[OSLCCoreSpecAppendixA#Value_type_Property][=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 1 Keep it as defined currently and provide examples of proper usage of =oslc:propertyDefinition= where the value is consistent with =oslc:name= 1 Create an entirely new resource which copies =oslc:Property= without =oslc:propertyDefinition= present. * Discussion to continue. * Next Meeting: April 26th at 1PM Eastern US
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r5
<
r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r5 - 19 Apr 2012 - 14:33:31 -
MichaelFiedler
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback