Forums » Help »
XQJ ModuleURIResolver Behavior
Added by Anonymous almost 16 years ago
Legacy ID: #6353474
Legacy Poster: Monte Hansen (montehansen)
I am using saxonb9-1-0-5 xqj to process an xquery template that imports another. I
have implemented URIResolver and ModuleURIResolver. The import looks like so: >
import module namespace myns="urn:someurn" at
"format-number.xq"; ModuleURIResolver.resolve() fires as expected.
However, the locations[] field has pre-resolved the import to
<env.getBaseURI()>/<moduleImportSpec>, which in my case is
effectively <working-directory>/format-number.xq. Worse is when I prefix
the module name with "/" (or "/somedir/"), the
locations[] field is left as a literal, but without the leading "/",
it attempts to resolve the path using concatenation
<env.getBaseURI()>/<baseURI>/format-number.xq, and the
baseURI field is always empty. I think it's customary to specify modules located in the
same folder without a leading path separator (meant to be relative to the resolver’s
baseURI). Arguably, this behavior might be appropriate if the implementation hadn't
registered its own resolver, but when it has, the location[] values have now been
corrupted since the resolver has no way of knowing whether the template intended the
path part, or if it's Saxon. This forces the resolver to make dangerous assumptions it
shouldn't have to. When I look at the source of the QueryParser.applyModuleImport
method, it appears you might have intended for the platform.makeAbsolute call to be
applied on modules already loaded, not sure. In either event, it would seem to be a bug
or erroneous logic. Might I suggest a change such that the job of resolving uri is left
to the registered URIResolver. Thanks for your consideration. Monte
Legacy ID: #6355457
Legacy Poster: Michael Kay (mhkay)
It's working this way by design. I feel strongly that the relative URI in the module
location list should be interpreted as being relative to the static base URI of the
module in which it appears, and that the module resolver should not be able to change
this. This is a fundamental characteristic of the semantics of a relative URI. The job
of the ModuleURIResolver is to dereference the resulting absolute URI, not to perform
the initial absolutization. JAXP in its URIResolver design got this wrong, and it causes
a lot of problems because it means there is no way of knowing wither two URIs are
equivalent. I didn't want to repeat that mistake. The XmlResolver in .NET is a better
model. If you're having problems with this, perhaps it's because you aren't setting the
static base URI of the original module correctly? If you don't want the location to be
treated as a relative URI, then you can always specify an absolute URI. If you really
want to ignore what the specs have to say about the semantics of URIs entirely, you can
always invent your own private URI scheme, and then you can do anything you like.
Please register to reply
.