Hi,
This is all speculation, but FWIW:
In my experience the current version of Xerces is very
consistent about rejecting 'malformed' URIs pretty much everywhere and
anywhere.
If you look, I would guess that it's your environment that is
not consistent: you're not getting the version of Xerces you think
you're getting, at least not for all parts of Xerces. I would guess that
the classes in resolver.jar are being found elsewhere in the classpath
and so come from a previous version of Xerces. I don't recall when
Xerces started to be more strict about URIs but it was within the last
major revision or so.
Also Xalan, I presume that's the XSLT engine you're using, is
now a part of the Java standard and may be messing you up as well. You
have to override the version in the JRE using the 'endorsed' if you
don't want the crusty old version they included with your JRE. There's a
Xalan FAQ about this.
I agree the error message could be nicer :)
Chris
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 28, 2004 11:27
To: [EMAIL PROTECTED]
Subject: Re: resolver.jar does not handle Windows file names
I know this now, and I have corrected my build to use the correct URI
format.
Unfortunately, the situation is that transformation works if
resolver.jar
is not on the classpath. I have an ANT build script that contains an
<xslt> task to transform an xml document. The stylesheet contains a
variable declaration that loads a document:
<xsl:variable name='sunxml' select='document($sundd)' />
The value of $sundd was an absolute windows filename "c:/bla.bla.xml"
The <xslt> task ran perfectly fine. I added an <xmlvalidate> task to
the
build, and added resolver.jar to the classpath so I could use schema
files
on the local file system. This broke the <xslt> task because of the
malformed URI.
So now we have a conflict. I have a transformation that works perfectly
fine without resolver.jar, but fails if I add resolver.jar. This to me
is
a problem. If nothing else, the error message that was generated should
have indicated that the URI was malformed. I only got that error
message
when I ran ANT witn -verbose so I could get the stack trace.
Software needs to be consistent. If the transformer had rejected the
filename, then I never would have expected resolver to handle it.
However,
transformation does handle it, and then it breaks when you add
resolver.jar to the classpath, so I view this as a bug.
Perhaps the problem is that the xsl processor should have detected the
absolute file name in document($sundd) and fixed it before it handed it
off to the resolver.
In my case, I was able to fix the problem by stuffing the "/" in front
of
the path. It would be a lot more user friendly if resolver or the xslt
processor did that for me.
Michael Giroux
Joseph Kesselman <[EMAIL PROTECTED]>
05/28/2004 10:41 AM
Please respond to xerces-j-user
To: [EMAIL PROTECTED]
cc:
Subject: Re: resolver.jar does not handle Windows file
names
The resolver is expecting a URI, and a Windows file name is not a URI.
Use <xsl:variable name='doc' value='document("file:///c:/..... ")/>
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
