Bug#552018: libxml-commons-resolver1.1-java: fails to find entries in some catalogs

[Daniel Leidert]

Am Freitag, den 23.10.2009, 20:59 +0000 schrieb brian m. carlson:
> On Fri, Oct 23, 2009 at 10:27:37AM +0200, Daniel Leidert wrote:
> > Am Donnerstag, den 22.10.2009, 17:40 +0000 schrieb brian m. carlson:
> > >   lakeview ok % java
> > > -cp /usr/share/java/xml-commons-resolver-1.1.jar:/etc/xml/resolver
> > > org.apache.xml.resolver.apps.resolver -s
> > > http://docbook.sourceforge.net/release/xsl-ns/current/xhtml/docbook.xsl system
> > 
> > This happens for both docbook-xsl and docbook-xsl-ns. In both cases,
> > using the above command, but with "... -u ...URI... uri" works.
> 
> I can't reproduce this difference in behavior.  I get the same problems
> whether I use "-u ... uri" or "-s ... system".

I think I know why: If you carefully check your log, the result
parsing /etc/xml/catalog for the system id is:

- delegateSystem is found before delegateURI
-> switching to the correct catalog
- delegateURI is parsed before delgateSystem in the catalog
-> Result: nothing found to resolve system id

For the URI it is:

- delegateSystem is found before delegateURI
-> Result: nothing found to resolve uri

Pleaes check this in verbose mode! Am I right?

At my system, the situation is a bit different parsing /etc/xml/catalog:

- delegateURI is found before delegateSystem
-> Result: nothing found to resolve system id

Trying to get the URL:

- delegateURI is found before delegateSystem
-> switching to catalog /etc/xml/docbook-ns-xsl.xml
- delegateURI is found before delegateSystem
-> switching to catalog /usr/share/xml/docbook/stylesheet/docbook-xsl-ns/catalog.xml
-> Resolving URI

Switching the entry occurrences of delegateURI and delegateSystem
in /etc/xml/catalog results in the same behaviour as on your system. We
have different orderings in /etc/xml/catalog but the same in


> Practically, the
> important part is whether the URI entries work, since docbook-xsl*
> contains stylesheets, which are going to be looked up by URI, not by
> system identifier.

Correct, but order matters here. Make sure, the delegateURI entries are
found before delegateSystem entries. Then the URI resolving should work.

[..]
> > The problem seems to be, that for the URI two entries exist: delegateURI
> > and delegateSystem. However, using `-u ... uri' and `-s ... system' are
> > explicit enough to not get confused by the same URL being registered as
> > an URL and System ID entry in the catalog. This looks like a bug in the
> > commons resolver to me, but I don't have the catalog spec in mind atm.
> 
> I've just read the spec, and I can't find any part that explains why
> this shouldn't work.

Then this is clearly a bug.

Regards, Daniel