[oslc-core] Core and Domain Spec Versioning String

[Steve K Speicher]

What Nick says was my understanding as well.  In some cases, it is 
redundant, but there is a use case for it.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: Nick Crossley/Irvine/IBM at IBMUS
> To: oslc-core at open-services.net
> Date: 04/20/2010 07:44 PM
> Subject: Re: [oslc-core] Core and Domain Spec Versioning String
> Sent by: oslc-core-bounces at open-services.net
> 
> 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?
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100420/c84bead2/attachment-0003.html>