使用 xsd:any 实现可扩展模式
到目前为止，我一直通过定义具有“名称”和“值”属性的占位符元素来处理扩展，如下面的示例所示，
<root>
<typed-content>
...
</typed-content>
<extension name="var1" value="val1"/>
<extension name="var2" value="val2"/>
....
</root>
我现在计划切换到使用xsd：任何。如果您能帮助我选择最佳方法，我将不胜感激
- 如果我指定 processContents="strict"，则 xsd:any 相对于我以前的方法有什么附加值
- EAI/ESB 工具/库可以针对任意元素执行 XPATH 表达式吗？ return
- 我看到各种绑定工具在生成绑定代码时单独处理此问题。如果我包含 namespace="http://mynamespace" 并在代码生成期间提供“http://mynamespace”的架构，情况是否相同？
- 这符合 WS-I 标准吗？
- 我有什么遗漏的地方吗？
谢谢
Until now, I've been handling extensions by defining a placeholder element that has "name" and "value" attributes as shown in the below example
<root>
<typed-content>
...
</typed-content>
<extension name="var1" value="val1"/>
<extension name="var2" value="val2"/>
....
</root>
I am now planning to switch to using xsd:any. I'd appreciate if you can help me choose th best approach
- What is the value add of xsd:any over my previous approach if I specify processContents="strict"
- Can a EAI/ESB tool/library execute XPATH expressions against the arbitrary elements I return
- I see various binding tools treating this separately while generating the binding code. Is this this the same case if I include a namespace="http://mynamespace" and provide the schema for the "http://mynamespace" during code gen time?
- Is this WS-I compliant?
- Are there any gotchas that I am missing?
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
<xsd:any processContents="strict">gives people the ability to add extensions to their XML instance documents without changing the original schema. This is the critical benefit it gives you.<xsd:any>or not.<xsd:any>very elegantly. This is understandable, since they have no information about what it could contain, so they'll usually give you an untyped placeholder. It's up the the application code to handle that at runtime. JAXB is particular (the RI, at least) makes a bit of a fist of it, but it's workable.<xsd:any>makes life a bit harder on the programmer, due to the untyped nature of the bindings, but if you need to support arbitrary extension points, this is the way to do it. However, if your extensions are well-defined, and do not change, then it may not be worth the irritation factor.关于第3点
这对应于 @XmlAnyElement JAXB 中的注释。行为如下：
@XmlAnyElement - 全部保留为 DOM 节点
如果使用此注释对属性进行注释，则 XML 文档的相应部分将保留为 DOM 节点。
@XMLAnyElement(lax=true) - 将已知元素转换为域对象
通过设置 lax=true，如果 JAXB 具有与该 QName 对应的根类型，那么它将转换该块到域对象。
Regarding point 3
This corresponds to the @XmlAnyElement annotation in JAXB. The behaviour is as follows:
@XmlAnyElement - Keep All as DOM Nodes
If you annotate a property with this annotation the corresponding portion of the XML document will be kept as DOM nodes.
@XMLAnyElement(lax=true) - Convert Known Elements to Domain Objects
By setting lax=true, if JAXB has a root type corresponding to that QName then it will convert that chunk to a domain object.