document(), static base URI, and JAR files

Added by Anonymous over 17 years ago

Legacy ID: #3961278 Legacy Poster: Henryk Hecht (henrykhecht)

Before I describe the problem, allow me to explain what I'm doing by way of exposition. I've a stylesheet that acts upon some data in concert with some supplementary data obtained through document(RELATIVE_URL). Nothing exceptional in that, and of course it works well until the stylesheet and the supplementary data are packaged in a .jar, whereupon things fall apart and I end up with: FODC0005: java.io.FileNotFoundException: /path/containing/jar/RELATIVE_URL I am not confident, but I believe this to be a bug. According to the standard: ...If it is a relative URI reference, then it is resolved against the base URI of $base-node if supplied, or against the base URI from the static context otherwise (this will usually be the base URI of the stylesheet module) Now, when run within the .jar, static-base-uri() returns: jar:file:/path/containing/jar/jar.jar!/path/to/stylesheet/xsl.xsl It may or may not be relevant that base-uri(document('')) returns the expected value outside the jar, but the empty sequence within it. So, two questions: First, is Saxon failing to resolve RELATIVE_URL against the base URI per the standard, or am I misunderstanding (in a rather hopeful way!) what "resolve" or "against the base URI from the static context" means? I fully admit to not having read up on, for instance, how the base URI is transformed before having the relative URI appended, which is probably relevant. Second, as this must be a rather common scenario, what is the recommended procedure? I'm somewhat hesitant to write document(jar:file:RELATIVE_JAR_URL!RESOURCE_URL) as it makes development (when things aren't jar'd) somewhat awkward. Does one somehow set the base URI to something different at runtime (how? and to what?)? Is a special URIResolver required? Indirection through document(extension-function(RELATIVE_URL)? -- HH

Replies (2)

RE: document(), static base URI, and JAR file - Added by Anonymous over 17 years ago

Legacy ID: #3961372 Legacy Poster: Michael Kay (mhkay)

According to RFC 2396 we have: absoluteURI = scheme ":" ( hier_part | opaque_part ) hier_part = ( net_path | abs_path ) [ "?" query ] net_path = "//" authority [ abs_path ] abs_path = "/" path_segments So a hierarchic URI always has a "/" after the colon. Thus jar:file:/path/containing/jar/jar.jar!/path/to/stylesheet/xsl.xsl is an absolute URI, but it contains an opaque scheme-specific part rather than a hierarchic schema-specific part and therefore cannot be used as input to the URI resolution algorithm. Java implements this literally: isAbsolute() and isOpaque() both return true. Being opaque rather than hierarchic, the URI cannot be used as the base URI to resolve a relative URI. This is inconvenient, of course, but I don't think it's a bug. You could potentially use the URIResolver as a workaround, though it's tricky because although the URIResolver is responsible for dereferencing the URI and is given the base URI and relative URI separately, the system also has to absolutize the URI to enforce constraints on document stability and this is done independently of the URIResolver. It might be that the best workaround is to modify the base URI to use a non-standard scheme: replace "jar:file:" by "jarfile:". When you do this, the resolution of the URI works OK, and you could convert it back to "jar:file:" in your URIResolver to allow it to be dereferenced. Horrible, I know.

RE: document(), static base URI, and JAR file - Added by Anonymous over 17 years ago

Legacy ID: #3962487 Legacy Poster: Henryk Hecht (henrykhecht)

Sorry to make you explain the RFC, I can only say that my appetite for specs had been fully sated by two hours of poring over xmlns and URI material in chasing down a serious namespace bug in xerces. Two further questions, if I may: As I would like the stylesheets to function outside of the jar as well as in, it appears I need something like: <xsl:variable name="fakeBaseURI" select="replace(static-base-uri(), '^jar:', 'jar')/> (which obviously does nothing when the base URI isn't a jar) and then: document(resolve-uri($relativeURI, $fakeBaseURI)) wherever I had previously used document($relativeURI), is this correct? I'd really rather not have to write a robust URIResolver, so it seems reasonable to subclass some other implementation and just handle the jarfile: URI scheme. Is Saxon's URIResolver suitable for this? Even so, I suppose I have to resolve the relative URI against the post-! segment of the jarfile URI myself, which is not too bad but still seems unnecessary as the post-! segment can implicitly define an hierarchal scheme. Though it is clearly (now) no fault of Saxon's, and indeed it probably could not behave otherwise, I can't help but feel this is significantly more difficult than it ought to be. But then, I still feel that way about the lack of a proper inclusion facility in xslt, so perhaps I am just being picky. -- HH

(1-2/2)

Please register to reply

Project

Profile

Help

Saxon