|
| Re: XML EString serialization - end-of-lines on windows [message #1220140 is a reply to message #1220125] |
Tue, 10 December 2013 05:19   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vlad,
Comments below.
On 09/12/2013 10:19 PM, Vlad Gheorghe wrote:
>
> In an application running on a win32 host, we have a UI which binds
> Text widgets to EString attributes.
> The in-memory representation contains the line separator "\r\n".
>
> We use an XML serialization, where some of the attributes are
> persisted as elements.
>
> The reason for this is that we want to have a more text-level
> diff-friendly format.
>
>
> In the resulting serialization, at the end of each line of such
> elements we get 3 characters: "
> \r\n"
It's hard to interpret this. What exactly are the three characters?
>
> I know of Resource#OPTION_LINE_DELIMITER, but I think that using it
> would result in "
> \n" (which is correct imo, as the framework would preserve the string
> value).
It generally should preserve exactly the character content of the value....
>
>
> 1) Is this a bug ?
I'm not sure exactly what you're saying shows up verses what you expect
should show up.
>
> 2) Is there a way to get only "\r\n" as a line terminator ?
There's a issue of what terminator is used for the XML itself and what
value is serialized for you one element's text content, but I don't
follow what you say is happening verses what you're expecting. The
option should only affect the terminator used for the XML itself, not
for the values themselves.
>
>
> Regards,
> Vlad Gheorghe
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: XML EString serialization - end-of-lines on windows [message #1220184 is a reply to message #1220148] |
Tue, 10 December 2013 09:44 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vlad,
A SAX parser will always convert the whatever linefeed convention is
used in the source file into \n in the SAX stream. Looking at SAX, you
can't know if the file really contained \r\n or just \n. So within
element content, the \n doesn't need to be encoded, because it will be
preserved, but the \r needs to be encoded, because it will be lost. So
that's what you're seeing. For both attribute content and element
content you should see that what goes in is the same as what comes out.
How it looks in the file itself is not directly meaningful, only that
want ends up in your model after parsing is significant.
Of course this who issue how what line convention is used in your
literal values is kind of fishy anyway. You edit the value in windows
and send it to a linux machine, do you want it to use the window's
conventions there? Who knows what each different client wants...
On 10/12/2013 7:28 AM, Vlad Gheorghe wrote:
> Hello Ed,
>
> Thank you for the reply.
>
> The character string appearing at the end of the lines is the string
> obtained by removing the whitespace from the java string literal:"& #
> x D ; \r\n"
>
> (It showed up ok in the comment preview, but it seems that the first
> part gets interpreted by the browser).
>
> Best regards
> Vlad
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XML EString serialization - end-of-lines on windows [message #1220482 is a reply to message #1220184] |
Thu, 12 December 2013 06:35 |
Vlad Gheorghe
Messages: 127
Registered: May 2011 |
Senior Member |
|
|
Ed,
Thanks a lot for the enlighting explanation.
This is the relevant section from the xml standard:
http://www.w3.org/TR/REC-xml/#sec-line-ends
Ed Merks wrote on Tue, 10 December 2013 11:44Vlad,
A SAX parser will always convert the whatever linefeed convention is
used in the source file into \n in the SAX stream. Looking at SAX, you
can't know if the file really contained \r\n or just \n. So within
element content, the \n doesn't need to be encoded, because it will be
preserved, but the \r needs to be encoded, because it will be lost. So
that's what you're seeing. For both attribute content and element
content you should see that what goes in is the same as what comes out.
How it looks in the file itself is not directly meaningful, only that
want ends up in your model after parsing is significant.
I understand now why the EMF xml serialization works like this.
The actual problem seems to be a different one though.
As we are trying to interoperate with another application using the serialized xml files, the "model" is not constructed only in the EMF application, but in the other applications too.
(In our case, that is a DXL script using the MSXML processor on windows).
Regards
Vlad
|
|
|
Powered by
FUDForum. Page generated in 0.02883 seconds
] 
Search
Help
Register
Login
Home
