Christian Gross wrote:At 23:43 1/13/2003 +1100, you 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. This means that it might well be possible that in the future the scenario will change: as we switched from CORBA to XML-RPC, we might switch to RMI, SOAP or WebDAV, without any backward compatibility issue to consider (meaning that we will be backward compatible to XML:DB clients, not to XML-RPC calls that the client makes). While I don't see the XML-RPC stuff going away anytime soon, please note that there is no contract whatsoever that the way XML-RPC access is implemented will not change in the future: our only contract with users is to have a consistent client-server scenario with the XML:DB APIs.
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.
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?
This said, I'm still not getting what you mean when you talk about XPath result not being specification compliant. AFAIK there is no cross-platform and standard way of returning an XPath result, so the actual decision is left to the implementor. But I'd be more than willing to know more about this: can you point me out to some documentation on this topic?
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. Ok one can argue that nodelist is a node and therefore the result tag does not break the notation. The only comment there is that XMLRPC is used to embed yet another document. This is legal because the spec is vague.
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.
DocumentImpl doc = new DocumentImpl(); Element root = doc.createElement( "result" );
doc.appendChild( root );
int count = 0;
while ( ns != null && ns.hasMoreNodes() ) {
Node n = ns.getNextNode(); if ( n.getNodeType() == Node.DOCUMENT_NODE ) {
n = ( ( Document ) n ).getDocumentElement();
} if ( n instanceof DBNode ) {
( ( DBNode ) n ).expandSource();
} root.appendChild( doc.importNode( n, true ) );
count++;
}root.setAttribute( "count", Integer.toString( count ) );
return TextWriter.toString( doc ); }
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.
Christian Gross Software Engineering Consultant / Trainer http://www.devspace.com North America: 1-450-675-4208 Europe: +41.1.701.1166
