Doing a side-by-side comparison of the upper-level superstructure of the v1 and v2 OSLC CM specs, I noticed two things.
(1) In v1 Service Provider Catalog representation, the oslc_disc:ServiceProvider element has an oslc_disc:details with a rdf:resource attribute giving "the URI of a browsable resource providing details of the service provider or catalog." For RTC, this was the URI of a particular project area. I couldn't find any counterpart to this in the v2 CM or Core specs. Was this an intentional omission? I.e., do we believe that it's no longer needed? (2) In a v1 Service Provider Catalog, the catalog entries reference v1 Service Provider resources as local, inline resources; these v1 Service Provider resources reference v1 Service Description resources as regular resources. In v1, a particular Service Description resource is associated with a particular domain. E.g., it will be a CM Service Description resource. In a v2 Service Provider Catalog, the catalog entries reference v2 Service Provider resources as regular resources; these v2 Service Provider resources reference v2 Service resources as local, inline resources. In v2, a particular Service resource is associated with a particular domain. A v2 Service Provider resource is designed to reference multiple and heterogenous v2 Services. Selecting from a v1 Service Provider Catalog yields the URI of a v1 Service Description resource. The analogous selection from a v2 Service Provider Catalog would yield the URI of a v2 Service resource. However, since v2 Service resources are inlined into the v2 Service Provider document, the only available URIs for these are ones with fragment '#' identifiers that select a node based on its rdf:nodeID. Two issues I can see with this: (a) It means that all clients that dereference v2 Service resources are responsible for interpreting the fragment identifier and using it to locate the element with that rdf:nodeID. This is clunky for clients of the v2 protocol. (b) It's impossible to claim that the URI of a v1 Service Description resource is also the URI of a v2 Service resource - the latter has a fragment identifier; the former does not. A cross-application "project links" that starts off referencing a v1 CM Service Description resource would end up referencing a v2 Service Provider resource, rather than a v2 Service resource, once the target server is upgraded to add support for CM v2 under the existing CM v1 URIs. ---jim
