At 10:13 1/13/2003 +0100, you wrote:
Christian Gross wrote:
Hi
I have added the following patch at the end of this email. It addresses the following, what I think is an issue.
> The problem I see with this result for a query is that you are embedding
> a document withing a document.  This means I have three document
> processing cycles.

Hmmm... I'm currently in the "if it ain't broken don't fix it" mood. I don't really understand the real advantage for this: we would be changing the format of the query replies (thus having to change also all the client code that uses the services) in order to gain just a little more comfort in analyzing the results (presumably from another language, since using the XML:DB API you end up with a ResourceSet). Am I missing something?

Ok imagine writing some client code to the query. The client makes a query

//getdoc

Then an answer is rececived.  The answer is

<result count="xxx">
        <doc></doc>
        <doc></doc>
</result>

This is not XPath specification compliant since the XPath returns to you a set of nodes only. eg, I tried with multiple XPath visualizers like XMLSpy. Usually a node set is returned and I think Xalan uses the object org.w3c.dom.traversal.NodeIterator to represent a node-set. Using the current result format increases the processing requirements because either an object or DOM has to be instantiated before the serialization can occur. This is because you need to get past the result tag object, before the real processing can occur. And in the worst case you need to instantiate a DOM strip the result tag and save back to a string to get the actually resultset that you wanted.

By converting the data to an array as per my patch the end client has the option to paste everything into the <result>...</result> as desired or the end client can retrieve the XML data and assemble it as a node-set.

Yes the reason why I stumbled on this is because I was using C++ serialization. However, there may be more people using the XMLRPC layer since XML:DB is specific to Java, which means for some XML:DB it is absolutely useless.

Comments?


Christian Gross Software Engineering Consultant / Trainer http://www.devspace.com North America: 1-450-675-4208 Europe: +41.1.701.1166



Reply via email to