[oslc-core] Proposed language / modifications to "Range" definition

[Steve K Speicher]

Andrew J Berner/Dallas/IBM wrote on 09/28/2010 09:21:19 AM:

> From: Andrew J Berner/Dallas/IBM
> To: Steve K Speicher/Raleigh/IBM at IBMUS
> Cc: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>, 
oslc-cm at open-services.net,
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 09/28/2010 09:22 AM
> Subject: Re: [oslc-core] Proposed language / modifications to "Range" 
definition
> 
> So I understand the purpose of not requiring the type.  At some point we 
may 
> consider whether the type has to support a particular "interface" so 
that I 
> can count on it "knowing" relevant information, but let's not go there 
right now.
> 
> But we don't want to throw out the value of typing while allowing late 
> binding....If I do know the type (like "often the target resource is 
another 
> oslc_cm:ChangeRequest resource) then there is more that I can do with 
it, 
> since I have (in my imagination) written my client to use information 
from 
> such targets.  Can I find out in advance if it is, without having to 
fetch it?
> I may be "out of date"---it the type returned in a header, so I can at 
worst 
> have to make a cheap "HEAD" call instead of a GET?  Is the type of the 
target 
> inlined in the link? Unlike attributes of the target that we should NOT 
be 
> denormalizing, that wouldn't change, right? 

You can perform a HEAD operation setting an Accept header of what you 
want, say RDF/XML or JSON or plain XML.  You can determine if the service 
provider supports this.   If it does then, take for example, a request for 
RDF/XML could determine what kind of resource it is based on parsing if 
you locate the expected rdf:type or locate your properties of interest. 
Additionally, you could attempt a partial fetch and inspect the result to 
see if it is something you can work with.

The key point is, if we build this tight bindings across systems based on 
the "type" of resource, we lose some of the flexibility we get from our 
loose-coupled architecture.  So it may be the case that certain use cases 
may not work if the client can't locate certain properties on that 
resource but this is not a problem.  We just want to be clear in the spec 
that clients should support this behavior.

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