[oslc-core] v1 Service Descriptions vs v2 Services

[Jim des Rivieres]

> I believe you are saying it [oslc_disc:details] is still needed. Perhaps 
in an attempt to simplify, it got dropped. 
> I will take the action to add this back, barring any objections. 

I'm guessing it's still needed. I'm sure Kai would know.

> This is not intended way for it to work. 

Thanks Steve for the clarification.

Regards, jim



From:
Steve K Speicher/Raleigh/IBM at IBMUS
To:
Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-cm at open-services.net
Date:
06/17/2010 08:58 AM
Subject:
Re: [oslc-core] v1 Service Descriptions vs v2 Services



Thanks for the feedback Jim.  Adding the oslc-cm to this thread as it is 
both of CM and Core interest.  Comments below... 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> wrote on 06/15/2010 
05:17:55 PM:

> From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> 
> To: oslc-core at open-services.net 
> Date: 06/15/2010 05:18 PM 
> Subject: [oslc-core] v1 Service Descriptions vs v2 Services 
> Sent by: oslc-core-bounces at open-services.net 
> 
> 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?
> 

I believe you are saying it is still needed.  Perhaps in an attempt to 
simplify, it got dropped. 
I will take the action to add this back, barring any objections. 

> (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.
> 

In an attempt to simplify the model in v2, we pushed some of the 
information that was in the v1 ServiceProvider inline local resource and 
consolidated the SeviceDescriptor into the v2 resource definition of 
ServiceProvider. 

In v1, you'd have: 
   ServiceProviderCatalog (URI) 
     +- ServiceProvider 
        +- service (URI)       -> ServiceDescriptor 
                                    +- changeRequests 

In v2, you'd have: 
   ServiceProviderCatalog (URI) 
     +- serviceProvider (URI)  -> ServiceProvider 
                                    +- Service 
                                       +- domain = "
http://open-services.net/xmlns/cm/2.0#" 

> 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.

This is not intended way for it to work. 

> (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.

The URIs are intended to be stable.  If you want additional information 
from the v2 ServiceProviderCatalog about a ServiceProvider, a client can 
request that information to be "inlined" using oslc.properties. 

I'll take the action to define this clearly in the CM 2.0 spec section of 
compatibility