Jack Bates <firstname.lastname@example.org> 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  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 .
> 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"
> is that it's trying to use a different DTD?
> <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-
> Based Extension V1.0//EN"
> The xml-core package distributes "tr9401.dtd", in addition to
> "catalog.dtd" - here it is,
> - and here are the differences between it, and the "catalog.dtd"
> included in resolver.jar,
> 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.
XML Parser Development
IBM Toronto Lab