言語としてのXML私論ー企業間、企業内でのXMLの活用についてー

　前回「言語」について述べたので、今回は記号言語（人工言語）の一つのXMLに関して、思うことを書いてみよう。　もちろん、XMLは『拡張可能なマーク付け言語(Extensible Markup Language)』のことである。
私は、製造業でITをしている立場から、今回の話は、企業間および企業内の電子データ交換におけるXMLを考えることになることをお断りしておく。

＜Extensible Meta Language!?＞
L：Language（言語）
　言語の重要性は、前回にも述べた。　人間同士は、コミュニケーションするために、「自然言語」（ウィトゲンシュタインの言う Umgangssprache（独語）〔= 英：everyday language、日：日常言語〕）が必要だ。　電子データ交換においては、ウィトゲンシュタインが「記号言語（独：Zeichensprache、英：sign-language）」と呼んだ人工言語が必要となる。　その言語はウィトゲンシュタインが指摘したように、「論理的な文法－論理的な構文－に準拠した記号言語」でなければならない。
M：Meta（メタ）
　私は、XMLの"M"は、Markup (Language)の略でなく、Meta（Language）の"M" であるべきだと思っている。　確かにXMLはマークアップ言語には違いないのであるが。　B2B（企業間電子商取引）においては、パートナー間での情報交換が必要となるが、それぞれのビジネス・プロセスにおいて、正確に双方の意思が伝わる情報交換用のフォーマットがいる。　つまり、サプライ・チェーン上でのビジネス・プロセスにおいてパートナー間で双方の意思がきちんと伝えるためのコミュニケーション・ツールとしての言語を、論理的にかつ簡単に定義できる言語があってはじめて、情報交換用のフォーマットが作れるわけである。　そこに、B2Bでのメタ言語としてのXMLが意味を持つことになる。
そう思っていたら、Devan Shepherd著  "SAMS Teach Yourself XML in 21 Days" 2nd EditionのIntroduction（P.3）に以下のように書かれていた。
XML, the Extensible Markup language, is the lingua franca of the Internet. With XML, you have a completely extensible, easy-to-learn, and richly feature universal format for structuring data and documents that can be exchanged efficiently over the Web.
Even though the "M" in XML stands for "Markup", XML is not, strictly speaking, a markup language. Rather, it is a sophisticated "Meta" language used to describe highly structured and uniquely specialized markup vocabularies.　　（注：下線は、私が付けたもので、原文には下線はない） 
【訳】XML、つまり拡張可能なマークアップ言語は、インターネットの共通言語（lingua franca）である。　XMLによって、十分に拡張可能で、学びやすく、そしてWeb上で効率的な交換ができる構造化データと文書のための十分豊富なユニバーサル・フォーマットを手に入れることになる。
XMLの"M"はマークアップの略語であるにかかわらず、厳密に言えば、マークアップ言語ではない。　むしろ高度に構造化され、専門分野に特化したマークアップ語彙を記述するのに向いている「メタ」言語である。　（注：訳は私が行なったものである）
X：Extensible（拡張可能な）
　言葉は生き物だ。良いか悪いかわからないこともあるが、自然言語だってどんどん変わっていっている。　言語は時代背景に敏感なのだ。　ちょっと前はコンピュータなんぞ一般的でなかったし、コンピュータ関連の言葉もなかったのに、今じゃそこらじゅうにコンピュータ用語が溢れている。（そう言えば、最近「電子計算機」という言葉は聴かなくなったなあ）　グローバル化（この言葉はあまり好きでないのだが）が進み、どんどん他国の商習慣も入り、それに伴い、ビジネスで使う言葉もどんどん変わってきている。　そういう状況では、人工言語（記号言語）においては、フレキシブルで、拡張可能な言語が、なおさら求められるわけだ。　上記の挙げた"SAMS Teach Yourself XML in 21 Days"のP.15に、次の文を見つけた。
The "X" in XML stands for Extensible.  Extensibility means that the language can be advanced or stretched to meet specific needs. Because XML is not based on a finite set of tags, you can create descriptive tags that fit your requirements. 
【訳】XMLの"X"はExtensible（拡張可能な）の略である。　拡張可能性とは、特有なニーズに合わせるために言語が進化し、拡張できるという意味である。　XMLは、限定されたタグの集合によっているのでないので、要求要件に合う、意味内容が理解できるタグを自分で新しく作ることができる。（注：訳は私が行なったものである）

