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.
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 a
On Fri, 2013-04-05 at 11:15 +0200, Michael Piotrowski wrote:
> On 2013-04-05, Michael Seiferle wrote:
> chopping certainly *does* change the
> semantics--that's precisely why I've argued before that it shouldn't be
> on by default.
Agreed, but Christian has already said it will be off by default
Yes we are talking about data damage. As bad as disk errors garbling one's data.
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
> 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 thei
Hi Christian,
Am 12.04.2013 um 10:49 schrieb Christian Grün
:
> our CHOP flag is subject to frequent discussions, which is why we will
> eventually change the default to FALSE.
I really second that!
> For now, we are still a little
> bit resistant, as such a change will change the behavior of
Hi Jidanni, hi Michael,
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 swi
[Why did this not get posted...]
OK it did get posted.
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
[Why did this not get posted...]
OK but do you admit that this
* wrecks HTML jammingwordstogether
* wrecks KML jammingcoordinatestogether
https://developers.google.com/kml/documentation/kmlreference#gxlatlonquad
in fact I bet it wrecks all the other *ML languages.
You can compress the whitespace d
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec133ba-7fd9.html
"if an XML comment is in the middle of a block of text, the DOM node
view represents its position in the text while the basic view does
not."
http://www.w3.org/TR/html401/struct/text.html#idx-white
Michael,
On 2013-04-05, "Michael Seiferle" wrote:
> Michael (other than me :-)) you are obviously right.
Thanks :-)
--
Dr.-Ing. Michael Piotrowski, M.A.
Institute of Computational Linguistics, University of Zurich
Phone +41 44 63-54313 | OpenPGP public key ID 0x1614A044
* OUT NOW: Natural La
http://www.w3.org/TR/REC-xml/#sec-white-space
...On the other hand, "significant" white space that should be preserved...
So since your parser by default creates significant whitespace where there was
none,
and removes it where there was, perhaps it could be fixed please, without the
user
needin
OK but do you admit that this
* wrecks HTML jammingwordstogether
* wrecks KML jammingcoordinatestogether
https://developers.google.com/kml/documentation/kmlreference#gxlatlonquad
in fact I bet it wrecks all the other *ML languages.
You can compress the whitespace down to one, but any furtherisjust
Michael (other than me :-)) you are obviously right.
—
Mit freundlichen Grüßen
Michael Seiferle
On Fri, Apr 5, 2013 at 12:29 PM, Michael Piotrowski wrote:
> Dirk,
> On 2013-04-05, Dirk Kirsten wrote:
>> You are certainly right that with mixed content and the example you have
>> given here cho
Dirk,
On 2013-04-05, Dirk Kirsten 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 d
Hello Michael,
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 th
On 2013-04-05, Michael Seiferle 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
Hi Jidanni,
thanks for your feedback, this is just a guess, but did you try to set chopping
to false?
> declare option db:chop 'false';
>
> doc('tmp/doc.xml')
http://docs.basex.org/wiki/Options#CHOP tells you what it does:
> Chops all leading and trailing whitespaces from text nodes while build
Pardon me but basex 7.6 doc() function is out of control.
$ more ib.xml z.xq|cat
::
ib.xml
::
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
19 matches
Mail list logo
