使用xsd:any进行可扩展模式的架构设计

Question

到目前为止，我一直通过定义一个占位符元素来处理扩展，该元素具有如下示例中所示的"name"和"value"属性。

<root>
   <typed-content>
      ...
   </typed-content>
   <extension name="var1" value="val1"/>
   <extension name="var2" value="val2"/>
....
</root>

我现在计划开始使用 xsd:any。如果我指定processContents="strict"，相比之前的方法，xsd:any有什么增值作用呢？

1. 如果我返回任意元素，EAI/ESB工具/库能否对其执行XPATH表达式？
2. 我发现各种绑定工具在生成绑定代码时会单独处理它。如果我包含一个 namespace="http://mynamespace" 并在代码生成时提供“http://mynamespace”的模式，是否也是这种情况？
3. 这符合WS-I标准吗？
4. 我有没有忽略任何需要注意的问题？

谢谢！

- Aravind Yarram

Answer 1

1. 使用<xsd:any processContents="strict">可以使人们在不改变原始模式的情况下向他们的XML实例文档添加扩展。这是它带给你的关键好处。
2. 是的。操作实例的工具并不关心模式的样子，而是关注实例文档。对他们来说，使用<xsd:any>与否并不重要。
3. 绑定工具通常不能很优雅地处理<xsd:any>。这是可以理解的，因为它们没有关于它可能包含的信息，所以它们通常会给您一个未经分类的占位符。这需要应用程序代码在运行时进行处理。JAXB特别（至少在RI中）做得不太好，但还是可行的。
4. 是的。这是完全良好的XML模式实践，并且WS-I支持所有有效的XML模式。
5. <xsd:any>使程序员的工作有点困难，由于绑定的未经分类的性质，但如果您需要支持任意扩展点，那么这就是做法。然而，如果您的扩展是明确定义并且不会更改，则可能不值得烦恼。

- skaffman

---

@skaffman - 就第一点而言，假设我使用带有“strict”和命名空间=“xyz”的xsd:any，并与客户共享文档。我的客户也使用相同的模式对我发送的xml进行验证。如果将来我向实例文档添加新元素（而不将其添加到模式中），那么由于严格性，为什么验证不会失败，即使客户端正在针对旧模式执行验证？ - Aravind Yarram

@Pangea：假设，还是这实际上正在发生？ - skaffman

@skaffman - 如果您在询问用例，则它并非假设。但如果您在询问验证是否失败，则是的，这是假设性的。我正在尝试正确理解“严格”验证的真正概念。对我的无知请原谅 :- ( - Aravind Yarram

@Pangea：“strict”表示必须存在扩展的架构定义，并且数据必须针对这些架构进行验证。“lax”表示如果扩展的架构确实存在，则数据必须进行验证。“skip”表示不执行任何验证。 - skaffman

如果是那样的话，@skaffman，当我们使用“strict”时，向模式添加一个新元素应该会导致客户端验证失败，对吗？ - Aravind Yarram

Answer 2

关于第三点

绑定工具通常处理不太优雅。这是可以理解的，因为它们没有关于可能包含的信息，所以它们通常会给您一个未经类型化的占位符。在运行时，应用程序代码需要处理它。JAXB特别（至少是RI）对此进行了一些努力，但它是可行的。

这对应于JAXB中的@XmlAnyElement注释。其行为如下：

@XmlAnyElement - 保留所有DOM节点

如果您使用此注释注释属性，则将保留XML文档的相应部分作为DOM节点。

@XMLAnyElement(lax=true) - 将已知元素转换为域对象

通过设置lax=true，如果JAXB具有与该QName对应的根类型，则它将将该块转换为域对象。

• http://bdoughan.blogspot.com/2010/08/using-xmlanyelement-to-build-generic.html

- bdoughan