On Tue, 2019-03-05 at 13:44 +0100, Christian Grün wrote:
Liam,
Thanks a lot for your patch, very appreciated! Pull requests are even handier for us, but any type of commit is welcome.
Thanks! Awesome!
I'll do a pull request next time.
I've tried the snapshot and got it to work; however, the following query
(: declare option db:catfile "/home/lee/public_html/texts/Dictionaries/Pigott-PoliticalDictionary/xml/saxalog.xml"; :) xslt:transform( doc("try.xsl"), doc("try.xsl"), map { 'dummyparam' : 'socks' }, map { 'catalog' : "/home/lee/public_html/texts/Dictionaries/Pigott-PoliticalDictionary/xml/unused.xml" } )
works if i uncomment the option declaration, but not otherwise. The file given as a fourth argument to xslt:transform doesn't seem to be opened (according to strace for example). But if the argument is omitted, catalog resolution is not performed.
Also watch that having xml.catalog.ignoreMissing unset means the resolver will issue warnings if no properties file is found; rather than get bug reports about a weird message, Cannot find CatalogManager.properties i'd suggest either checking if the systemProperty for it is set, or reinstating invoke(method(CMP, "setIgnoreMissingProperties", boolean.class), CM, true); (modulo refactoring)
The system property is xml.catalog.ignoreMissing
I can look at tracking these two things down and making a pull request for them, unless i'm doing something obvious wrong.
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?
I think it's too soon; i don't think Saxon is using it for example.
Thanks!
Liam
Liam