我应该使用 XML 文件的命名空间来识别其版本吗
我正在使用 DataContractSerializer 将具有 DataContract 和 DataMember 属性的类序列化为 XML 文件。我的类稍后可能会发生变化，因此序列化文件的格式也可能会发生变化。我想用版本号标记我保存的文件，这样我至少知道每个文件的版本。我仍在决定如何以及是否要添加将旧格式的文件迁移到新格式的功能。但现在我很乐意识别版本不匹配的情况。
XML 文件的命名空间是否是存储文件版本的正确位置？我正在考虑将 DataContract 属性归因于我的类，如下所示。
[DataContract(Name="MyClass",Namespace="http://www.mycompany.com/MyProject/1.0
public class MyClass
...
然后，如果 MyClass 更改，我会更改名称空间...
[DataContract(Name="MyClass",Namespace="http://www.mycompany.com/MyProject/2.0)]
public class MyClass
...
这是 XML 名称空间的正确用法，还是有另一种更喜欢的方法来保存 XML 文件的版本？
I'm using DataContractSerializer to serialize a class with DataContract and DataMember attributes to an XML file. My class could potentially change later, and thus the format of the serialized files could also change. I'd like to tag the files I'm saving with a version number so I at least know what version each file is from. I'm still deciding how and if I want to add functionality that will migrate files in older formats to later formats. But right now I'd be happy with just identifying a version mismatch.
Is the namespace of the XML file the correct place to store the version of the file? I was thinking of attributing my class with a DataContract attributes as follows.
[DataContract(Name="MyClass",Namespace="http://www.mycompany.com/MyProject/1.0
public class MyClass
...
Then later if MyClass changes I would change the namespace...
[DataContract(Name="MyClass",Namespace="http://www.mycompany.com/MyProject/2.0)]
public class MyClass
...
Is this the correct usage of XML namespaces, or is there another more prefered way to save the version of an XML file?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以这样做，但是从 XML Infoset 的角度来看，数据的 XML 表示形式在不同版本之间变得完全不同（其中命名空间是元素的限定名称的一部分），因此您既不能向后也不能向前兼容性。
现在，XML 的一个优点是它可以通过 XPath 和 XSLT 等技术以向前兼容的方式轻松进行处理 - 您只需选择可以解释的元素，并保留任何您无法识别的元素。但这需要具有相同含义的元素在版本之间保留相同的名称（包括命名空间）。
一般来说，最好使架构向前兼容。如果您无法实现这一点，您可能仍然希望提供与现有工具尽可能多的兼容性（通常更容易实现针对仅读取数据的工具的兼容性，而不是与同时写入数据的工具的兼容性）。因此，在这种情况下，您应该避免存储版本号，而只是尝试解析您给出的任何内容，如果输入肯定格式错误，则发出错误信号。
如果您绝对必须打破两个方向的兼容性并从头开始，那么处理 WCF 数据协定的建议方法确实是通过更改命名空间，如 数据合同版本控制的最佳实践。其中也有一些细微的变化，例如在 URL 中使用发布日期而不是版本号（W3C 的架构非常喜欢这样做），但这些大多是风格上的。
You can do it this way, but then the XML representation of your data becomes completely different from version to version from XML Infoset point of view (in which namespace is the part of the qualified name of the element), so you have neither backwards nor forwards compatibility.
Now, one advantage XML has is that it can be easily processed in a forward-compatible way with technologies such as XPath and XSLT - you just pick the elements you can interpret, and leave anything you don't recognize as is. But this requires elements with the same meaning to retain the same name (including namespace) between versions.
In general, it is best to make your schemas forward-compatible. If you can't achieve that, you might still want to provide as much compatibility as possible with existing tools (it is often easier to achieve compatibility against tools which only read data, rather than with those which also write it). Consequently, you avoid storing version number in such cases, and just try to parse whatever you're given, signalling an error if the input is definitely malformed.
If you come to the point where you absolutely must break compatibility in both directions and start from a clean slate, the suggested way of handling this for WCF data contracts is indeed by changing the namespace, as described in best practices on data contract versioning. There are a few minor variations there as well, such as using publication date instead of version number in the URL (W3C is quite fond of this for their schemas), but these are mostly stylistic.