xmlns namespace resilency

Question

I receive data from a server as utf-8 encoded xml messages that look like

<?xml version="1.0" encoding="utf-8"?>
<Data namespace="http://example.com/data">
...
</Data>

The noteworthy thing about the example is that the "namespace" qualifier should in reality be the "xmlns" qualifier specifying the default xml namespace. The code for serialization / deserialization was (auto-) generated from a schema definition file, and both the xsd as well as the documentation that came along with it pretty much confirm that this is a bug.

However, this also means that the Data object now lives in the global / empty namespace (xmlns="") and the autogenerated code fails with the typical "There is an error in XML document ..." and "<Data xmlns=''> was not expected." kind of exception that the XmlSerialzier throws during deserialization that people see when the namespaces of the deserialization attributes / code and the xml document do not match.

While it is fairly easy to modify the autogenerated code and "hotfix" the Namespace definitions to e.g.

[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="", IsNullable=false)]
public partial class Data {

what I really wish is namespace resilency - that is, if at some point in the future the issue is fixed by the guys that provide me the data, I do not wish to be forced to adapt the Namespace definitions in the code again (any xmlns change will break the deserialization code with the aforementioned exception).

That is, I want code that is able to handle both the faulty xml above as well as e.g.

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns="http://example.com/data">
...
</Data>

or even (e.g. if they decide to go "backwards compatible")

<?xml version="1.0" encoding="utf-8"?>
<Data xmlns="http://example.com/data" namespace="http://example.com/data">
...
</Data>

What options do I have?

Answer 1

You were given "XML" that was had a big. You could have used XML Transforms to correct it before deserializing.