[oslc-core] What can an OSLC spec claim? What can a client assume?

[Steve K Speicher]

Hi Paul,

I've included some responses inlined below.

> From: Paul Komar/Lexington/IBM at IBMUS
> To: oslc-core at open-services.net
> Date: 01/06/2011 04:16 PM
> Subject: [oslc-core] What can an OSLC spec claim? What can a client 
assume?
> Sent by: oslc-core-bounces at open-services.net
> 
> Last month Martin Nally wrote "
> I think this confirms that the only safe option for a client is to 
assume 
> nothing. I think the spec should say this."
> 
> Can you please help me understand how a person can implement a client of 
a 
> service whose specification is based upon that much ambiguity?
> (I got the impression from reading some historical notes from WebDAV 
client 
> implementers that while the spec might be written to allow varying 
degrees of 
> sophistication of service implementations, they would have preferred a 
> tighter, more constrained spec.)

The intent of this guidance is to make it very clear that the motivation 
is to build flexible integrations that span time, upgrades, technology 
choices, etc.
So for some scenarios, clients may depend on certain resource formats and 
expect certain properties.  That won't change.  OSLC style of integration 
again focuses on loosely-coupled integrations, whereas efforts like WebDAV 
focused on very specific client-server interaction of SCM tools.
 
> Arthur Ryman replied to "I agree that clients should be able to 
gracefully 
> handle unexpected 
> responses."
> It seems to me that clients can gracefully decline to provide the 
desired 
> behavior when the server doesn't give the client what it needs.
> 
> Consider a use case where a client must get information from a service 
and 
> then use the information in the response to get more information 
(possibly 
> from another service). If the first service does not provide the 
requested 
> information, then the client cannot complete the use case.
> 
> Also, I'm curious to learn how to write good compliance tests if the 
client 
> can assume nothing. 

In having just contributed a test suite, the test suite can assume it is 
speaking to services that claim a level of support.  A test suite is not 
necessarily a well-behaved client in this way.

> While the Rest/OSLC world may want to be more flexible than the UML 
world 
> (with its effective requirement of transitive closure across domains, as 

> Martin also wrote about), OSLC services must provide the information in 
a 
> consumable way, right? I thought that the Restful way to handle version 
> upgrades was to use media types that provided compatible ways to add 
> information in subsequent versions, but allow older/smaller clients to 
use the
> older/smaller content.
> 
> It seems to me that a Rest/OSLC client might have to have a "broader" 
> expectation of valid responses than an client from the UML world. 
(Perhaps 
> there's an equivalence class of useful responses?)
> 
> In summary, I wonder if Martin or Arthur could write up a pattern for 
good 
> OSLC client implementations. 
> Maybe there would be a rule like " don't validate that the response is 
what 
> you expect, instead look in the response for the information that you 
require"?

As you stated it is not a bad way to think about it.  The Core WG is 
starting to build up primers and other material to help guide 
implementers.  This is good input to that effort for consideration on 
writing well-behaved OSLC clients.

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