rpc wire protocol for direct useage as it is likely to change in response to bugs and other improvements. Having said that I've gone through each of the scenarios and added notes on how they can be achieved using the current apis. Checking these implementations out has exposed a number of limitations in the current xpath query resolver for which I've filed bug reports and added unit tests.
1) Ability to do a "windowed" query on the server:
Given an XPath query, return only the N through N+size of the
entire result set produced by that query.
The elements are selected on the server, and only the qualifying
ones are returned to the client.
This is kinda available in the xmldb api already by the use of lazy evaluation in the next() method of the result set.
ResourceSet results = (do your quesry here);
if (results.hasNext())
{
for (int i = 0; results.hasNext(), ++i)
{
if (i > n)
{
if (i > n + pagesize)
break;... do your resource thing ... } }
Any driver that supports lazy evaluation will only need to download enough data to ensure the hasNext can operate.
Unfortunatly the xindice xml-rpc driver does not (at present) do this. But it is possible within the xmldb api. I've added an enhancement request for this.
2) Ability to just check for existence:
Given an XPath query, return just a true/false value, whether the
XPath query found something or not.
This implementation returns something like: <result>true</result>
The xpath expression boolean(//[EMAIL PROTECTED]'1']) could be used for this. Again xindice doesn't support none element results at present. I've added a bug report and unit tests for this example though.
3) Ability to just obtain a count of the elements qualified by an
XPath query (without any documents):
Given an XPath query, return somthing like: <result count="N"/>
The xpath expression count(//[EMAIL PROTECTED]'1']) could be used for this. Again xindice doesn't support none element results at present. I've added a bug report and unit tests for this example though.
4) Ability to query just document ids:
Given an XPath query, return something like:
<result>
<key>f0324bhj24bj23g4j</key>
<key>23i43468kj72b68b</key>
</result>
This isn't really supported in the xmlbd api using the xpath query service. The only way I can think of is to use a key from the document content. This is how it's done in belts (belts.sf.net).
5) Ability to query on attribute elements:
For instance, if the query is: /person/@name
Return something like:
<result>
<name>name1</name>
<name>name2</name>
</result>
Again this is a bug in xindice. It should be possible to return a resultset consisting of attribute nodes and their values. I've added test cases and a bug report.
-k.
