whitespace around comments

> declare option db:chop 'false'; > > doc('tmp/doc.xml')

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

Am 05.04.2013 um 06:02 schrieb jidanni at jidanni.org: > Pardon me but basex 7.6 doc() function is out of control. > > $ more ib.xml z.xq|cat > :::::::::::::: > ib.xml > :::::::::::::: > <Z> > <P>There should be a space: <!-- --> :here!</P> > <P>There should be a space:<!-- --> :here!</P> > <P>There should be a space: <!-- -->:here!</P> > <P>There should be a space: <!-- --> > :here!</P> > <P>There should be a space: > <!-- --> :here!</P> > <P>There should be a space: > <!-- --> > :here!</P> > <P>There should be a space: > <!-- --> > <!-- --> > :here!</P> > <P>There should be NO SPACE:<!-- --><!-- -->:here!</P> > <P>There should be NO SPACE:<!-- -->:<!-- -->:here!</P> > </Z> > :::::::::::::: > z.xq > :::::::::::::: > doc("ib.xml") > $ basex z.xq > <Z> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- -->:here!</P> > <P>There should be a space:<!-- --> > <!-- -->:here!</P> > <P>There should be NO SPACE:<!-- --> > <!-- -->:here!</P> > <P>There should be NO SPACE:<!-- -->:<!-- -->:here!</P> > </Z>$ basex z.xq|w3m -dump -T text/html > There should be a space::here! > > There should be a space::here! > > There should be a space::here! > > There should be a space::here! > > There should be a space::here! > > There should be a space::here! > > There should be a space: :here! > > There should be NO SPACE: :here! > > There should be NO SPACE:::here! > > So it failed all but two. > The problem seems to lie in the doc() function. > > In fact if you just left what you found intact, > you wouldn't wreck people's formatting too. > You don't wreck things when processing > let $k := > <coordinates> > 120.867029,24.167269,10 <!--1 G8247 AC66--> > 120.866931,24.167630,10 <!--2 G8247 AD50--> > 120.866832,24.167901,10 <!--3 G8247 AD43--> > </coordinates> > > then why not do the same with doc()? > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

On 2013-04-05, Michael Seiferle <ms at basex.org> wrote: > As chopping does not change any semantics (at least with regards to > what XML thinks of semantically important) but only aesthetics this is > enabled by default.

On Fri, Apr 5, 2013 at 11:15 AM, Michael Piotrowski <mxp at cl.uzh.ch> wrote: > On 2013-04-05, Michael Seiferle <ms at basex.org> wrote: > > > As chopping does not change any semantics (at least with regards to > > what XML thinks of semantically important) but only aesthetics this is > > enabled by default. > > I'm sorry to disagree, but chopping certainly *does* change the > semantics--that's precisely why I've argued before that it shouldn't be > on by default. > > The problem becomes obvious with mixed content, e.g., with chopping > enabled > > <doc> > <p>Lorem ipsum <em>dolor</em> <x>sit</x> amet ...</p> > </doc> > > becomes > > <doc> > <p>Lorem ipsum<em>dolor</em><x>sit</x>amet ...</p> > </doc> > > which is *not* the same, and AFAIKT this is not conforming behavior (and > BaseX doesn't honor xml:space either). > > I do understand that whitespace chopping as currently implemented is > useful for some data-oriented applications, even if it is not > conforming, but by default, the behavior should conform to the XML > standard. > > Best regards > > -- > Dr.-Ing. Michael Piotrowski, M.A. <mxp at cl.uzh.ch> > Institute of Computational Linguistics, University of Zurich > Phone +41 44 63-54313 | OpenPGP public key ID 0x1614A044 > * OUT NOW: Natural Language Processing for Historical Texts > * <http://morganclaypool.com/doi/abs/10.2200/S00436ED1V01Y201207HLT017> > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

On 2013-04-05, Dirk Kirsten <dk at basex.org> wrote: > You are certainly right that with mixed content and the example you have > given here chopping does make a semantic difference. > However, you can disable this behaviour so BaseX does what you want. So the > only reason I see why one should change the default behaviour would be > because the default is not confirmant to some XML standard. However, I can > not find any specifics in the spec about which is the expected behaviour, > so in my opinion BaseX is doing nothing wrong here.

> I see that this behaviour might be surprising for some users, but this > might as well be the case if it were the other way round.

> Additionally, if we would change this now it would break application > code and unless there is a good reason (i.e. BaseX is actually doing > something wrong or non-compliant) I don't see why one should change > the default.

On 2013-04-05, "Michael Seiferle" <ms at basex.org> wrote: > Michael (other than me :-)) you are obviously right.

