Date: Sep 30 2009

Agenda:

• Follow up on review comments from previous meeting
  • Reworded language about handling ETag header
  • Handling of namespace prefixes in selective properties
    • Reversal of position on prescribed namespace prefixes
    • Lack of standard for compact representation of QName
  • Added query support
    • Quality Management Query Syntax
    • Collections (for query results)
    • Pagination
• Draft specifications
  • Quality Management REST API
  • QM service discovery & description
  • Quality Management Resource Definition
  • Quality Management Query Syntax
  • Delegated Resource Selection and Creation (no draft available yet)
• Proposed schedule for 1.0 deliverables
  • 8/28 scenarios (done)
  • 10/1 draft (today)
  • 11/1 final
  • Please review drafts and provide feedback on the QM email list oslc-qm@open-servicesNOSPAM.net

Minutes:

Attendees: IngridJorgensen, JimConallen, ScottBosworth, PaulMcMahan, MikeSaylor, FarizSaracevic? , SteveAbrams, PaulMcMahan

• Reviewed recent changes/tweaks to REST API
  • Query API and selective properties support now require predefined XML namespace prefixes (reversal from previous position)
  • It would be helpful for the spec to clarify where these predefined prefixes are used
  • Discussions about OSLC Common specifications are underway. QM is interested in participating in this discussion and adopting these common specs when they are ready.
  • Q: How much has QM REST API drifted from CM REST API? A: Hardly at all. The main difference is QM spec does not include JSON.
• QM query syntax based on CM V1 query syntax spec except full text search
  • Concerns raised about lack of full text search support
  • Paul to investigate full text support
• The testplan and testcase resource definitions only contain basic properties from Dublin Core
  • This is intentional for V1 spec. Future versions of the spec are expected to add more QM specific properties
  • Q: Should the resource definitions contain any properties related specifically to requirements so that the use cases are properly covered? A: The Multi-valued properties portion of the REST API spec satisfies the use case but in a generic way. A future version of the resource spec may add properties that describe the cross-OSLC relationships more concretely.