CGMバージョン4のサポートが徐々に増えつつある中、近年このフォーマットによって保存、配布されるイラストレーションが急増しています。最も普及しているプロファイルは航空輸送協会（Air Transport Association）のWebCGMおよびATA GREXCHANGEプロファイルです。CALS協議会は、MIL-D-28003B 仕様の中でこれら双方のプロファイルを参照として付しています。

各種のプロファイルはいずれも、この文書で後述する“grobject”構造を使うことにより、CGMファイル内にメタデータを保存することに対応しています。このメタデータの保存についてさらに細かく検証することは、CGMファイルをより有効活用することに役立つでしょう。

メタデータとは？

グラフィックスファイルに保存されるグラフィック以外の情報は、基本的にいずれもメタデータと考えられます。ここで、イラストレーションの特定部分に関連づけるすべての情報について考えてみましょう。そのような情報には、シンプルなホットスポットやID、あるいは回路図のワイヤ直径、電圧、テスト値を詳細にまとめた一覧などがあります。

WebCGM
WebCGMは、“grobject”を使ってグラフィック以外の情報を保存します。次の属性が認められています。

ATA GREXCHANGE
ATAプロファイルにおいても、ほぼ同じ項目の属性が認められています。

id	オブジェクト固有のID
name	オブジェクトの名称
region	クリック可能なホットスポット領域
viewcontext	オブジェクトがリンク機能のターゲットの場合、ターゲットビュー
screentip	マウスがオブジェクト上にあるとき表示されるスクリーンティップ
refLoc	ATAに特化したリンク

特定プロファイルなし
CGMバージョン4を特定プロファイルなしで使用する場合は、CGMファイルにどのような情報も保存できます。ただしこの場合、通常は単一ベンダの製品のみで情報を必要に応じて処理できるというのが現状です。

追加情報を保存する方法

WebCGMまたはGREXCHANGEのいずれも、CGMファイル内に追加情報を保存できませんが、これにはそれなりの理由があります。異なるベンダの製品間でデータを交換するための相互運用性および信頼性を確保することが、これらのプロファイルにとって最も重要な目的だからです。

グラフィックオブジェクトとともに追加情報を保存する場合は、基本的に2つの方法があります。プロファイルなしにCGM4を使い、オブジェクトの専用DTDを使ってメタデータを保存できます。この方法はIsoDrawおよびIsoViewもサポートしていますが、他の製品でサポートされているとは限りません。

もう１つお勧めする方法は、CGMファイルとは別にXMLまたはSGMLコンパニオンファイルでメタデータを保存する方法です。この方法によって、現行および将来的なCGM製品との互換性を確保できます。.

CGMファイルは、次のような直接グラフィックスの内容に関係する情報のみを含むようにします。
 

• id:  オブジェクトの特定に必要。
• name: 共通名によってオブジェクトを指定するのに必要。CGM外部に保存することも可能。
• region: グラフィカルなコンテンツ、座標系および形。
• viewcontext: 四角形。座標系に置かれる。
  

シンプルなケースでは、スクリーンティップおよびリンク先URIをCGMファイル内に保存する場合もあり、その他の属性はいずれもファイル外部に保存します。

2つのケースについて考察します。

ケース1:
CGMの内部には、上述の属性をともなうgrobjectがあります。ここでは、単純なスクリーンティップをオブジェクトに加えて、“2376-A88”のようにパーツ番号を示します。もう1つ、クリックしてウェブアドレスに進むようにするオブジェクトがあるので、リンク先URI "http://www.itedo.com/" を加えます。

これらはシンプルなケースに使われる静的な属性なので、CGM内に容易に保存できます。

ケース2:
CGMファイル内に同じオブジェクトがあります。問題は、そのファイルを各種言語バージョンのパブリッシングまたはIETMで使用するということです。このため、単純なスクリーンティップは通用せず、ランタイムに特定言語のスクリーンティップを用意するための方法が必要となります。

同様の問題は、使用するリンクがファイルの使い方次第で異なる場合です。たとえば、ファイルをパーツカタログ内で使用するのか（パーツテーブルへのリンク）、または保守マニュアル内で使用するのか（解説文へのリンク）などの違いです。このケースでは、ランタイムに必要な情報をともなうコンパニオンファイル利用を検討するのがよいでしょう。

その他の注意点
これまで、WebCGMおよびGREXCHANGEに認められた属性について説明しました。これらの条件に従いながら同時に別の情報を加える場合は、外部的な保存を使うことになります。


