揭穿 XQuery 的神话和误解-xml教程
转载自：互联网 作者：cd3c.com
您正在看的xml教程是:揭穿 XQuery 的神话和误解。
XQuery 给软件架构师和开发人员带来了很多希望，因为大大减少了建立使用 XML 的服务所需要编写的代码量。您也许认为 XQuery 所做的一切很容易理解，但是在 XQuery 的软件开发社区中仍然存在着错误的想法和误解。Frank Cohen 在本文中详细剖析和澄清了围绕着 XQuery 的很多神秘色彩和误解。
如果您在使用 XML、Web 或者面向服务的架构（Service Oriented Architecture，SOA），那么很可能会从 XML Query (XQuery) 标准的制定中受益。虽然 XQuery 还未批准为正式标准，但已经有几十种实现每天都在帮助软件架构师和开发人员了。即将形成的 XML 文档查询标准包括了下一代 XML 选择语言（XPath 2）、XML 序列化、全文检索和功能性 XML 数据建模。这样规模的项目免不了有很多神话和误解需要揭穿。下面是围绕着 XQuery 的一些常见的神话和误解。
误解：数据库公司将 XQuery 视作其核心业务的直接对手
数据库公司将 XQuery 看作一个机会，与其核心解决方案互相补充。
对于软件架构师和开发人员而言，XQuery 提高了生产率，增加了敏捷性。工具供应商迫切希望支持 XQuery 是合情合理的。
对于开发人员来说，XQuery 很像 SQL，自然而然地对两者加以比较。何况越来越多的数据正使用 XML 标记，这就迫使数据库公司在产品中增加 XML 存储、持久性和查询的能力。XQuery 拥有如此众多的开发人员支持，以至于 IBM 和 Oracle 将它们的角逐放在一旁，转而扩展其核心数据库产品以提供 XQuery 能力。
数据库公司也看到了成为第一个充分利用 XML 格式的数据库供应商（从而最终成为市场霸主）所带来的机会。 目前存储在关系数据库中的数据按照行和字段进行了规格化。在 XML 世界中，每一行包含无限多个字段，每个字段都是父/子层次结构中的一部分。最先提供高性能和 XQuery 灵活性的供应商将赢得一个巨大的新市场。
一个证据是，XQuery 将 IBM 和 Oracle 团结在一起（不再是凶狠的对手），合作提出 JSR 225（参阅参考资料）， XQuery API for Java (XQJ)。在 .NET 这一边，Microsoft 和 IBM 共同向万维网联盟（W3C）提交了 XQuery 测试包。
神话：XQuery 将代替 XSLT
XQuery 和 XSLT 都有足够多的开发人员支持，将共存下去。事实上，XQuery 1.0 和 XSLT 2.0 最新规范的开发是先后进行的。
XQuery 和 XSLT 交叉之处在于它们解决的问题：XML 数据转换、XML 集合联邦和 XML 数据高级查询。开发人员仍仍将看到关于这两种技术的争论，包括各种各样的神话和误解。比如，我常常听说 XQuery 能够一次查询多个不同的源文件，因此要比 XSLT 优越得多。事实上，XSLT 2.0 处理程序允许在输入队列中给出多个节点。 XSLT 1.0 有 document() 函数，可以在一次转换中访问多个源文件，XSLT 2.0 还支持新的 collection() 函数。我也常常听到这样的说法，虽然 XQuery 的语法看起来更好，但是缺少 XSLT 模板风格的模式匹配。虽然这也许是真的，但我坚信 XQuery 也会增加这一功能。最终，开发人员可以预期这两种技术的改进和竞争将使它们的功能和能力不相上下。
最后，还有开发人员头脑迟钝的问题。参加的那些 XSLT 会议让我感到，我并没有真正理解它。 XSLT 的转换语法并没有像 Java 和 Jython 中通常所用的 main() 或 start 方法。我有时候将 XSLT 看作一种脚本，说明并没有真正理解 XSLT。XQuery 看起来很像 SQL，解决了很多我不得不从书架上翻找答案的问题。
神话：XQuery 将代替 SQL
XQuery 最适合于 XML，就像 SQL 最适合于关系数据。 XQuery 为需要访问、挑选、集成和转换一个或多个 XML 集合的应用程序提供了类似于 SQL 的查询能力。虽然 XML 的狂热者可能将世界上的一切都看成是用 XML 标签编码的，单关系数据库模型仍然根深蒂固，世界上大部分数字数据是用由行和列组成的表来进行编码的。SQL 不会很快地消失。相反已经出现 XQuery 扩展，将 SQL 调用的结果看作是 XML 文档集合的一部分。
如上所述，XQuery 对于 XML 就像 SQL 对于关系数据库。但是，有些时候甚至相对于关系数据库而言，XQuery 更容易使用。比方说，对于一般开发人员，使用 SQL 创建输出结果为新 XML 文档的多表外连接查询要比编写 XQuery 复杂得多。
XML 的普及已经迫使标准团体工作组扩展 SQL 规范，以便纳入 XML 处理功能。 SQLX Group、INCITS H2 小组和 ISO/IEC JTC1/SC32/WG2 的 SQL/XML 标准化都在致力于扩展 SQL 标准，使其能够处理 XML 数据。
误解：采用 XQuery 必须放弃过程性编程而转向面向对象编程
对于 XQuery 来说，过程性脚本语言和面向对象的编程语言都是一样的。如果愿意编写 PHP 脚本，仍然可以继续这样做。多数现有的编程语言都有 XQuery 实现。
XQuery 给开发人员带来的好处是减少了执行查询所需要的代码量。有时候关系数据在两个或更多的数据库中，开发人员需要生成报表来显示两个数据库的并。喜欢使用 Python 这类过程性编程语言的开发人员可能要编写 100 或更多代码行来检索、解析和处理数据。当然也可以编写几行 XQuery 来完成。
神话：XQuery 比 JDOM、JAXP 和其他 XML 解析 API 更难用
XQuery 用于 XML 数据并不比 XML 解析 API 更难。JDOM、JAXP 以及其他 XML 解析 API 提供了处理 XML 数据的 Java 代码和方法。很多面向对象的设计模式都准备编写处理 XML 文档复杂性的对象。编写 Java 对象需要时间、精力和专门的技能。底层 XML 数据格式的任何细微变化都需要修改对象。XQuery 的拥护者可以肯定地说，和使用 JDOM 编写 Java 对象相比，XQuery 脚本能够更快地发现应用程序需要表示的 XML 数据。另外，很多 XQuery 库都提供了 Java 接口，因此可以在 Java 类中编写 XQuery 代码来获得结果集，就像调用一个方法一样。然后让 Java 类处理结果。
神话：XQuery 难以学习
使用 Java、.NET 和其他语言的软件开发人员发现 XQuery 很容易学。XML 有很多不那么优美的地方，包括从早期的 SGML 标准继承下来的那些部分。 XQuery 使用一组简洁的命令，很容易处理 XML。虽然一般开人员要掌握 XQuery 面临着一些困难，但是学习曲线并不很陡峭，也不长。
Photoshop教程
数据结构
五笔输入法专题
QQ病毒专题
共享上网专题
Google工具和服务专题
误解：XQuery 不是产品，仅仅是很多层中的一层
如果需要管理和操纵 XML 数据，XQuery 就是程序库、应用程序编程或者服务栈所提供的功能规范。但是，底层的 XML 存储、检索和索引机制造成了 XQuery 实现的功能、性能和可伸缩性的很大差异。比如，最初曾经尝试将 XML 数据保存在关系数据库的 varchar2 字段中，然后简单地增加一个 XQuery 引擎层，结果查询性能很差。这就导致了在内容管理、数据持久性、Web 服务和面向服务架构（SOA）、数据仓库、联机分析处理（OLAP）、提取/转换/加载（ETL）、企业应用程序集成（EAI）和供应方管理等方面形成了专门的 XQuery 解决方案。
误解：XQuery 对于提高面向服务架构（SOA）的性能、控制复杂性没有多大用处
构建的系统要处理大量 XML 数据时，软件架构师和开发人员借助 XQuery 解决性能和复杂性问题。考虑下面的情况和相应的 XQuery 解决方案：
早期的研究表明，基于 ebXML 和 UBL 的服务中有效负载的数量和 XML 模式的复杂性呈爆炸性增长，在这里 XQuery 可以发挥重要作用。
XQuery 在很大程度上增强了 UDDI 解决方案，因为可以更好地管理和控制 UDDI 注册中心列出的资源。
软件架构师发现，滞后（so
[1] [2] 下一篇
