Dear Christian,

Thanks for your response. I'm going to try be more specific, but to remain concise.

In our restxq application, we have one "main" module and several "dependent" modules. The main module receives the http requests (well, it declare functions annotated with a path, say ourApp/{$param}), and calls functions in one of the dependent module. This dependent module is determined by the path : a request to ourApp/moduleA will cause the main module to use functions in the moduleA dependent module, while a request to ourApp/moduleB will cause it to call functions in the moduleB dependent module.

It works just well if we import all the dependent modules in the main module using the regular way, with import module statements. Yet, we want to go one step forward and import the dependent modules only when/if needed. More precisely, we'd like to be able to add new dependent modules in the restxq directory without having to modify the main module by adding new import module statements.

But it's probably some kind of inappropriate perfectionism that isn't worth spending much time !

Best,

Jean-Philippe

PS: Thanks for looking at the circular import issue. Having our dependent modules importing back the main module would be very helpful!

On Thu, Jun 20, 2013 at 10:44 PM, Christian Grün christian.gruen@gmail.comwrote:

Dear Jean-Philippe,

as you correctly guessed, there is no function in BaseX for dynamically importing XQuery modules. The function xquery:invoke [1] may serve a similar purpose. I’m not sure how the invocation of Java code could help here, so could you give us some more information on what you plan to do, and what needs to be done at runtime in your scenario?

Thanks, Christian

PS: our team member Leo is currently having a look at the circular module import issue.

[1] http://docs.basex.org/wiki/XQuery_Module#xquery:invoke ___________________________

...

Exist-db has an util:import-module function that allows to dynamically import an XQuery module at run time. I haven't found anything equivalent

in

...

BaseX. Is that right ?

I have also tried to see how to implement such a function directly in

Java,

...

but as far as I understand the module parsing process, functions prefix

are

...

checked at compile time. That would compromise any attempt to write such

a

...

function. Am I right ?

Best,

Jean-Philippe

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

Hi Christian,

I repoen this discussion about dynamic module loading. This issue is getting more and more blocking for us. Let me try to re-expain our needs. We've written a restXQ based webapp extendable with a plugin based mechanism, where plugins modules provide functions to be called from a main module. But to be able to call a plugin function from the main module, the plugin module has to be imported by the main module. As far as we know, this can only be done with a import module staetment. Thus, users who have installed our webapp and who want to install plugins have to dig into the xquery code to add these import statements. Even with a good documentation, for non technical users, this is to much to ask. If we could dynamically import modules with a function similar to exist's util:import-modulehttp://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/util&location=java:org.exist.xquery.functions.util.UtilModule, the plugin installation process would be dramatically simplified. Do you have any plan to implement such a function ? Or is there any workaround we could use ?

Best,

Jean-Philippe

On Fri, Jun 21, 2013 at 4:43 PM, Christian Grün christian.gruen@gmail.comwrote:

Hi Jean-Philippe,

thanks for providing us with the (concise) details.

In our existing RESTXQ projects, we directly decorate all executable functions with specific %rest:path annotations; this way, there is no need for an additional “dispatcher” function that delegates a call to a specific module or function. You can dynamically add and remove modules to your web application, as all .xqm files will automatically be parsed for restxq annotations before each query execution. Next, the implementation is smart enough to only parse code that has ben changed, so you shouldn’t encounter any bottlenecks even when working with hundreds of restxq modules. But I’m not sure if adding modules with restxq entry points is a reasonable alternative for your approach?

Your feedback is welcome; feel free to ask for more details, Christian ___________________________

2013/6/21 Jean-philippe Magué jean-philippe.mague@ens-lyon.fr:

...

Dear Christian,

Thanks for your response. I'm going to try be more specific, but to

remain

...

concise.

In our restxq application, we have one "main" module and several

"dependent"

...

modules. The main module receives the http requests (well, it declare functions annotated with a path, say ourApp/{$param}), and calls

functions

...

in one of the dependent module. This dependent module is determined by

the

...

path : a request to ourApp/moduleA will cause the main module to use functions in the moduleA dependent module, while a request to

ourApp/moduleB

...

will cause it to call functions in the moduleB dependent module.

