Time: 1:00PM 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 AutomationMeetings20120308
• Update on action items

* Main agenda items:

• Draft Spec discussion: AutoSpecificationV1
  • Automation Contribution options
    • Review discussion from 8 March meeting
    • Review new examples and review the Automation Result resource
    • Decide if we are closed on the approach
  • Open issues discussion
  • Spec completeness issues
    • Vocabulary
    • Examples
    • Guidance/Usage
    • Reviews
  • Implementation plans
• Next meeting:
  • 22 March, 10AM Eastern US

Minutes

Attending: Michael Fiedler, Charles Rankin, Vaibhav Srivastava, Dan Berg, Jing Qian, John Arwe, Paul McMahan?

* Automation Contribution discussion

• General approach in Option B at Automation Contribution options agreed upon
  • Really only matters from a guidance/wording point of view for the oslc_auto:hasContribution attribute. Implementers were always free to add additional attributes to the contribution.
  • Discussion on whether the contribution should be a separate, formal resource with all optional attributes. Agreement that this does not have additional benefit at this time. Does not solve any specific scenario
  • Discussion on dcterms:type vs rdf:type
    • Implication of Jena abbreviated XML implementation if contributions have multiple rdf:types - difficulty for non-RDF consumers to process resources
    • Current OSLC core rules for producing abbreviated xml say nothing about hardening the rdf:type on resource XML nodes to a particular value
    • TODO: Michael Fiedler will summarize and bring to core

* State predicate discussion (for verdict and state attributes)

• Discussed using URIs instead of state predicates for verdict and state attributes
• predicates have caused some issues for consumers in other specs - can be difficult to deal with on query, etc. Consistency of values across predicates another possible issue
• Use a URI to a "definition" of a state instead. Provide values in the automation vocabulary which can be used. Or service providers can use their own.
• This approach puts burden of state/verdict consistency on the service provider
• Make verdict zero-or-one, but allow state/desiredState to be zero-or-many
• TODO: Come up with a strawman/example for review.

* Parameter Definition discussion

• Members don't want required fields of oslc:Property to be a barrier/burden to using it. The oslc:propertyDefinition attribute was of particular concern.
• TODO: Another strawman/example in the spec of the simplest name/value parameter which could be used.

* Moving the specification forward

• Agreement that we need additional reviews. Request will be sent to the oslc-automation, oslc-core and oslc-community mailing lists requesting review.
• Need to make progress on sample and guidance pages for potential implementers new to OSLC

* Implementations

• Several workgroup members indicated their organizations would be in a position to begin implementations or prototypes once the spec enters convergence.

Next meeting: Thursday, 22 March at 10:00 AM Eastern US time (daylight savings time)