Re: [basex-talk] restriction on number of namespaces has apparently been lifted – thank you
As Christian has pointed out in private, this limitation hasn’t been
lifted yet. I ran into it when I tried to index all the XML files on my
hard disk.
It worked for my code files yesterday because I switched to a new
computer 1 year ago, and the number of code files / namespaces in them
has not reached the critical limit yet.
So I made an issue out of it: https://github.com/BaseXdb/basex/issues/902
Gerrit
On 20.03.2014 22:54, Imsieke, Gerrit, le-tex wrote:
Today I noticed that I could actually build an index of all XSLT, XProc,
Relax NG and Schematron files on my hard disk (3316 files). I couldn’t
do that 2 years ago because the maximum number of distinct namespaces in
a DB was limited to 256 or so.
Thanks, BaseX team, for lifting this restriction!
This has already proved really useful: I knew that I wrote an XProc step
that conditionally invoked a step whose local name I remembered. The
simple XPath expression
collection('home')//*:declare-step[*:choose//*:paths]
helped me identify the two relevant files.
Since we do a lot of development in XML-syntax languages, an XML
database is really really good for structured searches on these files. I
bet you XQuery devs still use grep to query your code ;)
Gerrit
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
> HURRA! -wi fixes the problem! Thank you very much, Christian, and Dirk, too. Perfect. It's helpful to know that BaseX interprets all command-line flags from left to right.. This way, flags that have been activated for a first command/query/etc. can later be turned off again in a single basex call. Have a good evening, Christian > I had not understood that I must use -w in combination with i - what I had > tried was -i ... -w . > > Now I know how I can always avoid the problem (which tends to be necessary > when dealing with mixed content, where of course embedded markup is usually > preceded and following by whitespace.) > > Problem solved, file closed, BaseX top. > > Kind regards, > Hans-Jürgen > > Trailing remark - of course your side answer is true, I had not thought of > that: options do not render the code unportable. Thanks for the reminder! > > > Christian Grün schrieb am Do, 20.3.2014: > > Betreff: Re: [basex-talk] Bug (?) - trailing whitespace in text nodes > An: "Hans-Juergen Rennau" > CC: "basex-talk@mailman.uni-konstanz.de" > , "Dirk Kirsten" > Datum: Donnerstag, 20. März, 2014 22:38 Uhr > > Hi Hans-Jürgen, > > > "Chops all leading > and trailing whitespaces from text nodes while building a > database, and discards empty text nodes. By default, this > option is set to true, as it often reduces the database size > by up to 50%. It can also be turned off on command line via > -w." > > > > The text > states clearly that chopping affects only text nodes stored > into a database. > > Just > another indication that we continuously need to improve > our > documentation (we are looking for > volunteers!). The chop option (which > is one > of the features that we introduced at a very early stage, > but > are hard to get out again) also applies > to the -i flag which I assume > you used to > specify the input. When using -w... > > > basex -wi input.xml . > xxx role="italic">abc > yyy. > > ...I get > the correct result. > > > > (Side remark: it would be a serious issue if the prolog > option were required, as this would imply that standard > conformant behaviour could only be achieved by making the > code unportable.) > > Side > answer: The situation is not ideal, but BaseX-specific > prolog > options won't at least cause any > compatbility issues, because the > option > declaration will simply be ignored by other processors. > > How did you proceed? > Christian ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
HURRA! -wi fixes the problem! Thank you very much, Christian, and Dirk, too. I had not understood that I must use -w in combination with i - what I had tried was -i ... -w . Now I know how I can always avoid the problem (which tends to be necessary when dealing with mixed content, where of course embedded markup is usually preceded and following by whitespace.) Problem solved, file closed, BaseX top. Kind regards, Hans-Jürgen Trailing remark - of course your side answer is true, I had not thought of that: options do not render the code unportable. Thanks for the reminder! Christian Grün schrieb am Do, 20.3.2014: Betreff: Re: [basex-talk] Bug (?) - trailing whitespace in text nodes An: "Hans-Juergen Rennau" CC: "basex-talk@mailman.uni-konstanz.de" , "Dirk Kirsten" Datum: Donnerstag, 20. März, 2014 22:38 Uhr Hi Hans-Jürgen, > "Chops all leading and trailing whitespaces from text nodes while building a database, and discards empty text nodes. By default, this option is set to true, as it often reduces the database size by up to 50%. It can also be turned off on command line via -w." > > The text states clearly that chopping affects only text nodes stored into a database. Just another indication that we continuously need to improve our documentation (we are looking for volunteers!). The chop option (which is one of the features that we introduced at a very early stage, but are hard to get out again) also applies to the -i flag which I assume you used to specify the input. When using -w... > basex -wi input.xml . xxx abc yyy. ...I get the correct result. > (Side remark: it would be a serious issue if the prolog option were required, as this would imply that standard conformant behaviour could only be achieved by making the code unportable.) Side answer: The situation is not ideal, but BaseX-specific prolog options won't at least cause any compatbility issues, because the option declaration will simply be ignored by other processors. How did you proceed? Christian ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] restriction on number of namespaces has apparently been lifted – thank you
Today I noticed that I could actually build an index of all XSLT, XProc,
Relax NG and Schematron files on my hard disk (3316 files). I couldn’t
do that 2 years ago because the maximum number of distinct namespaces in
a DB was limited to 256 or so.
Thanks, BaseX team, for lifting this restriction!
This has already proved really useful: I knew that I wrote an XProc step
that conditionally invoked a step whose local name I remembered. The
simple XPath expression
collection('home')//*:declare-step[*:choose//*:paths]
helped me identify the two relevant files.
Since we do a lot of development in XML-syntax languages, an XML
database is really really good for structured searches on these files. I
bet you XQuery devs still use grep to query your code ;)
Gerrit
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] mailing list archives 403?
Hi Jesse, I got feedback from the system administration; the problem is fixed again. Best, Christian On Tue, Mar 18, 2014 at 12:47 AM, Jesse Clark wrote: > Is anybody else getting a 403 Forbidden error trying to access the mailing > list archives? > https://mailman.uni-konstanz.de/pipermail/basex-talk/ > > -Jesse > > ___ > BaseX-Talk mailing list > BaseX-Talk@mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Hi Hans-Jürgen, > "Chops all leading and trailing whitespaces from text nodes while building a > database, and discards empty text nodes. By default, this option is set to > true, as it often reduces the database size by up to 50%. It can also be > turned off on command line via -w." > > The text states clearly that chopping affects only text nodes stored into a > database. Just another indication that we continuously need to improve our documentation (we are looking for volunteers!). The chop option (which is one of the features that we introduced at a very early stage, but are hard to get out again) also applies to the -i flag which I assume you used to specify the input. When using -w... > basex -wi input.xml . xxxabc yyy. ...I get the correct result. > (Side remark: it would be a serious issue if the prolog option were required, > as this would imply that standard conformant behaviour could only be achieved > by making the code unportable.) Side answer: The situation is not ideal, but BaseX-specific prolog options won't at least cause any compatbility issues, because the option declaration will simply be ignored by other processors. How did you proceed? Christian ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] possible bug - using inline functions in unit tests
Hi Jan,
the bug seems to be fixed already in the latest snapshot [1]; could
you give it a try?
Christian
[1] http://files.basex.org/releases/latest/
On Thu, Mar 20, 2014 at 6:35 PM, Jan Techter
wrote:
> Dear basex team,
>
> running the following unit test involving a simple anonymous function
>
> declare
> %unit:test
> function local:test-inline-function() {
> let $f := function($x) {$x+1}
> return unit:assert-equals( $f(5), 6)
> };
>
> raises a java exception
>
> [exec] Improper use? Potential bug? Your feedback is welcome:
> [exec] Contact: basex-talk@mailman.uni-konstanz.de
> [exec] Version: BaseX 7.8
> [exec] Java: Oracle Corporation, 1.7.0_51
> [exec] OS: Linux, i386
> [exec] Stack Trace:
> [exec] java.lang.ClassCastException:
> org.basex.query.value.type.AtomType cannot be cast to
> org.basex.query.value.type.FuncType
> [exec] at org.basex.query.func.InlineFunc.item(InlineFunc.java:261)
> [exec] at
> org.basex.query.func.InlineFunc.value(InlineFunc.java:280)
> [exec] at org.basex.query.QueryContext.value(QueryContext.java:367)
> [exec] at org.basex.query.gflwor.Let$LetEval.next(Let.java:230)
> [exec] at org.basex.query.gflwor.GFLWOR$2.next(GFLWOR.java:73)
> [exec] at org.basex.query.iter.Iter.value(Iter.java:64)
> [exec] at org.basex.query.expr.ParseExpr.value(ParseExpr.java:71)
> [exec] at org.basex.query.QueryContext.value(QueryContext.java:367)
> [exec] at
> org.basex.query.func.StaticFunc.invValue(StaticFunc.java:203)
> [exec] at org.basex.query.func.FuncCall.invoke(FuncCall.java:96)
> [exec] at org.basex.query.func.FuncCall.value(FuncCall.java:138)
> [exec] at
> org.basex.query.func.StaticFunc.invokeValue(StaticFunc.java:215)
> [exec] at org.basex.query.util.unit.Unit.eval(Unit.java:210)
> [exec] at org.basex.query.util.unit.Unit.test(Unit.java:127)
> [exec] at org.basex.query.util.unit.Unit.test(Unit.java:51)
> [exec] at org.basex.query.func.FNUnit.test(FNUnit.java:100)
> [exec] at org.basex.query.func.FNUnit.item(FNUnit.java:40)
> [exec] at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:46)
> [exec] at org.basex.query.MainModule.iter(MainModule.java:96)
> [exec] at org.basex.query.QueryContext.iter(QueryContext.java:310)
> [exec] at
> org.basex.query.QueryProcessor.iter(QueryProcessor.java:81)
> [exec] at org.basex.core.cmd.AQuery.query(AQuery.java:89)
> [exec] at org.basex.core.cmd.XQuery.run(XQuery.java:22)
> [exec] at org.basex.core.Command.run(Command.java:329)
> [exec] at org.basex.core.Command.execute(Command.java:94)
> [exec] at
> org.basex.server.LocalSession.execute(LocalSession.java:121)
> [exec] at org.basex.server.Session.execute(Session.java:37)
> [exec] at org.basex.core.Main.execute(Main.java:146)
> [exec] at org.basex.BaseX.(BaseX.java:119)
> [exec] at org.basex.BaseX.main(BaseX.java:38)
> [exec]
>
> updating to basex 7.8.1 didnt make any difference.
> Is this a bug?
>
> Best regards.
> Jan
>
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Mm, the documentation says:
"Chops all leading and trailing whitespaces from text nodes while building a
database, and discards empty text nodes. By default, this option is set to
true, as it often reduces the database size by up to 50%. It can also be turned
off on command line via -w."
The text states clearly that chopping affects only text nodes stored into a
database.
At any rate - the problem remains, whether or not I use option -w, and whether
or not I use prolog option db:chop. (Side remark: it would be a serious issue
if the prolog option were required, as this would imply that standard
conformant behaviour could only be achieved by making the code unportable.)
Kind regards,
Hans-Juergen
Dirk Kirsten schrieb am Do, 20.3.2014:
Betreff: Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
An: "Hans-Juergen Rennau" ,
"basex-talk@mailman.uni-konstanz.de"
Datum: Donnerstag, 20. März, 2014 18:28 Uhr
Dear Hans-Jürgen,
I am not quite sure it is
intended that the CHOP option is applied to
text nodes. At least the wording in the
documentation ("while building a
database") does not indicate it, while I
think it actually does make
sense. Christian
will have to answer whether this works as is intended
behavior.
However, you can set the chop option to false
within your XQuery by
declaring it
declare option db:chop "false";
and this should also affect
reading in files from the file system. At
least this works for me.
Cheers,
Dirk
On 20/03/14 17:47, Hans-Juergen Rennau
wrote:
> My understanding is that it only
affects database documents, and I used file input.
>
> Nevertheless, I also
tried option -w, but always got the same result.
>
> Kind regards,
> Hans-Jürgen
>
>
>
>
>
> Hans-Juergen Rennau
schrieb am 17:45 Donnerstag, 20.März 2014:
>
> Dear Dirk, thank
you.
>
> But this is
strange - I ran the query using a file as input - not a
database document.
>
> I tried two versions:
> BaseX 7.8.2 beta f505185
[Standalone]
> BaseX 8.0 beta
606f18b [Standalone]
>
> OS is Windows 7.
>
> I always get this result:
> xxxabcyyy.
>
> Using a different
XQuery processor, I get this result, as expected:
> xxx abc
yyy.
>
>
Kind regards,
> Hans-Jürgen
>
>
>
>
>
> Dirk Kirsten schrieb
am 17:10 Donnerstag, 20.März 2014:
>
> Dear Hans-Jürgen,
>
> When running
local:edit() on an in-memory node I get the expected and
> correct result, including whitespaces.
>
> I guess that you run
this command on a database node and the XML
> documents were parsed with CHOP being true
(which is the default), this
> would
explain the behavior and would be as expected. If you do not
want
> this you might consider setting
the CHOP option (see
> https://docs.basex.org/wiki/Options#CHOP)
to false.
>
>
Cheers,
> Dirk
>
>
> On 20/03/14 16:57,
Hans-Juergen Rennau wrote:
>> Dear
BaseX team,
>>
>> I think I observed a bug concerning
trailing whitespace in text nodes.
>>
>> Please
consider this input document:
>>
>> xxx abc
yyy.
>>
>>
>> [Note the
blanks between xxx and .]
>>
>> The result of
the following "null-transformation"
>>
>>
===
>>
>> declare function
> local:edit($n as node())
>> as node()? {
>> typeswitch($n)
>> case document-node() return
>> document {for $c in
$n/node() return local:edit($c)}
>>
case element() return
>>
element {node-name($n)}
>>
{for $ac in $n/(@*, node()) return
local:edit($ac)}
>> default
return $n
>> };
>> local:edit(.)
>>
===
>>
>> should be identical, but what I get is
this:
>>
>>
xxxabcyyy.
>>
>> The
> blanks after "xxx" are
gone!
>>
>>
>> When transforming mixed content like
docbook, this can have awkware consequences.
>>
>> Kind
regards,
>> Hans-Jürgen
>>
>>
>>
>>
___
>> BaseX-Talk mailing list
>> BaseX-Talk@mailman.uni-konstanz.de
>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>>
>
--
Dirk
Kirsten, BaseX GmbH, http://basex.org
|--
Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285,
Geschäftsführer:
| Dr.
Christian Grün, Dr. Alexander Holupirek, Michael
Seiferle
`-- Phone: 0049 7531 28 28 676,
Fax: 0049 7531 20 05 22
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] BaseX: Upcoming Features
To put some numbers on query precompilation [3]. I have been using Apache
ab to time a very simple RESTXQ request
declare %rest:GET %rest:path("bsp/simple")
%output:method("text")
function simple() {"test"};
>ab -n 100 -c 10 http://localhost:8984/bsp/simple
I timed this when my webapp folder had a large number of unrelated, and
uncalled, RESTXQ folders and apps and I get *1.77 requests / second*. If I
remove all these, to leave just the one simple() function I get *366
requests / second*. (This later figure is not that far from what I get
serving from /static.)
/Andy
On Thu, Mar 20, 2014 at 8:49 AM, Christian Grün
wrote:
> ...noted ;) Replication is indeed one of the features that we have
> already realized (but it's not open source yet).
>
>
> On Thu, Mar 20, 2014 at 12:03 AM, Alexander Shpack
> wrote:
> > Hi Christian,
> >
> > What about redo logs and master/slave replication?
> >
> >
> >
> >
> > On Tue, Mar 18, 2014 at 2:03 PM, Christian Grün <
> christian.gr...@gmail.com>
> > wrote:
> >>
> >> Dear BaseX aficionados,
> >>
> >> An upcoming version of our software (7.9 or 8.0) will make it much
> >> easier to perform updates and return items at the same time [1]. It
> >> will also contain an xquery:update function and will bring xquery:eval
> >> and xquery:evaluate together again [2] Another exciting and
> >> sophisticated feature we are working on is query precompilation [3],
> >> which will particularly speed up large XQuery applications and allow
> >> for more request-specific optimizations.
> >>
> >> Next, we are working on a Database Administration interface based on
> >> RESTXQ, and we will also drop out the confusing client/server dialog
> >> from the GUI.
> >>
> >> Feature 1 and 2 are already available via a feature branch [4]. If you
> >> are working with the git sources, we are excited to get your feedback!
> >>
> >> Christian
> >>
> >> [1] https://github.com/BaseXdb/basex/issues/873
> >> [2] https://github.com/BaseXdb/basex/issues/878
> >> [3] https://github.com/BaseXdb/basex/issues/874
> >> [4] https://github.com/BaseXdb/basex/tree/issue873
> >> ___
> >> BaseX-Talk mailing list
> >> BaseX-Talk@mailman.uni-konstanz.de
> >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
> >
> >
> >
> >
> > --
> > s0rr0w
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] possible bug - using inline functions in unit tests
Dear basex team,
running the following unit test involving a simple anonymous function
declare
%unit:test
function local:test-inline-function() {
let $f := function($x) {$x+1}
return unit:assert-equals( $f(5), 6)
};
raises a java exception
[exec] Improper use? Potential bug? Your feedback is welcome:
[exec] Contact: basex-talk@mailman.uni-konstanz.de
[exec] Version: BaseX 7.8
[exec] Java: Oracle Corporation, 1.7.0_51
[exec] OS: Linux, i386
[exec] Stack Trace:
[exec] java.lang.ClassCastException:
org.basex.query.value.type.AtomType cannot be cast to
org.basex.query.value.type.FuncType
[exec] at
org.basex.query.func.InlineFunc.item(InlineFunc.java:261)
[exec] at
org.basex.query.func.InlineFunc.value(InlineFunc.java:280)
[exec] at
org.basex.query.QueryContext.value(QueryContext.java:367)
[exec] at org.basex.query.gflwor.Let$LetEval.next(Let.java:230)
[exec] at org.basex.query.gflwor.GFLWOR$2.next(GFLWOR.java:73)
[exec] at org.basex.query.iter.Iter.value(Iter.java:64)
[exec] at org.basex.query.expr.ParseExpr.value(ParseExpr.java:71)
[exec] at
org.basex.query.QueryContext.value(QueryContext.java:367)
[exec] at
org.basex.query.func.StaticFunc.invValue(StaticFunc.java:203)
[exec] at org.basex.query.func.FuncCall.invoke(FuncCall.java:96)
[exec] at org.basex.query.func.FuncCall.value(FuncCall.java:138)
[exec] at
org.basex.query.func.StaticFunc.invokeValue(StaticFunc.java:215)
[exec] at org.basex.query.util.unit.Unit.eval(Unit.java:210)
[exec] at org.basex.query.util.unit.Unit.test(Unit.java:127)
[exec] at org.basex.query.util.unit.Unit.test(Unit.java:51)
[exec] at org.basex.query.func.FNUnit.test(FNUnit.java:100)
[exec] at org.basex.query.func.FNUnit.item(FNUnit.java:40)
[exec] at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:46)
[exec] at org.basex.query.MainModule.iter(MainModule.java:96)
[exec] at org.basex.query.QueryContext.iter(QueryContext.java:310)
[exec] at
org.basex.query.QueryProcessor.iter(QueryProcessor.java:81)
[exec] at org.basex.core.cmd.AQuery.query(AQuery.java:89)
[exec] at org.basex.core.cmd.XQuery.run(XQuery.java:22)
[exec] at org.basex.core.Command.run(Command.java:329)
[exec] at org.basex.core.Command.execute(Command.java:94)
[exec] at
org.basex.server.LocalSession.execute(LocalSession.java:121)
[exec] at org.basex.server.Session.execute(Session.java:37)
[exec] at org.basex.core.Main.execute(Main.java:146)
[exec] at org.basex.BaseX.(BaseX.java:119)
[exec] at org.basex.BaseX.main(BaseX.java:38)
[exec]
updating to basex 7.8.1 didnt make any difference.
Is this a bug?
Best regards.
Jan
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Dear Hans-Jürgen,
I am not quite sure it is intended that the CHOP option is applied to
text nodes. At least the wording in the documentation ("while building a
database") does not indicate it, while I think it actually does make
sense. Christian will have to answer whether this works as is intended
behavior.
However, you can set the chop option to false within your XQuery by
declaring it
declare option db:chop "false";
and this should also affect reading in files from the file system. At
least this works for me.
Cheers,
Dirk
On 20/03/14 17:47, Hans-Juergen Rennau wrote:
> My understanding is that it only affects database documents, and I used file
> input.
>
> Nevertheless, I also tried option -w, but always got the same result.
>
> Kind regards,
> Hans-Jürgen
>
>
>
>
>
> Hans-Juergen Rennau schrieb am 17:45 Donnerstag, 20.März
> 2014:
>
> Dear Dirk, thank you.
>
> But this is strange - I ran the query using a file as input - not a database
> document.
>
> I tried two versions:
>BaseX 7.8.2 beta f505185 [Standalone]
>BaseX 8.0 beta 606f18b [Standalone]
>
> OS is Windows 7.
>
> I always get this result:
> xxxabcyyy.
>
> Using a different XQuery processor, I get this result, as expected:
> xxxabc yyy.
>
> Kind regards,
> Hans-Jürgen
>
>
>
>
>
> Dirk Kirsten schrieb am 17:10 Donnerstag, 20.März 2014:
>
> Dear Hans-Jürgen,
>
> When running local:edit() on an in-memory node I get the expected and
> correct result, including whitespaces.
>
> I guess that you run this command on a database node and the XML
> documents were parsed with CHOP being true (which is the default), this
> would explain the behavior and would be as expected. If you do not want
> this you might consider setting the CHOP option (see
> https://docs.basex.org/wiki/Options#CHOP) to false.
>
> Cheers,
> Dirk
>
>
> On 20/03/14 16:57, Hans-Juergen Rennau wrote:
>> Dear BaseX team,
>>
>> I think I observed a bug concerning trailing whitespace in text nodes.
>>
>> Please consider this input document:
>>
>> xxxabc yyy.
>>
>>
>> [Note the blanks between xxx and .]
>>
>> The result of the following "null-transformation"
>>
>> ===
>>
>> declare function
> local:edit($n as node())
>> as node()? {
>> typeswitch($n)
>> case document-node() return
>> document {for $c in $n/node() return local:edit($c)}
>> case element() return
>> element {node-name($n)}
>> {for $ac in $n/(@*, node()) return local:edit($ac)}
>> default return $n
>> };
>> local:edit(.)
>> ===
>>
>> should be identical, but what I get is this:
>>
>> xxxabcyyy.
>>
>> The
> blanks after "xxx" are gone!
>>
>>
>> When transforming mixed content like docbook, this can have awkware
>> consequences.
>>
>> Kind regards,
>> Hans-Jürgen
>>
>>
>>
>> ___
>> BaseX-Talk mailing list
>> BaseX-Talk@mailman.uni-konstanz.de
>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>>
>
--
Dirk Kirsten, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
| Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
My understanding is that it only affects database documents, and I used file
input.
Nevertheless, I also tried option -w, but always got the same result.
Kind regards,
Hans-Jürgen
Hans-Juergen Rennau schrieb am 17:45 Donnerstag, 20.März
2014:
Dear Dirk, thank you.
But this is strange - I ran the query using a file as input - not a database
document.
I tried two versions:
BaseX 7.8.2 beta f505185 [Standalone]
BaseX 8.0 beta 606f18b [Standalone]
OS is Windows 7.
I always get this result:
xxxabcyyy.
Using a different XQuery processor, I get this result, as expected:
xxx abc yyy.
Kind regards,
Hans-Jürgen
Dirk Kirsten schrieb am 17:10 Donnerstag, 20.März 2014:
Dear Hans-Jürgen,
When running local:edit() on an in-memory node I get the expected and
correct result, including whitespaces.
I guess that you run this command on a database node and the XML
documents were parsed with CHOP being true (which is the default), this
would explain the behavior and would be as expected. If you do not want
this you might consider setting the CHOP option (see
https://docs.basex.org/wiki/Options#CHOP) to false.
Cheers,
Dirk
On 20/03/14 16:57, Hans-Juergen Rennau wrote:
> Dear BaseX team,
>
> I think I observed a bug concerning trailing whitespace in text nodes.
>
> Please consider this input document:
>
> xxx abc yyy.
>
>
> [Note the blanks between xxx and .]
>
> The result of the following "null-transformation"
>
> ===
>
> declare function
local:edit($n as node())
> as node()? {
> typeswitch($n)
> case document-node() return
> document {for $c in $n/node() return local:edit($c)}
> case element() return
> element {node-name($n)}
> {for $ac in $n/(@*, node()) return local:edit($ac)}
> default return $n
> };
> local:edit(.)
> ===
>
> should be identical, but what I get is this:
>
> xxxabcyyy.
>
> The
blanks after "xxx" are gone!
>
>
> When transforming mixed content like docbook, this can have awkware
> consequences.
>
> Kind regards,
> Hans-Jürgen
>
>
>
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
--
Dirk Kirsten, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
| Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Dear Dirk, thank you.
But this is strange - I ran the query using a file as input - not a database
document.
I tried two versions:
BaseX 7.8.2 beta f505185 [Standalone]
BaseX 8.0 beta 606f18b [Standalone]
OS is Windows 7.
I always get this result:
xxxabcyyy.
Using a different XQuery processor, I get this result, as expected:
xxx abc yyy.
Kind regards,
Hans-Jürgen
Dirk Kirsten schrieb am 17:10 Donnerstag, 20.März 2014:
Dear Hans-Jürgen,
When running local:edit() on an in-memory node I get the expected and
correct result, including whitespaces.
I guess that you run this command on a database node and the XML
documents were parsed with CHOP being true (which is the default), this
would explain the behavior and would be as expected. If you do not want
this you might consider setting the CHOP option (see
https://docs.basex.org/wiki/Options#CHOP) to false.
Cheers,
Dirk
On 20/03/14 16:57, Hans-Juergen Rennau wrote:
> Dear BaseX team,
>
> I think I observed a bug concerning trailing whitespace in text nodes.
>
> Please consider this input document:
>
> xxx abc yyy.
>
>
> [Note the blanks between xxx and .]
>
> The result of the following "null-transformation"
>
> ===
>
> declare function local:edit($n as node())
> as node()? {
> typeswitch($n)
> case document-node() return
> document {for $c in $n/node() return local:edit($c)}
> case element() return
> element {node-name($n)}
> {for $ac in $n/(@*, node()) return local:edit($ac)}
> default return $n
> };
> local:edit(.)
> ===
>
> should be identical, but what I get is this:
>
> xxxabcyyy.
>
> The blanks after "xxx" are gone!
>
>
> When transforming mixed content like docbook, this can have awkware
> consequences.
>
> Kind regards,
> Hans-Jürgen
>
>
>
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
--
Dirk Kirsten, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
| Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Hi,
did you set the chop option?
http://docs.basex.org/wiki/Options#CHOP
Regards, Max
2014-03-20 16:57 GMT+01:00 Hans-Juergen Rennau :
> Dear BaseX team,
>
> I think I observed a bug concerning trailing whitespace in text nodes.
>
> Please consider this input document:
>
> xxxabc yyy.
>
> [Note the blanks between xxx and .]
>
> The result of the following "null-transformation"
>
> ===
> declare function local:edit($n as node())
> as node()? {
> typeswitch($n)
> case document-node() return
> document {for $c in $n/node() return local:edit($c)}
> case element() return
> element {node-name($n)}
> {for $ac in $n/(@*, node()) return local:edit($ac)}
> default return $n
> };
> local:edit(.)
> ===
>
> should be identical, but what I get is this:
>
> xxxabcyyy.
>
> The blanks after "xxx" are gone!
>
> When transforming mixed content like docbook, this can have awkware
> consequences.
>
> Kind regards,
> Hans-Jürgen
>
>
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Bug (?) - trailing whitespace in text nodes
Dear Hans-Jürgen,
When running local:edit() on an in-memory node I get the expected and
correct result, including whitespaces.
I guess that you run this command on a database node and the XML
documents were parsed with CHOP being true (which is the default), this
would explain the behavior and would be as expected. If you do not want
this you might consider setting the CHOP option (see
https://docs.basex.org/wiki/Options#CHOP) to false.
Cheers,
Dirk
On 20/03/14 16:57, Hans-Juergen Rennau wrote:
> Dear BaseX team,
>
> I think I observed a bug concerning trailing whitespace in text nodes.
>
> Please consider this input document:
>
> xxxabc yyy.
>
>
> [Note the blanks between xxx and .]
>
> The result of the following "null-transformation"
>
> ===
>
> declare function local:edit($n as node())
> as node()? {
> typeswitch($n)
> case document-node() return
> document {for $c in $n/node() return local:edit($c)}
> case element() return
> element {node-name($n)}
> {for $ac in $n/(@*, node()) return local:edit($ac)}
> default return $n
> };
> local:edit(.)
> ===
>
> should be identical, but what I get is this:
>
> xxxabcyyy.
>
> The blanks after "xxx" are gone!
>
>
> When transforming mixed content like docbook, this can have awkware
> consequences.
>
> Kind regards,
> Hans-Jürgen
>
>
>
> ___
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
--
Dirk Kirsten, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
| Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] Bug (?) - trailing whitespace in text nodes
Dear BaseX team,
I think I observed a bug concerning trailing whitespace in text nodes.
Please consider this input document:
xxx abc yyy.
[Note the blanks between xxx and .]
The result of the following "null-transformation"
===
declare function local:edit($n as node())
as node()? {
typeswitch($n)
case document-node() return
document {for $c in $n/node() return local:edit($c)}
case element() return
element {node-name($n)}
{for $ac in $n/(@*, node()) return local:edit($ac)}
default return $n
};
local:edit(.)
===
should be identical, but what I get is this:
xxxabcyyy.
The blanks after "xxx" are gone!
When transforming mixed content like docbook, this can have awkware
consequences.
Kind regards,
Hans-Jürgen___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] Question about BaseX JAVA API Usage ...
Hello Christopher, thanks for your mail and we are happy to help. I also highly appreciate that you consulted the wiki first :) I fixed the links to the BaseX examples. Indeed, we change the project structure and did not update the corresponding links, so thank you for the hint. Indeed, your problem is not that much related to BaseX. To use the BaseX API from a Java program you have to add the jar file to your project. Using eclipse you can do so by selecting your project > File > Properties > Java Build Path > Libraries > Add External JARs... and selecting the BaseX jar file, which you can download at https://basex.org/products/download/all-downloads/ (Core package) Hope that helps. Cheers, Dirk On 20/03/14 11:12, Christopher Lyons wrote: > I've just starting using BaseX (V.7.8.1) and have a very quick question > that I hope somebody can help me with. I've reviewed the BaseX docs > and tried looking for an answer to this on the Wiki but have not been > successful. > > I've installed BaseX (on Win7 Pro/64-bit) and have been using the GUI > interface (non-server) and it has been working great. I just started > exploring the JAVA API and am having a few basic problems. I'm trying to > use the RunQueries.java example file (currently just need to do some > local queries from a JAVA app). Just an FYI, the links from BaseX doc > site to the GitHub example repository are all broken. The examples are > on GitHub but it looks like they were recently moved/updated and the > links must have changed and haven't been updated on the BaseX site. > > I'm an experienced programmer but am just getting up-to-speed with JAVA, > so my question may be more related to that than a specific BaseX problem > but hopefully someone can point me in the right direction. I use > Eclipse and when I create a test class with the RunQueries.java code, > Eclipse is not able to resolve the BaseX package imports at the start of > the class. Namely, the following code: > > import org.basex.core.*; > import org.basex.core.cmd.*; > import org.basex.data.*; > import org.basex.io.serial.*; > import org.basex.query.*; > import org.basex.query.iter.*; > import org.basex.query.value.item.*; > > Should the general install of BaseX put these packages into their proper > places? Or is there something else I have to do to get these packages > properly installed and able to be resolved? > > Appreciate any help. > > Thanks, > Chris Lyons > ___ > BaseX-Talk mailing list > BaseX-Talk@mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk -- Dirk Kirsten, BaseX GmbH, http://basex.org |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] Question about BaseX JAVA API Usage ...
I've just starting using BaseX (V.7.8.1) and have a very quick question that I hope somebody can help me with. I've reviewed the BaseX docs and tried looking for an answer to this on the Wiki but have not been successful. I've installed BaseX (on Win7 Pro/64-bit) and have been using the GUI interface (non-server) and it has been working great. I just started exploring the JAVA API and am having a few basic problems. I'm trying to use the RunQueries.java example file (currently just need to do some local queries from a JAVA app). Just an FYI, the links from BaseX doc site to the GitHub example repository are all broken. The examples are on GitHub but it looks like they were recently moved/updated and the links must have changed and haven't been updated on the BaseX site. I'm an experienced programmer but am just getting up-to-speed with JAVA, so my question may be more related to that than a specific BaseX problem but hopefully someone can point me in the right direction. I use Eclipse and when I create a test class with the RunQueries.java code, Eclipse is not able to resolve the BaseX package imports at the start of the class. Namely, the following code: import org.basex.core.*; import org.basex.core.cmd.*; import org.basex.data.*; import org.basex.io.serial.*; import org.basex.query.*; import org.basex.query.iter.*; import org.basex.query.value.item.*; Should the general install of BaseX put these packages into their proper places? Or is there something else I have to do to get these packages properly installed and able to be resolved? Appreciate any help. Thanks, Chris Lyons ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[basex-talk] feature's requests and not publicly released features
Dear all, First of all, BaseX is just fantastic ! Could you please tell me if you may release the following features in near future ? 1. User defined indexes Let's consider you have to index multi lingual documents. Currently, one have to partition each document in mono-lingual documents, and add them in separate collections because there can be only one fulltext index per collection, and because all text() nodes will be indexed. Are others BaseX users interested with user defined indexes (attribute, text, and fulltext) ? Wouldn't user defined indexes dramatically improve performance (during requests, and optimization) ? 2. Break current collection limitation on the maximum number of nodes. 3. Possibility to store millions of small documents, and do efficient 'db:replaces' or 'db:delete'. Last, How does BaseX team provide non-open-source features ? Best regards, Fabrice Etanchaud Questel/Orbit ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Re: [basex-talk] BaseX: Upcoming Features
...noted ;) Replication is indeed one of the features that we have already realized (but it's not open source yet). On Thu, Mar 20, 2014 at 12:03 AM, Alexander Shpack wrote: > Hi Christian, > > What about redo logs and master/slave replication? > > > > > On Tue, Mar 18, 2014 at 2:03 PM, Christian Grün > wrote: >> >> Dear BaseX aficionados, >> >> An upcoming version of our software (7.9 or 8.0) will make it much >> easier to perform updates and return items at the same time [1]. It >> will also contain an xquery:update function and will bring xquery:eval >> and xquery:evaluate together again [2] Another exciting and >> sophisticated feature we are working on is query precompilation [3], >> which will particularly speed up large XQuery applications and allow >> for more request-specific optimizations. >> >> Next, we are working on a Database Administration interface based on >> RESTXQ, and we will also drop out the confusing client/server dialog >> from the GUI. >> >> Feature 1 and 2 are already available via a feature branch [4]. If you >> are working with the git sources, we are excited to get your feedback! >> >> Christian >> >> [1] https://github.com/BaseXdb/basex/issues/873 >> [2] https://github.com/BaseXdb/basex/issues/878 >> [3] https://github.com/BaseXdb/basex/issues/874 >> [4] https://github.com/BaseXdb/basex/tree/issue873 >> ___ >> BaseX-Talk mailing list >> BaseX-Talk@mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > > -- > s0rr0w ___ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