It works just well if we import all the dependent modules in the main

module

...

using the regular way, with import module statements. Yet, we want to go

one

...

step forward and import the dependent modules only when/if needed. More precisely, we'd like to be able to add new dependent modules in the

restxq

...

directory without having to modify the main module by adding new import module statements.

But it's probably some kind of inappropriate perfectionism that isn't

worth

...

spending much time !

Best,

Jean-Philippe

PS: Thanks for looking at the circular import issue. Having our dependent modules importing back the main module would be very helpful!

On Thu, Jun 20, 2013 at 10:44 PM, Christian Grün <

christian.gruen@gmail.com>

...

wrote:

...

Dear Jean-Philippe,

as you correctly guessed, there is no function in BaseX for dynamically importing XQuery modules. The function xquery:invoke [1] may serve a similar purpose. I’m not sure how the invocation of Java code could help here, so could you give us some more information on what you plan to do, and what needs to be done at runtime in your scenario?

Thanks, Christian

PS: our team member Leo is currently having a look at the circular module import issue.

[1] http://docs.basex.org/wiki/XQuery_Module#xquery:invoke ___________________________

...

Exist-db has an util:import-module function that allows to dynamically import an XQuery module at run time. I haven't found anything

equivalent

...

...

...

in BaseX. Is that right ?

I have also tried to see how to implement such a function directly in Java, but as far as I understand the module parsing process, functions

prefix

...

...

...

are checked at compile time. That would compromise any attempt to write

such

...

...

...

a function. Am I right ?

Best,

Jean-Philippe

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

Hi Christian,

Thanks for your answer and for taking our feature request into consideration.

You propose to use xquery:eval, as long as we don't perform any updates (which is the case). But the documentation of this function mentions that two errors can be raised : in case of updates and when the evaluated expression yields function items. How should we understand this second limitation? Because modules precisely define functions...

Best,

Jean-Philippe

On Mon, Feb 24, 2014 at 10:59 AM, Christian Grün christian.gruen@gmail.comwrote:

Hi Jean-Philippe,

thanks for your describing your use case. I've recently thought about such an import-module function. It's not completely trivial, because a dynamic import function may result in the import of other modules, some of which may already have been statically imported, and so on. But I have added an issue to remember your feature request...

https://github.com/BaseXdb/basex/issues/869

...and I'll give you notice as soon as we have time to tackle this one.

In the meanwhile, the use of xquery:eval may be one way out, as long as you don't have to perform any updates.

Feel free to ask for more, Christian

On Mon, Feb 24, 2014 at 10:40 AM, Jean-philippe Magué jean-philippe.mague@ens-lyon.fr wrote:

...

Hi Christian,

I repoen this discussion about dynamic module loading. This issue is

getting

...

more and more blocking for us. Let me try to re-expain our needs. We've written a restXQ based webapp extendable with a plugin based mechanism, where plugins modules provide functions to be called from a

main

...

module. But to be able to call a plugin function from the main module,

the

...

plugin module has to be imported by the main module. As far as we know,

this

...

can only be done with a import module staetment. Thus, users who have installed our webapp and who want to install plugins have to dig into the xquery code to add these import statements. Even with a good

documentation,

...

for non technical users, this is to much to ask. If we could dynamically import modules with a function similar to exist's util:import-module, the plugin installation process would be dramatically simplified. Do you have any plan to implement such a function ? Or is there any workaround we could use ?

Best,

Jean-Philippe

On Fri, Jun 21, 2013 at 4:43 PM, Christian Grün <

christian.gruen@gmail.com>

...

wrote:

...

Hi Jean-Philippe,

thanks for providing us with the (concise) details.

In our existing RESTXQ projects, we directly decorate all executable functions with specific %rest:path annotations; this way, there is no need for an additional "dispatcher" function that delegates a call to a specific module or function. You can dynamically add and remove modules to your web application, as all .xqm files will automatically be parsed for restxq annotations before each query execution. Next, the implementation is smart enough to only parse code that has ben changed, so you shouldn't encounter any bottlenecks even when working with hundreds of restxq modules. But I'm not sure if adding modules with restxq entry points is a reasonable alternative for your approach?

Your feedback is welcome; feel free to ask for more details, Christian ___________________________

