Project

Profile

Help

Forums » Help »

Different Behavior for document()

Added by Anonymous about 17 years ago

Legacy ID: #4243743 Legacy Poster: W. Eliot Kimber (drmacro)

I'm not sure if this is a Saxon or an OxygenXML question, but since Saxon is issuing the messages: In my style sheet I am doing "include" processing by getting an attribute value that should be a URI (but will normally be a bare Windows filename) and then calling document() on it: <xsl:variable name="targetHref" select="@href"/> <xsl:variable name="targetDoc" select="document($targetHref)"/> As with the cast error I reported earlier, which I run this script using Oxygen8.1, it works fine for filenames like: Balance Sheet[1].f.w.xml But if I run it from a command window like so: set CLASSPATH=%NORTHSTAR_HOME%/java/lib/saxon8.jar;%NORTHSTAR_HOME%/java/lib/resolver.jar;%NORTHSTAR_HOME%/java/lib java -cp %CLASSPATH% net.sf.saxon.Transform -t -l -o %~2\output.ditamap %~1 %NORTHSTAR_HOME%\xslt\legacy_conv\legacy2dita.xsl Then I get this failure message: Running transform... Saxon 8.8J from Saxonica Java version 1.4.2_13 ... (stuff happens) ... + Resolving includes... *** base=file:/C:/projects/northstar/siberlogic_data/all-topics_master.xml *** targetHref=Balance Sheet[1].f.w.xml Error on line 14 of file:/C:/projects/northstar/xslt/legacy_conv/resolve_includes.xsl: FODC0005: Exception thrown by URIResolver: Invalid relative URI {Balance%20Sheet[1].f.w.xml}: Illegal character in path at index 15: Balance%20Sheet[1].f.w.xml ERROR: Failed to resolved reference to included document [Balance Sheet[1].f.w.xml] Processing terminated by xsl:message at line 19 in resolve_includes.xsl Now of course the value "Balance Sheet[1].f.w.xml" is not in fact a valid URI (without looking up RFC I believe the square brackets have to be escaped), but why is this working in one place (Oxygen) and not in the other? I can only assume that Saxon is depending on some other library for URI validation and/or resolution that is differently configured in Oxygen, perhaps to make it more Windows friendly. Should Saxon be failing in this case or should it silently handle Windows filenames "correctly" in this case? Thanks, Eliot


Replies (7)

Please register to reply

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4243747 Legacy Poster: W. Eliot Kimber (drmacro)

Actually, now that I re-read my message I see that I'm including resolver.jar in the classpath--that seems like a likely culprit. I will do more testing. Cheers, Eliot

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4243750 Legacy Poster: W. Eliot Kimber (drmacro)

OK, I tried taking resolver.jar out of my classpath and there was no change in behavior. Cheers, E.

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

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

I believe that Oxygen supplies its own URIResolver. Technically, according to the spec, the string passed to the document() function must either be a valid URI, or it must be a string that turns into a valid URI when you apply percent-encoding. I think this means that your supplied argument is invalid. However, Saxon delegates the validation of the URI to the URIResolver, and a user-supplied URIResolver is able to be more liberal. I think Saxon is doing the right thing by having a default URIResolver that interprets the spec strictly, although the existence of many products that are more liberal in this area tends to influence users' expectations.

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4243807 Legacy Poster: Giulio_Buccini (giulio_buccini)

Hi, I'm absolutely not expert, but I can image what Michael Kay will say: "you must use VALID uri only!". And I agree, I think Oxygen is wrong and Saxon is right. I don't know perfect solution for your problem... I can only suggest you what I prefer do in this situation: write a litle java class (with main method) that perform transformation for you. This approach have an important feature: your class can implement the "javax.xml.transform.URIResolver" interface! So you can intercept and manage by yourself all the "calls" to external URI resources, and pick your files as you want and where you want on your filesystem. I don't know if this is a perfect solution, nothing better come into my mind for now... good luck! Giulio Buccini

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4243829 Legacy Poster: W. Eliot Kimber (drmacro)

Ok, that all makes sense. I agree that it's as much a case of tools being too kind and creating unrealistic expectations. Now that I think about it more clearly, since I control the data set in this case, I can just do the escaping in my document. But for a more general-purpose system one would have to be more clever, either providing the sort of resolver Oxygen does or ensuring that URIs are correct when authored. Cheers, E.

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4243854 Legacy Poster: W. Eliot Kimber (drmacro)

Ok, I escaped the square brackets in my URIs and Saxon from the command line was happy, but Oxygen then failed to resolve the URIs, obviously not doing any unescaping. Doh! I will take this up with Oxygen support. Cheers, E.

RE: Different Behavior for document() - Added by Anonymous about 17 years ago

Legacy ID: #4245115 Legacy Poster: W. Eliot Kimber (drmacro)

I followed up with Oxygen. George says his reading of the relevant specs suggest that anyURI should allow any string that either is a URI or will be one following escaping. I haven't had time to review his argument against the specs but it seems reasonable. But in any case, since Saxon simply delegates to whatever resolver you choose, it's not really a Saxon problem but possibly an issue with the default resolver (which I assume comes from Java--I get the same failure from 1.4 and 1.5, BTW). If anybody cares, I've put together a little test case that demonstrates the failure. Cheers, Eliot

    (1-7/7)

    Please register to reply