Project

Profile

Help

Bug #4294

Using -x:org.ccil.cowan.tagsoup.Parser with .NET Transform.exe and Saxon 9.8 gives error XTSE0150: Namespace for stylesheet element should be http://www.w3.org/1999/XSL/Transform

Added by Martin Honnen 28 days ago. Updated 13 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Command Line
Sprint/Milestone:
-
Start date:
2019-08-21
Due date:
% Done:

100%

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

Description

I have run into an odd problem, using the .NET version of Saxon 9.8.0.12 EE, when I try to use the TagSoup parser that it has included setting the -x:org.ccil.cowan.tagsoup.Parser on the command line to Transform.exe to be able to parse a not well-formed input it doesn't run but instead gives me an error on the XSLT:

Saxon-EE 9.8.0.12N 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/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

The stylesheet is an XSLT stylesheet like the simplest one below and runs fine with Saxon (including the .NET version) if I don't use the -x:org.ccil.cowan.tagsoup.Parser:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
    <xsl:mode on-no-match="shallow-copy"/>
</xsl:stylesheet>

Is there any known issue that Saxon .NET wrongly applies the TagSoup parser to the XSLT or why does it raise that error?

Does this issue also occur in Saxon 9.9?

History

#1 Updated by Michael Kay 27 days ago

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

#2 Updated by Martin Honnen 19 days ago

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.

#3 Updated by Michael Kay 19 days ago

  • Tracker changed from Support to Bug
  • Status changed from New to In Progress

Yes, I've been working on it today but don't have significant progress to report.

The .NET code takes a rather different path from the Java code for allocating a parser, because the default is to use the Microsoft XML parser which is a pull parser.

#4 Updated by Michael Kay 19 days ago

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.

#5 Updated by Michael Kay 19 days ago

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.

#6 Updated by Michael Kay 19 days ago

  • Status changed from In Progress to Resolved
  • Assignee set to Michael Kay
  • Applies to branch 9.9, trunk added
  • Applies to branch deleted (9.8)
  • Fix Committed on Branch 9.9, trunk added

Fixed on 9.9 and trunk - though not as thoroughly tested as I would like.

The main change is that StylesheetModule.loadStylesheet() and StylesheetModule.loadStylesheetModule() now pick up config.getStyleParser() on .NET as well as on Java.

#7 Updated by O'Neil Delpratt 13 days ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.5 added

Bug fix applied in the Saxon 9.9.1.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF