Saxon

The base URI is going to depend on what your ResourceResolver returns. If it returns a Source object with no known SystemId (for example, a StreamSource) then the base URI of the stylesheet module will be unknown, and the xml:base attribute therefore has nothing to resolve against.

Ok, thank you Mike.

I'm gonna dive into my ResourceResolver and see what happens.

I suppose the resolve(ResourceRequest) should be call with uri=resolve-uri first param, and baseUri=xml:base value ?

Thanks again, Christophe

Ok, I've dived into ResourceResolver, and what's call.

I've log all calls to ResourceResolver.resolve, and they are all correctly resolved.

The instruction the throws the exception is this one :

<xsl:variable as="map(xs:string, item())" name="x:schematron-preprocessor" select="
			(
			map {
				'name': 'skeleton',
				'stylesheets': [
					resolve-uri('iso-schematron/iso_dsdl_include.xsl'),
					resolve-uri('iso-schematron/iso_abstract_expand.xsl'),
					resolve-uri('iso-schematron/iso_svrl_for_xslt2.xsl')
				]
			},
			map {
				'name': 'schxslt',
				'stylesheets': [
					resolve-uri('schxslt/2.0/include.xsl'),
					resolve-uri('schxslt/2.0/expand.xsl'),
					resolve-uri('schxslt/2.0/compile-for-svrl.xsl')
				]
			}
			)[doc-available(?stylesheets?1)]" static="yes" xml:base="../../lib/" />

I wasn't able to log the resolve call involved by the xml:base

Error message indicates that this is a static error. But err:FORG002 seems to be a dynamic error. The variable definition is a global variable.

I'm not sure in which ResourceResolver I have to look in to resolve my problem.

If it is a static error, I should look in xslCompiler.getResourceResolver.

I can provide the ResourceResolver logs, if needed.

Thanks in advance, Christophe

When all resources are unzipped, and contained in a simple directory, compilation succeeds. When I compile from a zip file, I have this error.

Can you try patching in version 6.0.11 of the XML Resolver, https://github.com/xmlresolver/xmlresolver/releases/tag/6.0.11

I wonder if this issue is the cause: https://github.com/xmlresolver/xmlresolver/issues/211

I've tried, without success. I've pushed the test case to https://github.com/cmarchand/saxon-support_6578

I'm gonna try to play with XsmlReader...

I've been able to reproduce the error with your test repository (thank you!).

I'm not sure what can be done, though. The resolver actually has no trouble resolving all the relative URIs from the stylesheets. But when we get to this:

<xsl:variable name="x:schematron-preprocessor" select="..." static="yes"
              xml:base="../../lib/" />

The XSLT processor needs to have an absolute URI to resolve the relative URis against.

I assume it tries to make ../../lib/ absolute based on the static base URI of the stylesheet module (I haven't tried to trace through the Saxon code at this point). Unfortunately, that base URI is jar:file:/path/xspec.jar!/io/xspec/xspec/impl/src/schematron/schut-to-xslt.xsl.

The Java URI class doesn't understand jar: URIs as relative URIs so:

URI.create("jar:file:/path/xspec.jar!/io/xspec/xspec/impl/src/schematron/schut-to-xslt.xsl")
   .resolve("../../lib/")

is ... ../../lib/ which isn't absolute.

So the expression fails.

Here's a solution that does appear to work:

        <xsl:variable name="sbu" select="resolve-uri('../../lib/', static-base-uri())"
                      static="yes"/>
	<xsl:variable as="map(xs:string, item())" name="x:schematron-preprocessor" select="
			(
			map {
				'name': 'skeleton',
				'stylesheets': [
					resolve-uri('iso-schematron/iso_dsdl_include.xsl', $sbu),
					resolve-uri('iso-schematron/iso_abstract_expand.xsl', $sbu),
					resolve-uri('iso-schematron/iso_svrl_for_xslt2.xsl', $sbu)
				]
			},
			map {
				'name': 'schxslt',
				'stylesheets': [
					resolve-uri('schxslt/2.0/include.xsl', $sbu),
					resolve-uri('schxslt/2.0/expand.xsl', $sbu),
					resolve-uri('schxslt/2.0/compile-for-svrl.xsl', $sbu)
				]
			}
			)[doc-available(?stylesheets?1)]" static="yes"/>

Saxon is smart enough to do the right thing resolving against the jar: URI, and the resolver is then capable of getting the resolved resources from the jar file.

On further reflection, it's absolutely clear to me why ../../lib/ isn't being resolved against the static base URI. I mean, what I said about the Java URI class is true, but it appears that Saxon does more than that for the latter case. And why does this succeed:

<xsl:variable name="absuri" static="yes"
              select="resolve-uri('test')"
              xml:base="../"/>

in a simple test stylesheet?

Thanks a lot, Norm. I'm gonna push a PR on XSpec impl with your solution, and see if everything still works correctly.

Christophe

Norm Tovey-Walsh wrote in #note-10:

On further reflection, it's absolutely clear to me why ../../lib/ isn't being resolved against the static base URI.....

I agree with you, you are right. But the reason why it is clear to you isn't clear to me.

Would you have some pointers to specs, javadocs, which could help me to feel that absolutely clear as you ?

Christophe

Complete typo on my part. I left out the word not.

On further reflection, it's absolutely not clear to me why ../../lib/ isn't being resolved against the static base URI. I mean, what I said about the Java URI class is true, but it appears that Saxon does more than that for the latter case.