Hi Dirk -- I understand that you don't want to break backward compatibility, but a)it never gets easier, only harder, when you must do that, as more existing applications accumulate and b)the example given of the type of problem is seriously bad code. (I totally believe this kind of code exists in the wild; I can't muster much sympathy for an observation that "give me every text node in the document" is likely to go wrong, because my experience says it is _certain_ to go wrong, you never do that without qualifying which text nodes you mean.)
And, really, yeah, a commitment to backward compatibility is good; a commitment to preserving error is not, and the CHOP default behaviour is an error. Abstractions like backward compatibility don't even get into the discussion when the initial client response is "you changed our data and broke it". The client having that reaction wasn't very nuanced about it (and didn't immediately understand they were looking at a copy) but they weren't wrong. This really is a serious bug for mixed content. So, please, could we get a release version commitment for when this bug will be fixed? Thanks! Graydon On Wed, Mar 26, 2014 at 1:37 PM, Dirk Kirsten <d...@basex.org> wrote: > Hello Graydon, > > As Christian already pointed out, we had this discussion on the mailing > list quite frequently. See Christians answer from some time ago for some > insight: > https://mailman.uni-konstanz.de/pipermail/basex-talk/2013-April/004984.html > > So although it is of course easily changed in our code, it does has some > serious implications in terms of backward compatibility. So you might be > able to convince your client by stating that we take backward > compatibility seriously and will take some time and thought to change > things that break applications :) > > Cheers, > Dirk > > On 26/03/14 18:24, Graydon Saunders wrote: >> Could we get _which_ future version? I recall this being said before >> 7.8 was released, too, and was feeling hopeful. >> >> I understand that from a technical perspective this is a completely >> trivial thing -- set the flag! -- but from the perspective of having >> to argue for three months to be able to use BaseX at all at a client >> whose internal tester did a naive load of some narrative-style XML, >> observed the loss of white space around internal-to-the-mixed-content >> tags, and said "this application is banned", it's not trivial at all. >> Especially since it's not technically correct to the XML spec; one is >> forced to argue that something is a minor quirk of an otherwise >> excellent application *after* it's already given senior, stubborn, and >> non-technical content experts metaphorical heart attacks. >> >> On Wed, Mar 26, 2014 at 1:15 PM, Christian Grün >> <christian.gr...@gmail.com> wrote: >>> True; this discussion is already going on for quite a while now. The default >>> value of CHOP will be changed in a future version of BaseX. >>> >>> >>> On Wed, Mar 26, 2014 at 6:14 PM, Graydon Saunders <graydon...@gmail.com> >>> wrote: >>>> >>>> Though I think "CHOP" defaulting to true is a bug compared to the >>>> expected behaviour of XML. >>>> >>>> And while it's very useful to have CHOP there for some kinds of data, >>>> for other kinds it's a severe hazard that it's the default. People >>>> have major freakouts when their documentation XML documents look like >>>> they've lost the white spaces around bold tags and will have nothing >>>> to do with BaseX thereafter. >>>> >>>> -- Graydon >>>> >>>> On Wed, Mar 26, 2014 at 1:08 PM, Dirk Kirsten <d...@basex.org> wrote: >>>>> Sorry, mail was supposed to be send to the mailing list... Information >>>>> is the same as in Leos mail >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [basex-talk] whitespaces in import >>>>> Date: Wed, 26 Mar 2014 17:59:12 +0100 >>>>> From: Dirk Kirsten <d...@basex.org> >>>>> To: Stefan Sechelmann <sec...@math.tu-berlin.de> >>>>> >>>>> Hello Stefan, >>>>> >>>>> On 26/03/14 17:51, Stefan Sechelmann wrote: >>>>> Is there some kind of whitespace normalization >>>>>> going on during import? >>>>> >>>>> Yes, it is. >>>>> >>>>> Can I set options that influence this behavior or is this a bug? >>>>> >>>>> Yes, you can. Set the CHOP option to false (see >>>>> https://docs.basex.org/wiki/Options#CHOP for details) or start BaseX >>>>> with the -w flag (which sets CHOP to false). >>>>> >>>>> Hope that helps. >>>>> >>>>> Cheers, >>>>> Dirk >>>>> >>>>> -- >>>>> 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 >>> >>> >> _______________________________________________ >> 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
