近年電子商取引の分野において、多くのXML文書標準が開発され、それらの仕様の競合がXMLデータ交換での相互運用性の問題を引き起こしています。具体的には

• 共通のタグ名を使っていてもビジネス上の意味(コンテキスト)が異なる
• ビジネスの仕方の違いによりデータ交換に必要な項目がそれぞれ異なる

注1　Commerce Oneが作成、公開するビジネスライブラリです。B2B電子商取引のためのXMLビジネスドキュメントおよびそのコンポーネント ライブラリを無料で提供し、そのメンテナンスやサポートを行っています。この標準ライブラリを使用したり各ユーザがライブラリ拡張をしたりすることによりアプリケーション間の相互運用性が促進されることを目的としています。

注2　同技術解説書 C-33 ebXML Core Componentsを参照してください。

UBLは2001年８月にOASISで発足したcommitteeです。チェアはJon Bosak氏(Sun Microsystems)です。メンバはCommerce One、Sun Microsystemsをはじめ、その他の企業や機関から39名(2002年3月19日現在)が参加^(注3）しています。

注3　参加メンバについてはhttp://oasis-open.org/committees/ubl/members.htm

UBL　Technical Committee(以下TCと呼ぶ)の組織は以下の通りです。Technical Subcommittee(以下SCと呼ぶ)がそれぞれUBLの技術的成果を追求し、Administrative SCがその管理および他の標準化団体との連携を行います。以下はその組織図です。

Administrative SCには3つのグループがあり全てチェアはJon Bosak氏が行っています。

Liaison SC

各SCからの要請を受け、協力機関とのレビュースケジュールの調整、協力機関からの正式告知の取りまとめ、要求するSCへの告知の伝達、UBL　TCとそのTCが検討する他の機関との連携に関するポリシーの提案を行います。
リエゾンとして任命されている機関は現在ARTS(小売業界)、ACORD(保険業界)、EIDX(電子業界)、 XBRL(財務会計業界)、RosettaNet(電子情報業界)などを含んでいます。

Marketing SC

TCメンバやOASISスタッフと共にUBLの取り組みに関する宣伝およびその採用の促進を行うことを目的としています。

Administration SC

全体のマネージメントをしています。

Technical SCには以下の5つのグループがあります。

Library Content SC

既存ライブラリを出発点とし、他の既存ビジネスライブラリやコア　コンポーネントの最良な部分をそれに組み込んで改良することで、標準XMLビジネスライブラリの迅速な開発を行います。
成果ドキュメントとしては、XMLビジネスライブラリのうちOrderドキュメントのコア コンポーネントを含むセットが2002年3月に出ており、５月まで内部および他の連携機関のレビューにかけられる予定です。Orderドキュメントセットの内容は以下の通りです。

1. UBLメソドロジドキュメント
   以下4つのドキュメント類の背景説明およびその考え方、生成方法(プロセス)が書かれています。
2. UBLライブラリのXMLスキーマ
   UBLのコア　コンポーネント ライブラリです。
3. UBL OrderドキュメントのXMLスキーマ
   OrderクラスのUBL定義のライブラリです。
4. コア　コンポーネント タイプのXMLスキーマ
   2のコアコンポーネント　ライブラリで使われる定義ライブラリです。
5. UBL Orderドキュメントのサンプル
   3のスキーマを用いて作成されるOrderドキュメントサンプルです。

Naming and Design Rules SC

伝票のスキーマデザイン、マークアップ(タグ)の名前付けのガイドラインとルールを勧告および文書化、保守し、UBL Group Planning Committee^(注4) のレポートに基づくデザイン原則に則る管理に関し責任を負います。
注4　UBLでTCが発足する前にUBLの基本方針を策定したPreliminary Groupの１つです。
活発なSCで様々な議論およびポジションペーパーがありますが、その概要は以下の項目にまとめられます。

マークアップ(タグ)の名前付け

タグのもつ意味がはっきりし、拡張時も意味とタグがユニークに１対１に決まるように名前付けする方法を提示することを目的としています。

属性(Attribute)と要素(Element)

ドキュメントスキーマを定義する際、それぞれのコンポーネントについて属性、要素のどちらを用いて表現すべきか、その使い分けを提示することを目的としています。

ドキュメントのバージョン管理

成果ドキュメント配布形態としてXMLスキーマを採用するにあたって、ドキュメントのバージョン管理方法を提示することを目的としています。

コード

UBLドキュメントで使用するコードの採用および保守方針を検討しています。

モジュール方式

配布ドキュメント分割および管理方法について検討しています。

ネームスペース

UBLが使用するネームスペースの書式について検討しています。

これらの議論の結果は成果としては以下のドキュメントにまとめられる予定です。
UBL Naming and Design Rules Specification

Context Methodology　SC

コア ライブラリを修正、加工してBIE^(注5）を生成するためのツールやメソドロジおよびマシンリーダブルなコンテキスト規則の記述方法を、Library Content SCに助力して、開発することを目的としています。
注5　Business Information Entityの略で、ビジネス上の意味がユニークに定義されているデータの要素またはその集合のことを指します。

Tools and Techniques SC

開発、品質保証、ドキュメント化、保守、UBL XMLデータフォーマットの改訂などで使われるツールや技術をTCに対して評価、勧告し、それらを反映するガイドラインを書き、保守することを目的としています。

Context Drivers SC

コンテキスト ドライバ^(注6）の開発および改良を目的としています。
注6　データをコンテキスト別に分けるための分類項目またはパラメータを指します。

UBLでは以下の３つの成果の配布を計画しています。

注7　Reusable Components、Common set of base components、UBL Library Components、Core Component Library,など、いろんなドキュメントで違う言い方をしています。UBL Libraryという言葉もUBLの成果全体を指すこともありまたComponent libraryをさすこともあります。

xCBLボキャブラリを元に、ebXMLのcore component technical specificationのガイドラインに倣う再利用可能なベース コンポーネントを作成します。xCBLをスタートポイントとして利用するのは、全く新しいところから始めるよりは、過去の経験をふまえ、広範に分析されて作成されたライブラリを元に発展させる方が無駄を省くことができるからです。コア　コンポーネントをビジネス上意味のある語として使うとき、BIE(Business Information Entity)と呼ばれ、(2)の標準XMLドキュメントを作成する際の構成要素となります。コンポーネント ライブラリは22項目からなりますが、実際に使われている代表的な項目を以下に示します。

• UBL ID
  UBLライブラリ全体を通してユニークな記号列IDです。
• Object Class
  論理的に関係のあるプロパティのグループのことです。
• Basic/Aggregate
  Basic BIE(1つのBIEから成る)かAggregate BIE(Basic BIEの複合語)かどうかを示します。
• Property Term
  語の持つ意味や特徴を表す属性です。
• Type
  ライブラリでコンポーネントに現れる型を表します。定義は別途されています。
  例: Numeric; A representation of a number.
• Property Qualifier
  語の使われるコンテキストまたは役割をPropertyを補う形で表します。
• Representation Term
  ライブラリでコンポーネントのベースとして使われる語とその意味を定義しています。
  例: Date;　A day within a particular calendar year (ISO 8601).
• UBL Name
  ‘property qualifier’ + ‘property term’ + ‘representation term/re-usable type(Aggregate BIEの場合)’の組み合わせで並べられる文字列です。
  例: Identifier = ‘なし’ + ‘Identifier’ + ‘Identifier’
  (representation termと同じproperty termは削除されます。)
• BIE Dictionary Name
  ‘Object class’ + ‘property qualifier’ + ‘property term’ + ‘representation term’の組み合わせでピリオドを挟みながら並べられる文字列です。
  例: Account. Identifier = ‘Account’ + ‘なし’ + ‘Identifier’ + ‘Identifier’ で、property termがrepresentation termと同じなので削除されます。
• Definition
  元々のxCBLの語の定義にUBLとして補足を加えたものです。

以下はUBL　nameが ’ Identifier’ であるコア コンポーネントの表示例です。

商取引で使われるドキュメントのスキーマです。(1)のライブラリを組み合わせて拡張し、以下の７種類のカテゴリに分けてドキュメントセットを作成します。Orderドキュメントはその調達カテゴリに含まれるものです。

• コア ライブラリ(上記コア コンポーネントを含む基本構成要素の定義)
• 調達(購入;Content Library SCがレビュー中のOrderドキュメントを含みます。)
• 資材管理(物品領収、計画スケジュール、納品)
• 支払い(納品通知、送金通知)
• 輸送(出荷報告)
• カタログ(商品カタログ、価格カタログ)
• 統計報告(会計報告)

次の図はOrderドキュメントスキーマの一部です。AccountCodeというxCBLのボキャブラリを元にライブラリからProperty TermやRepresentation Termを用いてOrder object classのコンポーネントを定義しています。

以下はOrderドキュメントスキーマを使用したOrder伝票のサンプル例の一部です。(属性値や要素値に関する定義は未定のためここでは仮の値を入れています)

(1)、(2)で提供される基本的なドキュメントのセットは既存のビジネスドキュメントのニーズには十分と考えられていますが、業界特有の必要となるカスタマイズの可能性を考慮し、これらを拡張するためのメソドロジを策定しています。これらのカスタマイズは、前述の標準コンポーネントをベースに行うため、相互運用性は保証されます。

次の図はLibrary Contentでレビュー中のOrderドキュメントに含まれるメソドロジの内容です。Orderドキュメントの作成過程を例にしてその成果の根拠とフレームワークを説明するものです。最終的にこれを改良していったものがUBLライブラリを保守、拡張するためのガイド(メソドロジ)となります。

以下はUBLの将来の展望で、UBLの広まり方は以下の４つのフェーズに分かれて発展していく予定です 。

Stage1 ベーシック ビジネスドキュメント(12ヶ月から18ヶ月)

最小のコアライブラリおよび共通ビジネスドキュメントのスキーマセットのリリースを行います。(2002年4月の時点でこのフェーズにいます)

Stage2 共通コンテキストのフォーム

特定のコンテキストで使われるフォームがコアライブラリから派生して拡張し追加され、いくつかの大企業はコンテキストメソドロジを用いて拡張したライブラリの設計および配布を始めます。

Stage3 Design-Time 改良

コンテキストベースのメソドロジを使い、大企業と垂直な業界間提携によるライブラリフォームの拡張が行われます。

Stage4 Run-Time スキーマ生成

コンテキストルールを定義すると、コンテキストドライバの連結によってオンデマンドで適当なドキュメントを生成するという、最高の相互運用性とビジネスプロセスの自動化を実現できます。真の”プラグアンドプレイ”の電子商取引に到達するには、マシンにより実行可能なビジネストランザクションの完全な仕様が必要となるでしょうが、それはUBLのスコープ外です。