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?). Regards, Andreas ---
