Liam,
Thanks a lot for your patch, very appreciated! Pull requests are even handier for us, but any type of commit is welcome.
I have merged your code, and I have done some further modifications (see the GitHub commit history for the changes in the code):
• I have decided to add a 'catalog' option to the function call [1]. This will reduce the chance of having the global option applied by mistake. • I have completely removed the assignment of static properties in the code; this way, custom user properties won’t be overwritten. I have added some notes in the revised version of the documentation [2] how to assign the custom properties. Comments and further edits on the Wiki article are welcome.
A new snapshot is available [3]. We are looking forward to feedback.
I noticed that Java 9 provides a better built-in support for XML catalog resolution [4]. With BaseX 10, we will probably switch to a newer version of Java. If we are going to upgrade: Would anyone reading this recommend us to keep up support for the separate Apache XML resolver library, or could we drop it completely and rely on Java’s built-in catalog support?
Best, Christian
[1] http://docs.basex.org/wiki/XSLT_Module#xslt:transform [2] http://docs.basex.org/wiki/Catalog_Resolver [3] http://files.basex.org/releases/latest/ [4] http://openjdk.java.net/jeps/268
On Tue, Feb 26, 2019 at 10:29 PM Liam R. E. Quin liam@fromoldbooks.org wrote:
The enclosed patch -- would you prefer a github pull request? -- makes xslt:transform() aware of XML catalog files, as other XML parsing already is. The same CATFILE preference is used (via the query context).
I refactored CatalogWrapper slightly so it could be reused. I also took away the line that sets verbosity to 0, as without it you can control verbosity via a system property, or using the CatalogManager.properties file.
I tested this with xml-commons-resolver-1.2/resolver.jar and with the built-in resolver and both seem to work.
I have not added tests. In addition, it'd be worth adding something to the documentation, especially about the xml.catalog.verbosity property (just verbosity in the .properties file).
Possible breaking change: i also removed the line that sets prefer=public. I spent ages trying to get catalogs working before i dicovered this, as i was using a system identifier! The code could check to see if the corresponding system property is set (users can't override the API with system properties, frustratingly), but since catalogs already say prefer=public or prefer=system in them, and it'd have needed to have been the same to work, i don't think this change breaks anythign in practice. It may make some catalogs start to work that had not been working, so maybe it's worth a line in the release notes.
Liam
-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Web slave for vintage clipart http://www.fromoldbooks.org/