[oslc-core] Core and Domain Spec Versioning String

[Nick Crossley]

I think the reasoning for having the core version was as follows: suppose 
you have a client that understands the core spec 1.0 format of resources, 
shapes, etc., and wants to issue a query that might have inlined resources 
from a bunch of different providers from multiple domains.  The client 
does not know or care about the versions of all the providers.  So, the 
client just asks for core version 1.0, and does not ask for any specific 
domain version.   The providers all return the relevant data in the 
representation defined by most recent version of their domain spec that is 
based on core 1.0.

The argument for having a domain spec version is to handle the case where 
a domain spec might have multiple revisions based on a single revision of 
the core spec - for example, we might have SCM 1.0 and SCM 2.0 both based 
on core 1.0, and a client might want to request one or the other 
explicitly, and/or to know which one it got back in a response.

Nick.


> On Tue, Apr 20, 2010 at 4:22 PM, Scott Bosworth <bosworth at us.ibm.com> 
wrote:
> > Question. In reading the core spec discussion on use of the
> > oslc-core-version header, I wondered what the use case is that 
requires a
> > core version string at all? Assuming that clients deal with 
domainspecified
> > services and resources, could it be the case that the only relevant 
version
> > for a service consumer is the domain spec version?
> 
> I started with the assumption that we would need an OSLC Core Version
> string and then somebody suggested that we also need OSLC Domain spec
> version strings too. Now I'm starting to think that I got things off
> on the wrong foot here.
> 
> Isn't having both an OSLC Core Version string and domain version
> strings redundant? One should be able to determine the OSLC Core Spec
> version given an OSLC domain version string.
> 
> The Core spec should define how to offer a version string and how to
> behave in relation to that version string, but should not define a
> version string itself. Anybody see any problems with that approach?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100420/0a23f6db/attachment-0003.html>