昨今の計算機技術の進歩に伴い、さらに高速・高精度化された数値計算が 望まれ研究される一方で、個別のプログラムに関して詳細な情報を得る方法、 膨大な量の解析結果から研究者毎に関心のある情報を引き出す手段は、 その技術の進歩に比べて未発達であると言える。

そこで、本来なら共有可能な貴重な情報にも関わらず抜け落ちている情報、 例えば経験に基づいた実験パラメータや、 数値計算プログラム利用の際の計算例などを含め、 増え続ける情報を、効率よく有効に利用可能な仕組みを構築・整備することが 重要となってきた。

こうした状況を受け、2000年11月、伊理正夫らを中心に 知見プラットフォーム推進協議会が発足した。 この協議会は、知見プラットフォームの普及と、 知見共有のために策定したコンテンツ形式と ソフトウェア・アーキテクチャを公開し、標準化を推進することを目的としている 。

この知見プラットフォーム構想の基となっているのが、 過去に情報処理振興事業協会（IPA）の 次世代デジタル応用基盤技術開発事業（平成10年度）において CAMP(Collaborative Activities for Materials Science Programs) プロジェクトが中心となって研究開発した情報共有システムである。 同システムでは、計算科学分野において萌芽期にあるプログラムの発展の促進を狙い、 従来ソースコードの公開に留まっていたものに、 計算例や計算テクニックなどのプログラム利用に関する様々な知見を付加し、 これの蓄積・流通・活用に至る整備された環境を提供する。

具体的には、既存の情報は知見文書と呼ばれる XML により構造化されたものに書き換え、 これをデータベースに蓄積し管理する知見情報サーバーと、 ネットワークを介した知見文書の検索・取得・登録をこなし 知見文書オーサリングツールという側面も持つ知見情報フロントエンド、 そして、計算プログラムが XML で表現された知見情報を入出力できるようにするための XML I/O ライブラリからなる（図１)。

実証実験は、生体高分子、メッシュ生成、計算流体力学、計算物理の ４分野の研究グループで行われ、以下の有用性が確認されている（表１)。

• パラメータ設定方法などのノウハウ継承、類似ケースへの転用による効率化。
• 協働作業による効率化。
• 多種類の解析結果の集積により、類似性や多様性が容易に評価可能。

知見プラットフォームは研究者間のコラボレーションを支援する、 知的研究基盤である。これは計算科学技術分野に限らず、 科学技術分野全般における研究開発活動を促進する上で 大きな効果が期待されると思われる。

地球惑星科学分野でも知見情報の定式化を行うことが強く要請されているが、 地球惑星科学分野内部での動きは、 地理情報学など行政サイドの必要の強い領域をのぞいては、 非常に鈍いと言わざるをえない。

これは、新たな知見情報を得ることが通常の研究活動とされ、 既存の情報を活かす組合せ方の調査、 さらにはそのための技術を開発することが、 従来、理学的研究とは見なされて来なかったことに加え、 XML 等の最新情報技術や計算機科学の動きを理解している地球惑星科学者が今だ少なく、 従って、このような研究活動に対する理解がない、 あるいは、どう評価していいかわからないことに依る。

今後さらに他分野へと範囲を拡げ発展しゆくと目される 上記知見プラットフォーム推進協議会の生成物と互換性を保つことで得られる種々の情報が、 物理・化学などの枠を超えた総合科学分野ともいえる地球惑星科学において 有用と成りうることは無論のこと、 むしろ総合的位置にあるが故に個別の学問の領域では 満たすことの出来ない知見を得ることのできる地球惑星科学こそが、 視野を拡げ積極的にその情報管理を行うべく活動すべきではないだろうか。

本研究では、知見プラットフォーム推進協議会における 流体工学・地球流体科学知見情報部会を視野に入れつつ、 知見情報の共有に必要となる技術について調査し、 地球惑星科学分野における知見情報共有システムの姿を模索したい。 なお、先駆的な試みゆえ、 地球惑星科学での応用を具体的に考える前段階としての概念的導入と整理を行うべく、 簡単な例を構成して考察を進める。

