Slide 6: Should RUS support full XPath or should it restrict XPath?

Full XPath compliance would be good because clients would not mystically get
back failed requests without knowing why. 

Full XPath compliance also means that you have to be able to return parts of
UsageRecords if the client selected only a part of a record. This is currently
not allowed by the specification because it requires you to return whole URs
only. 

XPath queries can be quite slow to execute and destroy any performance. This 
was the reason why we have actually removed all XPath queries from our RUS and
only allow pre-canned queries via separate operations (extractByUser etc.).
For performance I would recommend to put the extractBy... methods back into
the specification.
Also XPath queries are hard to map to SQL queries and RDBs are needed for
performance. How is this handled by other people.

The RUSQueryTooComplexFault (or equivalent) would give a server the chance to
respond reasonably when it deems the query as being too complex or taking too
much time to execute.

Suggestion 2 (restrict XPath) would be covered by Suggestion 1 (support full
XPath, allow RUSQueryTooComplexFault) since a server could restrict the
allowed XPath queries by returning the fault.

A possible solution to long queries could be to allow for a reply of style "I
am too busy, come back later". This could also be used selectively to defer
complex queries until low system load allows there handling.
That could be hard to implement in case of many concurrent requests, and it
would not solve the problem of many complex queries.

One solution to the problem could be to require proper authorization to be
allowed to execute complex queries. (e.g. the authorization decision also
is based on the query).

One solution would also be to have a method to return a catalog of allowed
queries that the server is willing to process. A variant of this would be
to have a operation to check if a server is willing to execute a query.
This functionality could already be provided by the query operation, because 
it will tell you if the server rejected the query and return the result 
otherwise.
A idea in conjunction with this would be to have a minimum catalog of simple
queries that a instance has to execute to give clients a well known fall-back
mechanism.

In case of allowing partial URs to be returned, how can a client validate the
result against the UR schema.
This problem should also be tackled by the DAIS-WG since they also have to
return query results. Check how they did address that problem.

Slide 6: Should RUS support full XPath or should it restrict XPath?

Full XPath compliance would be good because clients would not mystically get
back failed requests without knowing why. 

Full XPath compliance also means that you have to be able to return parts of
UsageRecords if the client selected only a part of a record. This is currently
not allowed by the specification because it requires you to return whole URs
only. 

XPath queries can be quite slow to execute and destroy any performance. This 
was the reason why we have actually removed all XPath queries from our RUS and
only allow pre-canned queries via separate operations (extractByUser etc.).
For performance I would recommend to put the extractBy... methods back into
the specification.
Also XPath queries are hard to map to SQL queries and RDBs are needed for
performance. How is this handled by other people.

The RUSQueryTooComplexFault (or equivalent) would give a server the chance to
respond reasonably when it deems the query as being too complex or taking too
much time to execute.

Suggestion 2 (restrict XPath) would be covered by Suggestion 1 (support full
XPath, allow RUSQueryTooComplexFault) since a server could restrict the
allowed XPath queries by returning the fault.

In case of allowing partial URs to be returned, how can a client validate the
result against the UR schema.
This problem should also be tackled by the DAIS-WG since they also have to
return query results. Check how they did address that problem.