Christian Gross wrote:
1. XML-RPC access in Xindice was, and still, is meant as a network transport for the networked XML:DB Java API: the fact of having a generic XML-RPC access to Xindice is just a (pleasant?) consequence.
Does this mean then that XMLRPC is a way to realize XMLDB? If so then it would be best for me to simply chuck away the XMLRPC and build an AXIS layer.
Probably (and always IMHO) yes.
2. Since XML-RPC direct access is somehow outside of the Xindice scope and not directly supported as it stands now, my suggestion is to feel free to add to your particular setup any XML-RPC method you might see as more consistent with your particular environment. We are currently discussing on (and if) give hooks to users to extend the XML-RPC layer in a structured way, but as of now it's more than enough to place your class in the o.a.x.server.rpc.messages package to add your own XML-RPC accessor.
That would mean changing the way the class is loaded since it seems it expects org.apache.xindice.rpc.messages.*, yes?
Exactly. Hopefully we'll soon come out with a mechanism to plugin XML-RPC methods in any namespace (even if, given that XML-RPC is just a transport I'm personally not that much convinced that this is a Good Thing).
This said, I'm still not getting what you mean when you talk about XPath result not being specification compliant.
In the XPath specification consider the following:
3.3 Node-sets
A location path can be used as an expression. The expression returns the set of nodes selected by the path.
Now comes the question what is a node-set? In the case of Xalan it is a w3 nodelist. And a nodelist is basically an array of nodes.
Well, yes. With the exception that any node might contain an arbitrary number of nodes.
But the problem is that the XMLRPC layer is used as a transport and the result tag is generated by the *.rpc.messages.Query class, not the XIndice infrastructure. Consider the following code:[...]
private String queryWrapper( NodeSet ns ) throws Exception { // Turn the NodeSet into a document.
The nodeset is the result of the query, which is correct, as per the XPath spec. But in the code the nodeset is converted into a document, even though it does not need to be converted into a document. XMLRPC allows the saving of an array, which is a 1 to 1 mapping of a nodeset. Saving the nodeset into a document breaks the spec of XPath 3.3 since you generating a document. And for those clients that are expecting a nodeset as a result-set they need to map the document back into a nodeset. And in my case where SOAP and the serialization is handled automatically this mapping adds an extra processing cycle.
OK, now I see your point, thanks for clarifying it. Basically what you don't want to see is another Document embedded in a Document. Which makes sense, but what if we would return not a Document but a DocumentFragment or, even better, just a Node? Just making some wid guesses, I'd have to check what needs to be changed (probably o.a.x.client.xmldb.ResourceSetImpl.java, which takes a document as a parameter should be enough: James, Kimbro?). But this said, we should also be careful about what this might change for people (ab?)using XML-RPC API with other languages.
Ciao,
-- Gianugo Rabellino