知見とは字のごとく「見て知ること」である。 つまり知見情報は見て知り得た情報であり、 そうした情報の一部は整理され論文などの形で発表されている。 だが、研究者の頭の中や１研究室内といった範囲に存在する情報のうち、 公にされれば非常に有用であるものも多々ある。

言葉を重ねることになるが、 例えば、数値計算プログラム利用の際の具体的な計算例、 同じ方向性をもつ研究者間で口頭で交わされたきた研究ノウハウや、 論文などに現れにくい失敗談、 実験における経験に基づいたパラメータなどである。

こうした情報がより円滑に交換される環境があれば、 それまで知り得なかった情報を端に、 研究者間の協力が活性化されると考えられる。

では、そうした環境には、どのような事が求められるだろうか。 次節では、それをふまえて、必要とされる要件について述べる。

知見情報共有システムに必要とされる条件は、 情報の記法と情報の操作の２つに大きく分類される。

上に挙げた要件を満たす手段として、 先の情報共有システムでは、情報の記法に XML 、 操作環境を Java で記述した C/S システムを採択している。

しかし、こと XML においては、その技術自身が発展途上にあるため、 情報共有システムが開発された当時に比べ、 現在、新たな技術や概念が現れ標準化へと向かいつつある。

そこで、４章では XML について紹介し、 知見情報を表現するのに XML が適している理由を述べる。 ５章６章では知見プラットフォームにおける知見文書を基に、 システム実装に関わる技術として有望と思われるものを紹介する。

XML（邦訳すると"拡張可能な印付け言語"となるが決して一般的ではない）は、 SGML（Standard Generalized Markup Language） [ISO 8879] のサブセットであり、 W3C（World Wide Web Consortium） によって作成され、その仕様が勧告されている。

これは言語を記述するための言語、即ちメタ言語であり、 言語の構造を記述する手段を提供するものである。 2001年01月現在での最新のものは、 2000年10月06日に勧告された XML 1.0 (Second Edition) である。

XML は、文書型が容易に定義でき、SGML で定義された文書が簡単に記述・管理でき、 インターネットを経由してそれらを容易に伝送・共有することを目標としている。

以下に XML 文書の例を示す。

この様に XML では、全ての情報は文字に置き換えて記録される。

XML 文書はテキスト・データである。 これはバイナリ・データと異なり人間の目で内容が確認できるという事を意味する。 しかし、従来よりみられる一般的なテキスト・データと異なり、 内容を構造化して表現することが可能となっている。 また、コンピュータもその内容を判読できるよう設計されている。

それを可能にしているのが、タグ（tag）によるマークアップである。

「XML の記法」という文字列に、それが表題であるという情報を付加するならば、 <title>XML の記法</title> のように、 不等号で挟まれたもの（ここでは <title>） で文字列を挟む。この行為をマークアップと呼ぶ。 各部の呼称を図２に示す。

なお、要素名とは不等号に挟まれた文字列を指し、 要素（element）の型（type）を表す（図２では title）。 また要素（element）は属性（attribute）を持つことができる（図３）。

XML では、中身（content）に要素（element）を含めることで階層構造を構成する。 これにより要素間に親子関係が生じ、情報を構造化する事ができる。 このような構造は図４の様な形で視覚的に表現できる。

上に挙げた要素等は一つの例に過ぎず、 XML では要素名や属性は必要に応じて任意に設定することが可能である。 これによりアプリケーション固有の要求に合わせて機能を拡張することができる。 コンピュータは要素や属性、要素間の構造を捉えることで、 内容を判読する。

一般に、XML を用いた情報表現の長所は"分かりやすさの向上"であり、 短所は"効率の低下"である。

• 長所
  1. 先天的特性による長所
     • テキストを扱う既存の多くのソフトウェアで容易に扱える
     • 人間が直接内容を確認することが容易である
     • 内容の修正も特殊なソフトウェアを必要としない
  2. 後天的特性による長所
     • 様々な分野で多くの人々から注目されたために、 XML 文書を処理する際に必要となる概念や規格、 ソフトウェアが活発に生まれており、 それらを利用することで、 個々のプログラム作成にかかる手間を減らし、 その構造もよりシンプルなものにすることができる。
