[ http://issues.apache.org/jira/browse/XMLBEANS-262?page=all ]
Raman Gupta updated XMLBEANS-262:
---------------------------------
Description:
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.
was:
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 converted to \n on the output), 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.
> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
> Key: XMLBEANS-262
> URL: http://issues.apache.org/jira/browse/XMLBEANS-262
> Project: XMLBeans
> Type: Bug
> Components: XmlObject
> Versions: Version 2.1
> Environment: Windows, JDK 1.5.0_06
> Reporter: Raman Gupta
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
