[oslc-core] Versioning and URI design

[Arthur Ryman]

Ian,

OSLC can offer implementation guidance wrt some goals, so we should make 
these goals explict.  I think these are the goals OSLC needs to satisfy:

1. Versioning MUST be consistent with independent evolution of clients and 
services, i.e. a change in the server MUST never break existing clients. 
This is the essence of loose coupling on the Web.

2. Since URLs get stored in many places, they MUST continue to work, 
possibly through the use of standard HTTP mechanism such as redirection.

3. The syntax of URLs SHOULD be opaque, except for any standard query 
parameters that OSLC defines.

Are these the right goals? 

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube







From:
Ian Green1 <ian.green at uk.ibm.com>
To:
oslc-core at open-services.net
Date:
03/15/2010 07:20 AM
Subject:
[oslc-core] Versioning and URI design
Sent by:
oslc-core-bounces at open-services.net



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







_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net