戦略的な考察

CGMファイル内のメタデータを必要最小限にすると、次のようなメリットがあります。

• grobjectおよび上述の属性は最近5年間変化がなく、この先も相当期間変わらない。したがって、将来的なCGMリリースおよび製品との互換性が保たれる。
• ＣＧＭファイル外部に保存されるメタデータは、いずれも維持しやすい。XML/SGMLコンパニオンファイルを使用する場合は、よく使われているツールを使って、必要に応じたデータ操作が可能。
• コンパニオンファイルには、あらゆる情報を保存できる。ベンダー独自のCGMインプリメンテーションに依存することはない。
• AECMA (European Aeronautics Consortium、欧州航空学会コンソシアム)はXMLコンパニオンファイルの概念を導入しており、他業界にも採用されている。
  

現在、CGMファイルの特別なスキーマまたはDTDはありません。保存される情報が、あまりにも多岐に渡るからです。
基本的には、次のようなXMLファイルを作成できます。
<cgmcompanion file=”myCGMfile.cgm” …(other attributes)>
  <grobject
    id=’myID1’
    screentipEng = ‘my English screentip’
    screentipGer = ‘mein deutscher Screentip’
    wireDia = ‘2.5 dia’
    link1 = ‘... some link’
    link2 = ‘... some other link’
    link3 = ‘... some third link’
  />
  <grobject  ... and so on for each object
    ...
  />
</cgmcompanion>

ランタイムに、grobjectのIDを使ってビューワーがマウスイベントをランタイム環境にレポートします。このオブジェクトの適切なリンクを探すには、たとえコンテキスト依存の場合でもシンプルなルックアップで十分です。

結論

認められた属性を扱う限りは、多くの場合はメタデータをCGMファイル内に保存することで十分に対応します。ただし、リンクおよび属性を別のファイルに保存するほうが良い場合も多々あります。

• 属性を頻繁に変更する場合。
• 他のプログラムから属性へのアクセスが必要な場合。テキストおよびグラフィックスのリンクなど。
• ファイルを頻繁に改訂しながら長期間維持する必要がある場合。
• 相互運用性が重要な場合。特定ベンダのCGMインプリメンテーションに依存したくない場合など。
• CGMプロファイルのいずれかで認められないグラフィックスオブジェクトとともに属性を保存する必要がある場合。ワイヤ直径、価格、テスト値など。
• 現在はシンプルなケースを扱っているが、将来的にはより精巧なイラストレーションが必要になると予想される場合。
  

付録：CGMバージョン4ファイルのアプリケーションストラクチャー
「アプリケーションストラクチャー」を使って、CGMファイルのホットスポットを定義します。ISO/IEC 8632:1992に対する1995 修正 2で、CGMにアプリケーションストラクチャーが加えられ、バージョン4がCGMの最新バージョンとして定義されました。アプリケーションストラクチャーによって、各種グラフィックエレメントに関連するファイルにグラフィック以外の情報を含むことができます。ただし、この修正はアプリケーションストラクチャーの構文を指定することのみを目的としており、そこに意味を割り当てることはしません。ここでは、制限されたテキストエレメントを含むアプリケーションストラクチャーの例を平文表記コードで示します。

BEGAPS 'callout1' 'grobject' STLIST;
APSATTR 'name' "14 1 'Callout 123'";
BEGAPSBODY;
RESTRTEXT 7 4 216,246 final '123';
ENDAPS;

アプリケーションストラクチャーは、BEGAPS (BEGin Application Structure)で始まり、ENDAPS (END Application Structure) で終わります。第1行目は、アプリケーションストラクチャーを定義します。ここには、“grobject”というタイプの構造が、固有の識別子“callout1”で示されています。

タイプgrobjectは、WebCGMおよびATA GREXCHANGEプロファイルで定義されています。第2行目は、“name”というAPSATTR (APplication Structure ATTRibute)を定義しています。次に続くストリングは、属性に関係するデータについての情報を含んでいます。14はストリングの略、1は後に続くストリングの数を示し、‘Callout 123’はストリング自体です。

このように構文を表すことによって、プログラムがデータ自体の意味を知らなくともデータを読み取ることができます。名前属性は、アプリケーションストラクチャー本体に含まれるグラフィカルプリミティブの名前として使います。最後に、BEGAPSBODY (BEGin APplication Structure BODY) および ENDAPSステートメントの間にグラフィカルプリミティブがあり、この場合単一の制約付きテキストエレメントです。