Saxon

While I found this in my first attempt to execute EE and it was with this stylesheet and real data, I see that I can reproduce the problem when executing the stylesheet with bogus input:

~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9he/saxon9he.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
<?xml version="1.0" encoding="UTF-8"?>~/s/companies/bpc $ 
~/s/companies/bpc $ java -jar ~/p/xml/xslt/saxon9ee/saxon9ee.jar -s:skeletonCommenter.xsl -xsl:skeletonCommenter.xsl
java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
	at net.sf.saxon.style.XSLKey.compileDeclaration(XSLKey.java:301)
	at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1235)
	at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:326)
	at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:222)
	at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:107)
	at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:785)
	at net.sf.saxon.Transform.doTransform(Transform.java:741)
	at net.sf.saxon.Transform.main(Transform.java:80)
Fatal error during transformation: java.lang.ClassCastException: net.sf.saxon.pattern.NodeKindTest cannot be cast to net.sf.saxon.type.BuiltInAtomicType
~/s/companies/bpc $ 

As a side note, oXygenXML reports a syntax error on line 64:

         match="Row[not(c:col(.,'ComponentType')='ABIE')]
                   [not(c:col(.,'BPCML')=('','0'))]"

... but there is nothing wrong that I can see with that expression and I get no static error when running HE as seen above. I'll report this to the oXygen folks.

I hope this is helpful.

. . . . . Ken

p.s. the stylesheet is not near complete and is the midst of being transformed from one approach to a different approach and so there is a mix of text and XML comments ... please don't judge the quality of the stylesheet writing from the incomplete work that you see. If I get a better version done before bed time then I'll post it.

I wanted to post the incomplete stylesheet in case the completed stylesheet does not trigger the exception.

I think the problem is that the c:col function has been inlined before it has been type-checked. The type-checking is responsible for adding the atomization (defined by the return type xs:string of the function) and once inlining has happened, the required type is lost.

Normally we take care to type-check everything before we optimize anything. But it seems that keys are being optmized before functions have been type-checked.

The order of events is controlled in PrincipalStylesheetModule.compile(). There are explicit comments there about the need to type-check functions before inlining them, but the policy has not been followed in the case of key definitions.