Saxon

Legacy ID: #8369805 Legacy Poster: Michael Kay (mhkay)

Well, my advice would be to use the s9api interface rather than XQJ. I designed the s9api interface in large measure because of my frustration that this kind of thing was too difficult in XQJ. The stupid thing is that Saxon is going out of its way to enforce silly restrictions in interfaces like XQResultSequence, where the restrictions make both your life as a user and mine as an implementor more difficult. I suspect you won't find an adequate solution without departing from pure XQJ interfaces. You can probably do it within an XQJ framework (get the XQItem from an XQResultSequence, cast it to SaxonXQItem, extract the underlying net.sf.saxon.om.Item, etc), but once you depart from pure XQJ code, you lose all the benefits you might have gained from portability, so you might as well use s9api interfaces to start with.

Legacy ID: #8369871 Legacy Poster: ailli (ailli)

Actually I was afraid you'd answer that. But since it is an inhouse application not being disstributed a lot I'll write an XQuery Helper using the s9api. This will give me the benefits of getting rid of XQJ and still having a single point of change in my code once the processor should change. Thank you for your quick reply, everything in the scope of Saxon seems to be really fast. ;)

Legacy ID: #8370274 Legacy Poster: ailli (ailli)

While working on the mirgation from XQJ to S9API I found, that you have the handy function compileModule(). May I ask what performance increase I might expect from compiling my XQuery modules compared to importing them (by providing the location) in my query statement? Is it worth buying the Saxon-PE version because of that feature? One thing I am not 100% certain about is what type to use for caching XML documents and results from my queries in my Java application. Is it appropriate to use Document as shown in one of the samples or is there a more efficient object type that should be used? It seems that Document involves a lot of overhead when binding into a new query. Thank you so much for your information.

Legacy ID: #8370338 Legacy Poster: Michael Kay (mhkay)

compileModule() is only useful to you if the same module is used (imported) by more than one query; it saves the work of recompiling the module each time it is imported, and it allows the memory occupied by the module to be shared. If you're using s9api, you should use the DocumentBuilder to build documents in memory; the resulting type is an XdmNode. Similarly, the results of a query will result in a sequence of XdmItem objects, which can be cast to XdmNode if they are nodes.

Legacy ID: #8370532 Legacy Poster: ailli (ailli)

Thanks a lot! Using the native Saxon API the response times of my webapplication decreased by a factor of about 10 and I have not even started optimizing yet. Pretty cool! Thank you so much for your help.