Dynamic Module Loading

> 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

> 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 at mailman.uni-konstanz.de > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > >

> 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 at 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 at 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 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 at 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 at 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 at 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. >

On Mon, Feb 24, 2014 at 10:40 AM, Jean-philippe Magué <jean-philippe.mague at 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 at 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 at 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 at 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 at 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 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<http://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 at 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 at 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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >

On Feb 24, 2014, at 4:40 AM, Jean-philippe Magué <jean-philippe.mague at 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 at 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 at 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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> 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 at 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 at 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 at 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 at 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 at 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 >

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

On Mon, Feb 24, 2014 at 4:55 PM, Christian Grün <christian.gruen at 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

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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

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 at 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 at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >

> 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.

> 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 at 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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> 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 at 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 at mailman.uni-konstanz.de >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> >> > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> 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 at 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 >

On Mon, Feb 24, 2014 at 6:32 PM, Christian Grün <christian.gruen at 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 at 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