[jdom-interest] end-of-line character

Jason Hunter jhunter at acm.org
Fri Jul 7 08:56:50 PDT 2000


> Only if that's what most people want to do. Most people don't want to
> do that. They'll be happy with any line separator we give them. Of
> those who care, 90%+ will want \r\n anyway. I see no reason to make
> anything else the default. Remember XML files are about
> interoperability. The platform on which an XML document is created is
> not necessarily the platform on which the document will be viewed,
> edited, or otherwise manipulated. line.separator only tells me on
> what platform the VM was running when it built a file. That's not
> necessarily the system that uses the file.

I tend to agree with Elliotte.  Use \r\n, allow an override.  I think
it's good files meant to be shared like this are created in a standard
way, and \r\n seems to be the network protocol standard way.  Plus using
\r\n means only Unix users will potentially see the ugliness, and
they're of course experienced enough to know what's going on and with
any luck are using editors smart enough to deal with \r\n encoding
(unlike Windows Notepad piece of crap).  In other words, "Not all
Windows users are morons, but all morons are Windows users."  :-) 
(Waiting to get flamed by a moron Unix user who feels left out.)

I have added this to the TODO.txt file in CVS.  Elliotte, do you have
time to make the modification?

> The default case should shield the ignorant from their ignorance. The
> best way to do that is to pick \r\n as the line separator. I am not
> aware of any cases where this choice of line ending will do anything
> worse than look bad when loaded into a text editor, and even that
> problem is rare. However, picking either \r or \n alone as the line
> separator will cause network programs to hang unexpectedly when
> talking to some servers and servlets 

Elliotte, out of curiosity, can you explain how a document with \n
endings is going to confuse the HTTP protocol, considering on both
upload and download the document is treated as raw data and not as
anything a server or proxy program itself will be parsing?

-jh-



More information about the jdom-interest mailing list