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 <[email protected]> To: [email protected] Date: 03/15/2010 07:20 AM Subject: [oslc-core] Versioning and URI design Sent by: [email protected] 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 [email protected] (Ian Green1/UK/IBM@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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
