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.
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:

* Main agenda items:

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)

Topic revision: r3 - 16 Mar 2012 - 14:38:07 - MichaelFiedler
 
This site is powered by the TWiki collaboration platform 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