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

[Arthur Ryman]

Paul,

OSLC is not really defining a new programming model. Instead it is 
adopting the programming model of the Web. An OSLC client should therefore 
behave like a Web browser. There are plenty of bad HTML pages and broken 
links on the Web, yet browsers don't crash. They handle pages as best they 
can and provide error messages when they can't proceed.

The same applies to OSLC servers. They need to be developed on the 
expectation that they'll get bad requests.

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063





From:
Paul Komar <pkomar at us.ibm.com>
To:
oslc-core at open-services.net
Date:
01/06/2011 04:14 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.)

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. 

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"?

--
Paul Komar
Jazz/RTC SCM Developer
Rational Software
IBM Software Group
Littleton, MA_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net