Date: Sep 9 2009

Agenda:

• Introduce new members
  • Big Lever (Glenn)
  • Tieto (Ingrid)
• Scenarios for v1.0 finalized
  • Scenario A: Validate a set of requirements
  • Scenario B: Test whether a requirement has been satisfied
  • Scenario C: Test a deliverable according to an established test methodology (deferred)
  • Querying resources (deferred)
  • Versioning resources (deferred)
  • Reporting on resources (deferred)
• Draft specifications
  • Quality Management REST API
  • QM service discovery & description
  • Quality Management Resource Definition
• Proposed schedule for 1.0 deliverables
  • 8/28 scenarios finalized
  • 10/1 draft
  • 11/1 final
  • Volunteers please contact Paul

Minutes:

Attendees: MichaelPena, IngridJorgensen, ScottFairbrother, JimConallen, ScottBosworth, IanGreen, PaulMcMahan

• Introduced Inga to workgroup
• Reviewed scenarios w.r.t. what is in scope for v 1.0 specifications
  • Scenarios A and B received some polished since last workgroup meeting and are in scope
  • The workgroup needs more discussion about scenario C about metadata and workflow, potentially across OSLC. It is not in scope for v1.0 but discussion about that scenario will continue for a future version of the spec
  • The reporting and versioning scenarios are not in scope
  • Some concerns were raised w.r.t. whether a 1.0 spec could really be considered complete without some type of query API. Paul to investigate what might be accomplished in the 1.0 time frame, and whether the current scenarios might call out an implicit need for query or whether a separate scenario specifically about search might be in order.
• Reviewed the Draft specifications
  • There was a lot of good conversation about the REST API specification in particular
    • We are taking the position that the XML namespace prefixes are not part of the specification. They are only used in the specification document for readability.
    • A good point was raised which is that if the namespace prefixes are not part of the standard then they should not be used in the selective properties. The full namespace URI should be used instead.
    • Also there was some discussion about the usage of "MAY" vs. "MUST". There are certain areas of the draft spec such as the part about ETag and If-Match headers where "MAY" should probably be changed to "MUST", or the spec should not prescribe any behavior at all.
    • Also discussed the usage of selective properties for update requests. Q: Why use selective properties instead of just providing the portion of the resource XML that needs to be updated? A: so that properties can be deleted. Q: Why not use empty elements for property deletion? A: Because there may be need to be a distinction between an empty property and a null property, i.e. a property that exists with an empty value vs. a property that does not exist at all.
  • Briefly discussed the resource XML and service description formats
    • A JSON resource format spec is not being provided in v1.0
    • These look a lot like the corresponding CM specs
    • We're taking a minimalist approach with the resource XML spec and allowing for extensions to that XML via namespaces