Bug #4206

XSLT stylesheet Compiler Error

Added by Jayaramu Chikkaiah 11 months ago. Updated 10 months ago.

Start date:
Due date:
% Done:


Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


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( at

Caused by: net.sf.saxon.trans.XPathException: Stylesheet compilation failed: 2 errors reported at at net.sf.saxon.s9api.XsltCompiler.compile(

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" ?

i2a.xsl (30.8 KB) Jayaramu Chikkaiah, 2019-04-30 05:09 i2a.xsl


#1 Updated by Jayaramu Chikkaiah 11 months ago

Actually XSLT line causing this issue

<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>

#2 Updated by Michael Kay 11 months 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.

#3 Updated by Jayaramu Chikkaiah 11 months ago

<xsl:variable name="descriptor-nodes" select="l1d | .//descriptor"/>

#4 Updated by Jayaramu Chikkaiah 11 months 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

#5 Updated by Michael Kay 11 months ago

  • Description updated (diff)

#6 Updated by Michael Kay 11 months ago

I can't reproduce the problem. Please supply a complete stylesheet.

#7 Updated by Jayaramu Chikkaiah 11 months ago

Attaching the xslt file for your reference. The above mentioned issue encounter on line # 90 of this file

#8 Updated by Michael Kay 11 months ago

I can't get a clean compile out of this because of the xsl:include dependencies, but if I comment out the xsl:includes, 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?

#9 Updated by Jayaramu Chikkaiah 11 months 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);


#10 Updated by Michael Kay 11 months 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() {
   public void startElement(String uri, String localName, String qName, Attributes atts) {
        if (localName.equals("variable")) {
             int index = atts.getIndex("", "select");
             if (index >= 0) {
        super.startElement(uri, localName, qName, atts);
XMLReader reader = SAXParserFactory.newInstance().newSAXParser().getXMLReader();
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.

#11 Updated by Michael Kay 11 months ago

  • Status changed from New to AwaitingInfo
  • Assignee set to Michael Kay
  • Priority changed from High to Normal

#12 Updated by Michael Kay 10 months 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

Also available in: Atom PDF