2013/6/21 Jean-philippe Magué jean-philippe.mague@ens-lyon.fr:

...

Dear Christian,

Thanks for your response. I'm going to try be more specific, but to remain concise.

In our restxq application, we have one "main" module and several "dependent" modules. The main module receives the http requests (well, it declare functions annotated with a path, say ourApp/{$param}), and calls functions in one of the dependent module. This dependent module is determined by the path : a request to ourApp/moduleA will cause the main module to use functions in the moduleA dependent module, while a request to ourApp/moduleB will cause it to call functions in the moduleB dependent module.

It works just well if we import all the dependent modules in the main module using the regular way, with import module statements. Yet, we want to

go

...

...

...

one step forward and import the dependent modules only when/if needed.

More

...

...

...

precisely, we'd like to be able to add new dependent modules in the restxq directory without having to modify the main module by adding new

import

...

...

...

module statements.

But it's probably some kind of inappropriate perfectionism that isn't worth spending much time !

Best,

Jean-Philippe

PS: Thanks for looking at the circular import issue. Having our dependent modules importing back the main module would be very helpful!

On Thu, Jun 20, 2013 at 10:44 PM, Christian Grün christian.gruen@gmail.com wrote:

...

Dear Jean-Philippe,

as you correctly guessed, there is no function in BaseX for dynamically importing XQuery modules. The function xquery:invoke [1] may serve a similar purpose. I'm not sure how the invocation of Java code could help here, so could you give us some more information on what you plan to do, and what needs to be done at runtime in your scenario?

Thanks, Christian

PS: our team member Leo is currently having a look at the circular module import issue.

[1] http://docs.basex.org/wiki/XQuery_Module#xquery:invoke ___________________________

...

Exist-db has an util:import-module function that allows to dynamically import an XQuery module at run time. I haven't found anything equivalent in BaseX. Is that right ?

I have also tried to see how to implement such a function directly

in

...

...

...

...

...

Java, but as far as I understand the module parsing process, functions prefix are checked at compile time. That would compromise any attempt to write such a function. Am I right ?

Best,

Jean-Philippe

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques :

ahn.ens-lyon.fr

...

...

...

...

...

Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

-- Jean-Philippe Magué Maître de Conférences à l'Ecole Normale Supérieure de Lyon +33 (0)4 37 37 63 13

Hi Jean-Philippe,

we are still hesitant to implement a function that dynamically adds all imported functions to the static query context. Such an extension wouldn't allow us anymore to statically determine which of the functions that are used in the XQuery expression do actually exist, and which may be imported at runtime by an import-module call.

However, we could add a function that returns a sequence of all functions declared in a specific module, and which could be browser for a specific function. I have added this idea (inspired by our team member Leo) and an example how to use it to GitHub [1].

Do you (and others) think that this solution would be a viable alternative to the util:import-module function from eXist? Christian

[1] https://github.com/BaseXdb/basex/issues/872

On Mon, Feb 24, 2014 at 4:55 PM, Christian Grün christian.gruen@gmail.com wrote:

Hi Jean-Philippe,

...

when the evaluated expression yields function items. How should we understand this second limitation? Because modules precisely define functions...

This means that the result of a query may not be a function, as e.g. in the following two examples:

xquery:eval("true#0"), xquery:eval("function() { 1 }")

Hope this helps, Christian

Just thinking out loudly .... what about resolving a function by a custom annotation too? This could enable to abstract away from function names (and signatures) and possibly change behaviour of an implementation by just moving an annotation from one function to another ... I think jaxws does something similar .... M.

On 24/02/2014 19:09, Imsieke, Gerrit, le-tex wrote:

Great idea!

And it seems as if a user will able to submit the module URI and a function name via RESTXQ and use this function even in an updating expression.

Maybe a variant of inspect:functions() could also accept a string (my use case: an application/xquery document that is submitted in a multipart RESTXQ POST request), parse it for function declarations and return them as function items.

You’d have one signature with an xs:anyURI argument and one with an xs:string argument. Or name the two functions differently and let both accept strings.

Gerrit

On 24.02.2014 18:32, Christian Grün wrote:

...

Hi Jean-Philippe,

