Aug 30, 2016 at 11:05 PM
Edited Aug 30, 2016 at 11:09 PM
I've been working with this library for a over a year and absolutely love it.
However, it still seems buggy to have to unescape a field in the POCO classes after it has already been deserialized from the generated xml.. In my mind, everything should be unescaped at this point.
Take this nm1 segment for example
this will get serialized into "malformed" xml while parsing that looks like this
I assume the way you would have liked the xml to look is like this:
the reason it get's malformed lies in the calls like this: element.SetValue(SecurityElement.Escape(dataElement.Value) ?? string.Empty)
SecurityElement.Escape escapes the string value with the " and then the XmlWriter escapes the value again when writing to xml because it encounters the ampersands in (") and escapes that as ("e;)
When the xml serializer deserializes the malformed xml into a POCO hierarchy the value for the .....S_NM1_MemberName.D_NM104_MemberFirstName field is "JOHN "JACK"" because the only thing that is escaped in the xml is the ampersand. Once
the ampersand is unescaped you have two more escaped characters to contend with.
static void Main(string args)
XElement elem = new XElement("D_NM104_MemberFirstName");
elem.SetValue("JOHN & JACK");
<D_NM104_MemberFirstName>JOHN & JACK</D_NM104_MemberFirstName>
Note the quotes do not need to be escaped because they are not between quotes.
However < and > do get escaped as well as the ampersand because they would break the the xml if written as their literal text
I believe this demonstrates that there isn't a reason to use the security element to perform any escaping when converting from edi into xml as that behavior already happens in the .NET xml libraries which you are using to build the xml document.