Return-Path: Delivered-To: apmail-xml-commons-dev-archive@www.apache.org Received: (qmail 25676 invoked from network); 29 Oct 2009 21:11:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Oct 2009 21:11:17 -0000 Received: (qmail 14055 invoked by uid 500); 29 Oct 2009 21:11:17 -0000 Delivered-To: apmail-xml-commons-dev-archive@xml.apache.org Received: (qmail 13975 invoked by uid 500); 29 Oct 2009 21:11:17 -0000 Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list commons-dev@xml.apache.org Received: (qmail 13967 invoked by uid 99); 29 Oct 2009 21:11:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 21:11:17 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=10.0 tests=HTML_MESSAGE,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.141 as permitted sender) Received: from [32.97.182.141] (HELO e1.ny.us.ibm.com) (32.97.182.141) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 21:11:05 +0000 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9TL95Jm013481 for ; Thu, 29 Oct 2009 17:09:05 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9TLAgnX1470684 for ; Thu, 29 Oct 2009 17:10:42 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9TLAfmS030491 for ; Thu, 29 Oct 2009 17:10:42 -0400 Received: from d25ml03.torolab.ibm.com (d25ml03.torolab.ibm.com [9.26.6.104]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9TLAfnj030482; Thu, 29 Oct 2009 17:10:41 -0400 In-Reply-To: <1256773703.3663.43.camel@tad> Subject: Re: resolver should be able to parse catalog files without needing to resolve external entities? To: Jack Bates Cc: commons-dev@xml.apache.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Glavassevich Date: Thu, 29 Oct 2009 17:10:39 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/29/2009 17:10:40 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCCDDFE05CC78f9e8a93df938690918c0ABBFCCDDFE05CC7" Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org --0__=0ABBFCCDDFE05CC78f9e8a93df938690918c0ABBFCCDDFE05CC7 Content-type: text/plain; charset=US-ASCII Jack, Jack Bates wrote on 10/28/2009 07:48:23 PM: > On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote: > > The OASIS catalog DTD is included in resolver.jar and there is a > > BootstrapResolver [1] which gets installed on the parser that reads > > the catalog which can return this DTD. I'm sure the reason that isn't > > happening is that the public and system IDs differ from the ones that > > the resolver knows about. You're supposed to extend BootstrapResolver > > (in your own application) if you need support for more than the > > well-known public IDs and URIs for the catalog DTDs / schemas and set > > an instance of this extension on the CatalogManager [2]. > > Thank you Michael! After some more digging, I think the reason that the > w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public > ID and URI, > > "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> > > is that it's trying to use a different DTD? > > Based Extension V1.0//EN" > "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd"> > > The xml-core package distributes "tr9401.dtd", in addition to > "catalog.dtd" - here it is, > http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd > > - and here are the differences between it, and the "catalog.dtd" > included in resolver.jar, > http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff > > I dunno if the w3c-dtd-xhtml catalog.xml actually requires this > different DTD, but it sounds like if it does, and the system ID isn't > accessible, then it will only be parsable by tools which extend > BootstrapResolver to add support for this different DTD? That's what I would do. I could imagine extending BootstrapResolver so that it uses a secondary catalog resolver so that you just update a catalog file instead of the code when you need a redirect for yet another catalog DTD. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org --0__=0ABBFCCDDFE05CC78f9e8a93df938690918c0ABBFCCDDFE05CC7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Jack,

Jack Bates <ms419@freezone.co.uk> wrote on 10/28/2009 07:48:23 PM:

> On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote:
> > The OASIS catalog DTD is included in resolver.jar and there is a
> > BootstrapResolver [1] which gets installed on the parser that reads
> > the catalog which can return this DTD. I'm sure the reason that isn't
> > happening is that the public and system IDs differ from the ones that
> > the resolver knows about. You're supposed to extend BootstrapResolver
> > (in your own application) if you need support for more than the
> > well-known public IDs and URIs for the catalog DTDs / schemas and set
> > an instance of this extension on the CatalogManager [2].
>
> Thank you Michael! After some more digging, I think the reason that the
> w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public
> ID and URI,
>
> <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
>   "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
>
> is that it's trying to use a different DTD?
>
> <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-
> Based Extension V1.0//EN"
>     "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd">
>
> The xml-core package distributes "tr9401.dtd", in addition to
> "catalog.dtd" - here it is,
> http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd
>
> - and here are the differences between it, and the "catalog.dtd"
> included in resolver.jar,
> http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff
>
> I dunno if the w3c-dtd-xhtml catalog.xml actually requires this
> different DTD, but it sounds like if it does, and the system ID isn't
> accessible, then it will only be parsable by tools which extend
> BootstrapResolver to add support for this different DTD?

That's what I would do. I could imagine extending BootstrapResolver so that it uses a secondary catalog resolver so that you just update a catalog file instead of the code when you need a redirect for yet another catalog DTD.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
 --0__=0ABBFCCDDFE05CC78f9e8a93df938690918c0ABBFCCDDFE05CC7--