• 短所
  • 文字として表現するために回りくどくなり、 従来のバイナリ・データと比べデータ量が増える。
  • 文字列以外のデータは変換してから処理する必要があるため、 そのための処理工程が増える。
  • 文字で表現しにくい画像データなどを取り扱いにくい。 これは直接バイナリのまま埋め込むことで回避できる。 また画像においては、 １[pixel²]毎に異なる情報として 取り扱う必要があるデータ（写真など）を除き、 図形情報として取り扱えるデータ（グラフ等）は、 後で紹介する SVG を利用することで積極的に対応できる。

XML と同様にタグを用いて情報を表すものに WWW における情報記述用共通言語 HTML があるが、 HTML は WWW 用に設計されているために視覚的意味付けに終始している傾向にあり、 データの論理構造と物理構造が混在した記法をとる。 データの論理構造を記述するための言語を表現するために設計された XML とは 現在は目的が異なっており、 比較競合する対象ではなくむしろ兄弟関係にある。 また、HTML は要素型を独自に定義することを許していない。 XML 自身は SGML の難解・厳格な部分を取り払い、 HTML のインターネットとの親和性を受け継いだ言語とも言える。 今日では XML を利用し、HTML を XHTML として再設計する方向にある。

XML はその拡張性の高さから、既に様々な分野から注目を浴びている。 主要な用途として、 新たなマークアップ言語の策定にメタ言語として利用すること（MathML etc.）、 情報の交換や再利用を円滑に利用できるよう書式を規格化すること（PML etc.）、 異なるシステム間で効率的に連携できるよう入出力を抽象化すること（MML etc.）、 HTML に代わる WWW 上の情報表現手段として利用すること（Compact HTML etc.） などが挙げられる。

以下に具体例を幾つか示す。

• 医療
  • MML（Medical Markup Language）:
    異なる医療機関（電子カルテシステム）の間で、 診療データを正しく交換する為に考えられた規格。
  • PML（Pharmaceutical Markup Language）:
    PML 研究所の中橋氏が開発。 目的は、薬剤添付文書の電子管理。
• 化学
  • BIOML（BIOpolymer Markup Language）:
    タンパク質や遺伝子などの生体高分子等に関して、 実験情報を記述する規格。
• 電子商取引
  • BizTalk：
    Microsoft を中心にフレームワークを模索。 多数の企業が XML への強い関心を示すしているが、 XML は非常に柔軟なため、XML 実装のフレームワークに 一貫性が求められる。BizTalk フレームワークは、 幅広いユーザーが一般的な手法で XML を使用できるように するための一連のルールを実装する。
• 携帯機器
  • Compact HTML（NTT DoCoMo）
  • MML（Mobile Markup Language：J-PHONE）
  • WML（Wireless Markup Language：KDDI）

知見文書は、情報を XML で構造化したものであると述べた。 これは個々の情報をタグでパッケージ化したものと表現することもできる。 知見プラットフォームにおける知見文書の構造の概念図を、図５に示す。

左側に計算例を、右側にプログラムを、 それぞれ知見文書として表現した場合の構造を示している。 これは CAMP プロジェクトが中心となり研究開発した 情報共有システムの場合を例にとった。 地球惑星科学分野においては、この他、 観測データや実験データを登録することが考えられる。

表２に、情報共有システムの実証実験において、 知見文書として登録された内容を示す。

実際の知見文書の例を一部、下に引用する（芦野, 2000）。

(4.2) に示した例と比較すると分かるが、 上の例では <!DOCTYPE document SYSTEM "document.dtd"> に相当する行が存在しない。 また、要素名にアンダースコア（ _ ）が多用されている。 以下では XML 文書の定義と検証をふまえながら、これらについて述べる。

XML 文書は、XML 宣言、文書型宣言、 XML インスタンスの３つのブロックにより構成される。

XML 文書の第１行目には、その文書が XML で記述されている旨を示す XML 宣言を記述する。XML 宣言では、 記述に用いた XML のバージョンや文字コードなどを宣言する。 2001年01月現在、XML のバージョンは 1.0 のみであり、 基本的にバージョンの違いによる種類の差を考慮する必要はない。

