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.