[jira] Created: (XMLBEANS-262) Line ending behavior inconsistent when using save(OutputStream)

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 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.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wing Yew Poon reassigned XMLBEANS-262:
--------------------------------------

    Assignee: Radu Preotiuc-Pietro

Radu, isn't this (the behavior reported) by design?

> Line ending behavior inconsistent when using save(OutputStream)
> ---------------------------------------------------------------
>
>                 Key: XMLBEANS-262
>                 URL: https://issues.apache.org/jira/browse/XMLBEANS-262
>             Project: XMLBeans
>          Issue Type: Bug
>          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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/XMLBEANS-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wing Yew Poon updated XMLBEANS-262:
-----------------------------------

    Issue Type: Improvement  (was: Bug)

This is not a bug. The behavior is by design.
As the reporter found, the behavior is in fact predictable and known, although perhaps not documented. The xml declaration ends with the system line separator, while lines within the xml body end with \n (line feed).
I personally would prefer the xml declaration to always end with \n as well, to be consistent with the rest of the document, regardless of the system.
As an enhancement, we could provide an option to output all lines to end with the system line separator.
Option 1 stated by the reporter is not possible, and conflicts with the xml spec. As the section cited by the reporter states, "the XML processor  MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character." Note the clause, "before parsing". Thus all the line endings in the input are normalized away before parsing, so there is no way for XMLBeans to get them back from the XmlObject.

> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

    [ 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...