XML 宣言は <? 処理命令ターゲット 処理内容 ?> という処理命令の形式をとる。 具体的には、
<? xml version=" XML のバージョン" encoding="文字コード名" standalone="yes|no" ?>
となる。ここでバージョン番号は必ず記述しなければならない。 また、文字コードの指定とスタンドアローンの指定は任意である。 文字コードは Unicode 多くの自然言語に対応可能なキャラクタセット。 cf.) http://www.unicode.org/ である UTF-8 と UTF-16 が規定値である。 スタンドアローンの指定の規定値は no である。なお、スタンドアローンに関しては後述する。

３番目の構成物 XML インスタンスは、階層構造を持った要素の集合である。 上の例では、<C_DOCUMENT>....</C_DOCUMENT>部が XML インスタンスになる。

２番目の構成物、文書型宣言（document type declaration）は、 文書中の要素、属性などを定義するものである。 文書型宣言で定義される文書型を DTD（Document Type Definition; 文書型定義）と呼ぶ。 DTD を外部ファイルとして用意し、それを XML 文書で利用することもできる。 文書型宣言は省略可能である。文書型宣言の例を２つ以下に示す。

これは (5.1) で例示した XML 文書を、 DTD で定義する場合に想像される文書型宣言である。 この例の内容は、あくまで筆者が XML 文書の構造を元に作り出したものであり、 一般的な文書型宣言の雰囲気を伝える以上の意図はない。 実際の (5.1) で引用した知見文書は、目的を持って文書型宣言を省略したものであり、 この文書型宣言が利用されているわけではないことに注意されたい。

これは (4.2) で例示した XML 文書の文書型宣言である。 上の例では文書型宣言の内容（DTD）が XML 文書内に存在するのに対し、 こちらは別途 document.dtd として DTD を記録したファイルを用意し、 これを文書型宣言の内容として参照している。

先に述べたように、XML では SGML と異なり、DTD の省略が許されている。 DTD の有無により、XML は下記の２種に分類される。

• Well-formed：（DTD 無）
  別名、整形式。XML の規格に適合しているもの。 基本的に１つ以上の要素を含み、開始タグと終了タグの対応がとれていれば良い （正確な定義は W3C による仕様書を参照のこと）。 全ての XML 文書は整形式を満たさなくてはならない。 整形式の XML 文書がある制約条件（DTD）を満たせば、妥当な XML 文書という。
• Valid：（DTD 有）
  別名、妥当。要素と属性や文書の構造をあらかじめ定義し（DTD）、 これに適合しているもの。厳密な検証を行うことができる。
  • スタンドアローン：ファイル中に必要な文書型定義が含まれるもの。
  • （非スタンドアローン）：定義部を外部ファイルに記述したもの。

XML がその将来を有力視された理由の一つに、 整形式の XML 文書を許したことが挙げられる。 しかし、異なる組織や研究者間で、円滑に XML 文書を交換する上で、 XML 文書の書き方のルールを曖昧さ無く表現し、 任意の XML 文書が正しい意図通りに記述されているかを検証することは、 非常に重要である。 そのためには、スキーマ言語を利用し、ルールを規定する必要がある。

XML 向けの代表的なスキーマ言語に、DTD を初めとして、以下のものが挙げられる。

1. DTD (Document Type Definition)
2. XML Schema
3. RELAX (Regular Language description for XML)

なお、(5.1) で引用した知見文書は上のいずれも利用していない。 その代わりに、 タグの定義を独自に定義した整形式の XML 文書（タグ辞書 知見プラットフォーム関連資料に従い、タグという表現を用いる。 と呼称）を用意しており、これをもって知見文書の検証を行っていると推定される。 ここで既存の DTD が採用されなかったのは、後述する DTD の弱点に起因する。 この手法は、後で詳細を述べる XML Schema や RELAX と同じ方向性を持つと言える。

定義の手段にいずれを選ぶにせよ、その記法は (3.1) で述べた要件を満たすよう、 策定する必要がある。 先の情報共有システムでの知見文書においては、 全体を共通タグと分野別タグに二分し、 共通タグセットでは知見情報の構造定義の他、情報提供者名や登録日時といった、 分野に依らない共通項目を表現するようにしている。

