Saxon

Note that there is a problem with this stylesheet which I have noted here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29790

I'm submitting this as W3C test case use-package-150.

I tried to fix that stylesheet taken from the spec by removing the @default-mode="j:xml-to-json"@ and putting all functions declared in the stylesheet into a namespace different from the default function namespace.

Now I am able to compile and export the package and also use the exported package with a stylesheet like the one given above, however when I directly try to provide the the package on the command line I still get a NullPointerException, pretty much with the same stack trace as earlier:

java.lang.NullPointerException
        at net.sf.saxon.style.UseWhenStaticContext.(UseWhenStaticContext.java:52)
        at net.sf.saxon.style.UseWhenFilter.startElement(UseWhenFilter.java:232)
        at net.sf.saxon.event.StartTagBuffer.startContent(StartTagBuffer.java:236)
        at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
        at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
        at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
        at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:370)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Sou
rce)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:451)
        at net.sf.saxon.event.Sender.send(Sender.java:179)
        at net.sf.saxon.style.StylesheetModule.loadStylesheetModule(StylesheetModule.java:131)
        at net.sf.saxon.s9api.XsltCompiler.addCompilePackages(XsltCompiler.java:568)
        at net.sf.saxon.Transform.doTransform(Transform.java:703)
        at net.sf.saxon.Transform.main(Transform.java:77)

My command line in a Powershell on Windows is like this:

 java -jar 'C:\Program Files\Saxonica\Saxon9.7EE\saxon9ee.jar' -t -xsl:'test2016082307.xsl;test2016082310.xsl' -s:test2016082304.xml

The input @test2016082304.xml@ continues to be the XML sample in the spec, the stylesheet @test2016082307.xsl@ is now

and the corrected stylesheet package is

    


	
	"
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
		
	
	
	
	
		
		
		
			
		
		
			
				
					
				
			
			
				
					
				
			
		
	
	
	
	
	
		
	
	
	
	
	
		
			
			{
			
				
					, 
					
				
				
				 : 
				
			
			}
		
	
	
	
		
			{
			
				
					,
				
				
				:
				
			
			}
		
	
	
	
	
		
			
			[
			
				
					, 
					
				
				
			
			]
		
	
	
	
		
			[
			
				
					,
				
				
			
			]
		
	
	
	
	
		
	
	
	
	
		
	
	
	
	
		
	
	
	
	
		
	
	
	
	
		null
	
	
	
	
		
	
	
	
	
		
	
	
	
	
		
		
			
				
			
			
				>Inc
			
		
	
	
	
	
	
	
	
		
		
			
				
					
						
						
					
					\"
					\\
					\b
					\t
					\n
					\f
					\r
					
						
					
					
						
					
				
			
		
	
	
	
	
		
		
		
			
			
			
			
		
	
	
	
	
	
		
		
	
	

When I use the CSV package sample from the XSLT 3.0 spec with a similar command line then Saxon does not give any error and executes the code fine so somehow the more complex package causes the NullPointerException.

Just an observation that I think the problem is specific to the way multiple packages are loaded when running from the command line. The test works when the packages are loaded one by one using the s9api API.

The problem with the command line mechanism is working out the dependencies between multiple packages. We can't reasonably ask users to list them in a particular order, so we need to handle reading a package before we've loaded all the packages that it depends on.