Re: Suggested patches for resolver: Windows driver-letter paths and resolveSystem() and <uri>

Hi Earl,

The change you're suggesting to resolveSystem() would break compatibility.
It also doesn't fit with the semantics of the method though I'm sure you
knew that before you suggested it. Any user of the resolver already has the
power to call resolveURI() after resolveSystem() if they choose to or make
any other sequence of calls they want on the Catalog. Have you considered
asking the Ant developers to modify the behaviour of the <schemavalidate>
task or provide some way to tune it?

As for your Windows drive letter patch you should attach that to a Bugzilla
issue [1]. A warning though ... No one has been maintaining the codebase
these days so can't say when that would get reviewed or committed. Probably
going to take a developer with an itch to scratch to get things moving
again.

Thanks.

[1] https://issues.apache.org/bugzilla/

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]

[email protected] wrote on 04/14/2008 07:00:01 PM:

> While working with xml-commons-resolver, I discovered that the code
> does not handle pathnames that utilize window's driver letters.  The code
> appears to lose the "absoluteness" of the path, causing resolution of
> other entities/files to fail that have it for a base.
>
> Also, and probably a little more controversal, is the resolution of
> system IDs.
> I noticed that resolverSystem() does not do a resolveURI() if no system
> mapping exists.  This is a problem when using the <schemavalidate>
> task in Ant.  I'm working with catalogs that contain numerous <uri>
entries
> to remap http URLs to local file URLs.
>
> Unfortunately, Ant/Xerces fails to resolve to the local URLs because
> resolveSytem() is used (because the URLs appears in SYSTEM idenitifiers
> in the documents).
>
> The XML resolution spec is not clear if the resolver should also check
<uri>
> entries or if the XML parser should do a URI lookup if a SYSTEM lookup
> fails (it appears Saxon may actually do this since it does not have
> the problem
> that Ant/Xerces does).
>
> To address the immediate problem, I checked resolveSystem() to call
> resolveURI() if it fails to find anything, and the change is in the
> Catalog.java.patch
> attached (but the patch also includes the Windows pathname fix also).
>
> Are any of these changes worth including in the resolver code base?
>
> --ewh