＜企業間、企業内でコミュニケーションするということ＞
　自然言語において、その言語を話す人が多くいればいるほど、その言語の持つ意味があり、その言語の力が大きなものとなる。　人工言語も自然言語と同様、その言語を使う人、企業が多ければ多いほど、その価値がでてくるわけである。
「企業文化、使用しているシステムやビジネスの仕方が異なる企業と企業の電子データ交換」や「企業内の異なるシステム間（企業内でも、 異なるプラットフォーム、異なる部署の仕組み同士では、企業間のデータ交換より難しい場合もある）」においては、そこで使用される言語は、できるだけシンプルで、覚えやすい、つまり「軽い」仕様の言語であるべきである。
各社（バイヤー、サプライヤーだけでなく、SCM上の関連会社やソフトベンダーやSIerも含む）の要望を聞き入れて、何でもできるようにしようとして、仕様を重くするより、完璧でないが、70～80％ぐらいを狙うような軽い仕様にすべきである。仕様を決めるためにも時間がかかるし、その仕様を理解するにも時間がかかるよう仕様が、最近多すぎる。　　　　　　　　　　　　　　
B2BにおいてLingua franca（共通語）として意味を持つためには、まず言葉の定義の明確化と用語の標準化が必要になる。　しかも１社との電子データ交換というわけにはいかないわけで、異なる仕組みを持つ複数の企業を相手にするには、各社毎に異なるフォーマットのデータを受ける側で吸収する何らかの仕組みを作らないと、金がかかって仕方ない。（それぞれに対応する仕組みを一つずつ作っていたら、たまったものではない。）　
また、企業間、企業内の電子データ交換（異なるシステムを「つなぐ」こと）においては、
① 企業間では、各企業の中の事情を持ち込まないように（異なる企業文化やビジネスのやり方をできるだけ持ち込まず）、ビジネスのコア分だけを抽出するために、「パブリック・プロセスとプライベート・プロセスを分けて考える」こと。
② 企業内では、部署毎の方言を吸収したり、複数の異なるシステムとデータのやり取りをするために、「アプリケーション機能（Application Functionalities）を他のアプリケーションから利用可能なサービスとしてつなぐ」こと。
を考慮する必要があろう。

＜３つの視点からXMLを見ると＞
　① 変換、②蓄積〔検索（Retrieve）を含む〕、③表示の3つの視点からXMLを見ると、
①「変換」は、十分に効果があると思う。　図では、 ３社のバイヤーから各社各様のフォー マットのフォーキャスト（需要予測）をサプライヤーが受け取る例を示している。各バイヤーでのアイテム名（バイヤー内で使用される品番）は異なるが、サプライヤーでは同一の仕様なので、同一のアイテム名（品番）の場合は、サプライヤー側ではそのアイテム名で束ねて表示したいし、各社から送られてくるフォーキャスト・データは、期間や予測の細かさが異なることが多いが、サプライヤーでは、社内の標準フォーマットに直したい。　バイヤー各社は企業文化が異なり、ビジネスの仕方は異なるわけだから当然、各社のフォーマットは違い、これを統一してくれというのは無理な話だ。　受け側のサプライヤーで各社のフォーマットの違いを吸収すればいいわけで、これがXMLとEAIツールを使えば、非常に簡単に「変換」できる。　固定長のテキストデータや、CSVデータでは、データベースに格納する前の処理が面倒だし、フォーマットが変更されるとメンテナンスが大変だが、その点XMLは「変換」を強力にサポートしてくれるものである。
② 蓄積〔検索（Retrieve）を含む〕は、RDB（リレーショナル・データベース）からXMLを扱えるようにしたものと、ネイティブXMLデータベースがあるが、私の経験ではまだ十分実務で使えるまでいっていないと思う。　XML文書の各タグとRDBのフィールドをMapping してRDBのデータとして扱うのが、現時点で一番いいのではないか。　昨年、オンメモリ・タイプのネイティブXMLデータベースを評価したが、処理速度は申し分なかったが、検索方法や開発方法においてまだ難があった。　実務において直接XML文書を扱えるようになるには、もう少し時間がいるような気がしている。　（反論はあるかもしれないが。）
③表示はまったくだめだと思っている。XSL-FO（Extensible Stylesheet Language Formatting Objects)は、企業で実際使うフォーマットに対応できないと思う。　XMLデータを変換し、HTMLのスタイルシートなどを用いてWebブラウザで表示することもあるかもしれないが、これも実際のビジネスで使うには物足りないものだ。　ということで、XMLを使って「変換」することは現時点においても非常に有効だと思う。

