[oslc-core] Requests for unknown or unsupported properties

[Steve K Speicher]

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 03/26/2012 09:21 AM
> Subject: [oslc-core] Requests for unknown or unsupported properties
> Sent by: oslc-core-bounces at open-services.net
> 
> 
> I couldn't find clear guidance on how providers should respond to 
requests
> for unknown properties, for instance in an oslc.properties or 
oslc.select
> parameter. This might be a request for a non-standard property that a
> provider doesn't recognize (e.g., http://example.com/ns#customProperty) 
or
> a standard, but optional property not supported by the provider.
> 
> An example from the CM domain is state predicates, which are optional
> properties on a ChangeRequest resource [1]. How should a provider 
respond
> to these queries if it doesn't support oslc_cm:approved? (I've left the
> query parameters unescaped and omitted oslc.prefix for readability.)
> 
> http://example.com/bugs/34?oslc.properties=oslc_cm:approved
> http://example.com/bugs?oslc.select=oslc_cm:approved
> http://example.com/bugs?oslc.where=oslc_cm:approved=true
> 
> Either responding with a 400 Bad Request or simply leaving unknown
> properties out of the response seem like reasonable choices. I propose 
we
> advise providers to simply leave the unknown properties out of the
> response. This way consumers can request optional properties without 
fear
> of running into errors. In the case of the oslc.where query above,
> providers might simply return no results.
> 
> I suggest we update OSLC Core Spec Selective Property Values [2] and the
> query specification [3] with guidance.
> 
> [1]
> http://open-services.net/bin/view/Main/CmSpecificationV2?
> sortcol=table;up=#Resource_ChangeRequest
> [2]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;table=up;up=#Selective_Property_Values
> [3] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery

Let's ignore for a moment, what needs to be fixed in the spec and look at 
these as a case-by-case basis and elaborate on the intent and then work 
our way backwards to see if we need to fill any holes.

Assuming the case where the server doesn't support the oslc_cm:approved 
predicate on ChangeRequests:

> http://example.com/bugs/34?oslc.properties=oslc_cm:approved
To me, this seems pretty clear that this should not be an error case. 
Server should return representation for bug 34 and simply omit 
oslc_cm:approved. What else it returns?  Could be no triples, could be a 
few, up to the server.

> http://example.com/bugs?oslc.select=oslc_cm:approved
Similar to the previous, not an error.  Simply omit.

> http://example.com/bugs?oslc.where=oslc_cm:approved=true
This should follow semantics of SPARQL WHERE.  If there are no triples 
that match this, which there can't be since oslc_cm:approved as the 
predicate of any triples.

> http://example.com/bugs?oslc.where=oslc_cm:approved!=true
Same as previous.  Though it would be worth running a few tests to confirm 
SPARQL behavior with some of these negative/edge cases.

This would seem to be in line with what the intent of the spec is.  If 
there is agreement on this (just re-confirming with this example), then we 
can propose what changes we may want.  Sam had offered to go off and do 
some experimenting to confirm some of this and propose some update.

- Steve