With BaseX 10, which will be based on JDK 11, we’ll switch to the built-in JDK Catalog Resolver [1], which tends to get good reviews, and which allows for a much cleaner and more consistent integration. Debugging should be easier as well, as errors will always be reported back if the catalog resolution fails.
We think about replacing the CATFILE option…
1. Option: CATFILE: path/to/catalog.xml
2. or XQuery: fetch:xml('file.xml', map { 'catfile': 'path/to/catalog.xml })
…with a new CATALOG option that takes multiple keys and values:
1. Option: CATALOG: files=path/to/catalog.xml,resolve=strict,prefer=public,defer=false
2. or XQuery: fetch:xml('file.xml', map { 'catalog': map { 'files': 'path/to/catalog.xml', 'resolve': 'strict', 'prefer': 'public', 'defer': false() }})
An alternative would be to completely drop the catalog options and assign all catalog options via system properties at startup:
java -Djavax.xml.catalog.files=path/to/catalog.xml .... BaseX
I’d love to get your feedback on these ideas, and your experiences with an early BaseX 10 snapshot [2]! Christian
[1] https://docs.oracle.com/en/java/javase/11/core/xml-catalog-api1.html#GUID-96... [2] https://files.basex.org/releases/latest-10/
On Fri, Nov 5, 2021 at 9:03 AM Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de wrote:
On 05.11.2021 03:03, Liam R. E. Quin wrote:
On Thu, 2021-11-04 at 18:43 -0400, Graydon Saunders wrote:
Related to this, setting the catalog for use by xslt:transform() is defeating me.
The only ways i have found to debug these are (1) with strace -f, to make sure the file is being read (2) with a CatalogManager.properties file [[ verbosity=65535 # relative-catalogs=false prefer = public catalogs=mycataloguefile.xml ]]
Likely you need entries in the catalog file starting with file:///
If you are uploading queries to a BaseX server, remember it's the server that needs to have had XLASSPATH set when starting, and that relativeURIs like "catalog.xml" might be sought for in the server's directory.
Liam
Liam and Christian have thankfully added support for resolving include/import URIs and doc(…) URIs approx 2 years ago [1]. A thing that I recently found was lacking is resolution of system identifiers that occur in documents. That is, if there is a reference to a DTD in a document that is read during the transformation, the catalog resolution does not apply to the public or system identifiers.
Is this the issue that you are encountering, Graydon?
Your first argument to xslt:transform is db:open('acme_content')[1]. Does this document have a DOCTYPE declaration? I’d have guessed that the DOCTYPE declaration was stripped away when the documents were loaded into the DB, that is, parsing with the DTD only happened during import. But maybe this is different if you use the internal parser.
Gerrit