• 共通タグ：接頭辞 C_
  • 書誌情報：接頭辞 H_
    • 概要、作者、キーワード：H_abstract, H_affiliation, etc.
    • 相互連関、ハイパーリンク
    • プログラムのダウンロード、実行
  • 共通属性
    • 物理定数
    • データ型
    • 物理量
    • 単位系
• 分野別タグ
  • 応用分野別：
    接頭辞 BB_ => 生体高分子, 接頭辞 BF_ => 流体解析, 接頭辞 BM_ => 非構造メッシュ, 接頭辞 BP_ => 物質材料設計
  • 数値解析プログラム依存
  • システム関係：
    接頭辞 P_ => 通信プロトコル, 接頭辞 S_ => 検索, 接頭辞 E_ => 拡張機能
• その他（主にシステム関係）
  • タグ辞書記述用：接頭辞 D_
  • フロントエンド：接頭辞 F_

知見プラットフォーム自体が、まだ試作の段階にあり、 一般公開されていないため、上記一覧にはやや不正確な所があると思われるが、 基本的な設計方針は実際と大きく異なることはない。

ここで注目したいのは、タグを分類する際に、 その目的に応じて要素名に接頭辞を付加している点である。

知見プラットフォームのように、幅広い分野をサポートするシステムを構築する際、 １つの団体が全ての文書型定義（ここではスキーマ言語としての DTD ではなく、定義そのものを指す；タグ辞書）を決定するのではなく、 それぞれの分野に明るい人間が集って各々文書型定義を作成し、 共通部分のみ１団体で統轄する形が現実的である。

そうした場合、共通部分を定義したもの、分野別に制定したもの、 と複数の文書型定義が１つの知見文書内に共存できなくてはならない。 XML では自由にタグが定義できるために、全く同じ名称のタグに、 定義した人それぞれが異なる意味を与える可能性があり、 こうした名前の衝突を解決しなければならない。 また、検証という面からも、どの要素がどの文書型定義により定義されているか、 明らかでなくてはならない。

接頭辞の付加は、この問題に対処すべく考え出されたものと思われる。 この記法が策定された段階では、 まだ後述する XML における名前空間の仕様 （Namespaces in XML）が整っていなかったため、 独自に解決する必要があったことも大きく関与している。 既に名前空間は1999年01月に W3C により仕様が勧告されており、 またそれに対応したソフトウェアも増えてきている。 地球惑星科学分野用の文書型定義を策定する際は、 名前空間をシステム共々考慮した形で進めて問題はないと考えている。

XML における名前空間（以降、名前空間と記する）とは、 複数の XML データ定義を混在させるための XML 拡張仕様である。

XML の仕様では、要素型が同じであるならば同じものと見なすよう 決められている。 そこでこの仕様では、名前空間（namespace）と名前空間接頭辞（namespace prefix） という概念を XML に導入し、混在を可能にした。

実際に名前空間を利用し、(5.1) で引用した知見文書を書き改めたものを次に示す。

名前空間は URI (Uniform Resource Identifiers) を識別名に用いる。 上の例ならば、"http://www.tikenpuratto.org/tiken/common"や "http://www.tikenpuratto.org/tiken/material"が該当する。 なお、この URI は筆者が説明のために仮に作成したものであり、 例えばブラウザでアクセスしても全く意味はない。 URI は識別名として用いているに過ぎず、該当場所のドキュメントの有無は勿論、 実際にそのホストが存在する必要もない （ただし他者に既に利用されているものを用いてはならない）。 実際は、知見プラットフォームのサイトが完成し公開されれば、 その URI が適当であろう。

例の２行目では、DOCUMENT 要素の名前空間として "http://www.tikenpuratto.org/tiken/common"を指定し、 その名前空間に属する要素名の接頭辞に C を用いる事を定義している。 同様に７行目では、BODY 要素に含まれる接頭辞 BP の要素が、 名前空間"http://www.tikenpuratto.org/tiken/material"に属することを定義している。

名前空間接頭辞を付けなかった場合に、 どの名前空間に属するかを指定する構文が用意されている。 これを利用すると、上の例はもう少しシンプルに表される。

ここでは２行目に <DOCUMENT xmlns="http://www.tikenpuratto.org/tiken/common"> と記述することで、 既定の名前空間に"http://www.tikenpuratto.org/tiken/common" を指定している。

