Hi Ryan, all,
Looking more closely at the XML specification I agree with Ryan that it’s valid to remove spaces when xml:space is default.
But I would suggest that a better behavior for the elements <source> and <target> would be to either preserve or normalize.
For a logical viewpoint if there is an <ignorable><source> </source></ignorable> entry it is very likely because it separates two segments that will still need that separation after merging. So a better default XLIFF processor behavior would be to either preserve or normalize.
Cheers,
-yves
From: [mailto:] On Behalf Of Ryan King
Sent: Thursday, February 18, 2016 4:09 PM
To: '' <>
Subject: [xliff] Question on xml:space handling
Hi all,
Yves logged two issues on the MS XLIFF OM github project (thanks Yves for testing!):
<data> made of spaces only is not preserved
https://github.com/Microsoft/XLIFF2-Object-Model/issues/13
<source> with only spaces are emptied on deserialization
https://github.com/Microsoft/XLIFF2-Object-Model/issues/11
I have no doubt that the first one is a bug since the default for <data> is preserve.
The second one is trickier. The default for <source> and <target> is to allow the application to decide. In this case, the OM is using .Net XmlReader, which removes whitespace by default. So, in order to preserve whitespace during serialization/deserialization, the user must set xml:space=”preserve” to override the default behavior of XmlReader.
So my question to this esteemed body of professionals: Should the MS XLIFF OM override the default behavior of XmlReader and preserve whitespace when xml:preserve=”default”?
Thanks,
Ryan
