> Note that i have a public identifier, so using prefer-public lets that
> be resolved.

xmllint and BaseX seem to behave differently on my system. With
xmllint and xsltproc, your examples run fine.

When running the following query…

fetch:xml('all.xml', map { 'dtd': true(), 'catfile': 'saxalog.xml' })

…with or without the xml-resolver-1.2.jar library, I get:

Stopped at .../fetch.xq, 1/10:
[fetch:open] ".../all.xml"Resource "...\nonsense.dtd (Das System kann
die angegebene Datei nicht finden)" not found.

The only difference is that the "Cannot find
CatalogManager.properties" warning appears if the Apache resolver is
in the classpath.

Your example (with the public identifier) returns the expected result
if I replace "nonsense.dtd" with "http://nonsense.dtd";. Do you
experience a similar behavior?

> > I’ll still need to understand why it makes a difference if we assign
> > the value of the CATFILE option or the xslt:transform option to the
> > transformer?

I noticed that the query

  xslt:transform("try2.xsl", "try2.xsl", (), map { 'catalog' : "saxalog.xml" })

runs fine with the snapshot I provided before. And the following query

  declare option db:catfile "saxalog.xml";
  xslt:transform("try2.xsl", "try2.xsl", (), map { 'catalog' : "notfound.xml" })

raises the expected error. Things are different, though, if we replace
"try2.xsl" with doc("try2.xsl"): If the doc function is used, the
document will not be resolved by the XSL transformer, but already by
BaseX.

In a nutshell: You convinced me well enough that we should simplify
things and handle catalogs globally. Understanding catalogs is quite a
challenge in itself, and we shouldn’t necessarily make it even more
challenging. I have simplified the code again, so it looks pretty
similar to your original solution ;)

• If a global catalog file list is defined, it will also be assigned
to the XSL transformer. In fact, that’s the default behavior anyway if
functions like fn:doc are used in BaseX.
• No warnings will be output to standard error, unless
xml.catalog.ignoreMissing is overwritten.

The documentation has been updated, and new snapshots are available.

Reply via email to