Bug (?) - trailing whitespace in text nodes

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: > > <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> > > > [Note the blanks between xxx and <emphasis>.] > > 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: > > <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> > > 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

> Dear BaseX team, > > I think I observed a bug concerning trailing whitespace in text nodes. > > Please consider this input document: > > <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> > > [Note the blanks between xxx and <emphasis>.] > > 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: > > <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> > > 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

Dirk Kirsten <dk at basex.org> schrieb am 17:10 Donnerstag, 20.März 2014:

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: > > <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> > > > [Note the blanks between xxx and <emphasis>.] > > 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: > > <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> > > 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

Hans-Juergen Rennau <hrennau at yahoo.de> schrieb am 17:45 Donnerstag, 20.März 2014:

Dirk Kirsten <dk at basex.org> schrieb am 17:10 Donnerstag, 20.März 2014:

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: > > <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> > > > [Note the blanks between xxx and <emphasis>.] > > The result of the following "null-transformation" > > ======================= > > declare function

> 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: > > <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> > > The

> > > When transforming mixed content like docbook, this can have awkware consequences. > > Kind regards, > Hans-Jürgen > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

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 <hrennau at yahoo.de> 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: > <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> > > Using a different XQuery processor, I get this result, as expected: > <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> > > Kind regards, > Hans-Jürgen > > > > > > Dirk Kirsten <dk at basex.org> 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: >> >> <para>xxx <emphasis role="italic">abc</emphasis> yyy.</para> >> >> >> [Note the blanks between xxx and <emphasis>.] >> >> 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: >> >> <para>xxx<emphasis role="italic">abc</emphasis>yyy.</para> >> >> 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 at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >

Dirk Kirsten <dk at basex.org> schrieb am Do, 20.3.2014:

wrote: > My understanding is that it only

> > Nevertheless, I also

> > Kind regards, > Hans-Jürgen > > > > > > Hans-Juergen Rennau <hrennau at yahoo.de> schrieb am 17:45 Donnerstag, 20.März 2014: > > Dear Dirk, thank

> > But this is

> > I tried two versions: > BaseX 7.8.2 beta f505185

> BaseX 8.0 beta

> > OS is Windows 7. > > I always get this result: > <para>xxx<emphasis

> > Using a different

> <para>xxx <emphasis

> >

> Hans-Jürgen > > > > > > Dirk Kirsten <dk at basex.org> schrieb

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

want > this you might consider setting the CHOP option (see > https://docs.basex.org/wiki/Options#CHOP)

> >

> Dirk > > > On 20/03/14 16:57, Hans-Juergen Rennau wrote: >> Dear

>> >> I think I observed a bug concerning

>> >> Please

>> >> <para>xxx <emphasis

>> >> >> [Note the

>> >> The result of

>> >>

>> >> declare function > local:edit($n as node()) >> as node()? { >> typeswitch($n) >> case document-node() return >> document {for $c in

>>

>>

>>

local:edit($ac)} >> default

>> }; >> local:edit(.) >>

>> >> should be identical, but what I get is

>> >>

>> >> The > blanks after "xxx" are

>> >> >> When transforming mixed content like

>> >> Kind

>> Hans-Jürgen >> >> >> >>

>> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >

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

> basex -wi input.xml .

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

Christian Grün <christian.gruen at gmail.com> schrieb am Do, 20.3.2014:

> "Chops all leading

> > The text

> basex -wi input.xml .

>

> 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 <christian.gruen at gmail.com> schrieb am Do, 20.3.2014: > > Betreff: Re: [basex-talk] Bug (?) - trailing whitespace in text nodes > An: "Hans-Juergen Rennau" <hrennau at yahoo.de> > CC: "basex-talk at mailman.uni-konstanz.de" <basex-talk at mailman.uni-konstanz.de>, "Dirk Kirsten" <dk at basex.org> > 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 . > <para>xxx <emphasis > role="italic">abc</emphasis> > yyy.</para> > > ...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

On Thu, Mar 20, 2014 at 11:15 PM, Christian Grün <christian.gruen at gmail.com> wrote: >> 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 <christian.gruen at gmail.com> schrieb am Do, 20.3.2014: >> >> Betreff: Re: [basex-talk] Bug (?) - trailing whitespace in text nodes >> An: "Hans-Juergen Rennau" <hrennau at yahoo.de> >> CC: "basex-talk at mailman.uni-konstanz.de" <basex-talk at mailman.uni-konstanz.de>, "Dirk Kirsten" <dk at basex.org> >> 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 . >> <para>xxx <emphasis >> role="italic">abc</emphasis> >> yyy.</para> >> >> ...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