如何管理基于Xml的文档的不同不兼容格式

我有一个应用程序,它以基于Xml的格式保存文档(比如word文档)——目前从xsd文件生成的C#类用于读取/写入文档格式,直到最近我不得不更改文档格式时,一切都很好。我关心的是作为我的应用程序的未来版本的向后兼容性 需要

例如,假设我更改文档的模式以在某处添加一个(可选)额外元素,那么我的应用程序的旧版本将忽略额外元素,并且不会出现任何问题:

<doc>
    <!-- Existing document -->
    <myElement>Hello World!</myElement>
</doc>

但是,如果进行了突破性的更改(例如,将属性更改为元素或元素集合),则我的应用程序的旧版本应忽略此元素(如果该元素是可选的),或者通知用户他们正在尝试读取使用我的应用程序的较新版本保存的文档。这也让我感到头疼,因为我的应用程序的所有未来版本都需要完全独立的代码来读取这两个不同的文档。

此类更改的一个示例是以下xml:

<doc>
    <!-- Existing document -->
    <someElement contents="12" />
</doc>

改为:

<doc>
    <!-- Existing document -->
    <someElement>
        <contents>12</contents>
        <contents>13</contents>
    </someElement>
</doc>

为了避免将来的支持难题,我想提出一个体面的策略来处理我将来可能进行的更改,以便我现在发布的应用程序版本能够在将来应对这些更改:

• 文档的“版本号”应该存储在文档本身中吗?如果是,应该使用什么版本控制策略?文档版本是否与.exe程序集版本匹配,或者是否应使用更复杂的策略(例如,主要版本更改表示中断更改,而次要版本增量表示非中断更改-例如额外的可选元素)
• 我应该使用什么方法来阅读文档本身,如何避免为不同版本的文档复制大量代码?
  • 尽管XPath显然是最灵活的,但它的实现比简单地用xsd生成类要复杂得多。
  • 另一方面,如果使用DOM解析,那么在源代码管理中,每次中断的更改都需要一个新的文档xsd副本,如果需要将修复应用于旧模式(仍支持旧版本的应用程序),则会导致问题。

此外,我在假设我所做的所有更改都可以分为两类,即“尖刻更改”和“非破坏性更改”,但我并不完全相信这是一个安全的假设。