On 04 Feb 2011, at 17:40, Glenn Adams wrote:

<snip />
> so if one specifies
> file:///../fop.xml

If I understand correctly, while it does not violate the URI syntax, this would 
not be considered a relative URI either way.
That is, java.net.URI will consider it absolute, because it has a scheme 
component (file://).

A URI is relative only if the scheme component is absent. An absolute file path 
starting at the root is still a relative URI if it is not preceded by 
'file://'. It can be resolved against an absolute file: URI, but for other 
purposes also against an ftp:, http:... 

> if you are discussing the use of the Java URI class, this is another matter, 
> but just keep in mind that external specifications of the file URL should 
> never have a relative path for <path>, and all external specifications of the 
> form file:///foo.bar refers to the file foo.bar in the root directory (and 
> not in relationship to some implied xml:base);

Very true, and that is exactly how java.net.URI.resolve() operates. If you call 
it on a URI created for the string "file:///foo.bar", you will simply get the 
same absolute URI back, no matter which URI you resolve against (xml:base, 
user-config base...).

That said, I believe the issue raised by Jeremias concerns the implicit 
resolution of relative paths  against the current working directory (due to: 
new File(relativePath)), instead of a possible absolute file URL (font-base?).



Reply via email to