[0] I agree that as far as the xml parsing is concerned, it is quite indistinguishable escaping quotes or not in the text nodes - things are quite different of course in the attributes if the delimiter is colliding. Hence, I agree with Paul Clapham's posts. It is better to fix the filter functions than messing with semantically equivalent xml by electing one preferably over the others.
[0.1] Having said that, is it not dom4j's authors also have had made a choice in that regard? as I so far have not been able to discover which setting in the OutputFormat object capable to do one thing than the other in that regard, namely escaping or not escaping quotes or apos, say, --- other than ampersand and closing angle bracket which is a must for the latter two---, in the text nodes or attributes. So maybe it is also fair to quest about that from a user's point of view.
[1] With the above in mind, I have looked into the issue and it is indeed quite a bit of a difficulty bending it one way rather than the other. The main issue is that you can more easily output without escaping the quot or doubly blow the ampersand into ("). A full control seems inevitably fall upon context handling or base more heavily on
string writing kind of operation effectively making some post-processing the output as text file rather than a subset of text file, more specifically an xml document.
[2] This is one concrete way to achieve the objective, profiting double blown in the write out and then use unescape once. The trick is to properly double blown all the leaves first (including text nodes, attributes, comments and processing-instructions). After doing that in a more general setting, a broad set of documents can be output to the desire formats. This is the implementation into the exiting code.