we are still hesitant to implement a function that dynamically adds all imported functions to the static query context. Such an extension wouldn't allow us anymore to statically determine which of the functions that are used in the XQuery expression do actually exist, and which may be imported at runtime by an import-module call.

However, we could add a function that returns a sequence of all functions declared in a specific module, and which could be browser for a specific function. I have added this idea (inspired by our team member Leo) and an example how to use it to GitHub [1].

Do you (and others) think that this solution would be a viable alternative to the util:import-module function from eXist? Christian

[1] https://github.com/BaseXdb/basex/issues/872

On Mon, Feb 24, 2014 at 4:55 PM, Christian Grün christian.gruen@gmail.com wrote:

...

Hi Jean-Philippe,

...

when the evaluated expression yields function items. How should we understand this second limitation? Because modules precisely define functions...

This means that the result of a query may not be a function, as e.g. in the following two examples:

xquery:eval("true#0"), xquery:eval("function() { 1 }")

Hope this helps, Christian

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

Hi Gerrit,

And it seems as if a user will able to submit the module URI and a function name via RESTXQ and use this function even in an updating expression.

I guess we'll have to disallow the execution of updating functions. Otherwise, we cannot tell at compile time if an expression will be updating or not (this is a fundamental requirement of XQuery Update 1.0).

On 24.02.2014 18:32, Christian Grün wrote:

...

Hi Jean-Philippe,

we are still hesitant to implement a function that dynamically adds all imported functions to the static query context. Such an extension wouldn't allow us anymore to statically determine which of the functions that are used in the XQuery expression do actually exist, and which may be imported at runtime by an import-module call.

However, we could add a function that returns a sequence of all functions declared in a specific module, and which could be browser for a specific function. I have added this idea (inspired by our team member Leo) and an example how to use it to GitHub [1].

Do you (and others) think that this solution would be a viable alternative to the util:import-module function from eXist? Christian

[1] https://github.com/BaseXdb/basex/issues/872

On Mon, Feb 24, 2014 at 4:55 PM, Christian Grün christian.gruen@gmail.com wrote:

...

Hi Jean-Philippe,

...

when the evaluated expression yields function items. How should we understand this second limitation? Because modules precisely define functions...

This means that the result of a query may not be a function, as e.g. in the following two examples:

xquery:eval("true#0"), xquery:eval("function() { 1 }")

Hope this helps, Christian

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- 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@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vöckler

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

Hi Jean-Philippe, hi Maud,

we are glad to finally provide you with the discussed extension of inspect:functions [1,2]!

Your feedback is welcome, Christian

[1] http://docs.basex.org/wiki/Inspection_Module#inspect:functions [2] http://files.basex.org/releases/latest/

On Mon, Feb 24, 2014 at 6:32 PM, Christian Grün christian.gruen@gmail.com wrote:

Hi Jean-Philippe,

we are still hesitant to implement a function that dynamically adds all imported functions to the static query context. Such an extension wouldn't allow us anymore to statically determine which of the functions that are used in the XQuery expression do actually exist, and which may be imported at runtime by an import-module call.

However, we could add a function that returns a sequence of all functions declared in a specific module, and which could be browser for a specific function. I have added this idea (inspired by our team member Leo) and an example how to use it to GitHub [1].

Do you (and others) think that this solution would be a viable alternative to the util:import-module function from eXist? Christian

[1] https://github.com/BaseXdb/basex/issues/872

On Mon, Feb 24, 2014 at 4:55 PM, Christian Grün christian.gruen@gmail.com wrote:

...

Hi Jean-Philippe,

...

when the evaluated expression yields function items. How should we understand this second limitation? Because modules precisely define functions...

This means that the result of a query may not be a function, as e.g. in the following two examples:

xquery:eval("true#0"), xquery:eval("function() { 1 }")

Hope this helps, Christian

Hi Jean-Philippe,

have you thought about just writing the dynamic imports to the main module by text replacement? You could use comments to mark the respective area.

(: start-dynamic-imports :) import module namespace plugin1 import module namespace plugin2 (: end-dynamic-imports :)

Regards, Max

