将 xsd:any 用于可扩展架构答案

【问题标题】：using xsd:any for extensible schema将 xsd:any 用于可扩展架构
【发布时间】：2011-02-03 02:37:39
【问题描述】：

到目前为止，我一直在通过定义具有“name”和“value”属性的占位符元素来处理 extensions，如下例所示

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

我现在打算改用 xsd:any。如果您能帮我选择最佳方法，我将不胜感激

如果我指定 processContents="strict"，xsd:any 与我以前的方法相比有什么附加值
EAI/ESB 工具/库能否针对我返回的任意元素执行 XPATH 表达式
我看到各种绑定工具在生成绑定代码时分别处理这个问题。如果我包含 namespace="http://mynamespace" 并在代码生成期间为“http://mynamespace”提供架构，情况是否相同？
此 WS-I 是否兼容？
有什么我遗漏的问题吗？

谢谢

【问题讨论】：

标签： java web-services xsd jaxb xmlbeans

【解决方案1】：

使用<xsd:any processContents="strict"> 使人们能够在不更改原始模式的情况下向他们的XML 实例文档添加扩展。这是它为您带来的关键好处。
是的。与操作实例相比，工具并不关心架构是什么样子，而是他们查看的实例文档。对他们来说，是否使用<xsd:any> 并不重要。
绑定工具通常不能非常优雅地处理<xsd:any>。这是可以理解的，因为他们没有关于它可以包含什么的信息，所以他们通常会给你一个无类型的占位符。由应用程序代码在运行时处理它。 JAXB 是特别的（至少是 RI），它有点用力，但它是可行的。
是的。这是非常好的 XML Schema 实践，WS-I 支持所有有效的 XML Schema
<xsd:any> 由于绑定的无类型特性，程序员的生活有点困难，但是如果您需要支持任意扩展点，这就是实现它的方法。但是，如果您的扩展是明确定义的，并且不会更改，那么它可能不值得刺激因素。

【讨论】：

@skaffman - 关于第 1 点。假设我将 xsd:any 与“strict”和 namespace="xyz" 一起使用，并与我的客户共享文档。我的客户也在使用相同的模式对我发送给他的 xml 执行验证。如果将来我向我的实例文档添加一个新元素（不将其添加到架构中），那么即使客户端正在针对 OLD 架构执行验证，为什么验证（因为严格）没有失败？
@Pangea：假设的，还是真的发生了？
@skaffman - 如果您询问用例，那么这不是假设。但是，如果您询问验证是否失败，那么是的，这是假设性的。我试图正确理解“严格”验证的真正概念。原谅我的无知:- (
@Pangea：“严格”表示扩展的架构定义必须存在，并且数据必须针对这些架构进行验证。 “lax”意味着如果扩展的模式确实存在，那么数据必须验证。 “跳过”表示不执行验证。
@skaffman - 如果是这种情况，那么当我们使用“严格”时，向模式中添加新元素应该无法通过客户端验证，对吧？

【解决方案2】：

关于第 3 点

绑定工具一般不处理非常优雅。这是可以理解，因为他们没有关于它可以做什么的信息包含，所以他们通常会给你一个无类型的占位符。这是上处理它的应用程序代码运行。 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

【讨论】：