Date: 26 July 2010

Agenda:

• spec issues resolved since last workgroup meeting
• Collect any additional feedback from work group on current draft spec
• OSLC Core: decision on RDF

Minutes:

• Reviewed and agreed to RESOLVED on spec issues answered since last workgroup meeting
• Discussed relatedChangeRequest relationship properties. Should the spec use dcterms:relation instead? The workgroup like the idea of a general purpose relationship property such as this. But it is already defined in core so its available to service providers without necessarily including it in the QM spec. If later we find that it is needed for some particular scenario then we can explicitly add it to the QM spec.
• Covered two additional items spec issues:
  • Inconsistencies in the "Occurs" column of resource tables
    • AI: PaulMcMahan to correct and resolve issue
  • executablePath property of TestScript. Why isn't it a relationship property? Main reason is because its value might be any type of identifier and maybe not a valid URI. For example UNC pathname.
    • AI: PaulMcMahan to investigate using a relationship property and resolve WI
• Workgroup needs to consider whether the OSLC-Core-Version header should be required for the client to interact with OSLC V2 service provider, or if the oslc-qm-* Accept headers defined in the QM V1 spec would be sufficient for identifying QM V1 clients. The QM V1 spec was not really specific about the behavior when application/xml Accept header is sent, so whether this is safe of not depends on how clients of the V1 spec have been implemented.
  • • AI: PaulMcMahan to investigate whether known clients of the V1 api sent the oslc-qm-* Accept header or if they sent application/xml.
• Discussed new property of TestExecutionRecord -- oslc_qm:configuration. Its purpose is to reference environment information (OS, hardware, etc) but does not specify a Range. Leaving Range unspecified rather than defining some new QM resource for allows adoption of future OSLC specification for configuration. This seems important since the concept of environment/configuration will probably span several domains (automation, change, etc).
• Ideally a TestExecutionRecord could also reference some type of Build resource. Workgroup decided to leave this unspecified now as the automation workgroup is still in the process of defining this type of resource.
• The QM spec needs a summary table like is shown on the CM spec which clarifies the alignment/adoption of core spec
  • AI PaulMcMahan to add summary table
• Discussed the core workgroup's position on mandatory RDF/XML. The QM workgroup is in favor of the mandate and will fully adopt it into QM V2 spec.
  • AI PaulMcMahan to add clarification of application/xml vs. application/rdf+xml to QM V2 sepc