> > > >> Thanks for the update Jorg, and looks like we agree on the issue now. > > Understand what you're saying about changing in a major release. However, > > I > > would think that at least the Javadoc should be updated. Ideally, to > > provide helper functionality without breaking backwards compatibility, > you > > could do something *like* one of the below: > > > > (a) add a ContractConsistentStaxDriver which wraps Stax driver and > > enforces the 'toXML contract' > > (b) add a standardiseStaxOutput(String rawXML) helper method to XStream > > which strips the header and pretty-prints it > > (c) add an overloaded StaxDriver constructor with an standardiseXML > > boolean flag that does the standardisation in (a), where the default > > constructor sets this as false > > > > I need to raise a (definite!) bug for something completely different. > > Would you like me to add a bug and/or enhancement request(s) for this? I > > was thinking of: > > > > (1) A Javadoc and FAQ correction bug > > (2) An enhancement request for the helper functionality > > (3) A major-release enhancement request for consistent toXML > functionality > > (which would supercede the changes in (2)) > > > > Am I overdoing it? :-) > > Simply open an issue as normal bug. The main problem with the compatibility > is concerning the data, not necessarily the code. Since I'll probable use > something like StaxMate for pretty print, I am inclined to create a derived > StaxMateDriver. > > - Jörg > > OK, single bug XSTR-734 opened for this. See also XSTR-733 for another issue I had (with code to reproduce it). Thanks for your help so far.
Stuart
