views:

161

answers:

1

Folks,

We have been using OpenXml APIs found in System.IO.Packaging for creating a package file that contains some Xml/Binary files, hence the package is some how structured as below:

Package/
 -/DataFolder1/an xml file.xml
 -/DataFolder2/another xml file.xml
 -/Bin/other binar files

This has been used for version 1.0 of the application and it is doing quite well.

We are in the planning phase of V2 anticipating the following changes in the package structure :

  • there might be additional files in the package

  • there might be some amendments in the Xml schema of existing files (example ... new nodes )

  • there might be some changes in the Xml schema of the existing files (example ... removing nodes or changing the data type)

I would appreciate any advice based on real life experience tackling backward/forward computability between the file formats and the application itself, so we can have both the application and its file format evolve independent on each other.

+1  A: 

Without further knowing your application it is difficult to advise you. However, different versions of you custom XML could be handled by adding an attribute containing the version number or - if there have been major changes in the schema - by changing the namespace to contain a new version number.

If you want to have a look at how OpenXML itself deals with versioning and extensibility I suggest that you read Part 5 of the OpenXML specification:

Office Open XML - Part 5: Markup Compatibility and Extensibility

0xA3