Closed ysavourel closed 7 years ago
Thanks for reporting this issue. If you would like to contribute a fix, please do so via a pull request. Otherwise, we will evaluate and prioritize the fix as appropriate.
Upon further examination of the issue, this is by design. If you declare xml:space="preserve" then you will get the expected output. Perhaps you are expecting the default "processing mode" of the OM to be to preserve whitespace? In which case, this is not a bug but a design change.
To clarify a bit more: this is the default behavior of the OM because it is based on .Net XmlReader/Writer which does not preserve by default.
Looking more closely at the XML specification, I have to agree: default
means the reader does whatever it wants. I had read it as: "The reader can normalize or preserve". But it seems that complete deletion is valid too.
So it's not a bug.
But I would change this as a request for a change in behavior. While remove spaces on outer content is fine, it seems that completely removing spaces in elements that are content like <source>
and <target>
is probably unwise. I would expect to either normalize or preserve whitespace there.
I'll also post a not to answer your email in the XLIFF list.
Thanks for reporting this issue. If you would like to contribute a fix, please do so via a pull request. Otherwise, we will evaluate and prioritize the design change request appropriately.
It looks like the content of
<source>
is removed on reading when it is made of spaces. For example if we have this:We get this output (no content for
<ignorable>
):While I would expect this output:
It happens also for
<segment>
elements.