mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
前回は,ニュースサイトやブログに関わる書誌情報を表わすXMLボキャブラリであるRSSの話でしたので,今回は,ニュースを表わすXMLボキャブラリであるNewsMLについてお話しします。
今回は,インターネットを利用した電子商取引(EC:Electronic Commerce)のボキャブラリについてお話しします。近年のEC市場の成長は目覚ましく,2000年から2005年までの年平均成長率は,アジア・太平洋93.5%,西欧75.5%,日本74.8%,米国63.5%の順となっています。それを反映して世界のEC市場において米国の占める割合は,2000年の52.4%から2005年には44.0%まで減少するという調査結果が出ています。また経済産業省の調査によると,2003年の日本のEC市場は77兆4000億円規模となり,そのうち企業対企業間(B2B:Business-to-Business)ECによるものは全体の94.6%という高い割合を示しています。
EDIは,B2Bの原型であり,コンピュータの実用化が始まってから間もなく試みられ,30年を超える実績があります。EDIの表現形式としては,日本のCII,米国のASC X12,欧州のEDIFACTがあります。図1にEDIFACT形式で表わした注文データを示します。EDIFACTでは,交換するデータをメッセージと言い,メッセージを構成する要素を特定の記号を使って区切り,特定の文字列をタグとして使ってデータの構造を表わします。
▼図1 EDIFACTで表わした注文データ
UNB+jagat+ooprinting' UNH+0RDERS' DTM+20060923' NAD+BY+日本印刷技術協会+和田1-29-11+東京都杉並区+166-8539' NAD+SU+○○印刷' PIA+名刺:桃太郎' QTY:500:枚' UNT UNZ
EDIFACTメッセージは,暗号のように見えますが,一つひとつの要素は単純な形式になっています。プラス記号はセグメント・タグとデータ要素を,コロンは複合データ要素を,アポストロフィはセグメントを,それぞれ区切ります。UNBは交換ヘッダーを,UNHはメッセージ・ヘッダーを,UNTはメッセージ・トレーラー,UNZは交換トレーラーを,DTMは日時,NADは名前と住所を,PIAは注文製品,QTYは数量と単位を,それぞれ表わします。こうした表現を「伝統的なEDI」と呼びます。
図1のEDIFACTデータをXML形式で表現すると,図2のようになるでしょう。EDIFACTからXMLへの自動的な変換は可能で,標準的なマッピング(対応)規則もあります。ちなみに,図2のボキャブラリは私が設定したものですから,必ずしもこのようになるわけではありません。こうしたXMLに基づくEDI表現を「XML/EDI」と呼びます。一般に,XML方式の採用によって,情報システムの運用効率がよくなり,開発や保守に関わる費用が節減できる,という見通しがありますが,伝統的なEDIには冗長な部分がほとんどありませんので,大量データの交換に向いています。一方,XML/EDIは新たに開発されるEDIシステムへ適用されたり,不定形なデータの交換に利用されたりすると思われます。
▼図2 XML/EDIで表わした注文データ
<?xml version="1.0?">
<order>
<date>20060923</date>
<senderID>jagat</senderID>
<receiverID>ooprinting</receiverID>
<buyer>
<name>日本印刷技術協会</name>
<address>
<street>和田1-29-11</street>
<city>東京都杉並区</city>
<postcode>166-8539</postcode>
</address>
</buyer>
<supplier>
<name>○○印刷</name>
</supplier>
<product>
<type>名刺</type>
<name>桃太郎</name>
<quantity>500</quantity>
<unit>枚</unit>
</product>
</order>
図2のXML/EDIデータをPrintTalkで表現すると,図3のようになるでしょう。これが図2と違うのは,PrintTalkのボキャブラリが公開されている点です。PrintTalkは,顧客と印刷会社との間で取り交わされる印刷物の見積り要請から承認を経て発注までの情報を,事務取引に印刷仕様を含めて表すXMLボキャブラリです。その印刷仕様を表わすボキャブラリがJDFであるという点に注目してください。ただし,図3の表現では,複雑になる印刷仕様をカタログ機能を用いて省略しています。
▼図3 PrintTalkで表わした注文データ
<?xml version="1.0" encoding="UTF-8"?>
<PrintTalk xmlns="http://www.CIP4.org/JDFSchema"
version="1.1" payloadID="1234"
timestamp="2006-09-23T22:39Z">
<!-- ヘッダー -->
<Header>
<!-- 発信者 -->
<From>
<Credential domain="DNS">
<Identity>www.jagat.or.jp</Identity>
</Credential>
<Credential domain="e-print-commerce.com">
<Identity>日本印刷技術協会</Identity>
</Credential>
<Credential domain="DUNS">
<Identity>jagat</Identity>
</Credential>
</From>
<!-- 受信者 -->
<To>
<Credential domain="DNS">
<Identity>ooprinting.com</Identity>
</Credential>
<Credential domain="e-print-commerce.com">
<Identity>○○印刷</Identity>
</Credential>
<Credential domain="DUNS">
<Identity>ooprinting</Identity>
</Credential>
</To>
<!-- 電子商取引サービスの仲介者 -->
<Sender>
<Credential domain="DNS">
<Identity>e-print-commerce.com</Identity>
<SharedSecret>******</SharedSecret>
</Credential>
<UserAgent>EPT for Buyer</UserAgent>
</Sender>
</Header>
<!-- 依頼 -->
<Request>
<!-- 購入注文 -->
<PurchaseOrder AgentID="kisi"
RequestDate="2006-09-23T1000-0800" Expires="2006-10-10T1700-0800">
<!-- ジョブ定義 -->
<JDF DescriptiveName="購入注文" ID="JDF001"
Type="Product" Status="Waiting" Version="1.1">
<!-- 顧客情報 -->
<CustomerInfo CustomerID="Customer001" rRefs="Contact001" />
<!-- リソース・プール -->
<ResourcePool>
<!-- 連絡先 -->
<Contact ID="Contact001" Class="Parameter">
<Address Street="和田1-29-11" City="東京都杉並区" PostalCode="166-8539" />
<Company ID="Company001" Class="Parameter" OrganizationName="日本印刷技術協会" />
</Contact>
<!-- 配送意図 -->
<DeliveryIntent ID="Delivery001" Class="Intent"
rRefs="Contact001 Item001" Status="Available">
<!-- 出荷意図 -->
<DropIntent>
<Required DataType="TimeSpan" Preferred="2006-10-09T1700-0800" />
<ContactRef rRef="Contact001" />
<DropItemIntent Amount="500" Unit="枚">
<ComponentRef rRef="Item001" />
<Pricing Item="合計" Price="5000" />
<Pricing Item="配送料" Price="400" />
<Pricing Item="消費税" HasPrice="250" />
</DropItemIntent>
</DropIntent>
</DeliveryIntent>
<!-- 部品意図 -->
<Component ID="Item001" Class="Quantity" Status="Available"
ComponentType="FinalProduct" CatalogID="桃太郎さまの名刺" />
</ResourcePool>
<!-- リソース・リンク・プール -->
<ResourceLinkPool>
<DeliveryIntentLink rRef="Delivery001" Usage="input" />
</ResourceLinkPool>
</JDF>
</PurchaseOrder>
</Request>
</PrintTalk>
PrintTalkのボキャブラリは,JDFをラッピングする(包む)ことによって明解な構造にしています。前述のEDIに印刷仕様を含めると,それがかなり複雑になりそうなことは想像できるでしょう。B2BのXMLボキャブラリの中に,製造仕様まで含むPrintTalkのようなものがあるかどうかは分かりません。なお,PrintTalkは,B2BのXMLボキャブラリであるcXML(commerce XML)を参考に作られていますが,まだ確立したボキャブラリではありません。
ECのXMLボキャブラリについて理解する際は,その処理モデルを強く意識する必要があります。ECとは,従来手書きであった伝票を電子的に表わし,かつ相手との交換を電子的に行う手続きです。PrintTalkで想定する印刷受注の手続きを表1に示します。表1で明らかなように,こうした抽象的な手続き,つまり処理モデルは手作業のアナロジー(相似)になっています。
▼表1 PrintTalkで想定する手続き
順序 | 手続き | 情報が流れる方向 |
---|---|---|
1 | 見積り依頼 | 消費者→印刷業者 |
2 | 見積り | 消費者←印刷業者 |
3 | 購入注文 | 消費者→印刷業者 |
4 | 注文確認 | 消費者←→印刷業者 |
5 | 取り消し | 消費者←→印刷業者 |
6 | 辞退 | 消費者←→印刷業者 |
7 | 注文状況確認依頼 | 消費者←→印刷業者 |
8 | 注文状況報告 | 消費者←→印刷業者 |
9 | プルーフ確認依頼 | 消費者←印刷業者 |
10 | プルーフ確認回答 | 消費者→印刷業者 |
11 | 送り状 | 消費者←印刷業者 |
紙面の都合上紹介できなかったECに関わるその他のXMLボキャブラリには,BizTalk,eCo Framework,ICE(Information and Content Exchange),IOTP(Internet Open Trading Protocol),RosettaNet,xCBL(XML Common Business Library),ebXML(e-business XML)といったものがあります。もう少し時間をかけて調べたいと思っています。
▲このページのTOPへ