[Oslc-Automation] Availability Spec review - my feedback - OSLC Actions - thread 3 Resource: AR

[John Arwe]

MP> oslc_avail:memberOf
TF> What would you think about introducing both directions,

(relatively recent) Core linking guidance discourages it.  As soon as you 
have 2 copies, they can get out of sync and other ugly consequences arise. 
 See my reply in thread 1.

TF> But to be honest this "but this is not necessarily the case" is one 
thing I don't get about OSLC. I mean wouldn't it be nice as someone who 
implements a client for the Avail Spec, to be able to trust that the 
resource behind this link will be a specific type?

It's called the Open World assumption, from W3C Linked Data (i.e. OSLC did 
not come up with or name it AFAIK).  It's the way the Web works - client 
makes a GET request, it gets a response, but there is no guarantee that it 
understands the format of any response body ... even if its GET said 
Accept: application/rdf+xml and it got a 200 response, it has to look at 
the response's content type to know IF it got RDF/XML (and the server is 
allowed to send literally anything, so it might not be).  Robust clients 
have to care about that and code for it.  Non-robust clients can make 
assumptions and skip the extra code, and those assumptions can be wrong. 
All fine. 

The consequences are that robust clients are more complicated, 
interoperability is not "guaranteed" by spec compliance (although in 
truth, is it ever *really* guaranteed if you're talking about specs with 
anything other that MUSTs/MUST NOTs??), and that new/improved "things" can 
be freely deployed.  If you're brilliant and come up with HTML5, you can 
serve it.  If (as a server) you care about wide interop with existing 
clients, then you might serve it only in certain cases based on requests 
from the client.  If (as a server) you're the hot new app with zero 
existing clients to worry about, you can serve HTML5 only.  You choose, 
not the spec authors.

None of this *prevents* you (as a client) from saying that you'll only 
function with servers that DO adhere to the assumptions rendered explicit 
in the specs.  Nor does it prevent servers (or server authors as a group, 
in some vocabulary OSLC or other) from exposing a signal to clients 
explicitly SAYING that you meet all those assumptions, in order to give 
"clients with assumptions" an easy way to figure out if they want to play 
with your implementation or not.

The net reason for putting the burden on clients to deal with anything is 
future extensibility.  RDF itself is pretty extensible, so there might be 
a reasonable-sounding argument that if you're using RDF (which OSLC 2.0 
assumes in Most but not All cases ... look at compact-xml) then you can 
just multi-type and you're done.  That imposes a burden on the servers 
however, that not all server owners like.




Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140514/18d876ac/attachment-0003.html>