Handle XML Schema changes without code changes

Question

Currently we have a XML Schema and the code reads the xml file, validates against the schema and save to database. In future there would be schema changes, how can the code handles them without needing to rewrite the code for new schema.

Thanks,

Let me give an example

<Products>
   <product id="1">
      <name> ABC </name>
      <desc> good one </desc>
   </product>
</products>

XPath mapping configuration

Table      Column     XPath
Product    id         //Products/product/id
Product    name       //Products/product/name
Product    desc       //Products/product/desc

Now the C# code reads id, name and desc and generates an insert statement based on the Mapping configuraiton

If the schema changes and new element is added say price and we would add that price to mapping, so the new insert statement that is generated includes price.

Will this work?

Answer 1

I hate parsing XML and loading it into objects. Due to this, you can try the following approach.

Create a C# object that represents the XML data you are talking about. Serialize that C# class, and viola you have an XML schema that is strongly typed. Also, if in the future you need additional schema changes, simply modify the C# class and reserialize and you're all set.

This also removes the need to parse the XML document (assuming you are utilizing it within the CLR), as you can simply reference the C# class and you can deserialize it back into memory without any parsing.

Answer 2

The way of handling something like this that immediately comes to mind would be to have a known good skeletal XML schema with no data in it, have the code parse and learn that schema, and then have it run on whatever arbitrary input you give it. When the XML schema changes, simply have a trusted user/admin go in and change the known good skeleton.

You should make sure your database can handle these changes without any extra prodding, and you should most definitely have at least a few tests that run regularly and throw off alerts if a problem is detected. One of the most dangerous elements in 'low maintenance' processes like these is that they often fail quietly and there's no way to tell they're broken!

I'm a little afraid I'm not getting your whole question because you added a bunch of tags that aren't obviously in your question, but hopefully this helps.

Answer 3

If the location for the XML data changes, unless you want to abstract the crap out of your XML file (include metadata in the document describing where to find things) you're out of luck. If your data elements will always be in the same place, all you have to do is keep your XSD file as a separate file, and change it when necessary to validate the document.