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

[Daniel Leidert]

Am Donnerstag, den 22.10.2009, 17:40 +0000 schrieb brian m. carlson:

> libxml-commons-resolver1.1-java is unable to look up some catalog
> entries on a Debian system.  With docbook-xsl-ns and docbook5-xml,
> xmlcatalog (part of libxml2) responds as follows:
> 
>   lakeview ok % (unset XML_CATALOG_FILES; xmlcatalog --shell)
>   > system http://docbook.sourceforge.net/release/xsl-ns/current/xhtml/docbook.xsl
>   file:///usr/share/xml/docbook/stylesheet/docbook-xsl-ns/xhtml/docbook.xsl
>   > system http://docbook.org/xml/5.0/rng/docbook.rng
>   file:///usr/share/xml/docbook/schema/rng/5.0/docbook.rng
>   > %
> 
> This is correct.  Using this package:
> 
>   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 raised verbosity (BTW: shouldn't `-d xx' overwrite the verbosity value
from CatalogManager.properties? This looks like a bug to me.) and found
the following:

Using the plain /etc/xml/catalog catalog results in

> [..]
> DELEGATE_PUBLIC: -//OASIS//DTD DocBook CALS Table Model
> 	file:/etc/xml/docbook-xml.xml
> Resolve SYSTEM (systemid):
>   system id: http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
> resolveSystem(http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl)
> Result: null

Note, that it did not find a catalog for the requested system ID! Now
commenting out the related delegateURI entry in /etc/xml/catalog and
trying the command again, results in:

> [..]
> DELEGATE_PUBLIC: -//OASIS//DTD DocBook CALS Table Model
> 	file:/etc/xml/docbook-xml.xml
> Resolve SYSTEM (systemid):
>   system id: http://docbook.sourceforge.net/release/xsl-ns/current/html/docbook.xsl
> resolveSystem(http://docbook.sourceforge.net/release/xsl-ns/current/html/docbook.xsl)
> Switching to delegated catalog(s):
> 	file:/etc/xml/docbook-xsl-ns.xml
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Parse catalog: file:/etc/xml/docbook-xsl-ns.xml
> Loading catalog: file:/etc/xml/docbook-xsl-ns.xml
> Default BASE: file:/etc/xml/docbook-xsl-ns.xml
> delegateURI: http://docbook.sourceforge.net/release/xsl-ns/
> 	file:///usr/share/xml/docbook/stylesheet/docbook-xsl-ns/catalog.xml
> DELEGATE_URI: http://docbook.sourceforge.net/release/xsl-ns/
> 	file:/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/catalog.xml
> delegateSystem: http://docbook.sourceforge.net/release/xsl-ns/
> 	file:///usr/share/xml/docbook/stylesheet/docbook-xsl-ns/catalog.xml
> DELEGATE_SYSTEM: http://docbook.sourceforge.net/release/xsl-ns/
> 	file:/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/catalog.xml
> resolveSystem(http://docbook.sourceforge.net/release/xsl-ns/current/html/docbook.xsl)
> Result: null

This time it found the correct catalog to delegate the request, but
still missed to rewrite the system ID. Now commenting out the
delegateURI entry in /etc/xml/docbook-xsl-ns.xml, the correct location
is finally found:

[..]
> resolveSystem(http://docbook.sourceforge.net/release/xsl-ns/current/html/docbook.xsl)
> Result: file:/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/html/docbook.xsl

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.

Regards, Daniel