I have Serialized Instance Data from a 3rd party application, it is in XML and I want to load it into an object and work with it.
I generated a XSD off the the XML and it works great. The XML represents the state of a form the user filled out. The first time I generated the XSD, I hadn't filled out the whole form -the form instance being what is serialized. I went back and filled out the whole form, so that all the controls I need are present, and created a new XSD, and used XSD2Code to generate a new class.
Question is, if I don't know what all of the serialization looks like for the form itself - is my approach flawed from the beginning or is it the best that I can do?
Is sticking interfaces on the Controls I need on the generated classes a good way to mitigate changes in the characteristics of the underlying instance data?
I know now that I at least need to be able to work with certain things in the form and they are all present. If in the future more stuff is added to the form, I can regenerate the XSD and build on already present implementation.
Is this a sound approach, in that I will create a partial class which specifies on the generated classes that they at least implement the things I need?
Is there anything you can foresee that will challenge the code that I write that works with these interfaced types in the instance class?
Is there a way to have my de-serialization methods, not break if theres stuff that it isn't expecting?
Ignorance is generally not a best practice.
If they are sending you the XML, then don't they know what shape it is? Don't they have an XSD?
At the very least, can't they provide you with a document on the format?
In any case, you need an XSD that represents what they will actually be sending you, so you can generate classes that match what you will actually receive. It's even possible that you'll find that the XML structure they are sending you does not match any possible set of classes, and that you will need to deserialize "manually".