Bug #4206
closedXSLT stylesheet Compiler Error
0%
Description
using SaxonEE 9.6.
we have a xslt having this below line
<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>
and it results in below exception
net.sf.saxon.s9api.SaxonApiException: Stylesheet compilation failed: 2 errors reported at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:546) at
Caused by: net.sf.saxon.trans.XPathException: Stylesheet compilation failed: 2 errors reported at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:97) at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:543)
Adding the StaticErrorHandler gives the error message as
Invalid character '' in expression; SystemID: file:/xxxx/xxxx.xsl; Line#: 90; Column#: 144
which points to the above mentioned XSLT line
we think its related to Union operator as the below code works
<xsl:variable name="descriptor-nodes" select="l1d | //descriptor"/> --> without dot, works good
<xsl:variable name="descriptor-nodes" select="l1d"/> --> works good
<xsl:variable name="descriptor-nodes" select=".//descriptor"/> -->works good
with this ,we can conclude that xsltcompiler throws fatal error for expression "node1 | .//node2" ?
Files
Updated by Jayaramu Chikkaiah over 5 years ago
Actually XSLT line causing this issue
<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>
Updated by Michael Kay over 5 years ago
Could you please
(a) supply a repro - that is, a minimal stylesheet that exhibits the error
(b) try running it on a more recent release? - i.e. 9.8 or 9.9.
(c) check that you really don't have an expression containing a backslash (\
). The most likely explanation of the error message is that you have accidentally used a backslash in place of a forwards slash, which is not allowed in XPath.
Updated by Jayaramu Chikkaiah over 5 years ago
<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>
Updated by Jayaramu Chikkaiah over 5 years ago
Hi Michael, below is the xslt line which cause this error
<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>
But below lines works
<xsl:variable name="descriptor-nodes" select="l1d | //descriptor"/>
<xsl:variable name="descriptor-nodes" select="l1d"/>
<xsl:variable name="descriptor-nodes" select=".//descriptor"/>
I'm getting the same error with 9.8 version
Updated by Michael Kay over 5 years ago
I can't reproduce the problem. Please supply a complete stylesheet.
Updated by Jayaramu Chikkaiah over 5 years ago
Attaching the xslt file for your reference. The above mentioned issue encounter on line # 90 of this file
Updated by Michael Kay over 5 years ago
I can't get a clean compile out of this because of the xsl:include
dependencies, but if I comment out the xsl:include
s, I get only "missing function" errors, no syntax error on the instruction in question.
I wonder how you are running the transformation? In particular, I wonder if you're hitting the old JDK XML parser bug that sometimes corrupts XML attribute values? Which JDK version are you running under? Do you get a problem if you use Apache Xerces in place of the JDK parser?
Updated by Jayaramu Chikkaiah over 5 years ago
we are on Java 1.8 and here is the code
we are not using any specific perser, then it might be one from JDK.
public File xsltTransform(File inputFile, File resultFile, File xsltFile) throws Exception {
Source src = new StreamSource(inputFile);
Transformer transformer = pFactory.newTransformer(new StreamSource(xsltFile));
StreamResult sr = new StreamResult(resultFile);
transformer.transform(src, sr);
}
Updated by Michael Kay over 5 years ago
This is all rather puzzling.
One thing I notice is that line #90 in the supplied file is only 83 characters long whereas the parser is reporting the location as column #144.
Do you get the same result if you attempt to run it from the command line?
I think it would be useful to trace exactly what attribute values are being passed from the XML parser to Saxon. We could do that by injecting a SAXFilter into the channel between the XML parser and the XSLT compiler. Something like this:
Source src = new StreamSource(inputFile);
TemplatesHandler handler = pFactory.newTemplatesHandler();
XMLFilterImpl filter = new XmlFilterImpl() {
{
setContentHandler(handler):
}
public void startElement(String uri, String localName, String qName, Attributes atts) {
if (localName.equals("variable")) {
int index = atts.getIndex("", "select");
if (index >= 0) {
System.err.println(atts.getValue(index));
}
}
super.startElement(uri, localName, qName, atts);
}
}
XMLReader reader = SAXParserFactory.newInstance().newSAXParser().getXMLReader();
reader.setContentHandler(filter);
reader.parse(new InputSource(xsltFile);
May need to play with this a little to get more focussed information from the tracing, e.g. to display the location information. May also need to check that this is actually using the same XML parser that the failing run is using.
Updated by Michael Kay over 5 years ago
- Status changed from New to AwaitingInfo
- Assignee set to Michael Kay
- Priority changed from High to Normal
Updated by Michael Kay over 5 years ago
- Status changed from AwaitingInfo to Closed
I am closing this as unresolved because we do not have enough information to reproduce it and diagnose it. If more information becomes available, please feel free to re-open it.
Please register to edit this issue