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 -- Best Regards, Samuel Padgett | IBM Rational | [email protected]
