> From: Samuel Padgett/Durham/IBM@IBMUS > To: [email protected], > Date: 03/26/2012 09:21 AM > Subject: [oslc-core] Requests for unknown or unsupported properties > Sent by: [email protected] > > > 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
