Re: [basex-talk] Optimizing Element Access By Attribute Value Matching
Happy to know it can be done. I will definitely ping you when the project turns commercial.
[basex-talk] Simple xQuery functions do not work as expected
I think the issue is not of great relevance. Up to now, I hadn't the issue when working programmatically, so it appears to be a GUI problem which probably could be solved be assigning more memory to the runtime. I did not try this out. However, I can see that I'm quite often in the red region of memory consumption after a having worked with it a while. I'm going to start a larger batch these days crunching through several gigs of data. If this problem arises there I'll let you know. Kind regards, Goetz
[basex-talk] Distributing queries to several on several processors
So far I did not find any information on how BaseX can be advised how to use computing resources. The use case here is as follows: I get several megabytes of xml files each day, usually between 50 and 100 MB. These are organized in one database per day. Since most queries run on a daily base this works perfectly fine. However, there are situations when I need to run a query over a larger time span, say three or six months. (Note that I'm speaking of read-only queries here, not of transactions.) Of course I can do this in a loop (for $db in $db-list) but since the data in each database is completely independent from that in the other databases it would make perfect sense to parallelize the query. Is there a way to achieve this using xQuery? I'm aware of the possibility to split the sequence into several ones and run them in different threads on different connections using Java, for instance. But even then I still don't know what the server does (my queries run in a client-server configuration): will it occupy just one processor, or will it distribute the workload?
[basex-talk] Simple xQuery functions do not work as expected
Hi Christian, nice tip - I did not know this. With BaseX I'm really a newbie, and I just try to get my work done. As to now, it's a very nice experience, and BaseX supports many of the requirements I have. I'll give it a try and let you know! Kind regards
[basex-talk] Creation of Full-Text-Index failed
For the task at hand I need to create a database on a daily base from file packages I received. The language taken here is German, however the files contain lots of international characters as well. Usually this does not harm, and I don't know if this is the real cause of failure in this case. Actually, the database was created, but an error message occurred which was not very specific: file xxx could not be parsed. File xxx was the last file of the package, and it was accessible for xQuery search. However, no full-text index was created as with the other packages. Trying to create the index directly resulted in a different message: Improper use? . Stack Trace: java.lang.ArrayIndexOutOfBoundsException. The package can be downloaded from http://www.hellerim.de/downloads/BaseX/20150203_023.7z. This does not look like a problem with the data but rather like a bug in BaseX. If I'm wrong, however, I would prefer to get a message which points me to the problem so I can try to solve it. Kind regards, Goetz
Re: [basex-talk] RESTXQ accept/produces issue
Hi Marc,
I remember this issue has been discussed before (I just cannot find
any online reference).
I agree that the produces annotation should be ignored if no Accept
header is given.. Which version have you been using? Does it occur
with the latest snapshot?
Thanks in advance,
Christian
On Tue, Apr 21, 2015 at 2:05 PM, Marc van Grootel
marc.van.groo...@gmail.com wrote:
Hi,
I spend a couple of hours pulling my hair before I realized what was
going on here.
Question: what happens when I call a RESTXQ function which has a
rest:produces('application/xml') annotation but the request does not
have a Accept header?
This is what HTTP 1.1 spec[1] says about that:
If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is present,
and if the server cannot send a response which is acceptable according
to the combined Accept field value, then the server SHOULD send a 406
(not acceptable) response.
In fact, what does happen is that you get a 404, and this is caused by
the rest:produces annotation. In a REST call you do not always set or
have the option to set an appropriate accept header (e.g. HTTP client
libraries or when doing doc('http://.') call from XSLT).
I believe that when no Accept header is present the response should
assume that any mediatype is ok. Additionally it would be nice for
REST clients if in case the path matches but the content-negotiation
fails that a 406 would be returned instead of a 404. The latter is
saying the resource does not exist, whereas 406 expresses that the
issue is with the media-type but the resource may exist.
Quite possibly the text in the RESTXQ spec has to be modified as well
in that case because it currentlly reads (consistent with current
behaviour):
If the %rest:produces annotation is specified, a function will
only be invoked if the HTTP Accept header of the request matches one
of the given types.
Would it be possible to get this changed? Or is it maybe better to
take this up in another forum?
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
[2]
http://exquery.github.io/exquery/exquery-restxq-specification/restxq-1.0-specification.html#produces-annotation
--Marc
Re: [basex-talk] Basex xquery import module classpath lookup
Hi Karel, this is because the URI resolver is specific to query processing, whereas the Context references all kind of information relevant to storage, user management etc. If you look at Saxon, for example, you will see that the correspondent function is also located in a more specific class (QueryCompiler). Do you think that the reasoning makes sense? Christian On Tue, Apr 21, 2015 at 5:06 PM, Karel Hovorka karel.hovo...@semantico.com wrote: Hi Christian, thank you for checking my pull request and considering it. I am not sure if I understand the change. Why did you decide not to attach it to the global context? I thought that is exactly the place for it to be and URIResolver will then work globally for current database context. Karel On 21/04/2015 15:46, Christian Grün wrote: Hi Karel, I have integrated a variant of your proposal; a new snapshot is available [1]. As you will see in the example in the unit test [2], I decided not to attach the URI resolver to the global database context (Context.java), but to the QueryProcessor. As a result, the URI resolver won't be available when using the LocalSession API. Your feedback is welcome, Christian [1] http://files.basex.org/releases/latest [2] https://github.com/BaseXdb/basex/blob/8.2/basex-core/src/test/java/org/basex/query/ModuleTest.java#L92 On Mon, Apr 20, 2015 at 5:05 PM, Karel Hovorka karel.hovo...@semantico.com wrote: Hi Christian, I submited pull request with example, that works fine for me. It is still just an example far from final submit. I decided to put resolver logic call in StaticContext and to use Context only as container for the information, because StaticContext uses some properties that are used for default resolution (baseUri). Not sure, if StaticContext.io should be replaced in other 2 locations in QueryParser (ftMatchOption, ftThesaurusID). Let me know what you think. Karel On 17/04/2015 16:59, Karel Hovorka wrote: Not at all, thanks for all your help. Sure thing, I will see what I can do and try to push my proposition. Karel On 17/04/2015 15:54, Christian Grün wrote: Hi Karel, How do you propose we continue? Do you have more specific idea how to implement it to core? Maybe you could a build a solution that works for you, and I'll look at it? Ideally, it shouldn't break any of the existing JUnit tests.. Sorry for giving only a few pieces of advice; I'll look at it if I have more time! Christian In meanwhile I was thinking of pushing very simple incomplete test, that would just execute 2 simple xquery files from classpath (where 1 is module being imported from 2nd). Incomplete part would be of course the url resolving mechanism part. Karel Right! Christian P.S. Sorry for double send, I forgot to reply all first time. On 15/04/2015 14:15, Karel Hovorka wrote: Thanks for the reply. I agree. It definitely should be one api both for LocalSession and ClientSession, otherwise it wouldn't be really helpful. I made example like this, because I saw, that both ClientSession and LocalSession accept Concept class as constructor parameter (even though not all ClientSession constructors require it). I will checkout master and see if I get any ideas about how to integrate it to current codebase. Karel On 15/04/2015 12:25, Christian Grün wrote: Hi Karel, I thought I'll wait for some more time; maybe Johan has a suggestion as well? To anticipate my first thoughts: As we want to keep the LocalSession and ClientSession implementations identical in terms of functionality, I believe it will get difficult to bind arbitrary Java code to a URI resolver. It may easier be possible if you work with the QueryProcessor class, but, still, I'm not sure about all the implications. But it was already helpful to see how you would like to see the feature integrated. Is there anything else I can do to help? Thanks for asking. This is the code that's currently called when resolving module imports: https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/basex/query/util/pkg/ModuleLoader.java#L70-L134 If you have some time left, I invite you to check out our sources, play around with the code and, optionally, send us a little pull request that demonstrates your ideas. The basex-core package works without any dependencies, but just ask if you need help. Cheers, Christian On Wed, Apr 15, 2015 at 1:11 PM, Karel Hovorka karel.hovo...@semantico.com wrote: Karel On 13/04/2015 10:15, Karel Hovorka wrote: Hello Johan and Christian, this is the simpliest snippet, that I am using to run xquery (without giving it any input xml): System.setProperty(org.basex.QUERYPATH, “/workspace/project/src/main/resources/xquery/); Context context = new Context(); LocalSession session = new LocalSession(context); session.setOutputStream(System.out); String xq =
Re: [basex-talk] Basex xquery import module classpath lookup
Hi Karel,
I have integrated a variant of your proposal; a new snapshot is available [1].
As you will see in the example in the unit test [2], I decided not to
attach the URI resolver to the global database context (Context.java),
but to the QueryProcessor. As a result, the URI resolver won't be
available when using the LocalSession API.
Your feedback is welcome,
Christian
[1] http://files.basex.org/releases/latest
[2]
https://github.com/BaseXdb/basex/blob/8.2/basex-core/src/test/java/org/basex/query/ModuleTest.java#L92
On Mon, Apr 20, 2015 at 5:05 PM, Karel Hovorka
karel.hovo...@semantico.com wrote:
Hi Christian,
I submited pull request with example, that works fine for me.
It is still just an example far from final submit.
I decided to put resolver logic call in StaticContext and to use Context
only as container for the information, because StaticContext uses some
properties that are used for default resolution (baseUri). Not sure, if
StaticContext.io should be replaced in other 2 locations in QueryParser
(ftMatchOption, ftThesaurusID).
Let me know what you think.
Karel
On 17/04/2015 16:59, Karel Hovorka wrote:
Not at all, thanks for all your help.
Sure thing, I will see what I can do and try to push my proposition.
Karel
On 17/04/2015 15:54, Christian Grün wrote:
Hi Karel,
How do you propose we continue? Do you have more specific idea how to
implement it to core?
Maybe you could a build a solution that works for you, and I'll look
at it? Ideally, it shouldn't break any of the existing JUnit tests..
Sorry for giving only a few pieces of advice; I'll look at it if I
have more time!
Christian
In meanwhile I was thinking of pushing very simple incomplete test, that
would just execute 2 simple xquery files from classpath (where 1 is module
being imported from 2nd). Incomplete part would be of course the url
resolving mechanism part.
Karel
Right!
Christian
P.S. Sorry for double send, I forgot to reply all first time.
On 15/04/2015 14:15, Karel Hovorka wrote:
Thanks for the reply.
I agree. It definitely should be one api both for LocalSession and
ClientSession, otherwise it wouldn't be really helpful.
I made example like this, because I saw, that both ClientSession and
LocalSession accept Concept class as constructor parameter (even though
not
all ClientSession constructors require it).
I will checkout master and see if I get any ideas about how to integrate
it
to current codebase.
Karel
On 15/04/2015 12:25, Christian Grün wrote:
Hi Karel,
I thought I'll wait for some more time; maybe Johan has a suggestion as
well?
To anticipate my first thoughts:
As we want to keep the LocalSession and ClientSession implementations
identical in terms of functionality, I believe it will get difficult
to bind arbitrary Java code to a URI resolver. It may easier be
possible if you work with the QueryProcessor class, but, still, I'm
not sure about all the implications.
But it was already helpful to see how you would like to see the
feature integrated.
Is there anything else I can do to help?
Thanks for asking. This is the code that's currently called when
resolving module imports:
https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/basex/query/util/pkg/ModuleLoader.java#L70-L134
If you have some time left, I invite you to check out our sources,
play around with the code and, optionally, send us a little pull
request that demonstrates your ideas. The basex-core package works
without any dependencies, but just ask if you need help.
Cheers,
Christian
On Wed, Apr 15, 2015 at 1:11 PM, Karel Hovorka
karel.hovo...@semantico.com wrote:
Karel
On 13/04/2015 10:15, Karel Hovorka wrote:
Hello Johan and Christian,
this is the simpliest snippet, that I am using to run xquery (without
giving it any input xml):
System.setProperty(org.basex.QUERYPATH,
“/workspace/project/src/main/resources/xquery/);
Context context = new Context();
LocalSession session = new LocalSession(context);
session.setOutputStream(System.out);
String xq =
IOUtils.toString(getClass().getResourceAsStream(/xquery/test.xq),
StandardCharsets.UTF_8);
LocalQuery query = session.query(xq);
query.next();
As you can see, I am setting QUERYPATH and looking files on filesystem,
where they are in the project, which works fine for development, but
cannot
work in production, because files will be in jar or war.
I would imagine this snipped to be changed to something like this:
//System.setProperty(org.basex.QUERYPATH,
“/workspace/project/src/main/resources/xquery/);
Context context = new Context();
context.setURIResolver(new DefaultURIResolver() {
//Signature same as org.basex.io.IO.get
public IO resolve(String resource) {
InputStream in =
Re: [basex-talk] Strange bug ? testing the db:path of a non-stored database node
The bug has been fixed in the latest snapshot [1]. You'll now get an empty string instead (caused by the facts that the in-memory database node neither has a document node nor has a path that could be referenced). Thanks, Christian [1] http://files.basex.org/releases/latest On Tue, Apr 21, 2015 at 4:27 PM, Christian Grün christian.gr...@gmail.com wrote: Thanks for the stack trace. Obviously, db:path() shouldn't trigger an error. Instead, I guess it should return an empty string. I'll check this out. On Tue, Apr 21, 2015 at 4:23 PM, cmarch...@oxiane.com wrote: Hello, I have this error. According to http://docs.basex.org/wiki/Database_Module#Database_Nodes, I thought modify() was transforming a node to a database node It seems it does not initialize a document name... Best regards, Christophe Error: Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.1 Java: Oracle Corporation, 1.8.0_31 OS: Windows 7, amd64 Stack Trace: java.lang.NullPointerException at org.basex.query.value.item.Str.get(Str.java:49) at org.basex.query.func.db.DbPath.item(DbPath.java:23) at org.basex.query.expr.ParseExpr.value(ParseExpr.java:64) at org.basex.query.QueryContext.value(QueryContext.java:415) at org.basex.query.up.expr.Transform.value(Transform.java:91) at org.basex.query.up.expr.Transform.iter(Transform.java:59) at org.basex.query.up.expr.Transform.iter(Transform.java:25) at org.basex.query.MainModule.iter(MainModule.java:114) at org.basex.query.QueryContext.iter(QueryContext.java:343) at org.basex.query.QueryContext.execute(QueryContext.java:605) at org.basex.query.QueryProcessor.execute(QueryProcessor.java:98) at org.basex.core.cmd.AQuery.query(AQuery.java:83) at org.basex.core.cmd.XQuery.run(XQuery.java:22) at org.basex.core.Command.run(Command.java:379) at org.basex.core.Command.execute(Command.java:95) at org.basex.gui.GUI.exec(GUI.java:466) at org.basex.gui.GUI.access$400(GUI.java:41) at org.basex.gui.GUI$7.run(GUI.java:410) Query: copy $c := test/ modify () return db:path($c) Query plan: QueryPlan compiled=true Transform Let Var name=$c id=0 as=node()/ CElem QNm value=test type=xs:QName/ /CElem /Let Empty size=0/ DbPath name=path(node) VarRef Var name=$c id=0 as=node()/ /VarRef /DbPath /Transform /QueryPlan
Re: [basex-talk] Strange bug ? testing the db:path of a non-stored database node
Thanks for the stack trace. Obviously, db:path() shouldn't trigger an error. Instead, I guess it should return an empty string. I'll check this out. On Tue, Apr 21, 2015 at 4:23 PM, cmarch...@oxiane.com wrote: Hello, I have this error. According to http://docs.basex.org/wiki/Database_Module#Database_Nodes, I thought modify() was transforming a node to a database node It seems it does not initialize a document name... Best regards, Christophe Error: Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.1 Java: Oracle Corporation, 1.8.0_31 OS: Windows 7, amd64 Stack Trace: java.lang.NullPointerException at org.basex.query.value.item.Str.get(Str.java:49) at org.basex.query.func.db.DbPath.item(DbPath.java:23) at org.basex.query.expr.ParseExpr.value(ParseExpr.java:64) at org.basex.query.QueryContext.value(QueryContext.java:415) at org.basex.query.up.expr.Transform.value(Transform.java:91) at org.basex.query.up.expr.Transform.iter(Transform.java:59) at org.basex.query.up.expr.Transform.iter(Transform.java:25) at org.basex.query.MainModule.iter(MainModule.java:114) at org.basex.query.QueryContext.iter(QueryContext.java:343) at org.basex.query.QueryContext.execute(QueryContext.java:605) at org.basex.query.QueryProcessor.execute(QueryProcessor.java:98) at org.basex.core.cmd.AQuery.query(AQuery.java:83) at org.basex.core.cmd.XQuery.run(XQuery.java:22) at org.basex.core.Command.run(Command.java:379) at org.basex.core.Command.execute(Command.java:95) at org.basex.gui.GUI.exec(GUI.java:466) at org.basex.gui.GUI.access$400(GUI.java:41) at org.basex.gui.GUI$7.run(GUI.java:410) Query: copy $c := test/ modify () return db:path($c) Query plan: QueryPlan compiled=true Transform Let Var name=$c id=0 as=node()/ CElem QNm value=test type=xs:QName/ /CElem /Let Empty size=0/ DbPath name=path(node) VarRef Var name=$c id=0 as=node()/ /VarRef /DbPath /Transform /QueryPlan
[basex-talk] Strange bug ? testing the db:path of a non-stored database node
Hello, I have this error. According to http://docs.basex.org/wiki/Database_Module#Database_Nodes, I thought modify() was transforming a node to a database node It seems it does not initialize a document name... Best regards, Christophe Error: Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.1 Java: Oracle Corporation, 1.8.0_31 OS: Windows 7, amd64 Stack Trace: java.lang.NullPointerException at org.basex.query.value.item.Str.get(Str.java:49) at org.basex.query.func.db.DbPath.item(DbPath.java:23) at org.basex.query.expr.ParseExpr.value(ParseExpr.java:64) at org.basex.query.QueryContext.value(QueryContext.java:415) at org.basex.query.up.expr.Transform.value(Transform.java:91) at org.basex.query.up.expr.Transform.iter(Transform.java:59) at org.basex.query.up.expr.Transform.iter(Transform.java:25) at org.basex.query.MainModule.iter(MainModule.java:114) at org.basex.query.QueryContext.iter(QueryContext.java:343) at org.basex.query.QueryContext.execute(QueryContext.java:605) at org.basex.query.QueryProcessor.execute(QueryProcessor.java:98) at org.basex.core.cmd.AQuery.query(AQuery.java:83) at org.basex.core.cmd.XQuery.run(XQuery.java:22) at org.basex.core.Command.run(Command.java:379) at org.basex.core.Command.execute(Command.java:95) at org.basex.gui.GUI.exec(GUI.java:466) at org.basex.gui.GUI.access$400(GUI.java:41) at org.basex.gui.GUI$7.run(GUI.java:410) Query: copy $c := test/ modify () return db:path($c) Query plan: QueryPlan compiled=true Transform Let Var name=$c id=0 as=node()/ CElem QNm value=test type=xs:QName/ /CElem /Let Empty size=0/ DbPath name=path(node) VarRef Var name=$c id=0 as=node()/ /VarRef /DbPath /Transform /QueryPlan
Re: [basex-talk] Optimizing Element Access By Attribute Value Matching
Hi France, I guess we won't be able to spend time for this unless we don't have a commercial project within sight. However, I have created a new DITA wish list [1] to collect features that DITA users miss most in BaseX. All your feedback is welcome! Christian [1] https://github.com/BaseXdb/basex/issues/1130 On Tue, Apr 21, 2015 at 4:00 PM, France Baril france.ba...@architextus.com wrote: Chirstian, I'm also starting to a few DITA projects with BaseX that use attributes for matches. Other projects were DITA-like and did not need to match attribute tokens in @class. There is a big and growing DITA community out there who need native XML database support, I think it might be interesting to include indexing attribute tokens in the roadmap at some point, even if only as a longer term items. This is a very important aspect of the DITA standard. HTML classes also use tokens more and more. So that's not just relevant to the DITA community. Regards, France On Mon, Apr 13, 2015 at 2:50 PM, Liam R. E. Quin l...@w3.org wrote: On Mon, 2015-04-13 at 12:38 -0500, Eliot Kimber wrote: For large repositories an XQuery like //*[contains(@class, ' topic/topic ')] is going to be quite slow I took this use case to the XQuery XSLT Working Groups a year or two ago (Jirka added the DITA case - I was thinking of (X)HTML) and the result was contains-token() which might be easier for the database to optimize. Judging by comments submitted against my awful tests for it :) I think BaseX may well support it already. Liam -- France Baril Architecte documentaire / Documentation architect france.ba...@architextus.com
Re: [basex-talk] IllegalMonitorStateException at org.basex.core.locks.DBLocking
Thanks for the example. I'm busy right now, but I will give you feedback soon.
On Mon, Apr 20, 2015 at 1:44 PM, Simon Chatelain schat...@gmail.com wrote:
Hello,
One more detail: if in the unsetLockIfUnused() method in the DBLocking
class, I put the locks.remove(object) call in a synchronized(locks){} block,
the problem does not appear any more, but as I don't understand exactly what
the problem is, I am not sure if it really solves it or if it just change
the timing a little bit making the problem less likely to happen.
Regards
Simon
Hello Christian,
After some testing on my side, I didn't see the
ConcurrentModificationException any more.
That's the good news.
However, when running a slightly modified version of the small test case
you wrote from my sample application, I faced another problem.
The test can run for a few seconds to almost an hour but eventually, the
following exception is thrown.
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryRelease(ReentrantReadWriteLock.java:374)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1260)
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.unlock(ReentrantReadWriteLock.java:1131)
at org.basex.core.locks.DBLocking.release(DBLocking.java:215)
at org.basex.core.Context.unregister(Context.java:287)
at org.basex.core.Command.execute(Command.java:105)
at org.basex.api.client.LocalSession.execute(LocalSession.java:132)
at org.basex.api.client.Session.execute(Session.java:36)
at basextest.BaseXTestDBLocking$1.run(BaseXTestDBLocking.java:43)
I attach my new test case (BaseXTestAdd.java), but the main modification
is that in each created thread I also add documents to the collections
instead of only opening it.
I was also able to see that in the call to getOrCreateLock() in
DBLocking#release(final Proc pr) (line 212) the lock is created while it
should already be in the locks Map, but I really cannot understand how this
is possible. It would mean that the lock was removed by another thread but
for that the usage value must be wrong in the lockUsage map, and I cannot
find any sequence of operation that could lead to such a situation.
Trying to pin-point more precisely the problem, I wrote another test
(BaseXTestDBLocking.java) that calls directly the acquire and release
methods of the DBLocking class. The problem seems to happen more quickly
with this test.
Any thoughts ?
Regards
Simon
[basex-talk] RESTXQ accept/produces issue
Hi,
I spend a couple of hours pulling my hair before I realized what was
going on here.
Question: what happens when I call a RESTXQ function which has a
rest:produces('application/xml') annotation but the request does not
have a Accept header?
This is what HTTP 1.1 spec[1] says about that:
If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is present,
and if the server cannot send a response which is acceptable according
to the combined Accept field value, then the server SHOULD send a 406
(not acceptable) response.
In fact, what does happen is that you get a 404, and this is caused by
the rest:produces annotation. In a REST call you do not always set or
have the option to set an appropriate accept header (e.g. HTTP client
libraries or when doing doc('http://.') call from XSLT).
I believe that when no Accept header is present the response should
assume that any mediatype is ok. Additionally it would be nice for
REST clients if in case the path matches but the content-negotiation
fails that a 406 would be returned instead of a 404. The latter is
saying the resource does not exist, whereas 406 expresses that the
issue is with the media-type but the resource may exist.
Quite possibly the text in the RESTXQ spec has to be modified as well
in that case because it currentlly reads (consistent with current
behaviour):
If the %rest:produces annotation is specified, a function will
only be invoked if the HTTP Accept header of the request matches one
of the given types.
Would it be possible to get this changed? Or is it maybe better to
take this up in another forum?
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
[2]
http://exquery.github.io/exquery/exquery-restxq-specification/restxq-1.0-specification.html#produces-annotation
--Marc
[basex-talk] Creation of Full-Text-Index failed
Addendum: This is an issue with German language only. Indexing with all other languages work as expected given there is enough RAM available to the JVM (sometimes the error messages issued are somewhat strange when they report negative array indexes in case of insufficient memory). Meanwhile I found two other packages exhibiting the same problem. The Java Batch runs on a Windows 8 Box with Base 8.1.1 and Java 1.8.0_40_b25 installed in client-server mode.
