XQuery to Java
Added by Anonymous over 18 years ago
Legacy ID: #3686908 Legacy Poster: James (jamesbrn)
I have written some XQuery functions and I am interested in converting them to Java methods, so as to include them in net/sf/saxon/functions/Extensions.java. Does Saxon 8.7 provide any mechanism that can do that? Thank you!
Replies (7)
Please register to reply
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3686972 Legacy Poster: Michael Kay (mhkay)
No, there's no mechanism to do this. Interesting idea though. Allowing query library modules to be separately compiled is certainly something I would like to do one day, and that's related. Please don't put your own extension functions in the Extensions.java module, by the way: they should go in your own namespace, in your own module, not in the Saxon namespace.
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3692760 Legacy Poster: James (jamesbrn)
OK, thanks a lot! I am now trying to convert manually my XQuery functions to Java methods. I cannot figure out how to construct elements dynamically: I have written the method: public static SequenceIterator returnComputedElement(XPathContext xpc, QNameValue qnv) throws XPathException { ComputedElement ce = new ComputedElement(qnv, null, null, AnyType.getInstance(), Validation.DEFAULT, false, true); System.out.println("\n\nBefore ce.iterate(xpc)\n\n"); SequenceIterator si = ce.iterate(xpc); System.out.println("\n\nBefore returning si\n\n"); return si; } and when I call it: for $x in doc("test4.xml")//element() return constructor:returnComputedElement(node-name($x)) the 1st message “Before ce.iterate(xpc)” is printed and then a java.lang.NullPointerException is thrown.
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3692814 Legacy Poster: Michael Kay (mhkay)
The TinyTree structure isn't really designed for easy use from user-written Java code, especially not for update/create access. If you really need to construct a tree this way, the way to do it is to create a TinyBuilder and then feed it SAX-like events via the Receiver interface. But you're probably better off building a JDOM or XOM element and wrapping it in a Saxon NodeWrapper. It depends on what you're trying to achieve, which I don't think I understand.
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3693990 Legacy Poster: James (jamesbrn)
My XQuery FLWOR example was not suitable. In fact, one of the XQuery functions I want to convert to Java does the following: input = an xml file output = an xml file whose structure is a subset of the input file (The set of nodes in the output file is a subset of the set of nodes in the input file and the same goes for the edges of the xml output tree. The root element is always contained in the output subtree). In my XQuery function, I have used “dynamic” element constructors (e.g. element {$name} {contents}). The contents include recursive calls of this function. I suppose that I have to use element constructors in my Java method as well, right? How should I build elements in Saxon?
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3694024 Legacy Poster: Michael Kay (mhkay)
I need to understand your motivation. If I had to do this in a Java application I would call an XQuery or XSLT transformation to do it. You're making life more difficult by trying to do it in Java, and I don't understand what you hope to achieve. As I explained before, the Saxon internals are not optimized for use from user-written Java applications. I've also explained the principle that if you want to do this, you should create a TinyBuilder and pipe events to it. You seem to have ignored that suggestion.
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3694444 Legacy Poster: James (jamesbrn)
I use the XQuery functions that I have written for querying large xml files, within the framework of a project for my University. I hope that if I convert the functions to Java, better performance will be achieved. Thank you for your advice.
RE: XQuery to Java - Added by Anonymous over 18 years ago
Legacy ID: #3694490 Legacy Poster: Michael Kay (mhkay)
I don't see any intrinsic reason why rewriting this code in Java should make it go significantly faster. Some people have found that the overhead of doing a cross-language procedure call exceeds any benefits obtained from the code running faster (if indeed it does run faster). I would look elsewhere for the performance gains.
Please register to reply