Comments on Change Management specs

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