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
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"?>
<Order
XMLns="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
-->
<BuyersID>20031234-1</BuyersID>
<cbc:IssueDate>2003-01-23</cbc:IssueDate>
<cbc:LineExtensionTotalAmount
amountCurrencyCodeListVersionID="0.3"
amountCurrencyID="USD">438.50</cbc:LineExtensionTotalAmount>
<cac:BuyerParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Bills Microdevices</cbc:Name>
</cac:PartyName>
<cac:Address>
<cbc:StreetName>Spring St</cbc:StreetName>
<cbc:BuildingNumber>413</cbc:BuildingNumber>
<cbc:CityName>Elgin</cbc:CityName>
<cbc:PostalZone>60123</cbc:PostalZone>
<cac:CountrySubentityCode>IL</cac:CountrySubentityCode>
</cac:Address>
<cac:Contact>
<cbc:Name>George Tirebiter</cbc:Name>
</cac:Contact>
</cac:Party>
</cac:BuyerParty>
<!-- Cut to one of the order lines -->
<cac:OrderLine>
<cac:LineItem>
<cac:BuyersID>1</cac:BuyersID>
<cbc:Quantity quantityUnitCode="PKG">5</cbc:Quantity>
<cbc:LineExtensionAmount
amountCurrencyCodeListVersionID="0.3"
amountCurrencyID="USD">12.50</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Description>Pencils, box #2 red</cbc:Description>
<cac:SellersItemIdentification>
<cac:ID>32145-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 樣式表（請參閱 參考資料）。
結束語
重新閱讀上一篇 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 及相關技術不斷地成熟和發展，我將對本專欄繼續保持關注。