[oslc-core] OSLC Domain Version String usage and identification

Nick Crossley ncrossley at us.ibm.com
Mon Apr 26 19:01:53 EDT 2010


Steve Speicher wrote:

> To be consistent across different usages and identification of what 
> version of what domain a service provider implements I recommend 
> these changes: 
> 
> 1) Have a single HTTP header called "OSLC-Version".  Its value is 
> limited to each domain's "Version string".  For example, of OSLC-CM 
> 2.0 it would be "oslc-cm-2.0" 

But this does not seem to address the use cases outlined when we described 
why two version strings appear to be needed.  Are we deciding not to 
address those use cases, and if so, why not?

> 2) Within the definition of the oslc:domain property on oslc:Service
> (and on oslc:ServiceProviderCatalog): 
> 
> Currently it states: 
>  oslc:domain (Resource, exactly-one) - namespace URI of the OSLC 
> domain specification that is implemented by this service. 
> 
> I recommend we change this to use the "Version string" above, such 
> that it reads: 
>  oslc:domain (String, exactly-one) - Version string of the OSLC 
> domain specification that is implemented by this service. 
>
> OR...Another approach would be to eliminate the version string and 
> just use namespace URI in HTTP header parameter 

However, in a separate email thread there was a proposal to remove version 
information from at least the core namespace URI - so if both changes were 
made we would appear to lose all version info.  Furthermore, the version 
string in the namespace URI (if there is one) seems easier in responses 
than to requests; asking the client to request a version through a 
namespace embedded in the URL seems more complex.

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


More information about the Oslc-Core mailing list