Yes. What puzzles me is that calling db:replace with a fourth argument of map { "chop" : false() } appears not to have any effect in the database in question.
This is probably because the input you are specifying are nodes, for which whitespaces have already been chopped in a previous step I tried to explain this better now in our documentation [1].
I have just spent much more time than I intended trying to find the relevant parts of the discussion in the email archive at
Thanks a lot, it was really interesting to read! Although it’s obviously too late to change anything about the status quo.
Speaking for myself, I think a better heuristic than dropping all whitespace-only text nodes and removing leading and trailing whitespace would be dropping whitespace-only text nodes only if every text-node seen so far as a child of this parent has been whitespace-only, and stripping leading whitespace only after a start-tag and trailing whitespace only after an end-tag.
Your idea sounds very appealing to me; I have just added it to our issue tracker [2]. I will still need to think about all the minor and hidden implications, but I think we could definitely live with changing the default behaviour:
* Nothing would change for highly structured input * For mixed content, things can only get better.
If there will be cases in which relevant whitespaces get lost, we could still fine tune your heuristics.
All the best, Christian
[1] http://docs.basex.org/wiki/Database_Module#db:replace [2] https://github.com/BaseXdb/basex/issues/913