[oslc-core] Core and Domain Spec Versioning String

[Samit Mehta]

One other possible scenario (if I am understanding the thinking around 
versioning and dependency between Core and Domain Specs) is that there are 
significant changes in Core 2.0 (e.g. a significant change in how partial 
updates is implemented).  The working group for the Domain spec that needs 
to make some minor changes to the to support some Domain specific scenario 
does not want to burden that all the providers upgrade to the Core 2.0. 
With a separate versioning of Core 2.0, they could decide that next 
version of the Domain spec (Domain vNext) would require Domain vNext be 
based on Core 1.0, but service providers can also optionally support Core 
2.0. 

I am not clear on how clients interact with different versions of 
Core/Domain spec, so I may have the above wrong.
____________________________________________
Samit Mehta
(512) 323-9350 - Work
mailto:samit.mehta at us.ibm.com
IBM Rational Software - Business Development

oslc-core-bounces at open-services.net wrote on 04/20/2010 06:44:14 PM:

> 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/20100421/9dd65300/attachment-0003.html>