Re: [basex-talk] supporting XML Catalog files in xslt:transform() (patch)
On Wed, 2019-03-13 at 20:15 +0100, Imsieke, Gerrit, le-tex wrote: > > On 13.03.2019 19:55, Liam R. E. Quin wrote: > > Yes, they are a bit of a nightmare. Actually i’ve thought about > > having > > the ability to write a URI Resolver in XQuery, > > db:resolve-identifier($system, $public, $purpose, $types) as > > xs:anyURI? > > > > but maybe it is too scary! > > I’ve already written a catalog resolver in XSLT… > https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/xsl/resolve-uri-by-catalog.xsl i bow down before your awesomeness :) but, the next step is to be able to use a user-written resolver in XSLT itself, e.g. for loading DTDs (other than the stylesheet contianig the resolver code...) For now though, thanks, Christian, for making the changes! Liam -- Liam Quin - web slave for https://www.fromoldbooks.org/ with fabulous vintage art and fascinating texts to read. Click here to have the slave beaten.
Re: [basex-talk] supporting XML Catalog files in xslt:transform() (patch)
On 13.03.2019 19:55, Liam R. E. Quin wrote: Yes, they are a bit of a nightmare. Actually i’ve thought about having the ability to write a URI Resolver in XQuery, db:resolve-identifier($system, $public, $purpose, $types) as xs:anyURI? but maybe it is too scary! I’ve already written a catalog resolver in XSLT… https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/xsl/resolve-uri-by-catalog.xsl
Re: [basex-talk] supporting XML Catalog files in xslt:transform() (patch)
On Wed, 2019-03-13 at 11:57 +0100, Christian Grün wrote: > > 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. That's good at least... > 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? Io, but i am running the example locally with no http involve, and using the standalone BaseX jar. But i did have to change it to map file: If you add verbosity = 999 to CatalogManager.properties you will see a log of what it is trying to resolve which may help (it also logs all the mapping rules it finds). > In a nutshell: You convinced me well enough that we should simplify > things and handle catalogs globally. :-) Yes, they are a bit of a nightmare. Actually i’ve thought about having the ability to write a URI Resolver in XQuery, db:resolve-identifier($system, $public, $purpose, $types) as xs:anyURI? but maybe it is too scary! > 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 ;) i’m sorry - i should have included more background and rationale as to why i did it the way i did, i think. > • 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. Perfect. > • No warnings will be output to standard error, unless > xml.catalog.ignoreMissing is overwritten. Perfect. > > The documentation has been updated, and new snapshots are available. it is all working for me. Many many thanks! Liam -- Liam Quin - web slave for https://www.fromoldbooks.org/ with fabulous vintage art and fascinating texts to read. Click here to have the slave rewarded with cold gruel.
Re: [basex-talk] supporting XML Catalog files in xslt:transform() (patch)
> 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.
Re: [basex-talk] Regex j-flag
Hi Andreas,
Yes, that’s true, it got lost in 9.1.2 [1]. Sorry for that.
BaseX 9.2 will be available soon. For now, feel free to use 9.1.1 or
the latest snapshot [2].
Best,
Christian
[1] https://github.com/BaseXdb/basex/issues/1669
[2] http://files.basex.org/releases/latest/
On Wed, Mar 13, 2019 at 11:06 AM Andreas Hartmann
wrote:
>
> Hi
>
> The "j" flag for regular expressions introduced in version 9.1 doesn't seem
> to work in 9.1.2 anymore. For example, matches("Fenster", "\bfenst", "ij")
> produces [FORX0001] invalid regular flag 'j'. The same expression works in
> 9.1.1.
>
> Best Greetings,
>
> Andreas
>
>
>
[basex-talk] Regex j-flag
Hi
The "j" flag for regular expressions introduced in version 9.1 doesn't seem
to work in 9.1.2 anymore. For example, matches("Fenster", "\bfenst", "ij")
produces [FORX0001] invalid regular flag 'j'. The same expression works in
9.1.1.
Best Greetings,
Andreas
