Support #4685

xsl:include href attribute expected behavior / bug?

Added by John Smail about 1 month ago. Updated 12 days ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


I've used the following syntax successfully with Saxon-EE 9.7 and XSLT 3.0, and only then found out it was not supposed to work...

<xsl:param name="globalParameterName" as="xs:string"/>
<xsl:include href="{$globalParameterName}"/>

It seems that according to the schema for XSLT, the xsl:include element's href attribute should be of type xs:anyURI. It doesn't really say anything about support for an attribute value template (xsl:avt). However, the runtime evaluation of the globalParameterName (which happens to be a file:/ URL, but typed as xs:string) is successfully resolving and including the intended stylesheet.

Also, a question was raised previously on that reinforces that behavior should not be supported, and the stylesheet not modified at runtime.

Is this now expected behavior and supported, or is this a bug?


#1 Updated by Michael Kay about 1 month ago

This certainly shouldn't work and a quick test shows that it doesn't: I get

Saxon-EE from Saxonica
Java version 1.8.0_121
Using license serial number V008779
URIResolver.resolve href="{$globalParameterName}" base="file:/Users/mike/Desktop/temp/test.xsl"
Error on line 5 column 47 of test.xsl:
  Invalid relative URI {{$globalParameterName}}: Illegal character in path at index 0:
Invalid relative URI {{$globalParameterName}}

So there's something going on here behind the scenes that we don't know about...

#2 Updated by Michael Kay about 1 month ago

What should work here in 3.0 is a static parameter:

<xsl:param name="globalParameterName" static="yes" as="xs:string"/>
<xsl:include _href="{$globalParameterName}"/>

#3 Updated by John Smail about 1 month ago

Hi Michael. Thanks for the quick follow-up and confirmation.

There's a minor difference in version number. We're on version and I see your test was on .21. Not sure if maybe this is an issue in .12 that was fixed in .21?

I did have a solution that was based on static parameters, but due to considerations in my environment/platform outside of Saxon, that had some implications that I wanted to avoid. ...which is what led me to trying the above.

The upshot here for me is the confirmation that this behavior (however it's manifesting) is not expected behavior and not something I should code to. If this isn't a confirmed bug for, I'll let you know if I come across an explanation for what I'm seeing just to close the loop.

#4 Updated by Michael Kay about 1 month ago

It seems very unlikely that this was a bug fixed between and There was over a year between these releases, so a lot could have happened, and it's a long time ago (2017) so I wouldn't necessarily remember; it just doesn't seem a very likely bug. I'm not going to install the .12 release from archive just to find out - sorry!

#5 Updated by Michael Kay about 1 month ago

I would mention also that 9.7 was released before the XSLT 3.0 specification was completely finished, and although they're likely to be minor, there may be changes in subsequent versions that bring the product into line with the spec. The current release is 10.1.

#6 Updated by John Smail about 1 month ago

Understood, and agree it's not worth the effort of backing up to .12 to confirm. I have what I need to know to make the necessary decision in this particular solution.

That's good information re: 9/7 vs. the spec completion. Thank you!

#7 Updated by Michael Kay 12 days ago

  • Status changed from New to Closed

Please register to edit this issue

Also available in: Atom PDF