Comments on Change Management specs

[David Honey1 <DavidHoney@uk.ibm.com>]

Comments in this colour...

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/change-mgt/change-mgt.html

CM servers MUST provide Turtle and JSON-LD, and
MAY provide RDF/XML, XML, and Atom Syndication Format XML representations.

When CM clients request:

• application/rdf+xml CM servers MUST respond with RDF/XML representation without restrictions.
• application/ld+json CM servers MUST respond with JSON-LD representation.
• application/xml CM servers MUST respond with OSLC-defined abbreviated XML representation as defined in the OSLC Core Representations Guidance
• application/atom+xml CM servers MUST respond with Atom Syndication Format XML representation as defined in the OSLC Core Representations Guidance
• The Atom Syndication Format XML representation SHOULD use RDF/XML representation without restrictions for the atom:content entries representing the resource representations.

[David]
These two sections are contradictory. For example, if a server does not
support RDF/XML, then it should be acceptable for the CM server to return
406 Not Acceptable. This is standard HTTP content negotiation, so I'm not
sure I understand the purpose of the bulleted section. Also, an ACcept
header can specify multiple acceptable media types with weighting. So the
bullet points are not necessarily mutually exclusive. A client might perform
a GET with both text/turtle and application/rdf+xml being acceptable, and
it's up to the server which of the two media types to provide in the response
.
2.9 Labels for Relationships

[David]
This section seems bizarre to me. We already provide a standard mechanism,
resource shapes, for defining labels for links. Why invent yet another
way of doing so? I thought that OSLC, in general terms, shunned the use
of reification.

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/change-mgt/change-mgt-resources.html

[David]
I was expecting some for
of class hierarchy, where there was a class used as the superclass that
defined the common properties, and then subclasses for Defect, Enhancement
etc that added their type-specific properties. The current presentation
makes it difficult to check for consistency where a property is described
for more than one class.

[David]
For properties like dcterms:creator,
I thought we discussed this in OSLC core and decided it should mention
foaf:Agent rather than foaf:Person?

[David]
The description of oslc_cm:affectsRequirement
uses a full URI whereas
elsewhere a QName is used. I think we should be consistent and use oslc_rm:Requirement.
Same comment for oslc_cm:implementsRequirement
 and oslc_cm:tracksRequirement.

[David]
The description of oslc_cm:tracksChangeSet
does not specify the
type of target resource. Now that we have an oslc_config:ChangeSet
type, should this be
mentioned for this property?



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU