[oslc-core] Core and Domain Spec Versioning String
Steve K Speicher
sspeiche at us.ibm.com
Tue Apr 20 21:19:56 EDT 2010
What Nick says was my understanding as well. In some cases, it is
redundant, but there is a use case for it.
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.
> > On Tue, Apr 20, 2010 at 4:22 PM, Scott Bosworth <bosworth at us.ibm.com>
> > > Question. In reading the core spec discussion on use of the
> > > oslc-core-version header, I wondered what the use case is that
> > > core version string at all? Assuming that clients deal with
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oslc-Core