Repository navigation
fontoxpath:evaluate can't see functions defined in XQuery, but can see those defined with registerCustomXPathFunction #513
Description
Calling fontoxpath:evaluate, I am getting errors like this:
Error: XPST0017: Function Q{https://github.com/rrthomas/ruth/raw/main/ruth.dtd}r
elative-path with arity of 1 not registered. Did you mean "Q{https://github.com/
rrthomas/ruth/raw/main/ruth.dtd}real-path (xs:string)"?
Here, ruth:real-path (the function suggested) is defined with registerCustomXPathFunction, while ruth:relative-path (the function that the evaluation can't find) is defined in XQuery that has been loaded with registerXQueryModule. I don't understand why one is visible to fontoxpath:evaluate but not the other.
I pushed a branch of my project that illustrates the problem when you run npm test, but I quite understand if that is too much code to go through—I can try to prepare a MWE if that's necessary.
Activity
DrRataplan commentedon Jul 28, 2022
Hey Reuben,
That is an old issue: functions that are declared with
registerCustomXPathFunctionare available globally. No real reason for this besides us implementing this before we've even giving XQuery a thought.Not sure what to do here to be honest. I mean, on one hand, we can just re-import the modules-in-scope from the module that calls
fontoxpath:evaluateautomatically: so if the outer script containsimport module namespace xxx="yyy";, also import that module when executing thefontoxpath:evaluate. This feels developer-friendly, but also not really predictable: if the queries are dynamic, they would depend on how they are used. In some contexts they would be OK, in others they would not.On the other hand, you could add an explicit module import:
fontoxpath:evaluate('import module namespace xxx="yyy"; xxx:my-function(.)', map{'.', .}). No as developer-friendly, but more explicit and predictable.Seeing as you are basically half of the (known) user-base of this function (Fonto is the other user 😉), I'm open for discussion here! What are your thoughts?
rrthomas commentedon Jul 28, 2022
Thanks very much for your detailed, helpful and friendly reply.
My perspective is as follows: on the one hand, Ruth (my project) is basically a wrapper around XQuery (so, fontoxpath), and currently a proportion of the code is simply workarounds for gaps in fontoxpath's XQuery functionality. (This is no disrespect to fontoxpath: I seem to have a tendency to write small programs much of whose code consists of workarounds for whatever libraries I'm using.) Hence, I would like fontoxpath to be as complete an implementation of XQuery/XPath as possible.
On the other hand, I have fairly limited use cases for Ruth, so I am not testing a wide range of XQuery functionality. You could say that at present my use of XQuery is quite "deep" (I use most of the different "mechanisms") but not very "broad" (e.g. I don't use a wide range of functions).
So overall, I am happiest if over time I can reduce the amount of workaround/polyfill code I have in Ruth with principled additions to fontoxpath.
In this particular case, I tried using your tip, and indeed that makes my custom functions visible; but I then have a similar problem with a variable
ruth_elementwhich is reported asdeclared but not in scope. It's defined in my variables hash passed toevaluateXPath*, so why can'tfontoxpath:evaluatesee it?rrthomas commentedon Jul 28, 2022
I have updated my
fontoxpath-evaluatebranch of Ruth to add theimport module namespacestatements where needed.I find that I would also need to import other modules dynamically (for example in my
cookbookexample/test). This suggests that I really want your "automagic" fix above.It would be good to better understand the downsides of doing that. I would imagine that normally I would want
fontoxpath:evaluateto run in the same context as that in which it is called; though I can see that it would be useful to be able to reset/change the context.