3

如何在 Java 中处理不断发展的 XML 模式？我有一个用例，我必须在 Java 应用程序中支持一组旧的和不断发展的 XML 模式（即支持 Foo v1、v2、v3、v4、v5）。

我的用例包括 - 读取针对不同版本的 Foo XML 模式编写的所有 Foo XML 内容 - 合并可能以不同版本编写的 Foo XML 内容与使用不同版本的 OVAL XML 模式（即将 Foo v1 与 Foo v5 合并）。

Foo XML 模式相当复杂，并且存在已知的向后兼容性问题，因此 Foo v1 XML 内容可能无法使用 Foo v3 XML 模式验证 XML 模式。

我想到了 2 种方法 1) 使用诸如 JAXB 之类的 Java XML 数据绑定，并为每个版本的 XML 模式生成一组绑定。以 Foo XML 模式为例，我将为 Foo XML 模式 v1 到 v5 生成 5 组绑定。挑战在于如何将 Foo XML 内容的版本与 XML 内容的另一个版本合并。

2) 创建一组 Java 数据模型并使用 SAX、DOM、JDOM 手动解析它，并尝试解决我可能遇到的所有向后兼容性问题。现在的挑战是我必须在没有 JAXB 帮助的情况下自己解析 XML。

我想就处理不断发展的 XML 模式的最佳方法获得一些建议。Java XML 数据绑定是正确的前进路径，还是创建我自己的 Java 数据模型并手动解析它？

4

3 回答 3

3

根据我的经验，最重要的是数据模型而不是输入格式。如果您可以提供一个干净的模型并抽象出不同输入的所有讨厌的东西，那么您最终会得到一个更干净、更易于管理的代码线。

鉴于单个文档的版本往往是增量的，如果您自己编写解析器，您可能可以获得相当多的代码重用，或者您可以创建并行 JAXB 包来处理与另一个类配对的每种格式以转换该版本特定模型到您的顶级模型。

于 2013-01-10T22:48:31.013 回答
1

Schema evolution is the big drawback of the data binding approach. If your schema is not stable, then data binding is going to be a hassle, as you have discovered. There's a basic conflict here: XML is designed to be flexible ("semi-structured") in the data structures it handles, and Java is not. Are you sure that data binding is the right approach for you? Might it not be better to use a programming language designed for XML, such as XSLT or XQuery?

于 2013-01-11T09:27:21.427 回答
1

我们为每个新版本提供 Java 转换器。他们能够从各自的先前版本进行转换。我们将 v1 作为 XML，使用 JAXB 将其转换为 Java，然后转换为数据模型 v2、v3、v4、v5。转换器都受版本控制，是每个已发布工件的一部分。

此外，我们支持 v2-1、v2-2 等分支。这要求我们有从分支 n 到下一个主要 n+1 的转换器（例如 v2-2 -> v3）。在某些时间间隔，我们停止支持“非常旧”的分支。

于 2013-01-10T22:49:44.623 回答