2014-02-24 10:40 GMT+01:00 Jean-philippe Magué < jean-philippe.mague@ens-lyon.fr>:

Hi Christian,

I repoen this discussion about dynamic module loading. This issue is getting more and more blocking for us. Let me try to re-expain our needs. We've written a restXQ based webapp extendable with a plugin based mechanism, where plugins modules provide functions to be called from a main module. But to be able to call a plugin function from the main module, the plugin module has to be imported by the main module. As far as we know, this can only be done with a import module staetment. Thus, users who have installed our webapp and who want to install plugins have to dig into the xquery code to add these import statements. Even with a good documentation, for non technical users, this is to much to ask. If we could dynamically import modules with a function similar to exist's util:import-modulehttp://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/util&location=java:org.exist.xquery.functions.util.UtilModule, the plugin installation process would be dramatically simplified. Do you have any plan to implement such a function ? Or is there any workaround we could use ?

Best,

Jean-Philippe

On Fri, Jun 21, 2013 at 4:43 PM, Christian Grün <christian.gruen@gmail.com

...

wrote:

...

Hi Jean-Philippe,

thanks for providing us with the (concise) details.

In our existing RESTXQ projects, we directly decorate all executable functions with specific %rest:path annotations; this way, there is no need for an additional "dispatcher" function that delegates a call to a specific module or function. You can dynamically add and remove modules to your web application, as all .xqm files will automatically be parsed for restxq annotations before each query execution. Next, the implementation is smart enough to only parse code that has ben changed, so you shouldn't encounter any bottlenecks even when working with hundreds of restxq modules. But I'm not sure if adding modules with restxq entry points is a reasonable alternative for your approach?

Your feedback is welcome; feel free to ask for more details, Christian ___________________________

2013/6/21 Jean-philippe Magué jean-philippe.mague@ens-lyon.fr:

...

Dear Christian,

Thanks for your response. I'm going to try be more specific, but to

remain

...

concise.

In our restxq application, we have one "main" module and several

"dependent"

...

modules. The main module receives the http requests (well, it declare functions annotated with a path, say ourApp/{$param}), and calls

functions

...

in one of the dependent module. This dependent module is determined by

the

...

path : a request to ourApp/moduleA will cause the main module to use functions in the moduleA dependent module, while a request to

ourApp/moduleB

...

will cause it to call functions in the moduleB dependent module.

It works just well if we import all the dependent modules in the main

module

...

using the regular way, with import module statements. Yet, we want to

go one

...

step forward and import the dependent modules only when/if needed. More precisely, we'd like to be able to add new dependent modules in the

restxq

...

directory without having to modify the main module by adding new import module statements.

But it's probably some kind of inappropriate perfectionism that isn't

worth

...

spending much time !

Best,

Jean-Philippe

PS: Thanks for looking at the circular import issue. Having our

dependent

...

modules importing back the main module would be very helpful!

On Thu, Jun 20, 2013 at 10:44 PM, Christian Grün <

christian.gruen@gmail.com>

...

wrote:

...

Dear Jean-Philippe,

as you correctly guessed, there is no function in BaseX for dynamically importing XQuery modules. The function xquery:invoke [1] may serve a similar purpose. I'm not sure how the invocation of Java code could help here, so could you give us some more information on what you plan to do, and what needs to be done at runtime in your scenario?

Thanks, Christian

PS: our team member Leo is currently having a look at the circular module import issue.

[1] http://docs.basex.org/wiki/XQuery_Module#xquery:invoke ___________________________

...

Exist-db has an util:import-module function that allows to

dynamically

...

...

...

import an XQuery module at run time. I haven't found anything

equivalent

...

...

...

in BaseX. Is that right ?

I have also tried to see how to implement such a function directly in Java, but as far as I understand the module parsing process, functions

prefix

...

...

...

are checked at compile time. That would compromise any attempt to write

such

...

...

...

a function. Am I right ?

Best,

Jean-Philippe

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be

more

...

...

...

humanistic than before." Busa, 1980.

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08

--

"Using computers will therefore lead us to a more profound and

systematic

...

knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.

-- Jean-Philippe Magué Maître de Conférences à l'Ecole Normale Supérieure de Lyon +33 (0)4 37 37 63 13

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk