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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
