In the XX compiler, static.xsl line 128, we process all the children of an xsl:stylesheet element using xsl:iterate; in particular it handles the xsl:import/include children at line 532, failing if there is an invalid attribute at line 549.
I'm now trying to debug the compiler by running it directly as a transformation, with the new -T option for tracing. For reference the invocation is:
~/GitHub/saxon-js-enterprise/build/temp/js/build/xslt3ee.js
-xsl:/Users/mike/GitHub/saxon-js-enterprise/build/temp/js/source/XX/compiler.sef
-s:/Users/mike/GitHub/xslt30-test/tests/attr/shadow/shadow-004.xsl
-o:/Users/mike/Desktop/temp/shadow-004.sef.json
-im:compile-complete
-debug
-T
-t
(Note in passing that the <applyT>
instructions are all logged twice; perhaps more important, (a) the mode name isn't present in the trace, and (b) we don't explicitly identify the template rule that gets called.)
This shows we are executing the apply-templates in XSLT-SEF-compiler line 406, on the xsl:transform
element, and this invokes the template rule at static.xsl#128, which processes all the children of the xsl:transform
in an xsl:iterate
.
At line static.xsl#263 we process the xsl:include element and put the processed xsl:include element in variable $possible.component
. This invokes the template rule at static.xsl#920, which at line 944 processes the _href shadow attribute. The template at #920 should return a copy of the xsl:include element with the @href attribute expanded.
We then reach the xsl:when condition at line 532 (though the trace isn't very helpful at revealing this), and the error comes at line 544.
It's now clear what's wrong: the check for bad attributes is looking at ./@*
rather than $possible.component/@*
.