＜XML Schemaについて＞
　私は、今使えるIT技術を組み合わせて、システムを構築する人間で、コンピュータの技術について、多くを語る資格はないかもしれないが、XML Schemaに関しては、以下のような理由で快く感じていない。　XML名前空間（Namespace in XML）をうまく扱えないという欠点があるので、DTDが良いとは言えないが、あえて言えば、DTDのほうが好きなくらいだ。
【XML Schemaが好きでない理由】
① スキーマなしでも、データは流通できる。（実際のインターネット上を考えてみればいいのではないか。）　型情報が全てでないはず。　テキスト情報だけでの処理のメリットも考えてみよう。　できるだけ軽く、情報を交換することが大切。
② XML Schemaのような「重い」仕様ではダメ（仕様は、「軽く」なくては！）。
③ 現状のB2Bにおいて、フロント（B2Bサーバー）で、XML文書の何をそんなにXML Schemaを使って（時間、負荷をかけて）、Validation（データの妥当性のチェック）をするのか？
ⅰ）上記で述べたように、「蓄積」はまだXMLだけでは無理があると思う。　データのValidationは、データが発生するところで、行なうべきだし、いろいろなマスタ・データを使ったチェックを行なう必要から、B2Bでは、フロント（B2Bサーバー）でのValidationにも限界がある。（Back-endにてもう一度Validationを行なう必要があろう。）
ⅱ）B2Bサーバーの送受信時に、毎回XML Schemaを使いValidationを行なうと負荷がかかり、送受信に支障をきたすことになる。（次々来るリアル・タイムデータがキューをあふれてしまうとか…）

＜XMLのバイナリ化（XML Binary Characterization）について＞
　私は、XMLは「テキスト・ベースで、人間が可読で、簡単なエディターでも内容を確認できる」ことが、大きなメリットであると考えてきた。　しかし、最近少し考えを変えつつある。　それは以下のように考えるようになったからである。
① B2Bにおいて、１文書が場合により数MB（聞くところによれば１文書が数十MBのデータを受け取った会社もあるらしい。それは、１アイテム分の情報が多いところに、１文書に多数のアイテム情報があるからである。）になることがある。　その理由は異常に長いタグ名にも起因しているが、XMLのテキスト・ベースの文書が、バイナリに比べ冗長なためである。そのために、メモリやハードディスクが無駄に多く必要であったり、処理速度にも悪い影響を与えることを幾度と経験した。
② B2Bでは、ビジネス・プロセスの自動化（Business Process Automation）を図り、情報の受け渡しを迅速かつ正確にそして効率よくすることが目的だが、その場その場でデータの中身が人間に可読できなくてもいいのかもしれない。　それよりも効率の良いデータ転送を考えるべきであろう。
③ 今後、企業間および企業内で使うだけでなく、携帯電話等の種々の機器で使うことの方が多くなることを考えれば、冗長性がありすぎることは問題。（KDDI研究所の汎用XML文書符号化方式「XEUS（ゼウス）」もXML文書の効率的な検索を目指しているXMLのバイナリ化技術で、携帯電話での使用を想定していると思われる。）
④ ハードウェアの技術もどんどん向上しているし、近いうちにバイナリのエンコード、デコードも瞬時にできるようになり、バイナリに関する負荷も無視してよくなるであろう。
まだ、私は、完全に「XMLバイナリ化賛成派」とはなりきっていないが、バイナリ化は、電子データの効率的な交換（Application Functionalitesをつなぐこと）において注目する必要があると思っている。

言語としてのXMLについて、いくつかの観点で書いてきた。　どんな言語でも完璧なものはない。　電子データの交換のツールとして、記号言語のXMLは、期待の持てるものに違いない。　その期待を摘み取るような、「重い」言語にしないように、皆で気をつけていきたいものだ。　"The limits of my language mean the limits of my limits of my language mean the limits of my world."の意味を皆がよく考えて、XMLが、「論理的な文法－論理的な構文－に準拠した記号言語」になっていってほしいものである。