Universal Business Language（通用商业语言，UBL）是一种 XML 商业信息交换和事务格式，本专栏中曾几次提到过它。1.0 版是 UBL 的一个重要里程碑，它带来了一些新的改进和 XML 表示的某些变化。Uche Ogbuji 将在这一期的文章中考察 UBL 1.0，并介绍 ebXML Core Components，后者构成了 UBL 概念模型的基础。
以前的 Thinking XML 专栏文章 中，我曾介绍过通用商业语言。UBL 是用于商业事务的一种文档库，适用于不同规模和不同地区的组织。UBL 背后的 OASIS 最近宣布，其成员已经批准 1.0 版作为 OASIS 标准。OASIS UBL 课题与 OASIS/United Nations Electronic Business XML (ebXML) 关系密切，这意味着，一旦完成 UBL，OASIS UBL 很可能快速跃升为正式国际标准。事实上，它正在 ISO Technical Committee 154（一个 UN/CEFACT 小组）的支持下走向 ISO 标准，用他们专门的术语叫开放贸易数据交换，它也是幕后支持 EDIFACT 标准的组织。UBL 小组和数十个其他标准组织及公会保持着密切联系，这种关系有平行的（UN/CEFACT、ANSI ASC X12、ISO、RosettaNet、OAG），也有纵向的（ACORD、HL7、SWIFT、XRBL）。我在以前的专栏文章中介绍过所有这些小组。
UBL 的非技术核心原则包括满足不同类型和不同地域组织的需求，并承诺突破版权和支持产权的障碍。现在，经过三年的开发，它已经成为了一种完整的产品。这意味着，很快您就会看到这些美好的原则再加上下面要讨论的技术细节是否足以让 UBL 成为 XML 文档交换的基础。
UBL 概述
UBL 是最直观的电子商业事务框架，规模庞大而且非常形式化。参与 UBL 开发的有许多组织，主要是 OASIS 和 UN/CEFACT。UBL 被设计成 exXML 消息（ebMS）的有效负载形式，通过业务过程标准和协议（契约）标准来管理，这两个标准分别为 ebXML Business Process Specification Schema（BPSS）和 Collaboration Protocol Profile and Agreement（CPPA）。UBL 在语义上由 ebXML Core Components 支撑，后者是标识某些抽象概念的可重用数据元素。Core Components 在付诸应用之前需要有业务上下文，UBL 定义的 Business Information Entities（BIEs）就是溶入上下文中（contextualize）的 Core Components。BIEs 组成了 UBL 概念模型，将业务概念组织到类和关联中。UBL 将组成业务事务的 BIE 转化成 XML 格式，以便将它们用于实际的消息。整个框架放在 ebXML Registry/Repository 中。这个 ebXML 框架的大部分现在已经被标准化为 ISO 15000。
ebXML Core Components
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）ebXML Core Components Technical Specification (ISO 15000-5) 是可重用的、灵活的业务信息表达系统。它定义了 Core Components (CC)，本专栏以前曾经数次提到。我曾经在 Thinking XML：XML 语义锚一文中指出，CC 是一种 自下而上 的方法，离散地定义术语和概念，独立于它们所属的文档（文档层由 UBL 或者类似的规范处理）。UBL 是第一个完全兼容的 CCTS 实现。
CC 可以是 原子性的（也称为基本组件）或 聚合的。邮政地址是聚合组件的一个例子，它是一致的抽象概念，包括几个原子组件，如省份和邮政编码。为了对 UBL 有一个直观的印象，考虑使用地址的很多上下文。比如在公司订货的情况中，常常会看到支付地址和发货地址的区别。这种区别反映在业务规则中，比如发货地址不可能是一个邮政信箱。这些区别组成的业务上下文就把组件转化成了 UBL BIE。上下文的一些因素可能影响到 BIE 的映射。比如，美国的地址有一种特殊的信息结构，从地址这一抽象概念中特化出来。它包括一个邮政编码，可加以识别和约束，比方说，不同于英国的邮政编码。前者完全由数字组成，而后者混合使用字母和数字（当然还有其他区别）。
Core Components Technical Specification 是根据 ISO/IEC 11179 元数据注册规范（一般性的数据词典）设计的。ISO 11179 规范非常完善而谨慎，毫无疑问，UML 建立在最严格的语义基础之上。我个人怀疑如此层层累积起来是否会造成不必要的僵化和复杂，但公平地讲，UBL 尝试将事物封装起来，因此除了应用程序的直接需求之外，并不需要深究其中的语义积淀。多数用户仅仅关心用什么样的标签和内容，以什么样的顺序，来构造一个有效的 UBL 文档。
XML 内幕
在以前关于 UBL 的介绍中，我曾经提到 UBL Naming and Design Rules（NDR），极其谨慎地将 BIE 转化为实际的 XML 组件。UBL 开发人员用表格详细地描述了 BIE，并使用 NDR 创建了 XML 模式。这一切如此严格，简直令人窒息（当然 NDR 文档也非常令人难忘），但您所关心的可能就是最后的结果：XML 模式。
为了看一看这个 XML 产品，我下载了 UBL 1.0 包，里面的内容非常齐全，从定义 BEI 的表格、ASN.1 模式归、各种文档类型的 XML 模式（不幸的是都是 WXS 而非 RELAX NG），直到示例文档和生成的文档。和上一次寻找 UBL 包的时候相比，示例 XML 很容易找到。看了一遍示例文档，我马上发现有些地方改变了。清单 1 和上一篇 UBL 文章中的例子是对应的，但这一次使用了 UBL 1.0。
清单 1. UBL 1.0 订购事务文档片段
？xml version="1.0" encoding="UTF-8"？Orderxmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0"xmlns:cbc= "urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0"xmlns:cac= "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0"!--Trimmed some spurious namespaces, as well as the xsi:schemaLocation attribute-- BuyersID20031234-1/BuyersID cbc:IssueDate2003-01-23/cbc:IssueDate cbc:LineExtensionTotalAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD"438.50/cbc:LineExtensionTotalAmount cac:BuyerParty cac:Party cac:PartyName cbc:NameBills Microdevices/cbc:Name /cac:PartyName cac:Address cbc:StreetNameSpring St/cbc:StreetName cbc:BuildingNumber413/cbc:BuildingNumber cbc:CityNameElgin/cbc:CityName cbc:PostalZone60123/cbc:PostalZone cac:CountrySubentityCodeIL/cac:CountrySubentityCode /cac:Address cac:Contact cbc:NameGeorge Tirebiter/cbc:Name /cac:Contact /cac:Party /cac:BuyerParty!-- Cut to one of the order lines -- cac:OrderLine cac:LineItem cac:BuyersID1/cac:BuyersID cbc:Quantity quantityUnitCode="PKG"5/cbc:Quantity cbc:LineExtensionAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD"12.50/cbc:LineExtensionAmount cac:Item cbc:DescriptionPencils, box #2 red/cbc:Description cac:SellersItemIdentification cac:ID32145-12/cac:ID /cac:SellersItemIdentification cac:BasePrice cbc:PriceAmount amountCurrencyCodeListVersionID="0.3" amountCurrencyID="USD"2.50/cbc:PriceAmount /cac:BasePrice /cac:Item /cac:LineItem /cac:OrderLine/Order
最大的变化是使用名称空间将元素分成了框架元素、基于基本 CC 的元素和基于聚合 CC 的元素。比如 cac:Address，从清单中可以看出它已经被标记为聚合概念（名称空间被绑定到 cac 前缀），它包含最基础的基于基本 CC 的元素（名称空间绑定到 cbc 前缀）。UBL 1.0 还稍微改变了结构和命名，但名称空间的地位明显上升了。这似乎表明，示例文档的创建者在很大程度上受 WXS 的影响，特别是使用名称空间的方式（偶尔不使用）。 这种格式对于那些更接近 ISO DSDL 世界观的人（比如我）而言，不仅会想我明白他们为何要用 Namespace Routing Language (NRL)。UBL 文档模快化处理的最佳实践还没有出现。
辅助性的 XML 研究
UBL TC 不能在真空中运行。此前曾经提到过，我对 UBL 1.0 缺少正式的 RELAX NG 模式感到失望。大阪技术学院的 Hiroshi Naito 和他的同事已经发表了 UBL 的 RELAX NG 模式草案。目前这项研究以 UBL 1.0 beta 而非最终版本为基础，文档用日语编写。上一期文章中曾经提到 Crane Softwrights Ltd. 免费提供的 UBL XSL-FO 样式表，能够用 XSLT 将 UBL 文档转化成 PDF、TeX 或者其他可供打印的格式。Ambrosoft 曾经提供了一个免费的 Java 格式化程序，能够在单个 Java .jar 文件中使用 Crane UBL 样式表（请参阅 参考资料）。
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）结束语
重新阅读上一篇 UBL 文章的结束语，我发现大部分观点仍然适用。UBL 有很多承诺，但是经过三年的研究之后，它仍然仅仅触及到满足电子商务需求所需要的大量文档和事务的皮毛。尽管在扩展性方面，UBL 做出了大量努力，但前途仍然不甚明朗。在 UBL FAQ 中，该小组指出：
在第一个版本中，UBL 没有打算再造已有 EDI 消息系统的功能，其中包括作为起源的 xCBL 规范。没有采用旧标准中的 40-50 种文档类型，UBL 第一个版本中只涉及简单的采购，包含 8 种基本文档类型（再加上所依赖的组件库）。这是一个明显的 80/20 解决方案，强调了对小型商业活动的适用性和成本低廉的通用软件。我非常赞同这种实用的观点。在雄心勃勃地规划 UBL 2.0 时，保持和其他组织（如 UN/CEFACT、OAG 和 ANSI X12）的联络对 UBL TC 很有助益。但是在 UBL 2.0 之前，还计划推出 UBL 1.1 版，这是一次很小的升级，主要是为了解决 1.0 版保留下来的一些突出问题。现在基础已经有了，UBL 1.0 包很快就能使用了。我建议您自己去研究它。随着 UBL 及相关技术不断地成熟和发展，我将对本专栏继续保持关注。
