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@IBMUS > To: [email protected] > Date: 04/20/2010 07:44 PM > Subject: Re: [oslc-core] Core and Domain Spec Versioning String > Sent by: [email protected] > > 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 <[email protected]> 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
