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.

Date: 26 July 2010


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


Attendance: IngridJorgensen, PaulMcMahan, ScottBosworth, NigelLawrence, ScottFairbrother, PaulSlauenwhite, ThomasNeal

  • 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
    • 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
  • 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
Topic revision: r4 - 28 Jul 2010 - 18:54:55 - PaulMcMahan
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