views:

687

answers:

5

In my application, I alter some part of XML files, which begin like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: version control yadda-yadda $ -->

<myElement>
...

Note the blank line before <myElement>. After loading, altering and saving, the result is far from pleasing:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: version control yadda-yadda $ --><myElement>
...

I found out that the whitespace (one newline) between the comment and the document node is not represented in the DOM at all. The following self-contained code reproduces the issue reliably:

String source =
    "<?xml version=\"1.0\" encoding=\"UTF-16\"?>\n<!-- foo -->\n<empty/>";
byte[] sourceBytes = source.getBytes("UTF-16");

DocumentBuilder builder =
    DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document doc =
    builder.parse(new ByteInputStream(sourceBytes, sourceBytes.length));

DOMImplementationLS domImplementation =
    (DOMImplementationLS) doc.getImplementation();
LSSerializer lsSerializer = domImplementation.createLSSerializer();
System.out.println(lsSerializer.writeToString(doc));

// output: <?xml version="1.0" encoding="UTF-16"?>\n<!-- foo --><empty/>

Does anyone have an idea how to avoid this? Essentially, I want the output to be the same as the input. (I know that the xml declaration will be regenerated because it's not part of the DOM, but that's not an issue here.)

A: 

In general white spaces are considered irrelevant in XML and are thus not preserved when an XML file is parsed. Most libraries that output XML have an option for outputting it with nice formatting and correct indentations but it will always be fairly generic. No "have an extra line right here".

Kris
The point is that there *was* a line in the original input, and it should be kept - as is the case for all whitespace in the remainder of the document!
Jens Bannmann
+2  A: 

Why do you want to avoid this?

The white-space outside of tags/elements is defined as insignificant by the spec. It simply does not exist, as far as the infoset is concerned that is represented by your DOM.

Consequently, upon serializing the DOM again, it will not be there.

If you are in the process of developing something that relies on this empty line... Don't.

Tomalak
No program relies on this format, of course.However, the files contain translation data; they're checked in to version control and maintained continously. Thus, it would be nice for viewing diffs if the only changes my app does are intentional ones.
Jens Bannmann
I thought so... I think the only sensible way of dealing with that is not to have this empty line in the files to start with. I don't think there is any recommendable method of retaining this line. Maybe the files should be as a rule passed through a tidying tool before checkin to avoid these inconsistencies.
Tomalak
+2  A: 

I had the same problem. My solution was to write my own XML parser: DecentXML

Main feature: it can 100% preserve the original input, whitespace, entities, everything. It won't bother you with the details, but if your code needs to generate XML like this:

 <element
     attr="some complex value"
     />

then you can.

Aaron Digulla
Thanks for the suggestion; DecentXML certainly looks like a nice thing to keep in mind! *bookmarksIt* Good to see that at least one of the "yet-another-parser" projects has a really good reason to exist. However, for my current problem, I'd much rather stay with the standard DOM API throughout my processing code, and simply add the line in the output stage.
Jens Bannmann
Then you need to add the text nodes manually at before the root element. Look at the Document object how to add normal (non-element) nodes. If that's not possible, you must create a filter for the writer/output stream which hacks the newline in there.
Aaron Digulla
A: 

I agree with Kris and Tomalak, the blank line is not relevant from the XML point of view. If your application needs to produce a blank line in the output, I would suggest to review the need of that requirement.

Anyway, if you still want that blank line to appear, I would suggest to download the source code of the XML parser you are using and modify that behaviour. But keep in mind that this is not standard XML and it will not be compatible with other applications.

Daniel H.
+1  A: 

The root cause is that the standard DOM Level 3 cannot represent Text nodes as children of a Document without breaking the spec. Whitespace will be dropped by any compliant parser.

Document -- 
    Element (maximum of one),
    ProcessingInstruction,
    Comment,
    DocumentType (maximum of one)

If you require a standards-compliant solution and the objective is readability rather than 100% reproduction, I would look for it in your output mechanism.

McDowell