This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
MainOslcCommonArchitecture
>
ReportingHome
>
QuerySupportInProviders
(04 Mar 2010,
DragosCojocari
)
(raw view)
---++ Unsupported/unknown arguments handling Q: _How should a Provider handle unknown or unsupported parameters defined by the_ _[[http://open-services.net/bin/view/Main/OslcQuery][Query Specification]] ?_ There are 2 possible options: fail silently or ignore the parameter. *Example 1* failing silently to handle _oslc.where_ and returning all records will change the semantics of a report/document requesting only the "high priority" requirements. *Example 2* failing silently to support _oslc.select_ will preserve the semantics 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 options is preferable. This raises a problem on what consumers should expect from providers and viceversa. Q: _Should the OSLC Reporting Specification request providers to suport all parameters?_ 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. Having 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 ignores unknown/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 the awkward position of not knowing if 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 (oslc.strict) 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. A simpler option is to allow the consumer to specify how the provider handles unsupported/unknown parameters in the request via the _oslc.strict_ parameter. *Note* the _oslc.strict_ parameter is similar to the "pedantic" flag found in many compilers. Example [[http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html][GNU C++ Compiler]] *Note* Support for this parameter is mandatory. The default value for _oslc.strict_ should be _true_ so that consumers can identify immediately the provider's capabilities and prevent incorrect documents/reports being created. The parameter's possible values are: _oslc.strict_ _= true_ the provider must return a [[http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1][HTTP 400 - Bad Request]] error if it encounters any parameter it cannot handle <blockquote><pre>http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit&oslc.offset=100&oslc.strict=true</pre></blockquote> __Result__ this request will succeed only if the provider supports all the parameter: _oslc.where, oslc.orderBy, oslc.limit._ _oslc.strict_ _= false_ the provider may silentlly ignore unknown/unsupported parameters <blockquote><pre>http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit&oslc.offset=100&oslc.strict=false</pre></blockquote> __Result__ this request will always succeed even if the provider supports none of the other parameters.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 04 Mar 2010 - 11:12:54 -
DragosCojocari
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback