[jdom-interest] XMLOutputter and newlines afterdeclaration/doctype

Vadim Strizhevsky Vadim.Strizhevsky at morganstanley.com
Wed Dec 18 14:20:00 PST 2002

Elliotte Rusty Harold wrote:
> At 3:55 PM -0500 12/18/02, Vadim Strizhevsky wrote:
> >I'd like to request an ability to output the whole xml as one line,
> >without any newlines, (except the final one I guess). Either controlled
> >by the same flag as other new lines or a separate boolean flag. While I
> >do agree that having them there is sematically inconsequential, there
> >are situations and non-semantic reasons when you may want to really have
> >xml output as a single line. You want doc as small a possible.
> Maybe 16 bytes difference at most? Only one or two bytes saved in
> most cases.  I'm not willing to complexify the API for that small a gain

Its not a huge compexity and that's only if you provide a separate flag.
I actually think that the assumption that jdom currently makes that when
I asked for no newlines I really meant no most newlines, but keep some
of them is strange and counter intuitive. 

> >Or you
> >want to generating a big log file of multiple xml messages that will
> >later be processes by scripts. Having the complete message on a single
> >line would simplify those scripts.
> No, it wouldn't; at least not if the scripts are using an XML parser;
> and if they're not why did you write the document in XML in the first
> place?

Logging. Test case generation/storage. Replay of daily xml messages.
Many different possible reasons for this. Yes there are other ways of
doing, yes you could store in separate files, yes you can still write
script that parse it, but it makes doing some things more complicated.

> >For now I will have XMLOutputter subclass that duplicates
> >printDeclaration and printDocType methods and doesn't print the newlines
> >when newline option is set to false.
> I suggest that's the appropriate solution here.

Oh well, it was worth a try. I still think that I shouldn't have to
duplicate functions, which I will have to keep in sync with future
versions of JDOM, to provide what to me looks like a reasonable
capability/control over the generated output.


More information about the jdom-interest mailing list