Hi David,
BaseX XQJ 1.2.3 has been released [1].
There should now be no compatibility issues while Saxon is on the classpath, it will also use Saxon's TransformerFactory implementation when it is available.
XQuery Serialization 3.0 parameters included in the Prolog of your XQuery expressions will NOT be understood by this version. For now, to affect Serialization, please pass Properties Objects to XQJ methods such as:
* XQItemAccessor.writeItem(OutputStream os, Properties serializationProperties); * XQItemAccessor.writeItem(Writer wr, Properties serializationProperties); * XQItemAccessor.getItemAsString(Properties serializationProperties);
A RFE to read and understand Serialization output properties from the XQuery Prolog has been duly logged and will go into a future version of BaseX XQJ.
As a result, all XQJ implementations will benefit, whether the accompanying XQuery processor itself supports XQuery 3.0 or not.
Let me know if you run into any other issues.
Kind Regards,
Charles
[1] http://xqj.net/basex [2] http://www.w3.org/TR/xslt-xquery-serialization-30/
On 1 October 2012 16:36, Charles Foster charles@cfoster.net wrote:
David,
For now, I have raised this as an issue "0000023" [1].
But overall, there are two sides to this story,
- There is almost certainly a bug in the XQJ implementation, (to be
fixed in a patch release). 2. Additional enhancements need to be made to the XQJ implementation. This will be in minor version release, to be released later.
As far as I am concerned, an XQJ implementation (e.g. BaseX XQJ) is ultimately responsible for the serialization of result sequences and items, not the processor (e.g. BaseX XQuery Processor) when of course you are using a software driver like XQJ.
You are attempting to override the default XQuery / XSLT serialization parameters in the XQuery prolog itself, which, according to XQuery 3.0 specification is a fair request.
Because Saxon throws an exception while it's on the classpath, I consider this to be a bug. I will resolve and issue a patch release so no exception occurs.
However, even after supplying the patch release, as it stands, the XQJ implementation ignores the XQuery 3.0 serialization parameters you are declaring in your XQuery prolog. I must add enhancements to the XQJ implementation so that it recognises serialization options being declared in the XQuery expression itself.
For now / when the patch release comes out, you can override default XQuery / XSLT serialization parameters by passing a Properties argument to various different Java methods, e.g.:
- XQItemAccessor.writeItem(OutputStream os, Properties serializationProperties);
- XQItemAccessor.writeItem(Writer wr, Properties serializationProperties);
- XQItemAccessor.getItemAsString(Properties serializationProperties);
@Christian I would like your opinion on something :-
If the user declares a serialization property in an XQuery prolog AND the user has also specified a serialization Properties object when calling an XQJ method which happens to contain serialization options which CONFLICT with the options declared in the XQuery prolog, what behaviour do you think should occur?
Some possibilities spring to mind:
- Java Properties Object is Priority. (Logger gets a warning message
about conflict). 2. XQuery Prolog declaration is Priority. (Logger gets a warning message about conflict). 3. Throw an Exception due to the conflict.
Currently, as it stands, I think the current behaviour in the XQJ implementation is for things like default namespace declarations, ordering mode, boundary space policy and so on, the XQuery expression has the priority over the current XQStaticContext.
Perhaps it is better to state whatever appears in the XQuery expression has absolute priority?
[1] http://xqj.net/issues/view.php?id=23
Kind Regards,
Charles
On 28 September 2012 20:17, Christian Grün christian.gruen@gmail.com wrote:
Dear David,
thanks for your e-mail and your report. I finally had some time to look at your example, and I managed to reproduce the problem. As the error is raised before BaseX gets into action, I'm passing this on to Charles Foster who wrote the wonderful XQJ implementation for BaseX..
@Charles: this is the Saxon class that raises the error..
https://dev.saxonica.com/repos/archive/opensource/latest9.2/hej/net/sf/saxon...
..and this is the specification link to the SEPM0009 code:
http://www.w3.org/TR/xslt-xquery-serialization-30/#ERRSEPM0009
Do you have an idea if this issue can be solved within your API?
Thanks, Christian
---------- Forwarded message ---------- From: David Oguns davidoguns@gmail.com Date: Thu, Sep 27, 2012 at 5:05 PM Subject: [basex-talk] XQJ: Exception using Saxon9 TransformerFactoryImpl To: basex-talk@mailman.uni-konstanz.de
I am trying to perform a basic document insert using the XQJ API communicating with a standalone BaseXServer. I have a lot of dependencies on my classpath (I'm sure this affects JAXP's behavior), including Saxon, Xerces, Xalan, and probably a few versions of some of them. When I set the transformer factor explicitly to Xalan, there is no exception, but otherwise it appears Saxon is being used and it down throw an exception. I have a very high opinion of Saxon so I have my doubts that it's doing anything illegal with respect to the standards, so I thought I should ask what is going on. This is the property I can set to get rid of the problem:
System.setProperty("javax.xml.transform.TransformerFactory", "org.apache.xalan.processor.TransformerFactoryImpl");
Here is the exception and stack trace:
javax.xml.xquery.XQException:
XQJTO013 - Values of 'standalone' and 'omit-xml-declaration' conflict
Root Cause:
net.sf.saxon.trans.XPathException: Values of 'standalone' and 'omit-xml-declaration' conflict
at MyClass.main(MyClass.java:82)
at net.sf.saxon.serialize.XMLEmitter.writeDeclaration(XMLEmitter.java:226)
at net.sf.saxon.serialize.XMLEmitter.openDocument(XMLEmitter.java:143)
at net.sf.saxon.serialize.XMLEmitter.startElement(XMLEmitter.java:303)
at net.sf.saxon.event.NamespaceReducer.startElement(NamespaceReducer.java:72)
at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:290)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:400)
at net.sf.saxon.event.Sender.send(Sender.java:154)
at net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:35)
at MyClass.main(MyClass.java:82)
And here is the relevant code:
XQDataSource xqs = new BaseXXQDataSource();
xqs.setProperty("serverName", "localhost");
xqs.setProperty("port", "1984");
XQConnection conn = xqs.getConnection("admin", "admin");
try {
XQStaticContext context = conn.getStaticContext();
XMLStreamReader xmlReader = XMLInputFactory.newInstance().createXMLStreamReader(new FileReader(args[0]));
XQPreparedExpression xqpe = conn.prepareExpression("declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization%5C%22;declare option output:omit-xml-declaration "no";declare variable $doc external;\nfn:put($doc,"jc003.xml")", context);
//xquery doc('oguns/jc001.xml')
try{
xqpe.bindDocument(new QName("doc"), xmlReader, conn.createDocumentType());
XQResultSequence xqrs = xqpe.executeQuery();
} finally {
xqpe.close();
}
}
finally {
conn.close();
}
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk