;) 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.gr...@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.a...@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.a...@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.gr...@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.a...@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.gr...@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.a...@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 > >>> > > >>> > > >> > >> > > >
