Main Page » Mailing List » August 2023

mapping functions

Wednesday, 16 August 2023 · 6 messages · last reply 17 Aug 2023
G
gerrit.imsiekein reply to Graydon Saunders, 16 Aug 2023, 06:4216 Aug 2023 05:34 #
You can import the library module in the evaluated expression. Example: https://github.com/transpect/control-backend/blob/main/webapp/control-backend.xqm#L60 Gerrit Sent from MailDroid
Quoted text · Graydon Saunders · 30 lines
-----Original Message----- From: Graydon Saunders <graydonish at gmail.com> To: BaseX <BaseX-Talk at mailman.uni-konstanz.de> Sent: Wed, 16 Aug 2023 4:42 Subject: [basex-talk] mapping functions Hello -- I have various databases that will be run through the same code after their contents is regularized. So the only different function is the one used for regularization. This can be handled by writing a wrapper function and passing in a label to say which function to use, but I was wondering if there's a way to do it in the configuration map directly. The configuration map exists as a text file and gets run through xquery:eval() at the start of the process. declare namespace abc='http://some/uri'; 'regularizationFunction': map { 'typeOne': abc:regularizationOne#1, 'typeTwo': abc:regularizationTwo#1 } doesn't work, because the abc functions aren't known at evaluation time. These functions are defined in the library module that's evaluating the configuration file but xquery:eval() doesn't know that. I don't see a way to use bindings to get around this. Is there a way to map a locally-defined function reference so xquery:eval() will recognize it? thanks! Graydon -- Graydon Saunders | graydonish at fastmail.com Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")
GS
Graydon Saunders16 Aug 2023 06:42 #
Hello -- I have various databases that will be run through the same code after their contents is regularized. So the only different function is the one used for regularization. This can be handled by writing a wrapper function and passing in a label to say which function to use, but I was wondering if there's a way to do it in the configuration map directly. The configuration map exists as a text file and gets run through xquery:eval() at the start of the process.
declare namespace abc='http://some/uri';
'regularizationFunction': map {
     'typeOne': abc:regularizationOne#1,
     'typeTwo': abc:regularizationTwo#1
}
doesn't work, because the abc functions aren't known at evaluation time. These functions are defined in the library module that's evaluating the configuration file but xquery:eval() doesn't know that. I don't see a way to use bindings to get around this. Is there a way to map a locally-defined function reference so xquery:eval() will recognize it? thanks! Graydon
-- Graydon Saunders | graydonish at fastmail.com Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")
IL
Imsieke, Gerrit, le-tex17 Aug 2023 02:07 #
Hi Graydon, Replying to the list for posterity. I hope you don’t mind. When you dynamically evaluate an expression (xquery:eval(), job:eval(), …), you start with the default values of the static context [1]. Nothing of the XQuery module from which you evaluate the expression is known (unless supplied by binding, but ordinary function declarations are not amenable to binding), therefore no risk of circularity. As stated in the table in [1], you can use module import [2] to augment this clean slate. In particular the module’s function declarations/signatures will be available then. If you don’t want the dynamically evaluated expression to import the whole module, you can store functions into variables and supply these variables to the evaluation through bindings. Haven’t tried it yet. Gerrit [1] https://www.w3.org/TR/xquery-31/#id-xq-static-context-components [2] https://www.w3.org/TR/xquery-31/#id-module-import
Quoted text · Graydon Saunders · 48 lines
On 16.08.2023 14:02, Graydon Saunders wrote: > Thank you for the specific example! > > I'm croggled that works without giving me a circular reference error of some kind, but it does work. > > Much appreciated! > > Graydon > > On Tue, Aug 15, 2023 at 11:34 PM <gerrit.imsieke at le-tex.de <mailto:gerrit.imsieke at le-tex.de>> wrote: > > You can import the library module in the evaluated expression. Example: https://github.com/transpect/control-backend/blob/main/webapp/control-backend.xqm#L60 <https://github.com/transpect/control-backend/blob/main/webapp/control-backend.xqm#L60> > > Gerrit > > > Sent from MailDroid <https://goo.gl/ODgwBb> > > -----Original Message----- > From: Graydon Saunders <graydonish at gmail.com <mailto:graydonish at gmail.com>> > To: BaseX <BaseX-Talk at mailman.uni-konstanz.de <mailto:BaseX-Talk at mailman.uni-konstanz.de>> > Sent: Wed, 16 Aug 2023 4:42 > Subject: [basex-talk] mapping functions > > Hello -- > > I have various databases that will be run through the same code after their contents is regularized. So the only different function is the one used for regularization. > > This can be handled by writing a wrapper function and passing in a label to say which function to use, but I was wondering if there's a way to do it in the configuration map directly. The configuration map exists as a text file and gets run through xquery:eval() at the start of the process. > > declare namespace abc='http://some/uri <http://some/uri>'; > 'regularizationFunction': map { > 'typeOne': abc:regularizationOne#1, > 'typeTwo': abc:regularizationTwo#1 > } > > doesn't work, because the abc functions aren't known at evaluation time. These functions are defined in the library module that's evaluating the configuration file but xquery:eval() doesn't know that. I don't see a way to use bindings to get around this. > > Is there a way to map a locally-defined function reference so xquery:eval() will recognize it? > > thanks! > Graydon > > -- > Graydon Saunders | graydonish at fastmail.com <mailto:graydonish at fastmail.com> > Þæs oferéode, ðisses swá mæg. > -- Deor ("That passed, so may this.") >
-- Gerrit Imsieke Geschäftsführer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke at le-tex.de, http://www.le-tex.de Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930 Geschäftsführer / Managing Directors: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt ---------------------------------------------- Besuchen Sie uns auf der Frankfurter Buchmesse in Halle 4.0, G94.
IL
Imsieke, Gerrit, le-texin reply to Graydon, 17 Aug 2023, 04:4017 Aug 2023 02:46 #
Quoted text · Graydon · 4 lines
On 17.08.2023 02:40, Graydon wrote: > The thing that has me croggled is that the dynamically evaluated > expression is in the module being imported, where it is bound to a > public variable in the module namespace.
That may be true, but if you are referring to it in the evaluated expression by its signature, this signature won’t be known – unless you import the module in the expression.
Quoted text · Graydon · 1 line
> 'typeOne': abc:regularizationOne#1
G
Graydonin reply to Imsieke, Gerrit, le-tex, 17 Aug 2023, 02:0717 Aug 2023 04:40 #
Quoted text · Imsieke, Gerrit, le-tex · 2 lines
On Thu, Aug 17, 2023 at 02:07:52AM +0200, Imsieke, Gerrit, le-tex scripsit: > Hi Graydon,
Hi Gerrit --
Quoted text · Imsieke, Gerrit, le-tex · 1 line
> Replying to the list for posterity. I hope you don’t mind.
Not in the slightest.
Quoted text · Imsieke, Gerrit, le-tex · 6 lines
> When you dynamically evaluate an expression (xquery:eval(), > job:eval(), …), you start with the default values of the static > context [1]. Nothing of the XQuery module from which you evaluate the > expression is known (unless supplied by binding, but ordinary function > declarations are not amenable to binding), therefore no risk of > circularity.
That makes sense; xquery:eval() has only the supplied static context.
Quoted text · Imsieke, Gerrit, le-tex · 6 lines
> As stated in the table in [1], you can use module import [2] to > augment this clean slate. In particular the module’s function > declarations/signatures will be available then. If you don’t want the > dynamically evaluated expression to import the whole module, you can > store functions into variables and supply these variables to the > evaluation through bindings. Haven’t tried it yet.
The thing that has me croggled is that the dynamically evaluated expression is in the module being imported, where it is bound to a public variable in the module namespace. https://www.w3.org/TR/xquery-31/#id-module-import does say that public variable declaration are included in what's imported. I'm pleased that it works, but I wouldn't claim I understand how it works. My (somewhat reduced) library module starts off as: module namespace xc = "http://example.com/stuff";
(: load the list of parameters:)
declare variable $xc:paramsFile external;
declare variable $xc:params as map(*) := file:read-text($xc:paramsFile) => xquery:eval();
followed by various functions, and the parameters start off:
import module namespace xc="http://example.com/stuff" at "library.xqm";
map {
    (: many parameters :)
    }
While I think I get that the xquery:eval() only has the static context provided to it, and by default has nothing, why the xquery:eval() doesn't try to evaluate the variable again when the library module is provided as context isn't at all clear to me. I suppose there has to be something in the import process that avoids infinite loops. Thanks! Graydon
-- Graydon Saunders | graydonish at fastmail.com Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")
G
Graydonin reply to Imsieke, Gerrit, le-tex, 17 Aug 2023, 02:4617 Aug 2023 18:06 #
Quoted text · Imsieke, Gerrit, le-tex · 10 lines
On Thu, Aug 17, 2023 at 02:46:24AM +0200, Imsieke, Gerrit, le-tex scripsit: > On 17.08.2023 02:40, Graydon wrote: > > The thing that has me croggled is that the dynamically evaluated > > expression is in the module being imported, where it is bound to a > > public variable in the module namespace. > > That may be true, but if you are referring to it in the evaluated > expression by its signature, this signature won’t be known – unless > you import the module in the expression.
Which implies that perhaps at import time in xquery:eval ONLY those variables and functions which are referenced in the evaluated expression are resolved from the imported module, which explains why the variable (which isn't referenced in the eval) doesn't cause an infinite loop. Thank you! I feel less confused. -- Graydon
-- Graydon Saunders | graydonish at fastmail.com Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")

Written for BaseX 10.7. BaseX may have changed since: please check the current documentation.

⚡Generated with XQuery