版本化文件格式的最佳/最便携方法

发布于 2024-09-17 05:08:27 字数 1061 浏览 5 评论 0原文

这个问题涉及 XML 模式和文件。

假设我正在开发一个具有基于文件界面的桌面应用程序,即用户将其进度存储在磁盘上的文件中 - 这对于绝大多数生产力应用程序以及更多应用程序来说都是相当标准的。该文件本质上是 XML,其架构通过某种方式存储在应用程序中。

众所周知,随着新功能的添加,架构很可能会发生变化。因此,为了严格的兼容性管理,我想确保程序可以通过检查文件来判断它最后保存在哪个确切的架构版本下,并通过一个或多个转换自动管道化文件以将其表示为工作文件格式,即最新的模式修订版。

实现此类功能的最佳实践方法是什么?在我看来,最简单的方法是为每个修订使用不同的架构命名空间,并确保至少文件的文档元素引用正确的命名空间。在我看来,这种方法的问题在于,它破坏了文件结构之间的关系 - 即,在修订版 x 下保存的文件的文档元素与下的相应元素相同类型修订版 y,但据应用程序所知,除非我明确告知,否则它们是无关的。然而,我敢说这种逻辑是 XML 名称空间存在的部分原因,所以老实说我不确定。那么你说呢?

编辑#1

进一步检查后发现,XML 模式本身就提供了“版本”属性。这可能是 .Net 中 XmlSchema 类型的字符串属性“Version”的来源,这是我想要的平台。这一切都很好,但是让 i) 我的文件和 ii) 我的应用程序尊重这个值是另一回事。正如 kbrimington 所建议的那样,在应用程序文件中强制使用“架构版本”属性是很简单的。然后,我只需将加载的 xml 文件中的版本属性与模式进行匹配,运行验证,然后让应用程序适当地/礼貌地责备用户/勇敢地挣扎。

编辑 #2

如果有人感兴趣,我会在架构上使用“版本”属性,并将其与应用于包装器的自定义属性相匹配。包装器从项目资源文件中检索表示架构的字符串(将进行检查以确保架构的版本与属性指定的版本匹配)。 main() 所做的第一件事是构建要使用的模式查找表,按版本索引,使用反射来检查可用的版本包装器类型。这听起来像是一种过度设计的做事方式,但我试图提前思考并通过使用几个可以插入新功能的任意步骤来构建冗余和灵活性。可能的改进包括实现自定义资源管理器类型来回避此处描述的一些 Heath-Robinson 功能。

This question concerns XML schemas and files.

Suppose I am developing a desktop application with a file-based interface, i.e. the user stores their progress in a file on disk - pretty standard for the vast majority of productivity applications and many more besides. The file is fundamentally XML, whose schema is stored by some means or another within the application.

It is acknowledged that the schema is very likely to change as new features are added. Therefore, for rigorous compatibility management, I'd like to make sure that the program can tell by inspecting the file which exact schema version it was last saved under, and automatically pipeline the file through one or more transforms to express it as the working file format i.e. the most recent schema revision.

What is the best-practice way to implement this kind of functionality? The simplest method seems to me to use a different schema namespace for each revision and ensure that at least the document element of the file references the correct namespace. The trouble with this approach is that, to my mind, it breaks the relationship of file structures to one another - i.e. the document element of a file saved under revision x is the same type as the corresponding element under revision y, but as far as the application knows, they're unrelated unless I explicitly tell it otherwise. However, I dare say that this sort of logic is part of the reason for the existence of XML namespaces, so I'm honestly not sure. What say you, SO?

edit #1:

It appears upon further inspection that XML Schema provides a 'version' attribute natively. This is presumably the source of the string property "Version" for the XmlSchema type in .Net, which is my intended platform. This is all well and good, but getting i) my files and ii) my application to respect this value is another matter. It would be trivial, as kbrimington suggests, to mandate a 'schema version' attribute in application files. Then I simply match the version attribute from a loaded xml file to a schema, run validation, and have the application throw a fit/politely chide the user/bravely struggle on as appropriate.

edit #2:

In case anyone is interested, I have gone with using the 'version' attribute on the Schema, and matching this to a custom Attribute which is applied to a wrapper. The wrapper retrieves a string from a project Resources file representing the schema (there will be a check to ensure that the version of the schema and the version specified by the attribute matches). The first thing that main() does is build a lookup table of schemas to use, indexed by version, using Reflection to examine the available version wrapper types. This sounds like an overengineered way of doing things, but I'm trying to think ahead and build redundancy and flexibility in by using several arbitrary steps into which new functionality could be inserted. Possible improvements include implementing a custom resource manager type to sidestep some of the Heath-Robinson functionality described here.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

许仙没带伞 2024-09-24 05:08:28

许多文件格式(XML 等)都考虑了向前兼容性。即使位图格式在标头中也有定义标头大小的元素,以便可以使用不同的标头结构定义新的位图格式。

我建议至少定义一些关于文件格式的不变规则。正如您所建议的,版本指示器可以是名称空间、文件扩展名,甚至只是文档中已知位置的元素。

如果您可以说“无论架构如何,这里总会有一个 元素,我可以用它来确定验证时使用哪个版本的架构...”,那么问题就解决了。关键是要有一些可以依赖的东西来确定版本,无论其他可能发生什么变化。

Many file formats, XML and otherwise, put some thought toward forward compatibility. Even the bitmap format has elements in the header that define how large the header is so that new bitmap formats can be defined with a different header structure.

I would recommend defining at least some invariant rules about your file format. A version indicator could be a namespace, as you suggested, a file extension, or even just an element in a known position in the document.

If you can say "There will always be a <version> element here, regardless of schema, which I can use to determine which version of the schema to use when validating...", then the problem is solved. The point is to have something you can depend on to determine the version, regardless of what else might change.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文