ACML の改良の余地

ACMLは構文規則に忠実に表現してるため、プログラミングスライスとクロスリファ レンスに必要な情報も一通り備わっていた。そのため、比較的容易に各々のツールを作 成することができた。また、このツール作成の経験から得られた成果として、現時点の ACMLの改良の余地を発見することができた。以下で、その主なものを示す。

6.3.1 エレメントノードの文脈のための情報とリンク

ACMLが表現する木構造には、幾つかの改良点があった。これらは、設計不足という よりも、実装を通じて初めて分かることである。DTDの設計には、多くのトレードオフ があるので、実装実験は重要である。

図 6.1: ACML文書の表示例

• エレメントノードの文脈

現在のACMLには、エレメントの文脈、特に、そのエレメントが何番目の兄弟であ るかの情報が不足している。特に下方から上方へ解析を行う場合は、親に戻って子 供を数えなければ知ることができない。例えば、図6.2で、あるstatementがthen 部か、else部かは、そのstatement(B,C)の属性には書かれていない。木構造が大 きくなれば、数えるのは面倒な定型作業である。これは、データ統合としてACML に含めるべきか、アプリケーションで対処すべきかなど検討中である。

• リンク

ACMLのリンク(ID/IDREF)による情報については、シンボル情報部から構文情報 部と型情報部へは、十分に関連付けができている。しかし、現在のACMLでは、そ

statement (if-else)

expression statement statement

A B C

図 6.2: 3.2.1節の例を木構造で表現

の逆向きのリンクがない。これも、ACMLに含めるべきか、アプリケーションで対 処すべきかは検討中である。

6.3.2 _{前処理に関する情報}

前処理系は、ANSI Cとは独立した文法(例えば、マクロ定義や条件付コンパイル)[52]

を持つ。XCIは前処理後のANSI Cプログラムにタグ付けするため、現段階ではマクロは 展開されたまま復元不可能である。これでは、ソースプログラムに対して完全には操作で きないし、解析結果もソースプログラムに完全には反映されない。マクロ定義を復元する 手法を検討する必要がある。

これは、我々だけが抱える問題ではなく、ANSI Cツールにとって一般的な問題である。

Sapidでは、部分的(#include命令と#define命令)に各ファイルに前処理前後間の対応 表を生成することで解決している。

6.3.3 _字句情報 ( 空白、コメント、インデント ) _の保存

ACML文書をアンパースすると、元のプログラムと意味的には等価であるが、見かけ は等価ではない。現在のACMLでは、字句情報を保存してないからである。プログラミ ングスタイル[55]は、ソフトウェアを理解する上で貴重な情報となり、プログラマの意図 も明確に表現する。字句情報の保存は、技術的には可能である。しかし、現在、その保存 方法について、ACMLのデータとして保存するか、あるいは、ACMLとは独立して保存 するかなど、その実現方法を検討中である。

6.3.4 DTD の決定性問題

現在のACMLを定義するDTDは、XML1.0[1]の仕様には合致しているが、推奨事項に 反するエレメント宣言をしている。XML1.0ではSGMLとの互換性を考慮して決定的内 容モデルを推奨しているが、ACML用のDTDでは決定的内容モデルになっていない。そ

のため、ACML用のDTDでは、正確な妥当性の検証ができない場合がある。しかし、制 限のない拡張BNFによるDTD表現は、簡潔で直感的に理解できる。仮に決定的内容モデ ルだけで、ACMLを定義しようとすると、エレメントの数を大幅に増やさなければなら ず、DTDを複雑にするだけである。それゆえ、現在のACMLの表現の方に利点がある。

また、他のスキーマ言語(例えば、RELAX[17])は、非決定的内容モデルの記述を認め ているものもある。これについては、十分に検討する必要があるが、次の点においては、

DTDの方に利点があることから、我々は、DTDに対して積極的である。

• SGMLで使われていた経緯から、成熟した技術で長所と短所が明確である。

• 安定ツールが、他のスキーマ言語よりもDTDの方を多くサポートしている。

• 文書規則をコンパクトに表現することができる。

• データ型はないが、エレメントの入れ子構造を簡潔に表現できる。