Support #6578
openFORG0002 not understood !
0%
Description
Hello !
I'm a little bit rusty on Xslt, and I need some help !
I'm trying to compile Xslt from XSpec, and my problem comes on compiling schxslt implementation.
All source code is at https://github.com/xspec/xspec/tree/v3.1.2 and packaged into a jar file : https://repo1.maven.org/maven2/io/xspec/xspec/3.1.2/xspec-3.1.2.jar
I have a ResourceResolver
that is able to resolve URIs inside jar files, and this ResourceResolver
is set on the xsltCompiler
.
I compile my Xslt with :
xsltCompiler.compile(source);
where source' systemId
is jar:file:/Users/cmarchand/.m2/repository/io/xspec/xspec/3.1.2/xspec-3.1.2.jar!/io/xspec/xspec/impl/src/schematron/schut-to-xslt.xsl
schut-to-xslt.xsl
includes preprocessor.xsl
which calls resolve-uri
with a relative base-uri
: https://github.com/xspec/xspec/blob/9612f076a8923fc34389314a65b5da422b614d70/src/schematron/preprocessor.xsl#L23
And I get a :
Static error in xsl:variable/@select on line 23 column 76 of preprocessor.xsl: FORG0002 Error in variable expression. Base URI {../../lib/} is not an absolute URI
I need help, because I do not understand why ! And I have no idea where my problem is !
I use Saxon HE 12.4.
Thanks in advance, Christophe
Files
Updated by Michael Kay 27 days ago
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.
Updated by Christophe Marchand 26 days ago
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
Updated by Christophe Marchand 21 days ago
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
Updated by Christophe Marchand 21 days ago
When all resources are unzipped, and contained in a simple directory, compilation succeeds. When I compile from a zip file, I have this error.
Updated by Christophe Marchand 20 days ago
- File support_6578.zip support_6578.zip added
I've written a test to reproduce. See attach file.
Run mvn test
There are two tests, that compile from unzipped jar, using XslCompiler.compile(File)
and XsltCompiler.compile(source)
, they both succeed.
There is one test that compiles from zip file, using a jar:file:/...
URI, and this one fails.
I expect the three tests to succeed.
Best regards, Christophe
Updated by Norm Tovey-Walsh 20 days ago
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
Updated by Christophe Marchand 16 days ago
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...
Updated by Norm Tovey-Walsh 14 days ago
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.
Updated by Norm Tovey-Walsh 14 days ago
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.
Updated by Norm Tovey-Walsh 13 days ago
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?
Updated by Christophe Marchand 13 days ago
Thanks a lot, Norm. I'm gonna push a PR on XSpec impl with your solution, and see if everything still works correctly.
Christophe
Updated by Christophe Marchand 13 days ago
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
Updated by Norm Tovey-Walsh 12 days ago
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.
Please register to edit this issue