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.
