3 Issues with Saxon/C
Added by Sean B. Durkin about 9 years ago
I have 3 issues with Saxon-HEC 0.3.1 .
(1) Method XsltProcessor::xsltSaveResultToFile() is defective. On the C++ side this method is implemented by calling xsltApplyStylesheet() and then writing the returned string directly into a file, using the native encoding of C++. I don't know what that native encoding is, but whatever it is, it is wrong. If xsltApplyStylesheet() returns an xml document as a string, and that includes an xml declaration with an encoding mark-up, that mark-up will not not respected, and the resultant file will be invalid because its actual encoding will contradict the mark-up. xsltSaveResultToFile() could have been implemented on the C++ side by leveraging the 'o' property.
(2) If the cwd is set to be non-empty, and the 'o' property is given as an absolute filename, xsltApplyStylesheet() will crash. This is because Saxon/C improperly assumes that the 'o' property is a relative filename, and not an absolute one.
(3) Saxon/C provides methods to compile a stylesheet, but no facility to leverage that compilation.
It would be great if these issues could be addressed in the commercial release, when it comes out.
Faithfully, Sean B. Durkin National Australia Bank
Replies (6)
Please register to reply
RE: 3 Issues with Saxon/C - Added by Sean B. Durkin about 9 years ago
h1. Addendum
A couple of more issues ...
(4) If the output filename specified by the 'o' property is relative, Saxon/C will raise 'java.lang.IllegalStateException: The document has not yet been built'.
(5) There appears no way to access the regular XSLT processor output (banner, summary information, details on errors, xsl:message production)
RE: 3 Issues with Saxon/C - Added by O'Neil Delpratt about 9 years ago
Hi Sean,
Thanks for the points you have raised. Let me try to respond to them in turn:
(1) I agree with what you have said and is something which I had doubts about. I did fix this in the development branch. I have reverted to doing the work of saving the file in the Java call-back method.
(2) and (4) I confirm this has been fixed in the development branch some time ago. I did file a new bug for this #2473 just now, but this I have resolved after inspection of the code base.
(3) Yes this has been resolved. We have re-worked the API design to incooperate the compile methods with matching transform methods.
(5) You said: "There appears no way to access the regular XSLT processor output (banner, summary information, details on errors, xsl:message production)" Not sure what you mean here. Do you mean to run XPath on the output? Could you please explain?
RE: 3 Issues with Saxon/C - Added by Sean B. Durkin about 9 years ago
Hi O'Nell,
About (5):
Compare Saxon-HE9 XSLT console (Win32) with Saxon/C API.
If you run a transform and use an xsl:message instruction, the output text will appear in the console's stdout stream. But with Saxon/C, where does this information go? There is no API point to collect it.
Also if you attempt to run a transform with syntax errors, you will get information about the errors, like the line number and column number of the origin of the error. With Saxon/C, you will at least get an exception raised, but that exception has no information in it. All the error messages, warnings and hints that are normally output are just lost with the current Saxon/C API.
To illustrate here is a capture of stdout from a run of Saxon-HE9 console ...
Saxon-HE 9.5.1.1N from Saxonica .NET 2.0.50727.5485 on Microsoft Windows NT 6.1.7601 Service Pack 1 Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser Stylesheet compilation time: 2784 milliseconds Processing file:///C:/Temp/Projects/XSLT/in.xml Building tree for file:///C:/Temp/Projects/XSLT/in.xml using class net.sf.saxon.tree.tiny.TinyBuilder Tree built in 31 milliseconds Tree size: 43 nodes, 93 characters, 4 attributes Execution time: 281ms Memory used: 4500392 NamePool contents: 8 entries in 8 chains. 6 URIs
Where is the equivalent information in the Saxon/C API?
Faithfully, Sean
RE: 3 Issues with Saxon/C - Added by O'Neil Delpratt about 9 years ago
Hi Sean,
Thanks for your useful feedback. Please see response below.
Sean B. Durkin wrote:
Compare Saxon-HE9 XSLT console (Win32) with Saxon/C API.
If you run a transform and use an xsl:message instruction, the output text will appear in the console's stdout stream. But with Saxon/C, where does this information go? There is no API point to collect it.
Yes you are quite right there is a problem here due to missing message listener on the Java side which needs interfacing in JNI (C++). This is something that we are aware of and are working on it. See bug issues: #2425 and #2437
Also if you attempt to run a transform with syntax errors, you will get information about the errors, like the line number and column number of the origin of the error. With Saxon/C, you will at least get an exception raised, but that exception has no information in it. All the error messages, warnings and hints that are normally output are just lost with the current Saxon/C API.
To illustrate here is a capture of stdout from a run of Saxon-HE9 console ...
[...]
Where is the equivalent information in the Saxon/C API?
Saxon-HE console is not directly available, but is something which is not too difficult to interface. In terms of the output which is sent to stderr we could give the option to redirect it to a file. I have filed this as a bug issue #2475
RE: 3 Issues with Saxon/C - Added by Sean B. Durkin almost 9 years ago
RE: 3 Issues with Saxon/C - Added by O'Neil Delpratt about 4 years ago
The bug issue #2475 had been created to address the point raised in (5) of this post. The command line interface of Saxon/C is equivalent to what you would find on Java and .NET was added in Saxon/C 1.0.1.
Please register to reply