Return-Path: 
 <commons-dev-return-795-apmail-xml-commons-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-commons-dev-archive@www.apache.org
Received: (qmail 60910 invoked from network); 17 Apr 2008 04:49:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Apr 2008 04:49:47 -0000
Received: (qmail 16914 invoked by uid 500); 17 Apr 2008 04:49:48 -0000
Delivered-To: apmail-xml-commons-dev-archive@xml.apache.org
Received: (qmail 16901 invoked by uid 500); 17 Apr 2008 04:49:48 -0000
Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:commons-dev-help@xml.apache.org>
list-unsubscribe: <mailto:commons-dev-unsubscribe@xml.apache.org>
List-Post: <mailto:commons-dev@xml.apache.org>
List-Id: <commons-dev.xml.apache.org>
Delivered-To: mailing list commons-dev@xml.apache.org
Received: (qmail 16890 invoked by uid 99); 17 Apr 2008 04:49:48 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2008 21:49:48 -0700
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of mrglavas@ca.ibm.com designates
 32.97.182.143 as permitted sender)
Received: from [32.97.182.143] (HELO e3.ny.us.ibm.com) (32.97.182.143)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2008 04:48:55 +0000
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3H4nAjj011355
	for <commons-dev@xml.apache.org>; Thu, 17 Apr 2008 00:49:10 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id
 m3H4nA2W329216
	for <commons-dev@xml.apache.org>; Thu, 17 Apr 2008 00:49:10 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3H4nA6a008751
	for <commons-dev@xml.apache.org>; Thu, 17 Apr 2008 00:49:10 -0400
Received: from d25ml03.torolab.ibm.com (d25ml03.torolab.ibm.com [9.26.6.104])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
 m3H4n9iZ008744;
	Thu, 17 Apr 2008 00:49:10 -0400
In-Reply-To: <deede5630804141600h469f6d01ge6f48e8f61a93930@mail.gmail.com>
Subject: Re: Suggested patches for resolver: Windows driver-letter paths and
 resolveSystem() and <uri>
To: commons-dev@xml.apache.org
Cc: "Earl Hood" <earl@earlhood.com>, earlhood@gmail.com
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: 
 <OF791C5BCA.F34D0103-ON8525742E.00165741-8525742E.001A787B@ca.ibm.com>
From: Michael Glavassevich <mrglavas@ca.ibm.com>
Date: Thu, 17 Apr 2008 00:49:24 -0400
X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.2HF446 |
 March 16, 2007) at
 04/17/2008 00:49:26
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Virus-Checked: Checked by ClamAV on apache.org

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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

earlhood@gmail.com 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