Unsupported/unknown arguments handling

Q: How should a Provider handle unknwown or unsupported parameters defined by the [[http://open-services.net/bin/view/Main/OslcQuery] [Query Specification] ]?

Q: Should the OSLC Reporting Specification request providers to implement all parameters, just a few or none?

There are 2 possible options: fail silently or ignore the parameter.

Example 1 failing sillently to handle oslc.where and returning all records will change the semanthics of a report/document requesting only the "high priority" requirementes.

Example 2 failing sillently to support oslc.select will preserve the semanthics of the report/document but will generate additional network traffic.

So depending on the parameter,consumer and use case one or the other of the optionsis is preferable. This raises a problem on what consumers should expect from providers and viceversa. Marking as mandatory only a subset of the requirements, and facing the prospect of new parameters introduced by future specs, can confuse providers and consumers alike. Hence the proposal is either to mark all parameters mandatory or none.

All parameters mandatory

The provider must support all parameters

This is the ideal scenario for the consumer but raises the bar for the provider to support the Query Spec. Havin server side support for filtering, sorting and property selection ensure an optimal reporting/document generation experience: the consumer gets exactelly what it needs and can consume the data with minimal pre-processing.

All parameters optional

The provider will ignore all unkwnon/unsupported parameters

Note: "ignore" may have different meanings based on the parameter. The exact behavior needs to be documented by each provider.

This implies very little effort for a provider which already exposes a RESTfull API. On the other hand this approach puts the consumer in a awkward position:were the parameters handled or not? Even if the consumer can compensate the of server side implementation for some parameters it needs to know if the server handles them or not. And with the server silently ignoring parameters this is not a straightforward task.

All parameters optional with strict mode

Lowering the bar for Query Spec support favors the adoption of the OSLC Reporting with providers. The consumer's problem in this case is that it needs to know parameter is supported or not. This can be achieved by providing the information in the resource shape or reading it from the provider manuals. Another option is to allow the consumer to specify how the provider handles unsupported/unkwnown parameters in the request.

Note the strictMode parameter is similar to the "pedantic" flag found in many compilers. Example GNU C++ Compiler

The parameter possible values are:

strictMode= *true* the provider must return a HTTP 400 - Bad Request error if it encouters any paramater it cannot handle

http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit&oslc.offset=100&stricMode=true

This request will succeed only if the provider supports all the parameter: oslc.where, oslc.orderBy, oslc.limit.

strictMode= *false* the provider may silentlly ignore unknown/unsupported parameters

http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit&oslc.offset=100&stricMode=false

This request will always succeed even if the provider supports none of the other parameters.

Note Support for this paramater is mandatory.