Saxon

The symptoms certainly seem to suggest that the TagSoup parser is being used (incorrectly) to parse the stylesheet.

I have now also tested with Saxon-EE 9.9.1.4N and it gives the same error:

Saxon-EE 9.9.1.4N from Saxonica
.NET 4.0.30319.42000 on Microsoft Windows NT 6.2.9200.0
Using license serial number V.....
Using parser org.ccil.cowan.tagsoup.Parser
URIResolver.resolve href="file:/C:/SomePath/SomeDir/./identity.xsl" base="null"
Using parser org.ccil.cowan.tagsoup.Parser
Static error at xsl:stylesheet on line 1 column 1 of identity.xsl:
  XTSE0150: Namespace for stylesheet element should be http://www.w3.org/1999/XSL/Transform
Namespace for stylesheet element should be http://www.w3.org/1999/XSL/Transform

I hope this support issue will be converted into a bug issue. Or let me know whether I should file a separate bug issue.

Command line is simply in Powershell:

PS C:\SomePath\SomeDir> & 'C:\Program Files\Saxonica\SaxonEE9.9N\bin\Transform.exe' -t -xsl:.\identity.xsl -s:.\input.xml -x:org.ccil.cowan.tagsoup.Parser

and the file identity.xsl is indeed an XSLT stylesheet because Saxon runs it fine if I don't use the -x:org.ccil.cowan.tagsoup.Parser option.

The relevant logic appears to be in StylesheetModule.loadStylesheet(), line 239, where the code reads:

            if (options.getXMLReader() == null && options.getXMLReaderMaker() == null && Version.platform.isJava()) {
                XMLReader styleParser = config.getStyleParser();
                options.setXMLReader(styleParser);
                Sender.send(styleSource, sourcePipeline, options);
                config.reuseStyleParser(styleParser);
            } else {
                Sender.send(styleSource, sourcePipeline, options);
            }

If I remove the test on Version.platform.isJava(), then it works. What is happening is that it goes into the "else" branch, and Sender.send() allocates a parser by calling config.getSourceParser() (which of course returns TagSoup).

So the question is, why is this test there in the first place?

Note that there is very similar code in StylesheetModule.loadStylesheetModule(), which is concerned with loading included or imported modules. This however contains extra checks to ensure that if a SAXSource with an initialized XMLReader was supplied then we respect that in preference.

I suspect the test for platform=Java is there because a different path is used on .NET for transformations invoked using the API rather than the command line. From the command line we appear to use the StandardURIResolver (as on Java), while from the API, by default, we use the DotNetURIResolver which delegates to a user-supplied XmlResolver if there is one.

Note that there's a clear coding error in Sender.send line 202 - after the call on config.getSourceResolver().resolveSource(), if this returns a recognized kind of Source and we make a recursive call on send(), we should then exit. Otherwise we inevitably go on to the "throw exception" path at the end of the method. It seems that the ability to supply a user-defined Source resolver is not being tested.