[oslc-core] Last call for comments Re: Proposed resolution for issue #42 - unknown selective and search properties in OSLC queries

[John Arwe]

>> "The provider can return an OSLC Error resource to indicate to the 
consumer that the query will not succeed as constructed."
> There should be some more explicit way to determine what properties are 
present, e.g. via a ResourceShape.

I sense an underlying difference of opinion on clients' responsibilities, 
that might have knock-on implications for providers.  Or maybe it's "how 
should I read 'can'?"

Resource shapes are optional today.  So telling even the best-intentioned 
clients to rely on them for this/any purpose will leave gaps.

By the same token, requiring all clients to write the code to introspect 
providers in order to get predictable results has its own issues.  There 
is a barrier-to-entry issue (raising the lower bar if we do this), and 
metadata (resource shape/etc) issues like availability (is it even 
present, given that it's optional) and durability (I can upgrade an 
implementation between client requests, so does a client have to 
re-introspect before each request in order to get predictable results?)

I'm sure we'll see, over time (even the near-er term) cases where existing 
clients are pointed at new providers where (due to bad/incomplete doc, 
etc) there is a mismatch in capabilities.  I read "can" as a MAY, without 
the potentially confusing "normative caps" occurring in informative text. 
It sounds to my ears Arthur like you'd prefer to either remain silent or 
impose something whose spirit is MUST/SHOULD NOT return an error result. I 
think we need to allow providers wishing to do so the flexibility to 
indicate the provider Knows For Sure that the client's request semantics 
could not be carried out (because that provider never exposes the 
properties being queried for).  By your arguments on SPARQL OPTIONAL, it 
sounds like a 4xx response would not be a good choice for that indication 
... and that agrees with my intuition.  I am going to be after the 
flexibility to introduce something in the future; a Warn header being the 
current front-runner in my head (and then clients can decide whether or 
not they check for it), but I'm not particularly attached to the 
mechanism.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130410/273c058a/attachment-0003.html>