Saxon

XQJ was designed for XQuery 1.0 and its architecture very much assumes that the query result is being returned to the application as a sequence of items, not as a serialized document. In addition, XQJ is subject to very strict licensing rules which demand 100% conformance to the test suite and no implementor extensions.

I'm really not sure how you would expect a serialized query result to be delivered by XQJ. The only methods for returning query results return the result as an XQSequence or similar, which is clearly a sequence of items rather than a serialized lexical XML document.

I would encourage you, if you want to take full advantage of facilities introduced later than XQuery 1.0, and full advantage of Saxon's capabilities, to move to the s9api interface instead. XQJ is a dead end; it isn't being further developed, and it bans implementors from developing their own extensions.

The XQuery 3.1 specification states "A processor that is not performing serialization may report errors if any serialization parameters are incorrect, or may ignore such parameters." The Saxon XQuery compiler validates the parameters because it is not known at query compile time whether serialization will be requested at query execution time.

Thank you for the detailed explanation behind the reasoning to close this issue. Much appreciated.

I would appreciate it even more, however, if this ticket could be reopened. Here’s why:

Leaving the issue aside as to why I have to use XQJ at the moment, I think these statements are false (except for the “designed for XQuery 1.0” bit):

XQJ was designed for XQuery 1.0 and its architecture very much assumes that the query result is being returned to the application as a sequence of items, not as a serialized document.

I'm really not sure how you would expect a serialized query result to be delivered by XQJ. The only methods for returning query results return the result as an XQSequence or similar, which is clearly a sequence of items rather than a serialized lexical XML document.

While it is true that XQSequence provides access to individual items via its XQSequence.getItem() method, it also offers methods like XQSequence.writeSequence(InputStream, Properties) which are clearly meant to output “a serialized lexical XML document” to a byte stream. In fact, the Javadoc for writeSequence even references the XQuery 1.0 serialization specification:

Serializes the sequence starting from the current position to an OutputStream according to the XSLT 2.0 and XQuery 1.0 serialization. Serialization parameters, which influence how serialization is performed, can be specified. Refer to the XSLT 2.0 and XQuery 1.0 serialization and Section 12 Serialization, XQuery API for Java (XQJ) 1.0 for more information.

So these methods are concerned with serialization. Alas, they refer to the wrong version of the spec.

Now I think the argument can be made that, when the query being executed was a XQuery 3.x query rather than an XQuery 1.0 query, we are beyond the scope of JSR 225 anyway, so it cannot mandate if and how output: options should be interpreted. My assumption as a user would hence be that for queries written in a successor of XQuery 1.0, writeSequence would work in accordance with the matching successor version of XSLT 2.0 and XQuery 1.0 serialization, too.

Implementation-wise, I think the following would work:

• In SaxonXQForwardSequence, depending on the version of the query being executed, take the output-properties of this.expression.getXQueryExpression().getExecutable().getOutputProperties().
• Merge these with any non-null Properties passed to writeSequence(…). (My assumption would be that Properties passed explicitly override output properties specified in the query.)
• The static SaxonXQSequence.setDefaultProperties(Properties) might be extended to take both “external” Properties and “internal” Properties (from the Executable).

What do you think?