前に触れたように、DTD は SGML の頃より用いられているスキーマ言語である。 これにより、要素の名前や順番の指定、親子関係の制限、 必須要素と任意の要素の区別などを設定する。 XML とも異なる独自の記法をとるが、XML Schema や RELAX に比べ、 簡潔に文書型を定義することができる。

しかし、XML の柔軟性に対応しきれず、以下の様な欠点を持つ。

• 名前空間をサポートしない。
• 厳密なデータ型を扱えない。
• XML と文法が異なる。

１番目の欠点により、DTD に依存した場合、 大規模な XML を利用したシステムを構築することが困難である。 ２番目の欠点により、XML を取り扱う際に型チェックを行わなければならず、 プログラミングの行程が増える。 ３番目の欠点により、XML の学習とは別に DTD の文法を学ばねばならない他、 DTD を操作しようと思うならば、ツールを XML とは別個に用意しなければならず、 開発コストが嵩む。

こうした問題点を解決すべく、 W3C が策定している DTD に代わるスキーマ言語が XML Schema である。

知見情報を XML で表現し、知見文書として流通させるためには、 地球惑星科学分野においても、先の情報共有システムにおける"タグ辞書"に該当する、 文書型の定義が必要となる。

総合科学分野であるがゆえに、 他分野で既に設定された定義を組み合わせて用いることも可能ではある。 しかし、どの分野においてもその分野独自の情報表現は存在するものであり、 またシステムが開発途上にある現在においては、 積極的に環境を整えてゆくべきであり、 地球惑星科学分野用の文書型定義の策定が課題となっている。

実際の策定において採択するスキーマ言語は、 今のところ、RELAX が適切であると言えるが、 その名前空間の仕様を確定させる必要がある。 RELAX Namespace の仕様は、現在、 開発者用メーリングリストにおいて一部公開されており、 盛んな議論が交わされている。 仕様が早期に確定することを期待する （2001年03月には JIS TR として RELAX Namespace が発行される予定のようだ）。

知見文書のようにデータを XML で記述した場合、 XML 形式の文書から必要な情報を取り出す、 あるいは XML 形式の文書を作成するといった操作を行う必要がある。

そのための手段として、XML を扱うアプリケーション（応用ソフトウェア）に、 XML 文書の読み込みや、その内容及び構造へのアクセスを提供するソフトウェア、 XML プロセッサがある。XML プロセッサの振る舞いは W3C の Extensible Markup Language (XML) 1.0 (Second Edition) にて規定されており、XML の妥当性を検証するものとしないものに分かれる。

XML パーサ（Parser）は、XML 文書をその構文に応じて解析し、 構文木を生成するプログラムである。 XML プロセッサは SGML の流れを受けており、 厳密には XML プロセッサ と XML パーサは異なるが、 SGML では重要であったその違いも、 XML ではほとんど意味をもたなくなっている。 そういう意味で、XML においては XML プロセッサと XML パーサは 同じものであるとみなして問題はないという。 本論文では、以降 XML プロセッサと XML パーサは、 同じ意味として用いる。

アプリケーションと XML 文書は図６のような関係を持つ。

XML パーサは、既に数種類公開されており、 一般にアプリケーションは直接 XML 文書を操作するのではなく、 XML パーサを操作して XML 文書を処理する。

以下に代表的な XML パーサを示す。

• Xerces：
  APACHE XML PROJECT http://xml.apache.org/crimson/ が製作している XML パーサ。 Java 版、C 版、Perl 版が開発されている。 IBM 製パーサ XML4J（XML Parser for Java）を元に開発された。 2000年01月現在の最新 Java 版は、Xerces Java Parser 1.2.3。
• Crimson：
  Sun Microsystems 製の XML パーサ Project X の改良版。 後述する JAXP (Java API for XML Processing) に標準で同梱されている他、APACHE XML PROJECT から入手することもできる。 2000年01月現在の最新版は、Crimson 1.1-ea2 (Early Access 2)。
• XP：
  XSLT など XML 関連技術の開発の主要メンバーである James Clark http://www.jclark.com/ による XML パーサ。2000年01月現在の最新版は XP Version 0.5。

XML パーサを利用するため、実際のアプリケーションは、 パーサが対応するプログラミング言語で記述するのが自然かつ有利である。

多くの XML パーサは Java 向けに書かれている。 また、ほとんどの XML パーサ自体、Java で記述されている。 これは Java が XML を扱う言語として優れていることを反映している。

Java が XML を扱う上で優れている点に、以下のものがある。

• Java のキャラクタセットが XML の標準のキャラクタセットである Unicode であるため、 XML で表現されたファイルを取り扱う際に、 キャラクタセットを意識する必要がほとんどないこと。
• 様々なプラットフォームへの移植に気を使わなくても良いこと。
• こうした理由により、多くの XML 用の資源が Java で書かれており、 XML を取り扱う環境が整っていること。

一方、Java での問題点としては、 Java で作成したプログラムの実行速度が、 C++ などの他の言語で作成したプログラムに劣ること、 Java で描くツリー構築・生成のモデルが いささか直感的ではないということ、などが挙げられる。 しかし、前者の問題は Java が登場した頃より指摘され続けていることであり、 その対策として、頻繁に用いるコードはネイティブコードへ コンパイルするといった高速化の技術も現れているため、 大きな問題ではないだろう。また、後者の問題は Java に限ったものではなく、 主要な他言語でも同じといえる。 後者の問題が極めて重要視されるような場合、 Xi などの別の手段を検討する必要がある。

知見情報共有システムの構築においては、 上に述べたメリットの方がデメリットに勝り、 従って Java を採用すると良いと思われる。 ただし、システムの内、 既存プログラムとの連携を担う XML I/O 部は、 XML との親和性もさることながら、 既存プログラムに採用されている言語との親和性が重要となってくるため、 この限りではない。

以下に、 化学平衡計算を行うプログラムを用いた具体例をもって、 前章までに紹介してきた幾つかの技術の実際を紹介する。 ただし、ここでは XML を利用するとどのような事が行えるのか見ることを目的としており、 平衡計算自体は一切問題にしていないことを予めお断りしておく。

なお、ここで用いたプログラムは FORTRAN 77 で記述され、 Wood and Hashimoto (1992) の手法が用いられている。

こうして計算して得た結果を、 各化学種の存在比を全体を 100% としてグラフに表す。 ここでグラフは XML ベースのベクタ画像形式である SVG（Scalable Vector Graphics）を利用した（図８）。

SVG は W3C により策定されており、 2000年01月現在、SVG 1.0 が勧告候補になっている。 これは近く、1.0 として正式に勧告される見込みである。

SVG の策定には Adobe Systems も積極的に参加しており、 既にブラウザ向けに SVG Viewer プラグインが公開されている。 また、PostScript などからも変換可能である。

以下に SVG の特徴を挙げる。

• 画像の大きさにかかわらずデータ量が同じである。
• 拡大縮小したり印刷しても綺麗である。
• リンクをサポートしている。
• スタイルシートをサポートしている。
• アニメーションなどの動的な表現が可能である。
• JavaScript などの言語によって対話性のある表現が可能である。

以下に図８の SVG コードを示す。

２次元のグラフであれば、ほとんど全てを SVG で記述することが可能である。 XSLT で容易に XML 文書のデータを SVG に変換することが可能なため、 知見情報共有システムにおいては、 知見文書内のデータを可視化する手段として期待される。

既存のプログラムの中には、FORTRAN で書かれたものも少なくない。 そうしたものを XML と連携させるためには、２通りの手段が考えられる。

1. XSLT を用いて XML データを加工し、既存のプログラムに渡す。
2. FORTRAN 向けに XML の API を用意し、モジュールとして組み込む。

多くの場合は前者で対応可能だが、 標準入出力や複数のファイルを組み合わせて利用する様な、 複雑なプログラムにおいて前者で全て賄うことは不可能である。

従って FORTRAN 用 XML API の開発が望まれる。 開発にあたっては、他の言語と異なり、 主要な仕様全てに準拠することは現実的ではない。 DOM Level1 に準拠するだけで、本目的は充分叶えられると思われる。

このドキュメントは以下のファイルより自動生成されました。

• XML：index.xml
• DTD：document.dtd
• XSLT：document.xsl
• CSS：document.css