Hi, It seems that in restxq mode relative paths for *declare base-uri* are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at 'mod2.xqm';) ---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at 'mod2.xqm';) ---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing tax". I am thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have *declare base-uri "../../app";*
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at 'mod2.xqm';) ---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
My motivation is to find a restxq config that avoids the "parsing tax".
Did you already try to move all non-restxq modules into the repository? That's what we usually do.
Pre-compilation will fix various of the problems, too (but this is still on our list, and non-trivial..).
Christian
On Mon, Jun 16, 2014 at 5:04 PM, Andy Bunce bunce.andy@gmail.com wrote:
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing tax". I am thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have declare base-uri "../../app";
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at 'mod2.xqm';) ---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
Did you already try to move all non-restxq modules into the repository?
I am sure that works but it does not seem the right use of the repository to me, particularly if those modules start to reference other non xqm files.
/Andy
On 16 June 2014 16:07, Christian Grün christian.gruen@gmail.com wrote:
My motivation is to find a restxq config that avoids the "parsing tax".
Did you already try to move all non-restxq modules into the repository? That's what we usually do.
Pre-compilation will fix various of the problems, too (but this is still on our list, and non-trivial..).
Christian
On Mon, Jun 16, 2014 at 5:04 PM, Andy Bunce bunce.andy@gmail.com wrote:
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing tax".
I am
thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have declare base-uri "../../app";
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com
wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at
'mod2.xqm';)
---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
I hesitate to suggest this given the recent thread about xquery file extensions :-), but an alternative solution to this might be to expose the extensions used for by restxq scan as a config option. I guess this currently is *.xqm *.xq. If I could set this to, for example, *.xqa, for "xquery active" or "xquery annotated", then the problem would go away.
/Andy
On 16 June 2014 16:21, Andy Bunce bunce.andy@gmail.com wrote:
Did you already try to move all non-restxq modules into the repository?
I am sure that works but it does not seem the right use of the repository to me, particularly if those modules start to reference other non xqm files.
/Andy
On 16 June 2014 16:07, Christian Grün christian.gruen@gmail.com wrote:
My motivation is to find a restxq config that avoids the "parsing tax".
Did you already try to move all non-restxq modules into the repository? That's what we usually do.
Pre-compilation will fix various of the problems, too (but this is still on our list, and non-trivial..).
Christian
On Mon, Jun 16, 2014 at 5:04 PM, Andy Bunce bunce.andy@gmail.com wrote:
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing tax".
I am
thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have declare base-uri "../../app";
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com
wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com
wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at
'mod2.xqm';)
---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and
it
works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
;) What about adding a .tmp extension to temporarily inactive files?
On Tue, Jun 17, 2014 at 12:13 AM, Andy Bunce bunce.andy@gmail.com wrote:
I hesitate to suggest this given the recent thread about xquery file extensions :-), but an alternative solution to this might be to expose the extensions used for by restxq scan as a config option. I guess this currently is *.xqm *.xq. If I could set this to, for example, *.xqa, for "xquery active" or "xquery annotated", then the problem would go away.
/Andy
On 16 June 2014 16:21, Andy Bunce bunce.andy@gmail.com wrote:
Did you already try to move all non-restxq modules into the repository?
I am sure that works but it does not seem the right use of the repository to me, particularly if those modules start to reference other non xqm files.
/Andy
On 16 June 2014 16:07, Christian Grün christian.gruen@gmail.com wrote:
My motivation is to find a restxq config that avoids the "parsing tax".
Did you already try to move all non-restxq modules into the repository? That's what we usually do.
Pre-compilation will fix various of the problems, too (but this is still on our list, and non-trivial..).
Christian
On Mon, Jun 16, 2014 at 5:04 PM, Andy Bunce bunce.andy@gmail.com wrote:
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing tax". I am thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have declare base-uri "../../app";
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to the location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com wrote:
Hi, It seems that in restxq mode relative paths for declare base-uri are resolved differently [1]. If I have
-webapp --folder1 ---mod1.xqm (which has import module namespace xm='test' at 'mod2.xqm';) ---mod2.xqm The import works. If I add declare base-uri "."; to mod1. the import fails, running the same code not via restxq and it works. Is this intended behavior? /Andy
[1] http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
;) There is something special about RESTXQ files in that they have an effect on the system behavior beyond just being available for potential execution. And one could imagine extending this to other areas where by other annotations hook in to system functions e.g. CRONXQ, EVENTXQ. Why not an extension rather than a location to flag up this behavior. /Andy
On 16 June 2014 23:19, Christian Grün christian.gruen@gmail.com wrote:
;) What about adding a .tmp extension to temporarily inactive files?
On Tue, Jun 17, 2014 at 12:13 AM, Andy Bunce bunce.andy@gmail.com wrote:
I hesitate to suggest this given the recent thread about xquery file extensions :-), but an alternative solution to this might be to expose
the
extensions used for by restxq scan as a config option. I guess this currently is *.xqm *.xq. If I could set this to, for example, *.xqa, for "xquery active" or "xquery annotated", then the problem would go away.
/Andy
On 16 June 2014 16:21, Andy Bunce bunce.andy@gmail.com wrote:
Did you already try to move all non-restxq modules into the repository?
I am sure that works but it does not seem the right use of the
repository
to me, particularly if those modules start to reference other non xqm
files.
/Andy
On 16 June 2014 16:07, Christian Grün christian.gruen@gmail.com
wrote:
My motivation is to find a restxq config that avoids the "parsing
tax".
Did you already try to move all non-restxq modules into the repository? That's what we usually do.
Pre-compilation will fix various of the problems, too (but this is still on our list, and non-trivial..).
Christian
On Mon, Jun 16, 2014 at 5:04 PM, Andy Bunce bunce.andy@gmail.com
wrote:
Thanks, I will give it a go. My motivation is to find a restxq config that avoids the "parsing
tax".
I am thinking of trying setting RESTXQPATH to restxq. Then using this structure: webapp -app1 --mod2.xqm
-restxq --app1 ---restmod1.xqm
-static --app1 ---index.html
Where restxq/app/restmod1.xqm etc all have declare base-uri "../../app";
Unless there is another imminent solution to this in the works :-)?
/Andy
On 16 June 2014 14:14, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy,
I agree that relative base-uri declarations should always refer to
the
location of the current query file, no matter in which context. This should be fixed in the latest snapshot [1].
Thanks, Christian
On Sun, Jun 15, 2014 at 12:25 AM, Andy Bunce bunce.andy@gmail.com wrote: > Hi, > It seems that in restxq mode relative paths for declare base-uri
are
> resolved differently [1]. If I have > > -webapp > --folder1 > ---mod1.xqm (which has import module namespace xm='test' at > 'mod2.xqm';) > ---mod2.xqm > The import works. If I add > declare base-uri "."; > to mod1. the import fails, running the same code not via restxq
and
> it > works. > Is this intended behavior? > /Andy > > [1] >
http://www.w3.org/TR/2014/REC-xquery-30-20140408/#id-base-uri-decl
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün