Ensuring backward compatibility for dynamically loaded types

Question

I have a type which is dynamically loaded. The variable part is read from an xml field in db. E.g.

class SomeClass 
{
   public int Id {get; set;}
   public string Name {get; set;}
   public string Url {get; set;}
}

the name and url part are contructed by reading an xml section of

<element>
    <name>Name</name>
    <type>string</type>
</element>
<element>
    <name>Url</name>
    <type>string</type>
</element>

Later on the class would be dynamically loaded to:

class SomeClass 
{
   public int Id {get; set;}
   public string Name {get; set;}
   public string Url {get; set;}
   public string FallbackUrl {get; set;}
}

from

<element>
    <name>Name</name>
    <type>string</type>
</element>
<element>
    <name>Url</name>
<    type>string</type>
</element>
<element>
    <name>FallbackUrl</name>
    <type>string</type>
</element>

How is backward compatibility maintained?Meaning if I extend later on the class, how can I assure that when the newer version when deployed on older version dbs(which sometime may be the case) would not crash?

Answer 1

Have a read: http://www.xfront.com/Versioning.pdf

In particular (abstract):

Consider two cases for changes to XML schemas:

Case 1. The new schema changes the interpretation of some element. For example, a construct that was valid and meaningful for the previous schema does not validate against the new schema.

Case 2. The new schema extends the namespace (e.g., by adding new elements), but does not invalidate previously valid documents.

Some options for identifying a new a schema version are to:

1. Change the (internal) schema version attribute.
2. Create a schemaVersion attribute on the root element.
3. Change the schema's targetNamespace.
4. Change the name/location of the schema.

XML Schema Versioning Best Practices

[1] Capture the schema version somewhere in the XML schema.

[2] Identify in the instance document, what version/versions of the schema with which the instance is compatible.

[3] Make previous versions of an XML schema available.

[4] When an XML schema is only extended, (e.g., new elements, attributes, extensions to an enumerated list, etc.) one should strive to not invalidate existing instance documents

[5] Where the new schema changes the interpretation of some element (e.g., a construct that was valid and meaningful for the previous schema does not validate against the new schema), one should change the target namespace.