[
https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773135#action_12773135
]
Raman Gupta commented on XMLBEANS-262:
--------------------------------------
Good point about option #1. Option #3 it is then.
For the enhancement, I how about two new XmlOption's:
setEolStyle(String eolStyle)
setEolStyleDeclaration(String eolStyle)
with the following constants as possible values:
EOLSTYLE_LF = "LF";
EOLSTYLE_CRLF = "CRLF";
EOLSTYLE_SYS = "SYS";
To maintain backwards compatibility, the option eolStyle would be set by the
user to EOLSTYLE_LF and eolStyleDeclaration would be EOLSTYLE_SYS. However, the
defaults provided by XmlBeans should probably be EOLSTYLE_LF or EOLSTYLE_SYS
for both. My personal preference would be _LF but I suspect most people would
expect _SYS to be the default.
> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
> Key: XMLBEANS-262
> URL: https://issues.apache.org/jira/browse/XMLBEANS-262
> Project: XMLBeans
> Issue Type: Improvement
> Components: XmlObject
> Affects Versions: Version 2.1
> Environment: Windows, JDK 1.5.0_06
> Reporter: Raman Gupta
> Assignee: Radu Preotiuc-Pietro
> Priority: Minor
>
> When executing an XmlObject.save(OutputStream) call, the output's line
> endings do not conform to any consistent and expected behavior. Even though
> this should not be a problem for any conformant XML processor due to
> http://www.w3.org/TR/REC-xml/#sec-line-ends, this sometimes causes problems
> with other tools or code.
> Here is a code snippet to reproduce:
> XmlObject x = XmlObject.Factory.parse("<root>\r\n<test/>\r\n</root>");
> OutputStream o = new FileOutputStream("out.xml");
> x.save(o);
> o.close();
> Viewing out.xml in a hex editor will show that the line ending after the XML
> declaration is determined by the System property line.separator (on windows,
> default is \r\n, or 0x0D, 0x0A) but the line endings after all the other
> elements is always a single \n (0x0A), regardless of line.separator and the
> input XML. In other words, line endings do not match either the line endings
> provided in the input XML, or the platform default value on Windows.
> I suppose there are several options for fixing this:
> 1) The XML declaration continues to use the System property, but for other
> line endings, the input XML's line endings should be respected when output
> (\r\n on the input is output as is), OR
> 2) That the output XML uses the System property and makes all line endings
> consistent.
> 3) Some combination of the above with new XmlOption's settings.
> My preference would be #3 so that the line ending behavior can be controlled
> by the user. For the default, I have no preference except to have some known
> documented behavior. Option #1 will sometimes result in a file with
> inconsistent line endings, but it could be argued that the user requested it
> so it is ok.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
