XQuery 作为xml数据转换引擎的软肋

当前很多的xml数据转换框架运行在XQuery引擎上，尤其是主流的SOA厂商产品，如oracle ESB等。

 

先不提performance问题，就功能范围来讲，XQuery确实提供了丰富的数据转换函数，并允许提供自定义转换函数，能够支持非常复杂的xml结构的转换（当然，这种复杂度实际上应当在进行数据模型架构设计时由架构师尽量避免）。

 

但个人认为，XQuery是一种中立的与编程语言无关的纯粹的面向xml的查询&转换语言，其应用场景定位于纯粹的xml语境中，其语言的操作范围仅限于XQuery运行时定义在XQuery语境中的内容，包括xml节点，变量，自定义函数等。

 

这种设计方法从一开始就避开了现实的业务需求语境，考虑的应用场景并不全面。XQuery是一种运行环境比较封闭，语法功能相对比较弱的语言，并未提供与当前程序运行环境相对接的规范，比如在XQueuy中调用java的自定义方法，这就对比较复杂业务的转换提供了一点障碍，需要进行二次转换才能完成整个转换场景。比如在xml转换过程中，需要对productID进行转换，转换成另外一个系统的product编码，通常是提供一个二维关系表来建立两种编码的mapping关系，转换过程中通过lookup方法，查找出目标系统编码。对此类需求，XQuery就不能很好的满足，因为将这种编码mapping关系配置在XQuery中显然是太合理的。

 

不清楚未来XQuery会不会在规范中增加调用（有点像callback的方法）运行环境的语法规范，但个人认为XQuery作为企业应用集成的转换框架，并不能提供完整的解决方案，如果进行二次转换，势必对性能产生影响。

 

注：有观点认为，包含业务信息的转换应当放在Adapter组件中，而不应该在服务总线上，此处本文并不针对架构方法进行讨论，仅就XQuery的功能进行讨论。