On Fri, Apr 5, 2013 at 12:29 PM, Michael Piotrowski <mxp at cl.uzh.ch> wrote: > Dirk, > On 2013-04-05, Dirk Kirsten <dk at basex.org> wrote: >> You are certainly right that with mixed content and the example you have >> given here chopping does make a semantic difference. >> However, you can disable this behaviour so BaseX does what you want. So the >> only reason I see why one should change the default behaviour would be >> because the default is not confirmant to some XML standard. However, I can >> not find any specifics in the spec about which is the expected behaviour, >> so in my opinion BaseX is doing nothing wrong here. > Well, if you agree that chopping may alter the semantics of a document, > wouldn't you agree that applying such a transformation *by default* is a > bad idea? > With respect to the XML specification, section 2.10 "White Space > Handling" says: > An XML processor MUST always pass all characters in a document that > are not markup through to the application. > Yes, the spec is vague wrt. to whitespace handling, and the existence of > the xml:space attribute shows that different behaviors--including > potentially corrupting ones--are possible. I would therefore interpret > the spec to mean that by default all characters should be preserved, but > that other behaviors are possible. >> I see that this behaviour might be surprising for some users, but this >> might as well be the case if it were the other way round. > No, because their documents wouldn't be corrupted. You can easily > remove all whitespace afterwards if you decide you don't need it, but > once it's gone, it's gone and cannot be restored. That's the problem. >> Additionally, if we would change this now it would break application >> code and unless there is a good reason (i.e. BaseX is actually doing >> something wrong or non-compliant) I don't see why one should change >> the default. > Well, I'm not on a crusade or anything, so if you believe that it's a > good idea to corrupt, by default, all documents containing mixed content > on import, or if this behavior must be kept for compatiblity, so be it. > I just wanted to point out that whitespace chopping may, in fact, alter > the semantics of documents--it's not as harmless as it may seem. > Best regards > -- > Dr.-Ing. Michael Piotrowski, M.A. <mxp at cl.uzh.ch> > Institute of Computational Linguistics, University of Zurich > Phone +41 44 63-54313 | OpenPGP public key ID 0x1614A044 > * OUT NOW: Natural Language Processing for Historical Texts > * <http://morganclaypool.com/doi/abs/10.2200/S00436ED1V01Y201207HLT017> > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> our CHOP flag is subject to frequent discussions, which is why we will > eventually change the default to FALSE.

> For now, we are still a little > bit resistant, as such a change will change the behavior of existing > BaseX applications out there, so we’ll probably combine the switch > with the next major release. > > For now, you can preserve whitespaces by e.g.. > > -- adding the line CHOP=false in your .basex configuration file > -- using the basex command-line flag -w > -- using "set chop false" as first command, or setting the options in > any other way described in our Wiki [1].

> The problem is, that you will be aware of this only AFTER you created a DB and worked with it. Unfortunately, users are not informed when creating a DB that they should think about whitespace. And there is no reason a user should assume that creating a DB would semantically change their data. [...]

On Fri, 2013-04-05 at 11:15 +0200, Michael Piotrowski wrote: > On 2013-04-05, Michael Seiferle <ms at basex.org> wrote: > chopping certainly *does* change the > semantics--that's precisely why I've argued before that it shouldn't be > on by default.

