这个问题涉及XML模式和文件。
假设我正在开发一个带有基于文件的界面的桌面应用程序，即用户将其进度存储在磁盘上的文件中 - 这对于绝大多数生产力应用程序而言非常标准，还有更多。该文件基本上是XML，其模式通过某种方式存储在应用程序中。
我们承认，随着新功能的添加，架构很可能会发生变化。因此，对于严格的兼容性管理，我想确保程序可以通过检查文件最后保存的确切模式版本来判断，并通过一个或多个转换自动管道化文件以将其表示为工作文件格式，即最新的架构修订版。
实施此类功能的最佳实践方法是什么？在我看来，最简单的方法是为每个修订使用不同的模式名称空间，并确保至少文件的document元素引用正确的名称空间。这种方法的问题在于，在我看来，它打破了文件结构之间的关系 - 即在修订版x下保存的文件的文档元素是相同的类型和下面的相应元素修订版y，但就申请人所知，除非我明确说明，否则它们是无关的。但是，我敢说这种逻辑是XML命名空间存在的部分原因，所以我老实说不确定。怎么说你呢？
编辑＃1 ：
进一步检查后，XML Schema本身提供了“版本”属性。这可能是.Net中XmlSchema类型的字符串属性“Version”的来源，这是我的预期平台。这一切都很好，但获得i）我的文件和ii）我的申请尊重这个价值是另一回事。正如 kbrimington 建议的那样，在应用程序文件中强制要求“架构版本”属性是微不足道的。然后我简单地将加载的xml文件中的version属性与模式进行匹配，运行验证，并让应用程序在适当的时候抛出一个适合/礼貌的用户/勇敢地挣扎。
编辑＃2 ：
如果有人感兴趣，我已经使用了Schema上的'version'属性，并将其与应用于包装器的自定义属性相匹配。包装器从表示模式的项目资源文件中检索字符串（将进行检查以确保模式的版本和属性指定的版本匹配）。 main（）所做的第一件事是构建一个要使用的模式的查找表，按版本索引，使用Reflection来检查可用的版本包装器类型。这听起来像是一种过度设计的做事方式，但我试图通过使用可以插入新功能的几个任意步骤来提前思考并建立冗余和灵活性。可能的改进包括实现自定义资源管理器类型以回避这里描述的一些Heath-Robinson功能。
答案 0 :(得分：2)
许多文件格式，XML和其他方式，都考虑了向前兼容性。甚至位图格式在标题中都有元素，用于定义标题的大小，以便可以使用不同的标题结构定义新的位图格式。
我建议至少定义一些关于文件格式的不变规则。版本指示器可以是您建议的命名空间，文件扩展名，甚至只是文档中已知位置的元素。
如果您可以说“这里总会有<version>元素 ，无论架构如何，我都可以使用它来确定验证时使用哪个版本的架构... “那么问题就解决了。关键是要有一些你可以依赖的东西来确定版本，无论其他什么可能改变。