Initial Change Management Specification Updates

Here are some initial proposed changes to the Change Management specification. There have been reviewed with Nick (his comments included). These are mostly editorial changes and I don't think any require a vote to proceed. Let me know in the comments if anyone has any issues. I'm starting on these updates today.

1. The decision to deprecate the use of dcterms:type and use rdf:type was done after CM 2.0 finalization. It is not clear if CM server implementations adopted this practice - RTC 6.0 seems to still use dcterms:type and there are defects with queries that use this. We may need to replicate type information in rdf:type and dcterms:type to preserve compatibility.

Nick: That’s right. I believe the Tasktop integration might have originally used separate rdf:type values, but we asked the dev team to support dcterms:type because that's what existing clients understood: I do not know if the use of multiple rdf:type values was kept in addition to the use of dcterms:type in that integration.

2. Rename oslc-cm-v3.html to change-mgt.html - to be consistent with config-mtg, and to get the version tag out of the file name.

3. Should Consumer and Service provider follow the client/server terminology of OSLC Core 3.0, and should these have a CM prefix to distinguish the domain from other such clients and servers? Neither of these pairs of terms are technically accurate. Client/Server seems to be too focused on implementation role. Consumer/Provider recognizes that any app could be either. But neither of these recognize that most applications are both consumers and providers. Hence the term Participant adopted by SoaML since any component could and often did both provide and consume services. But I think the LDP adoption of Client/Server is possibly the worst of the choices. But we should be consistent.

Nick: I tend to agree with your dislike of client/server, but as you say we should be consistent. I've made some passes through Config Mgmt for this, but it's not complete.

Jim: Upon further reflection on this, I think perhaps the reason for using client and server is to highlight the fact that this is a distributed, RESTful architecture. Consumer/provider doesn't necessarily suggest this architecture, and REST is fundamental to LDP and OSLC.

4. Section 3.1 is based on OSLC 2.0 and needs to be updated. This and Configuration Management are the first OASIS OSLC domain specifications. Is the overall document structure from open-services.net applicable for OASIS Specifications? Follow what Nick did for the configuration management spec.

5. References Resource Paging which is not yet supported by LDP or OSLC Core 3.0 - that is an OSLC 2.0 reference. Note that Chet clarified that OASIS specifications can make normative references to non-OASIS specifications as needed and approved by the TC. So references to OSLC 2.0 capabilities are fine and reflect the ongoing evolution of OSLC.

6. References partial representations which is not yet supported - that is an OSLC 2.0 reference - ensure this is needed. Anything that is not part of CM 2.0, and not yet completed in dependent standards (e.g., W3C LDP, OSLC Core 3.0), and not absolutely necessary in CM v3 should probably be deferred.

7. References LDP PATCH which is not yet supported - see if this is needed, or is non-normative guidance or for future consideration.

8. OSLC 2.0 query capabilities was a MUST, but this is not part of OSLC Core 3.0. It is still required for the domain. Nick changed this to MAY or SHOULD for config-mgt. Probably should do the same thing for CM.

9. RDF/XML representations should follow OSLC Core 3.0 requirements - use Turtle. But include a MUST to support RDF/XML for v2 compatibility.

10. Section 3.2 Specification Versioning should follow the resolution for OSLC Core 3.0. New domain specifications cannot break existing clients.

11. State resources have values Closed, In-progress, Fixed, etc. - should not be used in a URL. And these are specified as Resource Shape enumerations, not proper RDF. Are they subclasses of State?

Nick: According to the RDF best practices written by Arthur, enumeration values should be RDF individuals with an rdf:type of the enumeration class.