> (and > BaseX doesn't honor xml:space either).

On Fri, 2013-04-05 at 11:31 +0200, Dirk Kirsten wrote: > So if you could point out some details as why this is not conforming > behaviour, this would be interesting.

On Sat, Apr 13, 2013 at 8:28 AM, Liam R E Quin <liam at w3.org> wrote: > On Fri, 2013-04-05 at 11:31 +0200, Dirk Kirsten wrote: > >> So if you could point out some details as why this is not conforming >> behaviour, this would be interesting. > > It's a requirement in the XML Spec that the XML parser pass all > whitespace back to the application. Some whitespace may be marked as not > significant - that is only possible if there's a DTD and the space is in > a context where only elements would be valid, not #PCDATA. There's no > formal specification, although constructing an XDM instance from an > infoset, and constructing an infoset from XML, does not entail > discarding these spaces: > Chopping internal whitespace nodes in mixed content contexts is not > sanctioned by any version of any XML specification, with any setting of > xml:space. I think the onus would be on you to justify the non-standard > behaviour. > > On the other hand I can see its uses too. But I don't want it, and > always turn it off with BaseX :-) > > Best, > > Liam > > -- > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > Pictures from old books: http://fromoldbooks.org/ > Ankh: irc.sorcery.net irc.gnome.org freenode/#xml > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

From: Wendell Piez <wapiez at wendellpiez.com> Date: Tue, Apr 16, 2013 at 11:15 AM Subject: Re: [basex-talk] whitespace around comments To: Christian Grün <christian.gruen at gmail.com> Hi, Thanks to Cerstin for once again urging that CHOP not be set by default, and to Liam for reminding readers that this is *not* a new issue in markup processing -- indeed it was in view of problems with whitespace in earlier technologies (can anyone say "pernicious mixed content"?) that the XML Rec says what it does -- including section http://www.w3.org/TR/REC-xml/#sec-white-space. And thanks also to Christian for reminding us why much of the time, whitespace chopping is innocuous and helpful. Personally, I'm in an uneasy place with respect to these issues. I wholeheartedly agree with Cerstin and Liam that chopping should not be on by default. Leaving it on by default is wrong and non-conformant. However, I'm also working with an application in which it's very convenient to have it -- not only is the data highly structured and controlled -- no mixed content here -- but also part of its job is to offer clean representations of external data that is much dirtier and cruftier. It is supposed to clear bad data away and clean it up, so managing the whitespace on ingest is just part of what we are doing. For both scaling and usability issues (as Christian has suggested), whitespace chopping is nice to have. Yet at the same time, we are already calling XSLT for uses in which the chopping is destructive, and the day is not very far off when we will have mixed content in our primary data set too. Liam points out something very important: it is possible in principle to distinguish between whitespace that can be safely discarded (by design) and whitespace that can't -- if you have a schema or other specification that represents this design. As he notes, the XML Rec distinguishes between "significant" and "insignificant" whitespace by reference to content models that do and don't include #PCDATA (that is, whitespace that appears in "element content" or "mixed content"; cf http://www.w3.org/TR/REC-xml/#dt-elemcontent). If your content model for div says (p+), then whitespace between the 'p' element children of a 'div' (but not inside them) may often be judged safe to discard. (At least in a system in which a schema is used as a warrant of fitness for processing.) When technologies such as XQuery or XSLT are designed to work with and without schemas, however -- or where schemas cannot be considered as reliable indicators of markup semantics -- even relying on this mechanism can't solve the problem (to say nothing of deciding which schema languages you support). However, it can help to mitigate it. Then too, even XSLT 1.0 has strip-space and preserve-space configuration to indicate to a processor where it can "chop" whitespace. While it's a bit crude (it treats all elements with the same name the same), it can be useful. Over the longer term, therefore, I think that (1) CHOP needs to be "false" by default, (2) it should be possible to turn it on (just as I am learning how to turn it off), and also (3) that we also need more flexible and configurable means for discriminating how it should work, with and without schemas to reference. Cheers, Wendell On Sat, Apr 13, 2013 at 7:05 AM, Christian Grün <christian.gruen at gmail.com> wrote: > I’d like to add some more info on why we initially decided to chop > whitespaces, and why a sudden change of the default value may break > existing applications (if you know the details, simply skip this > section..): > > Many XML documents contain whitespace-only text nodes for properly > indenting elements. In highly structured data (i.e., when not working > with mixed content), these nodes are in fact completely irrelevant. > For example, if the following document… > > <xml> > <a>X</a> > </xml> > > …is parsed with CHOP set to true, we will get a document with a single > text node. The following query… > > for $t in //text() > return replace node $t with 'x' > > …will generate the following result: > > <xml> > <a>x</a> > </xml> > > If we set CHOP to false, the document will have three text nodes, two > of them whitespace-only, and the same query will create the following > result document: > > <xml>x<a>x</a>x</xml> > > This is just one example to demonstrate that a sudden change of the > default for chop would most probably lead to unwanted side effects in > existing applications. Another side effect: databases are expected to > increase in size, as all whitespace nodes will get their own node ids, > will be fully stored and indexed, etc. > > However, I completely agree that the removal of whitespaces may lead > to serious changes in mixed contents, and I easily admit that we > haven’t been aware of all the implications some years ago when we > started off designing the database. While I still believe that our > storage copes pretty well with nowaday’s requirements, I would love to > have some weeks off to completely rebuild it, and include > optimizations for all kinds of features that are relevant today > (including larger ranges for node ids and namespaces, or support for > other tree formats such as json). > > Thanks for reading, > Christian > ___________________________ > > On Sat, Apr 13, 2013 at 8:28 AM, Liam R E Quin <liam at w3.org> wrote: >> On Fri, 2013-04-05 at 11:31 +0200, Dirk Kirsten wrote: >> >>> So if you could point out some details as why this is not conforming >>> behaviour, this would be interesting. >> >> It's a requirement in the XML Spec that the XML parser pass all >> whitespace back to the application. Some whitespace may be marked as not >> significant - that is only possible if there's a DTD and the space is in >> a context where only elements would be valid, not #PCDATA. There's no >> formal specification, although constructing an XDM instance from an >> infoset, and constructing an infoset from XML, does not entail >> discarding these spaces: >> Chopping internal whitespace nodes in mixed content contexts is not >> sanctioned by any version of any XML specification, with any setting of >> xml:space. I think the onus would be on you to justify the non-standard >> behaviour. >> >> On the other hand I can see its uses too. But I don't want it, and >> always turn it off with BaseX :-) >> >> Best, >> >> Liam >> >> -- >> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ >> Pictures from old books: http://fromoldbooks.org/ >> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk -- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ -- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^

> Liam points out something very important: it is possible in principle > to distinguish between whitespace that can be safely discarded (by > design) and whitespace that can't -- if you have a schema or other > specification that represents this design. > > As he notes, the XML Rec distinguishes between "significant" and > "insignificant" whitespace by reference to content models that do and > don't include #PCDATA (that is, whitespace that appears in "element > content" or "mixed content"; cf > http://www.w3.org/TR/REC-xml/#dt-elemcontent). If your content model > for div says (p+), then whitespace between the 'p' element children of > a 'div' (but not inside them) may often be judged safe to discard. (At > least in a system in which a schema is used as a warrant of fitness > for processing.) > > When technologies such as XQuery or XSLT are designed to work with and > without schemas, however -- or where schemas cannot be considered as > reliable indicators of markup semantics -- even relying on this > mechanism can't solve the problem (to say nothing of deciding which > schema languages you support). However, it can help to mitigate it. > > Then too, even XSLT 1.0 has strip-space and preserve-space > configuration to indicate to a processor where it can "chop" > whitespace. While it's a bit crude (it treats all elements with the > same name the same), it can be useful. > > Over the longer term, therefore, I think that (1) CHOP needs to be > "false" by default, (2) it should be possible to turn it on (just as I > am learning how to turn it off), and also (3) that we also need more > flexible and configurable means for discriminating how it should work, > with and without schemas to reference. > > Cheers, Wendell > > > > On Sat, Apr 13, 2013 at 7:05 AM, Christian Grün > <christian.gruen at gmail.com> wrote: >> I’d like to add some more info on why we initially decided to chop >> whitespaces, and why a sudden change of the default value may break >> existing applications (if you know the details, simply skip this >> section..): >> >> Many XML documents contain whitespace-only text nodes for properly >> indenting elements. In highly structured data (i.e., when not working >> with mixed content), these nodes are in fact completely irrelevant. >> For example, if the following document… >> >> <xml> >> <a>X</a> >> </xml> >> >> …is parsed with CHOP set to true, we will get a document with a single >> text node. The following query… >> >> for $t in //text() >> return replace node $t with 'x' >> >> …will generate the following result: >> >> <xml> >> <a>x</a> >> </xml> >> >> If we set CHOP to false, the document will have three text nodes, two >> of them whitespace-only, and the same query will create the following >> result document: >> >> <xml>x<a>x</a>x</xml> >> >> This is just one example to demonstrate that a sudden change of the >> default for chop would most probably lead to unwanted side effects in >> existing applications. Another side effect: databases are expected to >> increase in size, as all whitespace nodes will get their own node ids, >> will be fully stored and indexed, etc. >> >> However, I completely agree that the removal of whitespaces may lead >> to serious changes in mixed contents, and I easily admit that we >> haven’t been aware of all the implications some years ago when we >> started off designing the database. While I still believe that our >> storage copes pretty well with nowaday’s requirements, I would love to >> have some weeks off to completely rebuild it, and include >> optimizations for all kinds of features that are relevant today >> (including larger ranges for node ids and namespaces, or support for >> other tree formats such as json). >> >> Thanks for reading, >> Christian >> ___________________________ >> >> On Sat, Apr 13, 2013 at 8:28 AM, Liam R E Quin <liam at w3.org> wrote: >>> On Fri, 2013-04-05 at 11:31 +0200, Dirk Kirsten wrote: >>> >>>> So if you could point out some details as why this is not conforming >>>> behaviour, this would be interesting. >>> >>> It's a requirement in the XML Spec that the XML parser pass all >>> whitespace back to the application. Some whitespace may be marked as not >>> significant - that is only possible if there's a DTD and the space is in >>> a context where only elements would be valid, not #PCDATA. There's no >>> formal specification, although constructing an XDM instance from an >>> infoset, and constructing an infoset from XML, does not entail >>> discarding these spaces: >>> Chopping internal whitespace nodes in mixed content contexts is not >>> sanctioned by any version of any XML specification, with any setting of >>> xml:space. I think the onus would be on you to justify the non-standard >>> behaviour. >>> >>> On the other hand I can see its uses too. But I don't want it, and >>> always turn it off with BaseX :-) >>> >>> Best, >>> >>> Liam >>> >>> -- >>> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ >>> Pictures from old books: http://fromoldbooks.org/ >>> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml >>> >>> _______________________________________________ >>> BaseX-Talk mailing list >>> BaseX-Talk at mailman.uni-konstanz.de >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > -- > Wendell Piez | http://www.wendellpiez.com > XML | XSLT | electronic publishing > Eat Your Vegetables > _____oo_________o_o___ooooo____ooooooo_^ > > > -- > Wendell Piez | http://www.wendellpiez.com > XML | XSLT | electronic publishing > Eat Your Vegetables > _____oo_________o_o___ooooo____ooooooo_^ > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

On Thu, Apr 18, 2013 at 4:03 PM, Christian Grün <christian.gruen at gmail.com> wrote: > Hi Wendell, > > thanks for your point of view. If you decide not to introduce a schema > for your data, and if you have the chance to prepare your input before > adding it to the database, you may now mark all your mixed content > with xml:space="preserve". > > One question to Liam: do you remember why "strip" is not a valid > option for the xml:space attribute? > > Christian > ______________________________________ > >> Liam points out something very important: it is possible in principle >> to distinguish between whitespace that can be safely discarded (by >> design) and whitespace that can't -- if you have a schema or other >> specification that represents this design. >> >> As he notes, the XML Rec distinguishes between "significant" and >> "insignificant" whitespace by reference to content models that do and >> don't include #PCDATA (that is, whitespace that appears in "element >> content" or "mixed content"; cf >> http://www.w3.org/TR/REC-xml/#dt-elemcontent). If your content model >> for div says (p+), then whitespace between the 'p' element children of >> a 'div' (but not inside them) may often be judged safe to discard. (At >> least in a system in which a schema is used as a warrant of fitness >> for processing.) >> >> When technologies such as XQuery or XSLT are designed to work with and >> without schemas, however -- or where schemas cannot be considered as >> reliable indicators of markup semantics -- even relying on this >> mechanism can't solve the problem (to say nothing of deciding which >> schema languages you support). However, it can help to mitigate it. >> >> Then too, even XSLT 1.0 has strip-space and preserve-space >> configuration to indicate to a processor where it can "chop" >> whitespace. While it's a bit crude (it treats all elements with the >> same name the same), it can be useful. >> >> Over the longer term, therefore, I think that (1) CHOP needs to be >> "false" by default, (2) it should be possible to turn it on (just as I >> am learning how to turn it off), and also (3) that we also need more >> flexible and configurable means for discriminating how it should work, >> with and without schemas to reference. >> >> Cheers, Wendell >> >> >> >> On Sat, Apr 13, 2013 at 7:05 AM, Christian Grün >> <christian.gruen at gmail.com> wrote: >>> I’d like to add some more info on why we initially decided to chop >>> whitespaces, and why a sudden change of the default value may break >>> existing applications (if you know the details, simply skip this >>> section..): >>> >>> Many XML documents contain whitespace-only text nodes for properly >>> indenting elements. In highly structured data (i.e., when not working >>> with mixed content), these nodes are in fact completely irrelevant. >>> For example, if the following document… >>> >>> <xml> >>> <a>X</a> >>> </xml> >>> >>> …is parsed with CHOP set to true, we will get a document with a single >>> text node. The following query… >>> >>> for $t in //text() >>> return replace node $t with 'x' >>> >>> …will generate the following result: >>> >>> <xml> >>> <a>x</a> >>> </xml> >>> >>> If we set CHOP to false, the document will have three text nodes, two >>> of them whitespace-only, and the same query will create the following >>> result document: >>> >>> <xml>x<a>x</a>x</xml> >>> >>> This is just one example to demonstrate that a sudden change of the >>> default for chop would most probably lead to unwanted side effects in >>> existing applications. Another side effect: databases are expected to >>> increase in size, as all whitespace nodes will get their own node ids, >>> will be fully stored and indexed, etc. >>> >>> However, I completely agree that the removal of whitespaces may lead >>> to serious changes in mixed contents, and I easily admit that we >>> haven’t been aware of all the implications some years ago when we >>> started off designing the database. While I still believe that our >>> storage copes pretty well with nowaday’s requirements, I would love to >>> have some weeks off to completely rebuild it, and include >>> optimizations for all kinds of features that are relevant today >>> (including larger ranges for node ids and namespaces, or support for >>> other tree formats such as json). >>> >>> Thanks for reading, >>> Christian >>> ___________________________ >>> >>> On Sat, Apr 13, 2013 at 8:28 AM, Liam R E Quin <liam at w3.org> wrote: >>>> On Fri, 2013-04-05 at 11:31 +0200, Dirk Kirsten wrote: >>>> >>>>> So if you could point out some details as why this is not conforming >>>>> behaviour, this would be interesting. >>>> >>>> It's a requirement in the XML Spec that the XML parser pass all >>>> whitespace back to the application. Some whitespace may be marked as not >>>> significant - that is only possible if there's a DTD and the space is in >>>> a context where only elements would be valid, not #PCDATA. There's no >>>> formal specification, although constructing an XDM instance from an >>>> infoset, and constructing an infoset from XML, does not entail >>>> discarding these spaces: >>>> Chopping internal whitespace nodes in mixed content contexts is not >>>> sanctioned by any version of any XML specification, with any setting of >>>> xml:space. I think the onus would be on you to justify the non-standard >>>> behaviour. >>>> >>>> On the other hand I can see its uses too. But I don't want it, and >>>> always turn it off with BaseX :-) >>>> >>>> Best, >>>> >>>> Liam >>>> >>>> -- >>>> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ >>>> Pictures from old books: http://fromoldbooks.org/ >>>> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml >>>> >>>> _______________________________________________ >>>> BaseX-Talk mailing list >>>> BaseX-Talk at mailman.uni-konstanz.de >>>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> _______________________________________________ >>> BaseX-Talk mailing list >>> BaseX-Talk at mailman.uni-konstanz.de >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> >> >> -- >> Wendell Piez | http://www.wendellpiez.com >> XML | XSLT | electronic publishing >> Eat Your Vegetables >> _____oo_________o_o___ooooo____ooooooo_^ >> >> >> -- >> Wendell Piez | http://www.wendellpiez.com >> XML | XSLT | electronic publishing >> Eat Your Vegetables >> _____oo_________o_o___ooooo____ooooooo_^ >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> I wonder if there's a way I could ask BaseX to invoke Saxon and ingest > its transformation results? So I wouldn't have to cache the stuff on a > disk. (Or maybe I should get myself that solid state drive. :-)