[oslc-core] Versioning and URI design

[Ian Green1]

Hello all,
What guidance, if any,  should OSLC offer to implementers of OSLC 
specifications around versioning of services and design of URIs?

Here are a couple of example scenarios:

Scenario A: Provider has a product with web clients, public REST APIs. 
These resource models offer application/rdf+xml representations of 
resources, but these representations differ from the OSLC representations. 
 Provider wants to additionally offer OSLC protocols & representations. 
One approach is to have OSLC-specific URIs.  Is anyone aware of scenarios 
where consumers would need to consume both OSLC and non-OSLC services over 
the same resources?

Scenario B: Provider offers OSLC services at v1 of an OSLC specification. 
Provider wants to additionally offer OSLC v2 services. (Let's assume that 
v2 is not backwards compatible with v1.) Provider has quality of service 
contracts which prevent it from withdrawing OSLC v1 services.  Provider 
has consumers which cannot upgrade to v2 services.  Provider has 
prospective consumers who cannot downgrade to v1 services.  One 
possibility is that v1 resources and v2 resources differ in their URIs. 
(This scenario differs from A because A is less constrained.)  This would 
have ramifications for consumers that pass URIs between providers (for 
example, C/ALM filters might break).

URI stability is crucial and I wonder if we ought to give some help to 
providers on how that can be achieved, what concerns need to be 
considered, what can be done if URIs "must" change and so on.

best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational





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