JPH04355855A - 汎用データストリーム・パーザ - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般的にはデータ処理
分野に関し、そして詳細には、様々なデータフォーマッ
トを有するデータストリームの送信及び受信のためのア
ルゴリズム及び方法に関するものである。更に、本発明
は、そのようなデータストリームの送受を希望するアプ
リケーション・プログラムと汎用データストリーム・パ
ーザが与えるサービスとの間のインターフェースにも関
するものである。

【０００２】

【従来の技術】多くの通信用ソフトウェア製品及びアプ
リケーションでは、複雑な自己定義型のデータストリー
ムをエンコード（構築）及びデコード（解釈）すること
が必要である。ネットワーク及びデバイス間通信におい
ては、データストリームのアーキテクチャとは、ある通
信ネットワークまたはデータチャンネルを介した送信及
び受信のため種々のデータ項目を組み立てるのに用いる
フォーマットのことを指すものである。このようなデー
タ・アーキテクチャには多くの種類がある。一般的には
、あるアプリケーション／プログラム／またはデータチ
ャンネルに入るかあるいはそれから出て来るデータのフ
ォーマットは、その特定のアプリケーション／プログラ
ム／またはそのデータチャンネルに接続したデバイスに
関連したデータのタイプに依存している。例えばシステ
ム・ネットワーク・アーキテクチャ（ＳＮＡ）サービス
では、その各ＳＮＡ製品、例えば分配サービス（ＳＮＡ
／ＤＳ）、文書交換アーキテクチャ（ＤＩＡ）、及び通
信・システム管理（ＣＳＭ）には、異なったタイプのデ
ータ・アーキテクチャが関係している。また、そのＳＮ
Ａ製品には、その他にも多くの例がある。異なったサー
ビスに対して違ったタイプのデータ・アーキテクチャが
通常出て来ているが、その理由は、それらサービスの特
定の要件のためや、またそれら各種サービスの各々のた
めに送るべきバイト数を最小限にすると同時に将来にお
ける変更や付加のための柔軟性を与えるようにするため
である。

【０００３】情報を送る必要がある時、送る対象となる
データ要素を、そのデータストリーム・アーキテクチャ
に適合した１つの線形シーケンスに組み立てなければな
らない。このプロセスをエンコードと呼ぶ。反対に、あ
るデータストリームが宛先に着いた時、そのデータスト
リームを分析し、それのデータ項目を抽出して関係する
アプリケーション又はソフトウェアで使用できるような
形式に変換しなければならない。このプロセスは、デコ
ードと呼ぶ。パージングという言葉は、それらエンコー
ド及びデコードを実現するのに必要なプロセスのことを
指すものである。勿論、異なるデータストリーム・アー
キテクチャにはそれぞれ異なるパージング論理が必要で
ある。現在、ソフトウェア開発者は、データ処理システ
ム又はノード内に個別のパージング手順を組み込んで、
通常遭遇する可能性のある異なるタイプのデータストリ
ームをエンコード及びデコードするようにしている。例
えば、それらデータストリーム（データ項目のタイプ及
びそれらの配列）は、典型的には、給与支払名簿ソフト
ウェア・アプリケーションに対するものは、磁気記憶媒
体（例えばハードディスク）に対するものと比べ全く異
なったものとなる。更に、それら個別のパージング手順
は、通常、あるアプリケーション（あるいはこれに類す
るもの）とのデータの渡しを、そのデータの受信と直列
に行うようになっている。これのためには、そのデータ
を適切に解釈するのに使うデータストリーム・フォーマ
ットをそれらアプリケーション等が知っていることが必
要である。

【０００４】

【発明が解決しようとする課題】異なった種々のデータ
ストリーム・アーキテクチャを受け入れるために１つの
システム内に別個の多くのパージング手順を組み込むこ
とは、高価であり、しかもシステム資源の設計、保守、
及び消耗の面で非効率的である。従って、もし単一で汎
用のデータストリーム・パーザを設計できれば、有益で
あろう。更に、そうした場合、そのようなパーザとこれ
を使うアプリケーションとの間には、それらアプリケー
ションをこれらが使用中のデータストリーム・フォーマ
ットに関する詳細な情報を知らなくてはならないという
繁雑さから保護するために、あるインターフェース構造
が必要となる。

【０００５】

【課題を解決するための手段】本発明は、データ処理シ
ステムで用いるための共通の汎用パーザ及びアプリケー
ション・プログラム・インターフェースである。そのシ
ステムは、データ通信チャンネルを備えた少なくとも１
つの処理ノードを含んでいる。パーザは、あるプログラ
ムからのデータをそのチャンネルに送るためにエンコー
ドし、また入って来たデータをあるアプリケーション・
プログラムに手渡すためにデコードする。そのチャンネ
ル上で入来するデータに対しては、パーザとそのプログ
ラムとの間のこの通信インスタンスを初期化する。この
初期化は、パーズテーブル内で定義したテンプレートに
対応したデータストリーム内の個々のデータ項目のフォ
ーマットを定義するパーズテーブル、を識別することを
含んでいる。また、この初期化は、その個々のデータ項
目に対しプライベートな記憶域割り当てることも含んで
いる。そして、そのようにした後、そのプログラムは、
パーザへのコールを発することによって、チャンネル上
でパーザが受け取ったデータの１テンプレート分のデー
タを要求する。そのコールは、パーザが用いるパーズテ
ーブルを識別するものである。これに応答して、パーザ
は、その識別したパーズテーブルに従ってその入来デー
タをデコードして、個々のデータ項目を抽出する。パー
ザは、それら個々のデータ項目をこれらの各々に割り当
てた上記プログラムのために記憶領域に記憶し、そして
次の組のデータ項目のためにコールされるまで、制御を
そのプログラムに転送する。

【０００６】上述の概要によれば、本発明は、多くのタ
イプのデータストリームを都合よく共通にエンコード及
びデコードすることができる汎用のテーブル駆動式の方
法を開示するものである。パーズテーブルは、与えられ
たデータストリームの構造及びレイアウトを記述する。 アプリケーション・プログラムは、共通のパーザへのコ
ールを発し、そしてこのパーザは、パーザテーブルを用
いて出力データストリームのエンコード又は入力データ
ストリームのデコードを行い、そしてそのデータを、そ
の所望のデータストリームの対し生成したテーブルを用
いてそのアプリケーションへ渡すようにする。長さフィ
ールド、構文識別子（コードポイント）、区切り等のエ
ンティティーの構成及び解釈は、希望であれば、アプリ
ケーションから完全に隠すことができる。マッピング・
データ項目及びユーザ出口によって、設計者はアプリケ
ーションとパーザとの間で渡すデータ項目用のソース／
ターゲット・フォーマットを指定することができる。あ
るいはこの代わりとして、あるユーザ出口を指定して、
構成すべきまたは解釈すべき個々のデータ項目を処理す
るようにすることができる。

【０００７】

【実施例】図１−７は、ある典型的なデータ処理システ
ムにおいて見ることのある、いくつかの異なったタイプ
のデータストリーム・フォーマットの例示的な例である
。これらデータストリームの１つの特徴は、これらが“
自己定義型”であるということである。即ち、それのデ
ータ項目のいくつかが、それ自体で当該データストリー
ムのフォーマットを定義する、というものである。例え
ば、そのデータストリームの要素は、１または２バイト
長のフィールド（“Ｌ”または“ＬＬ”）で始め、そし
てこの後に１または２バイトのコード即ちタイプ識別子
（“Ｔ”または“ＴＴ”）を続けて、後続の情報を唯一
に識別するようにすることができる。そして、そのよう
に識別した情報は、それ自身、自己定義型となって、ネ
スト状に繰り返すことがある。図１は、２バイト長（Ｌ
Ｌ）フィールドと、これに続く２バイトのタイプ識別フ
ィールド（ＴＴ）とによって構成した簡単なフォーマッ
トを示している。それのＤＡＴＡフィールド内の情報は
、長さがＬＬ−４の１つのデータ項目を形成する。 この例及び以下の例では、Ｌ及びＴは、１バイトのフィ
ールドを示し、ＬＬ及びＴＴ等は、２バイトのフィール
ド等を示している。図２は、埋め込みタイプのデータス
トリームを示しており、長さがＬＬでタイプがＴＴの項
目２００全体は、埋め込み型の項目２０２、２０４及び
２０６を含んでいて、これら項目は、各々１バイト長で
、そしてタイプ値がＡ、Ｂ、Ｃでその順序で生起するよ
うになっている。図３は、この図２と類似のデータスト
リーム・フォーマットを示しているが、これでは、項目
タイプ“Ｂ”は、オプション性のもの、即ちこのアーキ
テクチャの任意の特定のデータストリームにおいて生起
してもしなくてもよいものである。その他のフォーマッ
トでは、タイプＡ、Ｂ、Ｃのようなデータ項目は、いか
なる順序で生起しても許されることがあるかもしれない
。図４では、それらの生起順序はＡ、Ｂ、Ｃである。 しかし、図５では、その生起順序はＢ、Ａ、Ｃとなって
いる。また、ある種のデータストリームでは、ある種の
データ項目の繰り返しを許していることがある。これに
ついては図６に示してあり、これでは、タイプ“Ｃ”の
項目が連続して繰り返し生起している。また、図７に示
したフォーマットでは、その個々のデータ項目を長さバ
イトＬＬで記述しているが、１つのデータレコードの初
めと終りを、区切りＬＬＡＡと区切りＬＬＺＺによって
オフセットしている。ここでは、タイプＡＡの項目が１
つのレコードを始め、そしてタイプＺＺの項目がそのレ
コードを終了させるようになっている。以上のフォーマ
ットは、こなす必要のある多様なタイプのデータストリ
ーム・アーキテクチャのほんの数例にすぎない。従って
、その他の多種のタイプのフォーマットも、起こり得る
ものである。例えば、あるフォーマットでは、１つのデ
ータストリームの解釈が、このデータストリーム中で既
にデコードした項目の値に依存することになるかもしれ
ない。

【０００８】これから説明する例示的実施例では、アプ
リケーションが１つのデータストリームのエンコード及
びデコードを行うための２つのフェーズ、即ち、初期化
フェーズと処理フェーズとがある。その初期化フェーズ
は、ＯＰＥＮコマンドと類似したものであって、その環
境をセットアップししかもアプリケーションとエンコー
ダまたはデコーダとの間の通信を確立するのに用いるも
のである。図８及び図９に示すように、エンコードでは
、エンコード用アプリケーション８００が、８０２でＧ
ＤＰＥＩＮＩＴをコールし、デコードでは、デコード用
アプリケーション９００が９０２でＧＤＰＤＩＮＩＴを
コールする。このエンコーダ及びデコーダは、本例示的
実施例内のいかなる資源も“所有”することはない。 例えば、作業用記憶域、Ｉ／Ｏバッファ、パーズテーブ
ル、また外部のチャンネルまたはデバイスに対しデータ
ストリームを読み書きするルーチンでさえも、その初期
化コールで、１組のパラメータ（ＲＥＳＯＵＲＣＥ−Ｌ
ＩＳＴと呼ぶ）として渡すようにしている。また、その
チャンネルは、ノード間のデータリンク、または同一プ
ロセッサ内のプログラム間の内部メモリを横切るデータ
リンクのように、いかなるタイプのものでもよい。資源
をそのエンコーダまたはデコーダに渡す他に、当該アプ
リケーションは、変数ＨＡＮＤＬＥを渡すが、この変数
は、上記初期化手順によって戻すようになっている。そ
の初期化手順は、作業用記憶域をフォーマットし、エン
コード及びデコード処理に必要な状態情報を初期化する
。この初期化手順がそのコール元に戻る前に、その手順
は、上記変数ＨＡＮＤＬＥにある値をセットする。この
ＨＡＮＤＬＥ変数（ポインタ）は、当該アプリケーショ
ンと当該パーザとの連係を定義することになり、そして
エンコード（即ちＧＤＰＥＮＣＯＤ）またはデコード（
即ちＧＤＰＤＥＣＯＤ）のための全ての将来のコール時
にその変数を渡すようにしなくてはならない。一旦、初
期化が完了して当アプリケーションと当該エンコーダま
たはデコーダとの間の連係が確立し終わると、データス
トリーム処理を始めることができる。これをステップ８
０４及び９０４に示す。エンコードまたはデコードすべ
きデータは、それぞれエンコード（ＥＮＣＯＤＥ−ＲＰ
Ｌ）及びデコード（ＤＥＣＯＤＥ−ＲＰＬ）用の要求パ
ラメータリスト内のパラメータによって識別するように
する。それらエンコードＲＰＬ及びデコードＲＰＬを含
む個々のパラメータについては、後に詳述する。そのＥ
ＮＣＯＤＥ−ＲＰＬで参照する項目データをパーズテー
ブル共に使用することにより、エンコーダ８０４は、エ
ンコード形の出力データストリームを構築する。デコー
ドについては、デコーダは、ＤＥＣＯＤＥ−ＲＰＬ内の
情報を戻し、これは、どの項目を入力データストリーム
から抽出し終わっておりそしてそれらをどこに記憶して
いるかについて、当アプリケーションに教える。このア
プリケーションは、データをエンコードするためにステ
ップ８０４でＧＤＰＥＮＣＯＤをコールし、そしてデー
タをデコードするためにステップ９０４でＧＤＰＤＥＣ
ＯＤをコールする。１つのデータストリーム全体を処理
するためには、このアプリケーションは、ＧＤＰＥＮＣ
ＯＤまたはＧＤＰＤＥＣＯＤを多数回コールすることも
ある。

【０００９】与えられた任意のデータストリームについ
て、これをどのようにエンコード及びデコードするかを
パーザに教えるために、パーズテーブルを用いる。これ
らのパーズテーブルは、あるアプリケーションを設計す
る時に、図１８に示すデータストリーム定義言語（ＤＳ
ＤＬ）を用いて、定義するようにする。しかしながら、
それらパーズテーブルを、別の適当な方法で定義しても
よい。そのＤＳＤＬは本発明の一部を成すものではない
ので、ここでは詳しく説明しない。

【００１０】パーズテーブルは、図１０に概略的に図示
した木構造を形成するように互いに連係させた１組のデ
ータ項目記述子から構成してある。１つのパーズテーブ
ルは、開始記述子１０００で始まり、そして終了記述子
１００２で終了するようになっている。その開始記述子
は、テンプレートのリスト（図１０には図示せず）を指
し示すものである。そのテンプレートについては、後に
詳細に説明する。今のところでは、パーザとアプリケー
ションとの間のデータ項目のマッピング順序を指定する
のにテンプレートを用いる、ということを述べれば十分
であろう。１つのテンプレートは、例えば１データベー
ス・レコードのような１つのレコードと似ており、それ
は、処理に好都合なあるフォーマットに項目をグループ
化することを指定する。また、多数のテンプレートを単
一のデータストリームに対して定義して、コール元のプ
ログラムがそのデータストリームを“一度に１片”の割
で処理するのを可能にするようにすることができる。

【００１１】また、上記の開始記述子は、最初の記述子
１００４も指し、そしてこの最初の記述子１００４は、
順序で次の記述子を指し、更に同様のことを繰り返し、
そして最後の記述子１０１４が終了記述子１００２を指
すようになり、これでこのパーズテーブルが終了する。 一般的には、それら開始記述子と終了記述子との間で連
係させる記述子はどれも、項目記述子かグループ記述子
のいずれかとすることができる。各グループ記述子は、
多数の連係させた項目記述子及び／またはグループ記述
子を含むことができる。ボックス１００６に示したグル
ープ記述子は、グループ記述子１００７を含んでおり、
そしてこのグループ記述子１００７は、当該グループの
ある論理部分を形成する一連の項目又はグループの記述
子１００８−１０１０を含んでいる。明らかとなるよう
に、それらグループ記述子及び項目記述子は、ネスト化
することができる。

【００１２】次に、グループ記述子及び項目記述子の構
造を図１１、１２に夫々示す。それら双方の記述子の最
初のバイトは、記述子タイプ（ＤＴ）、即ち、これがグ
ループ記述子であるか項目記述子であるかを示すものを
含んでいる。グループ記述子または項目記述子の２番目
のバイトは、識別子（ＩＤ）を含んでいる。例として、
ＩＤフィールド内のゼロの値は、その項目またはグルー
プを識別していない、ということを示すことになる。ま
た、ある識別したグループとは、このグループがあるテ
ンプレートと関連があることを意味する。同様に、ある
識別した項目とは、このデータストリーム項目があるテ
ンプレート内で定義されたあるフィールドと関連がある
、ということを意味する。もしある項目が識別されてい
ない場合には、それをエンコード処理中において自動的
に構成し、そしてデコード処理中においてはアプリケー
ションに対し渡さないようにする。

【００１３】グループ記述子（図１１）では、それのＦ
ＩＲＳＴフィールドは、当該グループの最初の子記述子
へのポインタ（項目記述子またはグループ記述子のいず
れか）である。また、そのＮＥＸＴフィールドは、当該
グループの次の兄弟記述子（即ち同一階層レベル）への
ポインタである。ＦＬＡＧＳフィールドは、この特定の
記述子に対し定義した多数の制御ビットから成る。例え
ば、ある１つのビットは、当該グループが必要されてい
るものかあるいはオプション性のものであるかを示す。 その他のビットは、長さチェックまたは反復チェックを
行うべきか、また当該グループの長さまたは有無を計算
するためにある式を評価すべきかを示す。また、グルー
プ特定フィールドは、上記ＤＴ値が指定する特定のグル
ープタイプとＦＬＡＧＳ制御ビットの設定値とに応じて
、生起したりしなかったりするフィールドである。例え
ば、グループを繰り返すためには、ある反復範囲を与え
るようにする。条件付き記述子に対しては、それらグル
ープ特定フィールドは、ある式記述子へのポインタを含
んでいて、その式記述子は、当該グループの生起がいつ
あるかないかを定める規準を与えるようになっている。

【００１４】次に、項目記述子（図１２）については、
それのＮＥＸＴは、当該パーズテーブル内の次の（項目
またはグループ）記述子へのポインタである。ＤＳＡは
、上記エンコーダまたはデコーダの実行の間一時的に項
目値をセーブする必要のあるパーズテーブルについて、
これらのための実行時動的記憶領域へのオフセット・ポ
インタである。それらのＤＳＡ値は、パーズテーブルの
組立の間に割り当てるようにする。実行時には、その動
的記憶領域内に、そのＤＳＡフィールドが示すオフセッ
トにて値を記憶させるようにする。例えば、−１のＤＳ
Ａ値は、“空”値を示す。通常、データストリーム内で
生起する長さフィールドの計算のため、一時的な値をセ
ーブするようになっている。エンコード中は、そのＤＳ
Ａ値を使って、長さ値をどこに記憶させなくてはならな
いかを示すデータストリーム出力バッファへのオフセッ
トをセーブするようにする。デコード中は、そのＤＳＡ
値を使って、グループ構造または項目構造の長さを計算
するのに用いるものであるとデコードした項目値を、セ
ーブするようにする。

【００１５】図１３及び図１４は、ある例示のパーズテ
ーブルの詳細例を示すものである。図１３は、テンプレ
ートとグループと項目との関係を示している。Ａ、Ｄ及
びＪは、識別したグループであって、その各グループが
定義したテンプレートにも対応したものである。グルー
プＤは、グループＡ内にネストしたものでいる。このグ
ループＡは、項目Ｂと項目Ｃから成っているが、それは
、そのグループＤが新たなテンプレートを開始させるか
らである。テンプレートＤは、項目Ｆと項目Ｈとから成
っており、その項目Ｈは、グループＤ内にネストしたグ
ループＧ内に含まれているけれども、Ｄに含まれること
になる。この理由は、グループＧが識別したものではな
いからである（“（Ｇ）”で表す）。グループＪは、グ
ループＡの兄弟であり、そしてまたテンプレートＪにも
対応している。図１４には、この図１３のパーズテーブ
ルをより詳細に示す。図示のように、ＢＤＴ及びＥＤＴ
として示した記述子タイプは、それぞれパーズテーブル
の開始記述子と終了記述子を定義している。記述子ＧＤ
Ｔは、グループ記述子である。同様に、ＩＤＴは、項目
記述子を示す。また、これとは異なるタイプの項目記述
子及びグループ記述子を指定することもできる。また、
計算すべき式を定義するための多くの雑記述子がある。 以下には、いずれのパーズテーブルにも現れるような、
異なる種々の項目記述子タイプ及びグループ記述子タイ
プの例示的リストについて、簡単な説明を行う。

【００１６】ＧＲＯＵＰ　　ＳＥＱ：　　順次／非反復
グループ。このグループ記述子は、全ての従属インスタ
ンス（このグループの子記述子によって定義する）が、
それら子記述子で定義した順序で発生するようになった
、単一のグループ・インスタンスを規定するものである
。オプション性の非反復グループを規定するために、存
在規準を指定してもよい。オプション性グループとは、
その規準に依存してデータストリーム内で生起したりし
なかったりするものである。非反復グループの生起は、
ブール式または長さ式を評価したり、あるいは“ＬＴ”
接頭辞フィールドの有無を評価することによって、決め
ることができる。もしその存在試験が不合格となった時
（例えば、ブール式の評価がＦＡＬＳＥとなった時、ま
たは長さ式の計算でゼロまたは空となった時）には、そ
のグループのインスタンスが存在せず、従ってそのＮＥ
ＸＴ記述子を取り出すようにする。その“ＬＴ”接頭辞
は、そのグループデータの前に１バイトまたは２バイト
の“長さ”フィールドが先行し、その後に１バイトまた
は２バイトの識別フィールド即ち“タイプ”フィールド
が続く、特別な場合である。この場合には、ルックアヘ
ッド試験が行って、当該データストリーム内の適当な場
所でその正確なタイプ値が発生しているかどうかを判別
する。

【００１７】ＧＲＯＵＰ　　ＲＥＰ：　　反復グループ
。反復グループとは、データストリーム内に一連のグル
ープ・インスタンスが生起する可能性がある、というこ
とを意味する。この反復グループの各インスタンスは、
順次／非反復グループに対し記述した順次特性をもって
いる。このグループの最後のインスタンスの処理を完了
した時を指定するには、いくつかの方法がある。例えば
、このグループのインスタンスは、先に計算した長さ値
が尽きるまで、またはある式を評価してその結果がＴＲ
ＵＥ状態となるまで、あるいはある式の評価がＴＲＵＥ
状態となっている間、または固定したある回数だけ、生
起することができる。当該データストリーム内のそのグ
ループのインスタンスが生起していないという結果で、
その反復規準の評価が直ちに不合格となる場合がある。 従って、この反復規準は、存在規準としても機能する。

【００１８】ＧＲＯＵＰ　　ＳＥＴ：　　１組のメンバ
・インスタンス。このグループタイプは、そのメンバ・
インスタンスがデータストリーム内で任意の順序（必ず
しもメンバ記述子が規定した順序である必要はない）で
生起してもよいことを指定するものである。１つのグル
ープセットのメンバ構成要素は、必須のものでもオプシ
ョン性のものでもよい。このグループセット記述子及び
その子供を何回か解釈して、そのグループ・インスタン
スの全メンバ・インスタンスを検出するようにすること
ができる。あるグループセット記述子のメンバ記述子は
、いかなるＣＯＮＤＩＴＩＯＮＡＬ（条件付き）グルー
プ記述子または項目記述子（即ち、以下に定義するＩＴ
ＥＭＬＴ−）とすることができる。あるメンバ・インス
タンスはインスタンス組の中のどこでも生起できるので
、条件付き規準を指定して、所与のインスタンスがいつ
生起するかしないかを判定しなくてはならない。

【００１９】上記の反復グループと同様、何時全ての従
属メンバ・インスタンスの処理を完了したかを判定する
ために、いくつかの規準を規定することができる。例え
ば、もしそのグループ長を計算した場合、その長さが尽
きるまで処理を継続させ、また同様に、“ｗｈｉｌｅ”
式または“ｕｎｔｉｌ”式の評価によって終了を知らせ
るようにすることができる。最後に、そのグループ記述
子及びその従属物の走査の間に新たなインスタンスを検
出しなかった場合、そのグループ・インスタンスの処理
は、終了させる。

【００２０】ＩＴＥＭＦＬＥＮ：　　例えば１−２５５
バイトの間の固定長の項目。

【００２１】ＩＴＥＭＶＬＥＮ：　　例えば１−３２７
６７バイトの間の可変長の項目。

【００２２】ＩＴＥＭＵＮＩＱ：　　例えば１−２５５
バイトの間の唯一の定数値。この項目タイプは、自動的
にエンコーダによって挿入しデコーダによって除去する
コード・ポイントや接尾辞値のような定数、を規定する
のに用いることができる。

【００２３】ＳＴＲＥＡＭ：　　ストリーム項目。この
項目タイプによって、ファイルまたは文書のような無限
に長い項目を定義することが可能となる。

【００２４】ＩＴＥＭＬＴ：　　長さタイプ項目。この
記述子は、例えば１または２バイト長でその後に１また
は２バイトのタイプフィールド、その後にデータが続く
、自己定義型項目（即ちＬＴ．．．）を指定する。この
ＩＴＥＭＬＴによって規定したデータを、更にＩＴＥＭ
ＦＬＥＮ、ＩＴＥＭＵＮＩＱ、ＩＴＥＭＶＡＬＥＮに関
して規定することができる。また、このＩＴＥＭＬＴは
、このタイプのデータの共通使用による性能最適化のた
めに規定するものである。

【００２５】上述のように、更に多くの種々の雑記述子
がある。これらの記述子タイプは、必要な式（データス
トリーム内でオプション性のグループまたは項目の存在
規準及び有効性のためのアサーションを指定したり、長
さを計算したり、また必要であればそのデータストリー
ム内でルックアヘッドをしたりするのに必要な式）を指
定するのに用いるものである。

【００２６】ＴＥＳＴＬＫＡＨ：　　ルックアヘッド（
先読み）試験記述子であり、データストリーム内で＋ｊ
バイトの先読みを行わせ、そしてｋバイト定数に対して
試験を行わせるものである。このルックアヘッドは、デ
ータストリーム内を先行して走査することにより行うが
、既に処理を終えた項目オカレンスをマークするのに使
うデータストリーム・カーソルの状態を変化させること
はない。これは、入力デバイスから更にデータを読み取
ることを要求することができる。

【００２７】ＤＥＬＶ：　　デルタ計算記述子であり、
これは、データストリーム内で既に遭遇した値（例えば
長さフィールド）に、定数を加算または減算するデルタ
計算を行わせるものである。エンコード時には、定数を
データ長に加算することにより長さフィールドを計算す
る。デコード時には、デコードした長さフィールドから
定数を減算して（項目／グループ）構成要素オカレンス
の実際の長さを得る。この機能によって、同一のパーズ
テーブルをエンコード及びデコードに用いることができ
るようになっている。

【００２８】エンコードでは、正確な長さフィールド値
を得るのにこの機能を用い、そしてデコードでは、長さ
フィールド及びデルタ値が与えられた時の正確な（グル
ープまたは項目）データ長を計算するのにこの機能を用
いる。

【００２９】ＴＥＳＴＢＩＴ：　　ビット試験記述子で
あり、データストリーム内の単一ビットの“テストアン
ダーマスク（ｔｅｓｔ　ｕｎｄｅｒ　ｍａｓｋ）”を行
う。

【００３０】ＢＯＯＬＯＰ：　　ブール演算記述子であ
り、２つの式間の論理的なＡＮＤ比較またはＯＲ比較を
行う。これら種々の雑記述子の組み合わせを用いて、式
を指定するようにする。

【００３１】ＲＥＬＯＰ：　　比較演算記述子であり、
２つの式間の比較演算（即ち、ＥＱ、ＬＥ、ＧＥ、ＬＴ
、ＮＥ）を行う。

【００３２】ＬＫＡＨＦＬＤ：　　取出ルックアヘッド
・フィールド記述子であり、データストリーム内で現在
の位置からｊバイトだけオフセットしたｋバイトのフィ
ールド（即ち、デコードすべき次のバイト）を検索する
。

【００３３】ＴＥＳＴＵＳＥＲ：　　ユーザ試験記述子
であり、デコーダ要求パラメータ・リスト内で渡した３
２バイト・ビットマスクに対し試験を行う。

【００３４】ＣＯＮＤＥＦ：　　定数定義記述子であり
、式評価で用いる数値またはストリング定数を規定する
。

【００３５】ＡＳＳＥＲＴ：　　アサーション記述子で
あり、有効なデータをもつためには評価によってＴＲＵ
Ｅとならなければならない条件を規定する。エンコード
またはデコードしたデータに対して、どの程度までパー
ザが有効性チェックを行うべきかは、常に問題となるも
のである。ある場合には、アプリケーションがチェック
をより効率的に行うことができる。いずれの場合にして
も、データストリーム・タイプ毎に全ての起こり得る条
件（例えば、データ依存）を、自動的にチェックするこ
とは現実性がない。このアサーション記述子は、普通で
ない条件をチェックするという融通性を与えるものであ
る。この記述子は、他の記述子から式として参照されな
いが、グループまたは項目記述子の途中で発生すること
において、他の雑記述子とは異なっている。即ち、この
アサーション記述子は、項目またはグループ記述子のＮ
ＥＸＴポインタが参照し、また同様に、このアサーショ
ン記述子は、パーズテーブル階層内の次の記述子へのＮ
ＥＸＴポインタを含んでいる。アサーション記述子は、
２つの論理式、即ちＶＡＬＩＤＦ式とオプション性のＷ
ＨＥＮ式とを参照する。更に、エラーコードも含んでい
る。このアサーション記述子をデコード処理中に取り出
した時、先ずそのＷＨＥＮ式をこれがあるか否かについ
て評価する。この結果がＴＲＵＥであれば、次にそのＶ
ＡＬＩＤＩＦ式を評価する。もしこの結果がＴＲＵＥで
あれば、デコーダは、次の記述子を取り出すが、その他
の場合には、コール元のアプリケーションに対し制御を
その指定したエラーコードと共に戻す。また、ある場合
には、データストリームの内容によっては、このアサー
ションを適用すべきでない。従って、そのアサーション
条件（ＶＡＬＩＤＩＦ）を評価すべきか否か決めるため
に、ＷＨＥＮ式を設けている。もしこのＷＨＥＮ記述子
がなければ、アサーションを常に評価する。

【００３６】再び図１４において、ＢＤＴ１４００記述
子は、テンプレート・リスト１４０２を指し、そしてこ
のテンプレート・リスト１４０２は個々のテンプレート
定義を指している。ここで、テンプレート・リストＡ、
Ｄ及びＪに対応して３つのテンプレート１４０４、１４
０６及び１４０８を例示的にこのリストに含ませてある
。各テンプレート定義は、識別した１つのグループに対
応している。テンプレート１４０４（グループＡ）は、
ＧＤＴ１４１０で定義したグループに対応する。ＧＤＴ
１４１０のフィールド１４１２は、テンプレート・リス
ト１４０２内への対応するインデックスを含んでいる。 １４１４や１４１６のような１つのテンプレートの各エ
ントリは、識別した１つの同じグループ内に含まれてい
るか、あるいはその識別した（識別）グループ内にネス
トした識別していない（非識別）グループ内に含まれて
いる識別した項目に対応していて、これにより介在する
識別したグループがないようにしている。テンプレート
１４０４では、エントリ１４１４及び１４１６が、最初
のグループ記述子１４１０内に含まれた項目記述子（Ｉ
ＤＴ）１４１８（項目Ｂ）及び１４２０（項目Ｃ）に対
応している。このＩＤＴ自体、これが対応するテンプレ
ート内のエントリを識別するフィールド（例えば１４２
２）を含んでいる。例えば、ＩＤＴ１４１８のフィール
ド１４２２は、テンプレート１４０４の最初のエントリ
Ｂを識別する“１”を含んでいる。この図示例では、Ｇ
ＤＴ１４２４は、ＧＤＴ１４１０内にネストしてある。 それのフィールド１４２６は、テンプレートＤを指して
いる。また、ＧＤＴ１４２４は、２つの項目記述子１４
２８及び１４３０を有している。そのＩＤＴ１４２８の
テンプレート・フィールド・ポインタ１４３２は、当該
項目が識別されていないことを示す“０”を含んでおり
、従って、この項目記述子は、テンプレート内のフィー
ルドに対応していない。また、そのＩＤＴ１４３０のフ
ィールド・ポインタ１４３４は、テンプレート１４０６
の最初のフィールドＦを指している。もしこのテンプレ
ートの一部分（即ち、幾つかの項目）が非識別の反復グ
ループ内に含まれている場合には、テンプレートのその
一部分は、データストリーム内の反復したオカレンスに
対応することもある。別の識別グループ内に（直接また
は間接的に）ネストしたある識別グループは、現テンプ
レートを終了させそして新たなテンプレートを開始させ
る境界として機能する。このように、テンプレート定義
は、その対応する識別グループの終わりで、あるいはそ
の最初のネストした識別グループで終了する。

【００３７】上述のパーズテーブルの概念は、図１３の
１３００内に図示してあり、これは、その図１４のテン
プレート、グループ及び項目の関係をより明確に示して
いる。ボックス１３０２、１３０４及び１３０６は、そ
れらの各グループ記述子１４１０、１４２４及び１４３
６に対するテンプレートＡ、Ｄ及びＪに対応している。 Ｇは、どのテンプレートとも関連のないＧＤＴ１４３８
のことである。Ｂ及びＣは、グループＡの項目である。 Ｆは、グループＤの項目である。Ｈは、グループＧの項
目であり、Ｋ及びＬは、グループＪの項目である。テン
プレートＡは、識別グループＤが終了させるが、これは
項目Ｂ及びＣを含んでいる。グループＤが非識別のもの
であるとすると、テンプレートＡは、項目Ｂ、Ｃ、Ｆ、
Ｈを含むことになる。テンプレートＤ（項目Ｆ、Ｈ）は
、非識別グループＧに及び、そしてグループＤの終端で
終了する。テンプレートＪ（項目Ｋ、Ｌ）は、識別グル
ープＪで始まり、そしてこのグループＪの終端で終了す
る。

【００３８】図１５は、アプリケーション・プログラム
・インターフェース（ＡＰＩ）によってアプリケーショ
ンとパーザとの間でデータ・オカレンスを受け渡すため
に規定したデータ構造を示す。このＡＰＩの重要な部分
は、ルート・ポインタ・ベクトル（ＲＯＯＴＰＶＥＣ）
１５０６と、項目ベクトルＩＴＥＭＶＥＣ１５０８と、
及び項目データ要素１５１０とから成る３レベルの階層
である。思い起こされるように、初期化手順へのコール
（即ち、ＧＤＰＥＩＮＩＴまたはＧＤＰＤＩＮＩＴ）は
、資源リスト（ＲＥＳＯＵＲＣＥ−ＬＩＳＴ）を受入れ
、そしてパラメータＨＡＮＤＬＥ（これは、ＧＤＰＥＮ
ＣＯＤまたはＧＤＰＤＥＣＯＤに対する全てのコール時
に渡さなければならない）を戻すようにする。この初期
化手順に対し渡すそのＲＥＳＯＵＲＣＥ−ＬＩＳＴは、
パーザ作業領域のアドレス、パーズテーブル及び“ルー
トベクトル”（ＲＯＯＴＰＶＥＣ）１５０６を含んでい
る。その初期化手順は、パーザ作業領域１５００内でパ
ーザ制御ブロック（ＰＡＲＳＥＲ　ＣＯＮＴＲＯＬ　Ｂ
ＬＯＣＫ）１５０２を割り当て、そしてパーザテーブル
のアドレスとルートベクトルとをそのパーザ制御ブロッ
クにセーブする。ハンドル（ＨＡＮＤＬＥ）は、パーザ
が必要とする全ての資源をアドレス可能にする。 このアプリケーション／パーザ・インターフェースの例
では、このＨＡＮＤＬＥは、そのパーザ制御ブロックを
指している。また、そのルートベクトルは、パーズテー
ブル内で定義した各テンプレートに対するポインタを含
んでおり、そのＴＥＭＰＬＡＴＥ　ＩＤは、ルートベク
トル・ポインタ・アレイ１５０６へのインデックスとし
て定義する。また、それのＲＥＱＴＩＤは、ＧＤＰＥＮ
ＣＯＤ及びＧＤＰＤＥＣＯＤの要求パラメータ・リスト
内で渡して、アプリケーションとパーザとの間で渡すテ
ンプレート・インスタンスを識別するようにする。ルー
トベクトルの各エントリは、項目ベクトル（ＩＴＥＭＶ
ＥＣＴ１５０８）を指している。この項目ベクトルは、
その識別したテンプレートに対応したデータ項目に関す
る情報を含んでいる。各テンプレートに対するデータは
、１つの項目ベクトルを介してパーザに或いはパーザか
ら渡す。ＩＴＥＭＶＥＣＴの最初のエントリＭＡＸＩＴ
ＥＭＳ１５１２は、当該項目ベクトルの要素の数を含み
、これは、当該テンプレート内の項目数と等しい。その
ＭＡＸＩＴＥＭＳは、あるテンプレート・インスタンス
をデコードし終えた時、デコーダによってセットするも
のである。ＧＤＰＤＥＣＯＤからアプリケーションに制
御を戻した後、アプリケーションは、そのＭＡＸＩＴＥ
ＭＳを用いて、その項目ベクトルを走査することができ
る。項目ベクトルは、テンプレート内で定義した各項目
に対して、１つのエントリを含んでいる。例えば、ＩＴ
ＥＭＶＥＣＴ内の項目１に対応する１５１４は、ＦＬＡ
ＧＳフィールド、項目長フィールドＦＬＤＬ、及びデー
タ項目１５１０の記憶領域（ここで、この項目のための
実際のデータストリームを、パーザがまたはパーザのた
めに記憶させる）へのポインタＦＬＤＰを含んでいる。 この開示の目的上、そのＦＬＡＧＳは、シーケンス・フ
ィールド（ＳＥＱ）と、３つのフラグ、即ち空フラグ（
ＮＵＬＬ）、アプリケーション指定長フラグ（ＵＬＥＮ
）、及び移動フラグ（ＭＯＶＥ）を含むものとする。そ
のシーケンス・フィールドについては、詳細な例におい
て説明する。エンコード中、そのＮＵＬＬは、当該項目
についてエンコードする値がないことを示すため、アプ
リケーションがセットする。デコード中は、デコーダは
、データストリーム中に当該項目に関するインスタンス
を見い出さなかった場合に、そのビットをセットする。 また、そのＵＬＥＮフラグは、エンコード中にのみ用い
るものである。アプリケーションがこのフラグをセット
するのは、エンコードすべきデータにユーザが与えた長
さ（ＦＬＤＬ）をアプリケーションが用いることを望む
場合である。それ以外の場合には、エンコーダは、パー
ズテーブル内のテンプレート定義内で指定された値を用
いる。ＭＯＶＥフラグは、デコード中でのみ用いる。ア
プリケーションがこのフラグをセットするのは、当該項
目のデコードしたインスタンスをデコーダがアプリケー
ション指定のデータ領域へ移動させるのを希望する場合
である。この場合、アプリケーションは、ＧＤＰＤＥＣ
ＯＤをコールする前に、ＦＬＤＰポインタもセットしな
くてはならない。ＭＯＶＥがセットされていない場合、
デコーダは、そのＦＬＤＰをセットして、パーザ作業記
憶領域内のその項目データを指すようにする。

【００３９】次に、図１６中のＡＰＰ＿ＥＮＣＯＤＥは
、図８を更に詳細に示したもので、これには、アプリケ
ーションがデータ項目を送信のためエンコードするのに
用いる例示的ステップを示してある。先ず最初に行うの
は、パーザの初期化である。これは、ステップ１６０２
で、初期化ルーチンＧＤＰＥＩＮＩＴをコールすること
によって行う。このコールに伴い、用いるパーズテーブ
ルと、パーザ作業領域と、ルートベクトルと、エンコー
ドしたデータストリームを送るべき先の出力デバイスと
、を識別するパラメータを渡す。ＧＤＰＥＩＮＩＴは、
以後の全てのパージング・コール時に用いるＨＡＮＤＬ
Ｅ（これは、このアプリケーション／パーズ・インスタ
ンスを識別する）を返す。パージングのための１つのレ
コードの発生は、ステップ１６０４から始まる。このス
テップで、アプリケーションは、エンコードするテンプ
レートまたはレコードのインスタンスに対して、テンプ
レート識別子をセットする。１６０６で、そのテンプレ
ート識別子を用いてルートベクトルをインデックスして
、そのレコードの項目データをエンコーダに渡すのに用
いるＩＴＥＭＶＥＣＴ構造のアドレスをセットする。次
に１６０８で、空フラグを、ＩＴＥＭＶＥＣＴ内におい
てたまたま空となるそのレコードの各項目に対しセット
する。このような空の項目は、例えば、一連のデータベ
ース・レコードを送信中でしかも１つのデータベース・
レコードに含まれた名前のミドル・イニシャル・フィー
ルドが空の時、起こり得るものである。また、各項目に
対して適切であれば、アプリケーションが１つの項目の
全長より短い長さを用いることができる場合には、ステ
ップ１６１０で、ＩＴＥＭＶＥＣＴ内のその項目に対す
るＵＬＥＮフラグをセットする。このようにした場合、
その項目長を、アプリケーションがその項目用の長さフ
ィールドＦＬＤＬ内にセットする。これ以外の場合には
、パーズテーブル内で指定した項目全長を、パーザが使
用する。データベース・レコードの伝送を例に取ると、
固定長データベース・レコードを送信している時、ある
アプリケーションは、ＵＬＥＮフラグをセットすること
によって１項目のデフォルト長を無視したいことがある
。このような場合、そのアプリケーションは、そのデー
タベース内で１つの名前に対し割り当てた全長ではなく
、それらデータベース・レコード内のある例えば名前の
実際の長さのみを送出するのを希望することができる。 いずれにせよ、そのレコードの項目に対するそれら値は
、１５１０で例示した記憶装置内に常駐していなくては
ならない。しかしながら、それら項目値は、互いに隣接
している必要はなく、そのアプリケーションにとって最
も自然な形態でメモリ全体に“分散”してもよい。最後
に、その項目データ・ポインタＦＬＤＰを、エンコード
すべき各項目に対してセットしなくてはならない（１６
１２）。

【００４０】ある１つのレコードを実際にエンコードす
るには、ＧＤＰＥＮＣＯＤをステップ１６１４でコール
する。そして、このコールと共に、ハンドル（ＨＡＮＤ
ＬＥ）、テンプレート識別子（ＲＥＱＴＩＤ）、最終フ
ラグ（ＬＡＳＴＦＬＡＧ）、及びリターンコード・パラ
メータ（ＲＥＴＵＲＮ＿ＣＯＤＥ）を渡す。そのＬＡＳ
ＴＦＬＡＧパラメータは、ある反復グループの最後のオ
カレンスであるかどうかを示すフラグであり、これは、
反復グループに対応していないテンプレートとっては無
意味である。このプロセスは、ステップ１６１６に概念
的に示したように、エンコードすべきレコードが残って
いる間はアプリケーションが望むペースで継続する。こ
のエンコードが完了すると、アプリケーション処理は、
ステップ１６１８を続行する。この処理は、例えば、パ
ーザの作業領域用に用いている記憶領域を解放するか、
あるいはその出力デバイスを閉鎖するものである。しか
し、これらの活動は、アプリケーションに特有のもので
あり、従って本実施例には関係のないものである。

【００４１】テンプレート・オカレンスを渡すことがで
きる順序は、パーズテーブルが規定したグループ階層に
よって得られる。データは、このデータの構成要素が順
序非依存であると規定されていない限り、その階層順に
定義の順序で渡さなくてはならない。例えば図１４では
、テンプレートＡ、Ｄ及びＪのデータは、この順序でエ
ンコードする。多数のテンプレートをグループ−セット
（ＧＲＯＵＰ　　ＳＥＴ）記述子内の識別グループが定
義する場合、パーズテーブルが順序に対する制限を課し
ていないので、いかなる順序でレコードをエンコードし
てもよい。

【００４２】次に、図１７は、図９をより詳細にしたも
ので、これには、入って来たデータストリームのデコー
ドに関連する例示的アプリケーション・ステップを示し
てある。ここでも、アプリケーションは、ステップ１７
０２で最初にＧＤＰＤＩＮＩＴをコールすることによっ
て、パーザを初期化する。次に、ステップ１７０４でル
ーチンＧＤＰＤＥＣＯＤをコールして、最初の入来レコ
ードを取り出す。そのＧＤＰＤＥＣＯＤがステップ１７
０５で制御を返す時、そのリターンコードが“パーズの
終端（ＥＮＤ）”でない場合には、パーザは、その最初
レコードのいかなる入来データ項目も、項目記憶域１５
１０に記憶し終えたことになる。一方、もしそのデータ
ストリーム全体のパーズを完了した場合、ＧＤＰＤＥＣ
ＯＤは、ＲＥＴＵＲＮ＿ＣＯＤＥパラメータ内でパーズ
終了信号を戻す。このパーズ終了信号がないと仮定した
場合、そのデータを取り出すために、ステップ１７０６
は、その戻されたテンプレートＩＤ（識別子）を用いて
ＲＯＯＴＰＶＥＣをインデックスして、そのポインタを
正しいＩＴＥＭＶＥＣＴ構造へと位置指定する。この時
、ＦＬＤＰは、各項目に対する記憶データ１５１０を指
す。ステップ１７０８は、その記憶領域１５１０から各
項目を読むためのループをセットアップする。そのルー
プパラメータは、ＩＴＥＭＶＥＣＴの最初のエントリＭ
ＡＸＩＴＥＭＳに含まれた値にセットする（尚、コール
元に戻る前に、デコーダはＭＡＸＩＴＥＭＳをセットす
ることを思い出されたい。）。このＭＡＸＩＴＥＭＳ値
は、パーズテーブル内の各テンプレート記述子の一部と
して発生する。各項目に対して、ステップ１７１０で、
空フラグがセットされているか判定する。もしセットさ
れていれば、その項目を無視する。セットされていなけ
れば、ステップ１７１２及び１７１４でその項目を取り
出して適切な方法で処理し、そして次の項目のためにこ
のループを継続する。デコードした各項目について、そ
の項目データ長（ＦＬＤＬ）をデコーダがセットし、そ
してこれをアプリケーションがその項目データを取り出
すのに使う。既に述べたように、ＦＬＤＰフィールドを
、ＭＯＶＥフラグに依存してデコーダまたはアプリケー
ションがセットする。

【００４３】一般に（例えば、多くのテンプレートを定
義している複雑なパーズテーブルでは）、アプリケーシ
ョンは、デコードすべき次のテンプレート・オカレンス
を予測できないことがあるが、この理由は、そのパーズ
テーブルが定義した構造及び副構造が、それらのデータ
・インスタンスにどんな順序で発生することも許してい
ることがあるからである。従って、このアプリケーショ
ンは、全てのルートポインタベクトル・エントリをセッ
トし、そして次のコール時に処理できるような起こり得
るテンプレートのいずれかに対応する項目ベクトルを初
期化しなくてはならない。デコーダへの１回のコールに
付き、１つのみのテンプレート・オカレンスをデコード
するようにすることができる。従って、１つの項目ベク
トルを割り当て、そしてそれを参照するように全ての関
連するルートベクトルポインタをセットすることが可能
である。また、アプリケーションは、ＦＬＡＧＳフィー
ルド内のいかなる関連する制御もセットしなくてはなら
ない。例えば、アプリケーションは、“移動”モードま
たは“位置指定（ｌｏｃａｔｅ）”モードを選択するこ
とができる。

【００４４】エンコード及びデコードを行うパーザ論理
について、その詳細な例で例示する。下の表１は、図１
３及び図１４に示したパーズテーブルのサンプルをエン
コードした仕様である。これでは、ラベル（例えばＢＤ
Ｔ１４００）は、その記述子タイプ及び図１４に示した
記述子への参照を示す。しかしながら、この図１４には
、特定の項目及びグループのタイプ、存在規準、計算長
さ式を指定するのに必要な雑記述子等、完全なパーズテ
ーブルに必要な詳細が欠如している。これらの詳細は、
表１には入れてある。また、ある特定の項目またはグル
ープの記述子に関連した雑記述子は、それらのラベルの
最後の４文字としてその特定の記述子と同じ参照番号を
用いて示すことにする（例えば、ＣＨＫ１４１０はＧＤ
Ｔ１４１０に結びついたものである、等）。以下の説明
では、行番号を用いて特定の記述子を引用することにす
る。

【００４５】 　　　　　　　　　　　　　　　　表　　　　１パーズ
テーブルの明細 １．ＢＤＴ１４００　ＢＥＧＩＮＤＥＦ　ＴＬＩＳＴ＝
（Ａ，Ｄ，Ｊ）２．Ａ　　　　　．ＴＥＭＰＬＡＴＥ（
Ｂ：ＢＹＴＥ（１０），Ｃ：ＣＨＡＲ（６））３．Ｄ　
　　　　．ＴＥＭＰＬＡＴＥ（Ｆ：ＢＹＴＥ（２），Ｈ
：ＣＨＡＲ（５０））４．Ｊ　　　　　．ＴＥＭＰＬＡ
ＴＥ（Ｋ：ＢＹＴＥ（２０））５．ＧＤＴ１４１０　　
．ＧＲＯＵＰ　ＳＥＴ，ＩＤ＝Ａ，　ＯＣＣＵＲＳ＝（
ＷＨＩＬＥ，ＣＨＫ１４１０）６．ＣＨＫ１４１０　　
．　．ＴＥＳＴＬＫＡＨ　２，ＴＹＰ１４１０７．ＴＹ
Ｐ１４１０　　．　．ＣＯＮＤＥＦ（Ｘ’００Ａ１’，
Ｘ’００Ａ２’，Ｘ’００Ｂ１’，Ｘ’００Ｂ２’）８
．ＩＤＴ１４１８　　．　．ＩＴＥＭＬＴ　ＩＤ＝Ｂ，
ＴＹＰＥ＝Ｘ’００Ａ１’，ＬＥＮＲＮＧ＝（４，１０
），ＲＥＱ＝ＹＥＳ９．ＩＤＴ１４２０　　．　．ＩＴ
ＥＭＬＴ　ＩＤ＝Ｃ，ＴＹＰＥ＝Ｘ’００Ａ２’，ＬＥ
ＮＲＮＧ＝（２，６），ＲＥＱ＝ＮＯ１０．ＧＤＴ１４
２４　　．　．ＧＲＯＵＰ　ＳＥＱ，ＩＤ＝Ｄ，ＯＣＣ
ＵＲＳ＝（ＷＨＥＮ，ＣＨＫ１４２４Ａ），ＲＥＱ＝Ｎ
Ｏ１１．ＣＨＫ１４２４Ａ　．　．　．　ＴＥＳＴＬＫ
ＡＨ　２，ＣＨＫ１４２４Ｂ１２．ＣＨＫ１４２４Ｂ　
．　．　．　ＣＯＮＤＥＦ（Ｘ’００Ｂ１’，Ｘ’００
Ｂ２’）１３．ＩＤＴ１４２８　．　．　．　ＩＴＥＭ
ＦＬＥＮ　ＬＥＮ＝２１４．ＩＤＴ１４３４　．　．　
．　ＩＴＥＭＦＬＥＮ　ＩＤ＝Ｆ，ＬＥＮ＝２１５．Ｇ
ＤＴ１４３８　．　．　．　ＧＲＯＵＰ　ＳＥＱ，ＯＣ
ＣＵＲＳ＝（ＬＥＮＧＴＨ，ＬＥＮ１４３８），ＲＥＱ
＝ＮＯ１６．ＬＥＮ１４３８　．　．　．　ＤＥＬＶ　
ＩＤＴ１４２８，４１７．ＩＤＴ１４４２　．　．　．
　ＩＴＥＭＶＬＥＮ　ＩＤ＝Ｈ，ＬＥＮ＝ＬＥＮ１４３
８，ＬＥＮＲＮＧ＝（４，５０）１８．　　　　　．　
．　．　ＥＮＤＧＲＯＵＰ　ＧＤＴ１４３８１９．　　
　　　．　．　ＥＮＤＧＲＯＵＰ　ＧＤＴ１４２４２０
．　　　　　．ＥＮＤＧＲＯＵＰ　ＧＤＴ１４１０２１
．ＩＤＴ１４４６　．　ＩＴＥＭＦＬＥＮ　ＬＥＮ＝４
２２．ＧＤＴ１４３６　．　ＧＲＯＵＰ　ＲＥＰ，ＩＤ
＝Ｊ，ＯＣＣＵＲＳ＝（ＬＥＮＧＴＨ，ＩＤＴ１４４６
），ＲＥＰＲＮＧ＝（０，１０００），ＲＥＱ＝　　　
ＮＯ ２３．ＩＤＴ１４５０　．　．　ＩＴＥＭＦＬＥＮ　Ｌ
ＥＮ＝１２４．ＩＤＴ１４５４　．　．　ＩＴＥＭＶＬ
ＥＮ　ＩＤ＝Ｋ，ＬＥＮ＝ＩＤＴ１４５０，ＬＥＮＲＮ
Ｇ＝（１，２０）２５．　　　　　．　ＥＮＤＧＲＯＵ
Ｐ　ＧＤＴ１４３６２６．ＥＤＴ１４６０　ＥＮＤＤＥ
Ｆ

【００４６】この階層構造は、１つのグループをＧＲＯ
ＵＰ／ＥＮＤＧＲＯＵＰ文を突き合わせることによって
定義した、ネスト状グループとして表してある。上記の
ＩＴＥＭＬＴは、図１に示したデータ構造を表している
。また、上記“ＴＹＰＥ”パラメータは、２バイトのタ
イプ値を供給し、そしてこのタイプ値は、ＩＴＥＭＬＴ
記述子タイプに対して定義したＩＤＴ構造の一部として
記憶する。

【００４７】ＢＥＧＩＮＤＥＦ文のテンプレート・リス
トは（Ａ，Ｄ，Ｊ）を指定しているので、テンプレート
Ａ、Ｄ及びＪは、それぞれテンプレート識別子（ＴＩＤ
）１、２及び３をもつ。同様に、項目識別子（ＩＩＤ）
には、ＴＥＭＰＬＡＴＥ文内でそれらの順序位置を割り
当てる。例えば、テンプレートＡの項目Ｂ及びＣにそれ
ぞれ項目識別子１及び２を割り当てている。これは図１
４と一致している。

【００４８】図１８においては、図１３及び図１４のパ
ーズテーブルと一致したあるデータストリーム・フォー
マットを示してある。このフォーマット内の１つの特定
のデータストリーム例について、最初にエンコード論理
、そして次にデコード論理を通してその跡を以下にたど
ることにする。尚、上記パーズテーブル内のグループ記
述子を明示的に識別するものは、そのデータストリーム
内にはないことを思い出されたい。最初の３つの自己記
述ＬＬＴＴ構造（ＩＤＴ１４１８、ＩＤＴ１４２０及び
（ＩＤＴ１４２８、ＩＤＴ１４３４、ＩＤＴ１４４２）
で示している）は、ＧＲＯＵＰ　ＳＥＴを定義した１つ
のグループ１４１０のメンバとして規定しているので、
どのような順序で生起してもよい。更に、それら３つの
項目の内、ＩＤＴ１４１８のみがこのデータストリーム
内で生起することが必要である（文８のＲＥＱ＝ＹＥＳ
）。続いて、４バイトの長さフィールド（ＩＤＴ１４４
６）が生起しなくてはならない。最後に、１つの反復シ
ーケンスの可変長バイト・ストリングが続き、これによ
って、各バイト・ストリングのオカレンスが、１バイト
の長さフィールド（ＩＤＴ１４５０）とこれに続くその
長さの１つのバイト・ストリング（ＩＤＴ１４５４）か
ら成るようにすることができる。これらＩＤＴ１４５０
及びＩＤＴ１４５４は、ＧＤＴ１４３６に対応しており
、これは、表１では反復グループとして指定している。 このグループは、その反復範囲（表１の行２２のＲＥＰ
ＲＮＧ）が最小のゼロを指定しているので、４バイト長
さフィールド（ＩＤＴ１４４６）がゼロを含んでいる場
合にはオプション性のものである。

【００４９】この図１８に示した明示フィールドのエン
コードの間、ＧＤＰＥＮＣＯＤを４回コールする。１回
はテンプレートＡ、他の１回はテンプレートＤ、そして
残りの２回は、テンプレートＪの２回のオカレンスをエ
ンコードするためである。例示として、図１９に示した
そのエンコードすべき対象のデータは、’Ｃｏｍｐｕｔ
ｅｒｓ’、Ｘ’００Ｂ２’、’ＳＮＡ　　Ｎｅｔｗｏｒ
ｋｓ’、’ＩＥＥＥ’、’ＡＣＭ’であり、それは、デ
ータ構造中では次のように記述する。

【００５０】 ＴＥＭＰＬＡＴＥ　　ＮＡＭＥ　　ＴＩＤ　　ＩＴＥＭ
　　ＩＩＤ　　ＤＡＴＡＡ　　　　　　　　　　　　１
　　　　Ｂ　　　　　　　　１　　　　’Ｃｏｍｐｕｔ
ｅｒｓ’　　　　　　　　　　　　　１　　　　Ｃ　　
　　　　　　２Ｄ　　　　　　　　　　　　２　　　　
Ｆ　　　　　　　　１　　　　Ｘ’００Ｂ２’　　　　
　　　　　　　　　２　　　　Ｈ　　　　　　　　２　
　　’ＳＮＡ　　Ｎｅｔｗｏｒｋｓ’Ｊ　　　　　　　
　　　　３　　　　Ｋ（１）　　　１　　　’ＩＥＥＥ
’Ｊ　　　　　　　　　　　３　　　　Ｋ（２）　　　
１　　　’ＡＣＭ’

【００５１】ここで、初期化が完了
しており、また図１５に描いた連係データ構造が確立さ
れている、と仮定する。ルートベクトル（ＲＯＯＴＰＶ
ＥＣ）は、３つのエントリ、即ち各テンプレートＡ、Ｄ
及びＪに対して１つずつのエントリを含んでいる。例え
ば、ＲＯＯＴＰＶＥＣ（２）は、テンプレート２（別名
Ｄ）に対する項目ベクトルを参照する。これと同様に、
３つの項目ベクトルがある。１つの項目ベクトルの要素
は、図１５においては、３つのフィールド、即ちＦＬＡ
ＧＳ、ＦＬＤＬ及びＦＬＤＰを含んでいるように示して
ある。そのＦＬＡＧＳは、１バイトのシーケンス・フィ
ールド（ＦＬＡＧＳ．ＳＥＱ）、空フラグ（ＦＬＡＧＳ
．ＮＵＬＬ）、ユーザ長フラグ（ＦＬＡＧＳ．ＵＬＥＮ
）、及び“移動”フラグ（ＦＬＡＧＳ．ＭＯＶＥ）から
成る構造を規定している。エンコード機能に対しては、
ＮＵＬＬフラグ及びＵＬＥＮフラグのみを用いる。その
項目に対するデータ値が空の場合（即ち、その項目につ
いてデータ・オカレンスをエンコードしない）、ＦＬＡ
ＧＳ．ＮＵＬＬを“１”にセットする。コール元プログ
ラムがエンコード対象のデータ要素の長さを（ＦＬＤＬ
フィールドを介して）明示的に供給したい場合、ＦＬＡ
ＧＳ．ＵＬＥＮを“１”にセットする。もしそのＦＬＡ
ＧＳ．ＵＬＥＮが“０”の場合、エンコーダは、パーズ
テーブル内のＴＥＭＰＬＡＴＥ文内で規定された一定の
長さ値を用いる（例えば、表１の文１７の項目Ｈに対す
る長さ５０）。 これは、各データ項目に対する項目記憶域１５１０が、
少なくともその大きさでなくてはならないこと、しかも
項目データ・タイプに依存して、アプリケーションによ
って適切なパッド文字が供給されること、を意味する。 通常、可変長データに対しては、コール元プログラムは
、項目長さ値を明示的に指定することになる。

【００５２】ＦＬＡＧＳ．ＵＬＥＮが“１”の場合には
、フィールドＦＬＦＤは、その項目オカレンスの長さに
セットする。

【００５３】フィールドＦＬＤＰは、各項目要素に対し
てエンコードすべき対象の適切なデータ項目１５１０へ
のポインタを含んでいる。表記の便宜上、項目ベクトル
内のフィールド（例えばＦＬＤＬ）は、それぞれのテン
プレート名で表すことにする。例えば、Ｄ．ＦＬＤＬ（
２）は、テンプレートＤの２番目の項目（即ち“Ｈ”）
の長さフィールドを指す。

【００５４】手順ＧＤＰＥＮＣＯＤは、４つの入力パラ
メータ、即ちＨＡＮＤＬＥ、ＲＥＱＴＩＤ、ＬＡＳＴＦ
ＬＡＧ及びＲＣをもっている。そのＨＡＮＤＬＥは、Ｇ
ＤＰＥＩＮＩＴが生成し、そして制御情報、パーズテー
ブル、及びその他の資源を参照する。ＲＥＱＴＩＤは、
エンコード・ルーチンのいかなる所与のコール時におい
てもエンコードするようにコール元が要求しているテン
プレートの、要求テンプレート識別子（ＴＩＤ）を含ん
でいる。ＬＡＳＴＦＬＡＧは、ある反復グループの最後
のインスタンスの処理を完了した時を示す。ＲＣは、こ
の手順の状態を戻すリターンコードである。

【００５５】エンコード処理を説明するには、数個の変
数について説明する必要がある。 ＣＵＲＤＥＳ　　　　現行記述子。この変数は、エンコ
ーダが試験している最中の現行の記述子を参照する。初
期には、ＣＵＲＤＥＳは、ＢＤＴ１４００にセットする
。

【００５６】 ＣＵＲＴＩＤ　　　　現行テンプレート識別子。このパ
ラメータは、エンコーダが処理している最中のテンプレ
ートのテンプレート識別子を含んでいる。初期には、こ
の値は空である。

【００５７】 ＳＴＡＣＫ　　　　グループの反復を取り扱う後入れ先
出し型スタックである。

【００５８】 ＣＵＲＳＯＲ　　　　エンコードしたデータを書き込む
ための、データストリーム内で次に利用可能な位置を示
す、データストリーム・カーソルである。初期には、Ｃ
ＵＲＳＯＲ＝１（即ち、出力ストリームの最初のバイト
）である。

【００５９】以下のエンコード処理で発生するエンコー
ド化形データストリームは、図１９に示してある。その
エンコード・ステップは、以下に示す通りである。

【００６０】テンプレートＡのエンコードパラメータ・
セットアップ及び手順コール：　　最初に、テンプレー
トＤに対する項目ベクトルをコール元が初期化する。 １．Ａ．ＦＬＤＰ（１）をセットして、項目記述子Ｂの
データ要素（即ち、’Ｃｏｍｐｕｔｅｒｓ’）を参照す
るようにする。 ２．Ａ．ＦＬＡＧＳ．ＵＬＥＮを’１’にセットして、
コール元がそのデータ長を供給している、ということを
示すようにする。 ３．Ａ．ＦＬＤＬ（１）を、項目Ｂのそのデータ要素の
長さ（即ち９）にセットする。 ４．Ａ．ＦＬＡＧＳ．ＮＵＬＬ（１）を’０’にセット
して、Ｂの項目オカレンスは空でないことを示す。 ５．Ａ．ＦＬＡＧＳ．ＮＵＬＬ（２）を’１’にセット
して、項目Ｃの値が空であることを示す。 ６．ＲＥＱＴＩＤ＝１をセットする（即ち、テンプレー
トＡに対するＴＩＤ）。 ７．ＧＤＰＥＮＣＯＤ（ＨＡＮＤＬＥ，ＲＥＱＴＩＤ，
ＬＡＳＴＦＬＡＧ，ＲＣ）をコールする。ＬＡＳＴＦＬ
ＡＧの値は、無関係である。

【００６１】テンプレートＡのエンコーダ処理１．ＣＵ
ＲＤＥＳ＝１４００から開始し、エンコーダは、パーズ
テーブルを走査して、ＩＤがＲＥＱＴＩＤ（即ち１）に
等しいグループ記述子を捜す。そして、この記述子は、
ＣＵＲＤＥＳ＝１４００の時に発生し、これは、表１の
文５に対応している。この時点で、ＣＵＲＴＩＤをＲＥ
ＱＴＩＤにセットする。

【００６２】 ２．１つのエントリをＳＴＡＣＫに押し込んでそのグル
ープ記述子を表すようにし、そしてこのグループの最初
の項目で走査を続ける（即ち、図１４のＩＤＴ１４１８
または表１の文８）。

【００６３】 ３．記述子１４１８（ＩＴＥＭＬＴ　ＩＤ＝Ｂ）を識別
する。

【００６４】その次のステップは、この項目に対応する
図１５内の項目ベクトル・エントリを分析することによ
り、（ａ）コール元が非空の値を供給したかどうか判定
し、そして（ｂ）そのデータを取り出し、そしてこれを
当該項目記述子に応じてエンコードする。この場合、あ
る値が在る（即ち、’Ｃｏｍｐｕｔｅｒｓ’）。このＩ
ＴＥＭＬＴ記述子は、２バイト長さフィールド（ＬＬ）
と２バイトの“タイプ”フィールド（ＴＴ）とを規定し
ているが、それは、そのＴＹＰＥパラメータが２バイト
の定数を供給しているからである。従って、１３バイト
をそのデータストリームに出力し、そしてＣＵＲＳＯＲ
を増分して１４にする。その最初の２バイト（ＬＬ）は
、Ｘ’０００Ｄ’（１３）を含んでいるが、これは、そ
の長さバイト及びタイプ・バイトを考慮に入れるため、
Ａ．ＦＬＤＬ（１）（即ち、ソースデータの長さ）に４
を加算して計算したものである。それの第３バイト及び
第４バイトは、１６進の’００Ａ１’を含んでおり、こ
の値は、記述子ＩＤＴ１４１８から取り出す。バイト５
−１３は、’Ｃｏｍｐｕｔｅｒｓ’の文字ストリングを
含んでいる。

【００６５】 ４．ＩＤＴ記述子１４１８を処理した後、エンコーダは
、次の記述子１４２０を取り出す。これはＩＤＴ記述子
であり、これもまた識別したものであるが、その対応す
る項目ベクトル空フラグ（即ち、Ａ．ＦＬＡＧＳ．ＮＵ
ＬＬ（２））は、入力値がないことを示す。これは、そ
の項目記述子が当該項目が必要なものでないことを示し
ているので、許容可能なものである。もしこの項目が必
要なものであったとしたならば、コール元にエラーを返
していたはずである。しかし、この場合では、次の記述
子を取り出し、そしてＣＵＲＤＥＳ＝１４２４とする。

【００６６】 ５．次の記述子１４２４は、現行のセット・グループ（
即ち、ＧＤＴ１４１０）の１つのメンバを別のグループ
として定義するグループ記述子（ＧＤＴ）である。これ
も識別したものである（ＩＤ＝ＤまたはＴＩＤ＝２）。 これは、このグループが別のテンプレートを開始させ現
行のテンプレートを終了させることを意味する。

【００６７】この時点で、処理を中断し、そして制御を
ＲＣ＝０と共にコール元に返す。ＣＵＲＤＥＳは１４２
４に留まっているが、現行テンプレートＣＵＲＴＩＤは
空（０）にリセットする。このグループ記述子１４２４
は必要なものではないので（文１０のＲＥＱ＝ＮＯ）、
コール元は、次のコール時にテンプレートＤをエンコー
ドすることを要求しなくてもよいが、しかしこの例では
、テンプレートＤのエンコードを要求するものと仮定す
る。

【００６８】テンプレートＤをエンコードするためのア
プリケーション処理 パラメータ・セットアップ及び手順コール１．Ｄ．ＦＬ
ＡＧＳ．ＮＵＬＬ（１）＝’０’、Ｄ．ＦＬＡＧＳ．Ｕ
ＬＥＮ（１）＝’１’のセットを行う。 ２．Ｄ．ＦＬＤＬ（１）＝２及びＤ．ＦＬＤＰのセット
を行って、そのデータ　１６進’００Ｂ２’を参照する
。 ３．Ｄ．ＦＬＡＧＳ．ＮＵＬＬ＝’０’及びＤ．ＦＬＡ
ＧＳ．ＵＬＥＮ（２）＝’１’のセットを行う。 ４．Ｄ．ＦＬＤＬ（２）＝１２及びＤ．ＦＬＤＰのセッ
トを行って、そのデータ要素’ＳＮＡ　　ｎｅｔｗｏｒ
ｋｓ’を参照する。 ５．ＲＥＱＴＩＤ＝２（テンプレートＤのＴＩＤ）。 ６．ＣＡＬＬ　　ＧＤＰＥＮＣＯＤ（ＨＡＮＤＬＥ，Ｒ
ＥＱＴＩＤ，ＬＡＳＴＦＬＡＧ，ＲＣ）。

【００６９】テンプレートＤのエンコーダ処理１．ＣＵ
ＲＤＥＳ１４００から開始し、エンコーダは、パーズテ
ーブルを走査してＲＥＱＴＩＤ（即ち２）に等しいＩＤ
のグループ記述子を捜す。これは、直ちにＧＤＴ１４２
４によって満足される。

【００７０】 ２．ＧＤＴ１４２４をスタックに押し込み、そして最初
の子記述子、即ちＩＤＴ１４２８から走査を始める。

【００７１】 ３．ＩＤＴ１４２８は識別したものではなく（即ち、表
１でＩＤ＝０）、従ってその値を計算しなくてはならず
、それは、コール元からのデータとして渡していない。 この場合、このデータストリーム中のその次の２バイト
を１６進数’００００’に初期化し、そしてＣＵＲＳＯ
Ｒを２（これは、ＩＴＥＭＦＬＥＮ記述子（表１の文１
３）内でコード化した長さである）だけ増分させる。 このカーソル値は、エンコーダ作業領域内において、そ
の項目記述子（図１２参照）のＤＳＡ（動的セーブ領域
）フィールドが指定したオフセットの所にセーブする。 これは、後で、長さ値を埋め戻すのに用いる。

【００７２】次に、エンコーダは、その次の記述子ＩＤ
Ｔ１４３０を取り出す。 ４．ＩＤＴ１４３０は識別したものであり、そしてその
項目値１６進’００Ｂ２’は、先に述べたようにテンプ
レートＤに対する項目ベクトルを介して取り出す。その
値は、データストリームへ出し、そしてＣＵＲＳＯＲを
２だけ増分させる。

【００７３】次の記述子、即ちＧＤＴ１４３８を取り出
す。 ５．ＧＤＴ１４３８は、表１内では識別しておらず（Ｉ
Ｄは、文１５では省かれている）、従ってそれはスタッ
クし、そしてこのグループの最初のメンバ記述子ＩＤＴ
１４４２から処理を開始する。

【００７４】 ６．項目Ｈのデータ参照及びデータ長は、テンプレート
Ｄに対する項目ベクトル（図１５）の第２要素から取り
出し、そして項目Ｈに対するそのデータ要素をデータス
トリームに出す。即ち、Ｄ．ＦＬＤＬ（２）から始まる
データのＤ．ＦＬＤＬ（２）（１２）バイトをデータス
トリームに移動させ、そしてＣＵＲＳＯＲを１２だけ増
加させる。表１の文１７のパラメータＩＴＥＭＶＬＥＮ
で述べている通りＩＤＴ１４４２は可変長記述子である
ので、追加の処理を行って、文１７のＬＥＮパラメータ
が規定した長さフィールドに埋め戻しを行う。このＬＥ
Ｎパラメータは、文１６を参照している。この文１６の
ＤＥＬＶ記述子（ＬＥＮ１４３８）の定数（４）をデー
タ長さに加えて、値１６を得る。文１６の参照ＩＤＴ１
４２８は、この項目の長さフィールドを規定する記述子
を指している。項目ＩＤＴ１４２８のデータストリーム
・カーソル位置を以前にセーブしたということを覚えて
いると思うが、エンコーダは、ＩＤＴ１４２８中のＤＳ
Ａフィールドを用いて、データストリーム内にカーソル
位置１４にて値１６（１６進’００１０’）を記憶させ
る。

【００７５】 ７．次の記述子ＩＤＴ１４４２を取り出し、その結果、
ＣＵＲＤＥＳ＝１４３８となる。この記述子は、スタッ
クの最上部にあるもの（参照されたもの）でもあるので
、“グループ終了”であることを知らせる。１つのグル
ープの処理中、データストリームに出力したデータのそ
の蓄積した長さは、そのスタック内に保持している。 そのグループ終了が生起した時、もしそのグループが“
長さ限定型”の場合には、そのグループ長さを用いて長
さフィールドに埋め戻しを行う。文１５のＯＣＣＵＲＳ
節でその“ＬＥＮＧＴＨ”キーワードを指定しているの
で、ＧＤＴ１４３８はその長さ限定形である。この処理
は、ＩＤＴ１４４２に関して前述した処理に類似したも
のである。この単純な例では、そのグループＧＤＴ１４
３８の長さ指定は、可変長の項目ＩＤＴ１４４２の長さ
指定と同一であり、従ってこのグループの長さは、１項
目しかないので、１２である。それ故、上記と同じ結果
が生ずる、即ち、値１６をカーソル位置１４にて記憶さ
せる。そして、ここで、スタックをポップさせ、そして
ＧＤＴ１４３８の次の記述子、即ちＧＤＴ１４２４から
走査を継続する。

【００７６】 ８．記述子１４２４が今ではスタックの最上部にあるの
で、グループ終了を知らせる。この必要なグループ終了
処理は、ＧＤＴ１４２４が長さ限定形ではないので、最
小である。その最上部スタック・エントリの蓄積した長
さを以前のエントリに加算し、そしてそのスタックをポ
ップさせる。しかしながら、処理は直ちには継続しない
が、その理由は、その終了したグループのＩＤがコール
元のＲＥＱＴＩＤと一致していて、現行テンプレートの
処理が完了していることを示しているからである。次に
、ＣＵＲＤＥＳをＧＤＴ１４２４の次の記述子（即ち１
４１０）にセットし、ＣＵＲＴＩＤを空にセットし、そ
して制御をＲＣ＝０と共にコール元に戻して、テンプレ
ートＤを首尾よくエンコードし終えたことを指示する。 テンプレートＪのエンコーダ処理 パラメータ・セットアップ及び手順コール（最初のオカ
レンス） １．Ｊ．ＦＬＡＧＳ．ＮＵＬＬ（１）＝’０’及びＪ．
ＦＬＡＧＳ．ＵＬＥＮ（１）＝’１’のセットを行う。 ２．Ｊ．ＦＬＤＬ（１）＝４（’ＩＥＥＥ’内の文字数
）。 ３．データ要素’ＩＥＥＥ’を参照するように、Ｊ．Ｆ
ＬＤＰ（１）をセットする。 ４．項目Ｋが存在することを示すために、Ｊ．ＦＬＡＧ
Ｓ．ＮＵＬＬ（１）＝’０’とする。 ５．ＲＥＱＴＩＤ＝３（テンプレートＪのＴＩＤ）。 ６．ＬＡＳＴＦＬＡＧ＝’０’（反復グループ１４３６
の最後のオカレンスではない）。 ７．ＣＡＬＬ　　ＧＤＰＥＮＣＯＤ（ＨＡＮＤＬＥ，Ｌ
ＡＳＴＦＬＡＧ，ＲＣ）。

【００７７】テンプレートＪ（最初のオカレンス）のア
プリケーション処理 １．テンプレートＤのオカレンスを首尾よくエンコード
した後でコール元に戻った時、エンコーダはＣＵＲＤＥ
Ｓ＝１４１０及びＣＵＲＴＩＤ＝０の状態で出発したこ
とを思い出されたい。ＧＤＴ１４２４をスタックからポ
ップさせて出したので、現在のスタック・エントリの最
上部はＧＤＴ１４１０を反映している。ＲＥＱＴＩＤ＝
３でエンコーダに再び入った時、ＣＵＲＴＩＤが空（０
）でＣＵＲＤＥＳがそのスタックの最上部の要素と合致
しているので、そのスタックをポップさせ、そしてＣＵ
ＲＤＥＳを次の記述子即ちＩＤＴ１４４６にセットする
。

【００７８】 ２．ＩＤＴ１４４６は、非識別（固定長）項目である。 この場合の処理は、ＩＤＴ１４２８の処理と似たもので
ある。データストリームの次の４バイトを１６進’００
００００００’に初期化し、ＣＵＲＳＯＲを４だけ増分
させ、そしてカーソル値をある作業領域内に記述子ＩＤ
Ｔ１４４６内で指定したＤＳＡオフセットの所でセーブ
する。そして、次の記述子ＧＤＴ１４３６を取り出す。

【００７９】 ３．ＧＤＴ１４３６は、ＧＤＰＥＮＣＯＤ手順コールに
おいて渡したＲＥＱＴＩＤと合致したＩＤ＝Ｊ（ＴＩＤ
＝３）を有している。従って、これを、処理するために
選択する。ＧＤＴ１４３６は、文のＯＣＣＵＲＳ節で指
定した通りの、長さ限定形反復グループを指定している
。これは、そのグループの全てのオカレンスをエンコー
ドし終えた後、その長さフィールド（即ちこの例ではＩ
ＤＴ１４４６）を当該グループの（全オカレンスの）合
計バイト数にセットする、ということを意味している。

【００８０】 ４．ＧＤＴ１４３６をスタックに押し込み、そしてその
最初の子記述子ＩＤＴ１４５０から処理を続行する。

【００８１】 ５．他の非識別固定長フィールドと同様にこのＩＤＴ１
４５０を処理し、そしてＩＤＴ１４５４をＩＤＴ１４５
０の次ポインタを介して取り出す。

【００８２】 ６．ＩＤＴ１４５０は識別したものであり（ＩＤ＝Ｋま
たはＩＩＤ＝１）、従ってこの項目ベクトル内で参照し
たデータ要素（即ち、’ＩＥＥＥ’）を、前述のように
データストリームに出す。同様にして、その長さフィー
ルド（ＩＤＴ１４５０）を、データストリーム内で、こ
の場合１６進’０４’に埋め戻す。続いて、次の記述子
ＧＤＴ１４３６を取り出す。

【００８３】 ７．前述の場合と同じように、ＣＵＲＤＥＳ＝１４３６
であり、そして記述子１４３６も、現在の（最上部の）
スタック要素として反映している。しかしながら、この
場合、グループが反復の最中であってそのＬＡＳＴＦＬ
ＡＧがセットされていない（即ち２進’１’）ので、グ
ループ終了条件を起こさせていない。そして、スタック
はポップさせないが、制御をコール元に戻し、テンプレ
ートＪの次のオカレンスに備える。

【００８４】パラメータ・セットアップ及び手順コール
（第２のオカレンス） １．Ｊ．ＦＬＤＬ（１）＝３（’ＡＣＭ’内の文字数）
２．データ要素’ＡＣＭ’を参照するために、Ｊ．ＦＬ
ＤＰ（１）をセットする。 ３．ＬＡＳＴＦＬＡＧ＝’１’（反復グループ１４３６
の最後のオカレンス）。 ４．ＣＡＬＬ　　ＧＤＰＥＮＣＯＤ（ＨＡＮＤＬＥ，Ｒ
ＥＱＴＩＤ，ＬＡＳＴＦＬＡＧ，ＲＣ）。 そのＦＬＡＧＳフィールドは、最初のオカレンスの時の
設定値から無変化のままである。

【００８５】 テンプレートＪ（第２のオカレンス）のエンコーダ処理
１．エンコーダへ再び入る時、ＣＵＲＤＥＳ＝１４３６
、ＣＵＲＴＩＤ＝３、及びＲＥＱＴＩＤ＝３である。 テンプレートＪのこの２回目（最後）のオカレンスを処
理するため、処理は、最初の子記述子（ＩＤＴ１４５０
）から続行する。

【００８６】 ２．そのデータ要素が’ＩＥＥＥ’ではなく’ＡＣＭ’
であるということ以外は、最初のオカレンスに対しステ
ップ５−６で説明した処理を繰り返す。

【００８７】 ３．ここで、ＣＵＲＤＥＳ＝１４３６であり、記述子１
４３６は前に述べたようにスタックの最上部にある。し
かし、ＬＡＳＴＦＬＡＧ＝’１’なので、グループ終了
処理を行う。その長さフィールド（ＩＤＴ１４４６）に
埋め戻しを行って蓄積値９にし、そしてスタックをポッ
プさせて、次の記述子（ＥＤＴ１４６０）を取り出す。

【００８８】 ４．制御をコール元に戻す。しかし、ＣＵＲＤＥＳが“
ＥＮＤ”記述子を参照しているので、そのリターンコー
ド（ＲＣ）をセットして、このデータストリームのパー
ジングが完了したことを示す。

【００８９】デコード論理 デコードでは、項目ベクトルのフィールドは、そのほと
んどの部分をデコーダによってセットし、そしてそのフ
ィールドを、１つのテンプレート・オカレンスのデコー
ドから制御が戻った後にコール元のプログラムが調べる
。もしデータストリーム中である項目についての何のオ
カレンスも見い出せない場合には、デコーダは、その項
目に関する空フラグ（ＦＬＡＧＳ．ＮＵＬＬ）をセット
する。もしそれ以外の場合には、デコーダは、ＦＬＤＬ
内でその項目長を返し、そしてＦＬＡＧＳ．ＭＯＶＥの
設定値に依存して、デコーダ作業記憶領域に保持したそ
の項目データに対する参照を返すようにすることができ
る。このデコーダをコールする前に、コール元は、ＦＬ
ＡＧＳ．ＭＯＶＥ＝２進’１’のセットを行って、これ
により、デコーダがこれのバッファからコール元が指定
したデータ領域にその項目データを移動させるべきであ
ることを示す。この場合、そのアプリケーションは、そ
のＦＬＤＰフィールドもその目標データ領域を参照する
ようにセットしなくてはならない。もしＦＬＡＧＳ．Ｍ
ＯＶＥ＝’０’（２進）ならば、デコーダはＦＬＤＰを
セットして、これの作業記憶領域内のそのデータを参照
する。この場合、コール元は、制御が戻った後その項目
データを処理する必要がある。

【００９０】デコーダが返すもう１つのフィールドは、
１バイトのシーケンス・フィールドＦＬＡＧＳ．ＳＥＱ
である。このフィールドは、項目をデコードした順序を
得るために用いるものであり、これは、テンプレート内
の（おそらく多くの項目の）非空の全項目を直ちに判別
するのに走査することができるリストとして役立つ。具
体的に説明するが、その項目ベクトルの最初の要素から
始めると、ＦＬＡＧＳ．ＳＥＱ（Ｊ）は、そのテンプレ
ートのためにデコードしたＪ番目の項目の項目番号を含
んでいる。例えば、もしあるテンプレートが３０個の項
目を含んでおり、そして項目９、１５、２６及び６のみ
をこの順序でデコードしたとすると、ＦＬＡＧＳ．ＳＥ
Ｑ（１）、ＦＬＡＧＳ．ＳＥＱ（２）、ＦＬＡＧＳ．Ｓ
ＥＱ（３）及びＦＬＡＧＳ．ＳＥＱ（４）は、それぞれ
９、１５、２６及び６の値を含むことになる。処理した
その項目数をデコーダが返すので、アプリケーションは
、２進’０’の空フラグを捜すためにその項目ベクトル
全体を走査する必要なく、それら非空項目に直ちにアク
セスすることができる。

【００９１】ＧＤＰＤＥＣＯＤへのコールは、次のよう
に行う。ＣＡＬＬ　　ＧＤＰＤＥＣＯＤ（ＨＡＮＤＬＥ
，ＲＥＱＴＩＤ，ＩＴＥＭＣＯＵＮＴ，ＬＡＳＴＦＬＡ
Ｇ，ＲＣ，ＵＳＥＲＢＩＴＳ）を行い、これにおいて、
ＨＡＮＤＬＥは、ＧＤＰＤＩＮＩＴが発生し、そしてこ
のＨＡＮＤＬＥは、制御情報、パーズテーブル及びその
他の資源を参照する。

【００９２】ＲＥＱＴＩＤを返し、これは、デコードし
たオカレンスに対応したテンプレートを識別する、デコ
ーダが返してきたテンプレート識別子（ＴＩＤ）を含ん
でいる。

【００９３】ＩＴＥＭＣＯＵＮＴを返し、これは、最後
のコール時にデコードした項目数を含んでいる。

【００９４】ある１つの反復グループを処理する時、デ
コーダがＬＡＳＴＦＬＡＧをセットする。ある反復グル
ープの最後のオカレンスを処理し終えた時、このフラグ
を’１’（ＴＲＵＥ）にセットし、その他の場合’０’
（ＦＡＬＳＥ）にセットする。

【００９５】ＲＣは、この手順の状態を返すリターンコ
ードである。その取り得る値は、ＯＫ、ＥＲＲＯＲ、Ｄ
ＥＣＯＤＩＮＧ＿ＣＯＭＰＬＥＴＥである。

【００９６】ＵＳＥＲＢＩＴＳは、例示として３２ビッ
ト（フルワード）のビットベクトルであり、これはパー
ズテーブル内でコード化したＴＥＳＴＵＳＥＲ記述子を
介して試験することができる。本例では、この機能は用
いず、従って本例の中では“０”としてコード化してあ
る。

【００９７】ここで、初期化を完了し（即ち、ＧＤＰＤ
ＩＮＩＴへのコールによって）、またそのデータ構造を
図２０に示すように確立した、と仮定する。図２０にお
いて、そのＦＬＡＧＳフィールドは、シーケンス・フィ
ールド（ＳＥＱ）と、そしてＭ（ＦＬＡＧＳ．ＭＯＶＥ
）、Ｎ（ＦＬＡＧＳ．ＮＵＬＬ）、及びＬ（ＦＬＡＧＳ
．ＵＬＥＮ）で表した数個のブール値と、から成ってい
る。

【００９８】ＧＤＰＤＩＮＩＴをコールし終わってＨＡ
ＮＤＬＥが返ってきた後、ＣＵＲＳＯＲを初期化して入
力データストリームの最初のバイトを参照する。ＧＤＰ
ＤＥＣＯＤへのコールのためには、移動モードを項目Ｂ
に対して要求する。その他の全項目は、位置指定モード
を用いる。ここで、それら項目ベクトル内の全ＦＬＡＧ
Ｓバイトが１６進’００’に初期化されていると仮定す
る。従って、パラメータ・セットアップ及びコール・シ
ーケンスは、以下のようになる。 １．Ｂ．ＦＬＡＧＳ．ＭＯＶＥ（１）＝’１’；２．Ｂ
．ＦＬＤＰ（１）＝項目Ｂの１０バイト・データ領域へ
の参照 処理は、次のように行う。 １．ＣＵＲＳＯＲ＝ＧＤＴ１４１０から始め、デコーダ
は、ＯＣＣＵＲＳ式を評価して、このグループのオカレ
ンスがデータストリーム内に存在するかどうか判定する
。述部ＴＥＳＴＬＫＡＨ（ＣＨＫ１４１０）を評価する
ことにより、このデータストリーム内で２バイトのオフ
セットの所を先読みして、その次の２バイト（バイト３
：４）がその定数リスト（ＴＹＰ１４１０）内の値のい
ずれかと合致するかどうか見る。バイト３：４が、その
リスト内の最初の定数である１６進’００Ａ１’を含ん
でいるので、この試験はＴＲＵＥを返す。このＴＥＳＴ
ＬＫＡＨ述部があると、ＣＵＲＳＯＲを進めない。

【００９９】 ２．そのグループ記述子（ＧＤＴ１４１０）をＳＴＡＣ
Ｋに押し込む。このＳＴＡＣＫエントリの初期化中、そ
のグループの全ての子メンバを走査して、そのどれが必
要なものであり、またどれがオプション性のものか判別
する。１つの項目ビット・ベクトル（ＲＥＱＤＩＴＥＭ
）を構築して、そのスタック・エントリ内にセーブする
。この場合、３つのメンバ、即ちＩＤＴ１４１８、ＩＤ
Ｔ１４２０、及びＧＤＴ１４２４がある。しかし、その
最初のメンバＩＤＴ１４１８のみを、必要なものとして
コード化し、従って、構築したそのビット・ベクトルは
、２進’１００’となり、そしてこれをスタック・エン
トリ内にセーブする。処理した項目ビット・ベクトル（
ＰＲＯＣＩＴＥＭ）は、全てゼロに初期化する（即ち、
２進’０００’）。

【０１００】 ３．このグループは識別したものであるので（即ち、Ｉ
Ｄ＝Ａ）、１つのテンプレートの開始を見い出したこと
になる（ＴＩＤ＝１）。テンプレートＡはＴＩＤ＝１に
対応しているので、ＲＯＯＴＰＶＥＣ（１）が参照する
その項目ベクトルは、その現行の項目ベクトル（Ａ）と
なる。次に、デコーダは、全てのＦＬＡＧＳ．ＮＵＬＬ
を’１’に初期化する。

【０１０１】 ４．次に、ＣＵＲＤＥＳをこのグループの最初のメンバ
、即ちＩＤＴ１４１８にセットする。

【０１０２】 ５．デコーダは、この記述子が長さ−タイプ記述子であ
って、２バイトの長さフィールドとこれに続く２バイト
のタイプ・フィールドとから構成されていること、を認
識する。

【０１０３】 ６．次に、デコーダは、このデータストリームがその記
述子の定義と合っているかどうか判定する。このデータ
ストリーム内のそのタイプ・フィールド（バイト３：４
）は、記述子ＩＤＴ１４１８内で指定したタイプ・フィ
ールドと一致している。

【０１０４】 ７．その長さ値（即ち、１６進’０００Ｄ’）から４を
減算することによって、それのデータ長を求め、この結
果、データ長９を得る。

【０１０５】 ８．デコーダは、バイト５：１３からそのデータ値を抽
出し、そしてこれに関連する項目ベクトル値をセットア
ップする。具体的には、Ａ．ＦＬＤＬ（１）＝９、Ａ．
ＦＬＡＧＳ．ＮＵＬＬ（１）＝’０’とし、そして移動
モードがこの項目に対して有効なので、このデータスト
リーム内のバイト５：１３を、Ａ．ＦＬＤＰ（１）が参
照する場所へ移動させる。更に、Ａ．ＳＥＱ（１）＝１
とする。

【０１０６】 ９．データストリーム・カーソルを、１３（長さ、タイ
プ及びデータのフィールドに必要なバイト数）だけ増分
させる。更に、ＳＴＡＣＫ内のアキュムレータに１３を
加えて、処理した合計バイト数を記録する。

【０１０７】 １０．ＰＲＯＣＩＴＥＭビット・ベクトルを更新して、
このメンバ（当該グループの最初のメンバ）を処理し終
えたことを反映させるようにする。そのビット・ベクト
ルは、２進’１００’に更新する。当該グループは、こ
れのメンバ・オカレンスがどんな順序で生起してもよい
セットなので、この項目が、たとえこれが必要なもので
あっても、このデータストリーム内で最初に生起しなか
った、ということになっていたかもしれない。必要とす
る項目のこの有効化は、このグループ・オカレンスの処
理が完了した時に、ＲＥＱＤＩＴＥＭビット・ベクトル
とＰＲＯＣＩＴＥＭとを比較することによって行う。

【０１０８】 １１．ＣＵＲＤＥＳをＩＤＴ１４２０に（ＩＤＴ１４１
８の次のポインタを介して）進める。ＩＤＴ１４２０を
評価することにより、データストリーム内に一致するバ
イト・ストリングが在るかどうか判定する。ＩＴＥＭＬ
Ｔデコード論理は、このデータストリーム内でＴ（タイ
プ）フィールドが生起する所（バイト１６：１７）まで
先読みし、そしてその値を、ＩＴＥＭＬＴ記述子の一部
として発生したタイプ・フィールドに対して試験する。 この場合、バイト１６：１７が１６進’００Ａ２’では
なく１６進’００Ｂ２’を含んでいるので、その試験は
不合格となる。従って、ＣＵＲＤＥＳを、次の記述子Ｇ
ＤＴ１４２４（文１０）に進める。

【０１０９】 １２．デコーダは、ＧＤＴ１４２４が識別したものであ
って、このグループが新たなテンプレート定義を始める
ことを示している、と気づく。これは、テンプレートＡ
のデコードを終了させ、従ってデコーダはコール元に戻
って、そのデコードした項目を処理するようにする。そ
のリターンパラメータＲＥＱＴＩＤを現行のＴＩＤ（即
ち、１）にセットし、ＩＴＥＭＣＯＵＮＴパラメータを
１にセットし、ＲＣ＝０を返して、処理が成功したこと
を示す。ＣＵＲＤＥＳはＧＤＴ１４２４に留り、またこ
れと同様に、他の状態情報を非解放の記憶領域にセーブ
し、これによって、デコータが再びコールされた時に処
理を適切に継続できるようにする。また、テンプレート
Ａの処理が完了しても、グループＧＤＴ１４１０の処理
は未だ完了していないことに注意しなくてはならない。

【０１１０】コール元プログラムに戻ると、このプログ
ラムは、ＲＥＱＴＩＤによってその正確な項目ベクトル
にアクセスする。続いて、非空の項目値を処理する。結
果的には、ＧＤＰＤＥＣＯＤ（ＨＡＮＤＬＥ，ＲＥＱＴ
ＩＤ，ＩＴＥＭＣＯＵＮＴ，ＬＡＳＴＦＬＡＧ，ＲＣ，
０）を再びコールして、第２のテンプレート・オカレン
スＤのデコードを続けることになる。

【０１１１】 テンプレートＤ（第２のオカレンス）のデコード１．記
述子ＧＤＴ１４２４から処理を続行する。データストリ
ームのバイト１６：１７が１６進’００Ｂ２’を含んで
いるので、ＷＨＥＮ節がＴＲＵＥ（真）であると評価す
る。ＧＤＴ１４２４はセット・グループ（ＧＤＴ１４１
０）の３番目のメンバ要素なので、ＧＤＴ１４２４のＰ
ＲＯＣＩＴＥＭベクトルを２進’１０１’に更新して、
このＧＤＴ１４２４のオカレンスを見い出したことを反
映させる。この記述子ＧＴＤ１４２４は、スタックに押
し込み、（このグループが識別したものであるため）新
たな現行ＴＩＤを確立し、そしてＣＵＲＤＥＳをＧＤＴ
１４２４の最初の子（ＩＤＴ１４２８）へと更新する。

【０１１２】 ２．ＩＤＴ１４２８を解釈し、そしてその値を、項目セ
ーブ領域内に、その項目記述子のＤＳＡフィールドが指
定したオフセットの所にてセーブする。ＣＵＲＳＯＲを
２だけ増分させ、そして次の記述子ＩＤＴ１４３４を（
ＩＤＴ１４２８のＮＥＸＴ参照によって）取り出す。

【０１１３】 ３．ＩＤＴ１４３４を解釈し、そして、この項目は識別
したものであるので、これに関連する項目ベクトル要素
を更新して、その値（バイト１６：１７）を参照するよ
うにする。Ｄ．ＦＬＤＰ（１）を、そのデータ値を指す
ようにセットし（位置指定モードが有効）、Ｄ．ＳＥＱ
（１）＝１、Ｄ．ＦＬＡＧＳ．ＮＵＬＬ（１）＝’０’
、及びＤ．ＦＬＤＬ＝２とする。ＣＵＲＳＯＲを２だけ
増分し、そして次の記述子ＧＤＴ１４３８を取り出す。

【０１１４】 ４．長さ式（ＬＥＮ１４３８）を評価し、そしてそれが
正であるか試験して、データストリーム内にこのグルー
プのオカレンスが在るかどうか判定する。これは、ＤＥ
ＬＶ記述子を解釈することから成っている。記述子ＩＤ
Ｔ１４２８に対してセーブした値（ステップ２）を取出
し、そしてこれを４だけ減分させて（即ち１６−４）１
２を得る。このグループ長さは０より大きいので、更に
処理するためにそれを選択する。

【０１１５】 ５．ＧＤＴ１４３８をスタックに押し込み、そしてＣＵ
ＲＤＥＳをそれの最初の子記述子（ＩＤＴ１４４２）に
更新する。

【０１１６】 ６．この可変長さ項目（ＩＤＴ１４４２）を解釈する。 これのデータ長は、親グループ（ＧＤＴ１４３８）につ
いて既に説明したのと全く同じ方法で判定する。これは
例外的であるが、ここでは本例を簡素化するために、こ
れが発生することとする。この時点で、ＣＵＲＳＯＲは
１８に等しくなっている。そのデータ長（即ち、１０進
で１２）を、それの指定した長さ範囲（４，５０）と首
尾よくチェックし、そしてテンプレートＤに対するその
項目ベクトルを更新する。具体的に示すと、Ｄ．ＦＬＡ
ＧＳ．ＮＵＬＬ（２）を２進’０’にセットし、Ｄ．Ｆ
ＬＤＰ（２）を文字ストリング“ＳＮＡ　　Ｎｅｔｗｏ
ｒｋ”を指すようにセットし、Ｄ．ＳＥＱ（２）を２（
１０進）にセットし、Ｄ．ＦＬＤＬ（２）を１２（１０
進）にセットする。ＣＵＲＳＯＲを１２だけ増加し、そ
して次の記述子（ＧＤＴ１４３８）を取り出す。

【０１１７】 ７．ＧＤＴ１４３８はＳＴＡＣＫの最上部にあり、これ
は、このグループに対する処理が完了していることを示
している。ＧＤＴ１４３８は長さ限定グループなので、
チェックを行って、このグループのメンバに対し処理し
たバイト数が、所定のグループ長さ（即ち、１６バイト
）に間違いなく等しくなるようにする。続いて、ＳＴＡ
ＣＫをポップさせる。このグループは識別したものでは
ないので、次の記述子ＧＤＴ１４２４から処理を続行す
る。

【０１１８】 ８．ＧＤＴ１４２４が今やＳＴＡＣＫの最上部にある。 このＳＴＡＣＫをポップさせ、そしてＣＵＲＤＥＳを次
の記述子（ＧＤＴ１４１０）に進める。しかしながら、
ＧＤＴ１４２４は識別したものであるので、リターンパ
ラメータをセットし、そして次の記述子を解釈する前に
制御をコール元に戻すようにする。具体的には、ＲＥＱ
ＴＩＤ＝２、ＩＴＥＭＣＯＵＮＴ＝２、ＲＣ＝０にする
。

【０１１９】この時点で、コール元のアプリケーション
は、テンプレートＤのその項目ベクトルを処理し、そし
て第３のテンプレート・オカレンス（Ｊ（１））をデコ
ードするために戻る。

【０１２０】 １．ＣＵＲＤＥＳ＝ＧＤＴ１４１０及びＣＵＲＳＯＲ＝
３０で処理を続行する。ＧＤＴ１４１０はＳＴＡＣＫの
最上部にある。ＧＤＴ１４１０はセット・グループであ
り、メンバ・オカレンスはどんな順序で生起してもよい
ので、上記グループ記述子による反復をもう１度要求す
ることがある。従って、ＷＨＩＬＥ式（ＣＨＫ１４１０
）の評価を行い、そしてバイト３２：３３が記述子ＴＹ
Ｐ１４１０が指定したリスト内のどの値とも等しくない
ので、ＦＡＬＳＥ（偽）値が結果として生ずる。次に、
ベクトルＰＲＯＣＩＴＥＭ及びベクトルＲＥＱＤＩＴＥ
Ｍを用いてチェックを行って、そのセットの必要な項目
全ての処理が完了したかどうか見る。この試験には合格
となり、従ってＳＴＡＣｋをポップさせて、次の記述子
（ＩＤＴ１４４６）を処理のために取り出す。

【０１２１】 ２．ＩＤＴ１４４６を処理し、その結果、前述のように
その１６進’０００００９’の値を項目セーブ領域にセ
ーブする。次に、ＣＵＲＳＯＲを４だけ増分して、次の
記述子（ＧＤＴ１４３６）を取り出す。

【０１２２】 ３．ＧＤＴ１４３６は反復グループである。この反復グ
ループ用の初期処理を実施し、そしてＧＤＴ１４３６を
ＳＴＡＣＫに押し込む。その初期化処理は以下のものを
含んでいる。 ａ）そのＯＣＣＵＲＳ節の評価。このグループは長さ限
定形なので、その長さ式（この場合既に処理した長さフ
ィールドへの単純な参照である）を評価する。その長さ
値（９）は、このグループに関してエンコードした全て
の反復オカレンスの累積長さを示す。 ｂ）その評価した値はゼロより大きいので、ＧＤＴ１４
３６をＳＴＡＣＫに押し込み、またそのグループ長さ（
９）をそのスタック・エントリにセーブする。このグル
ープは識別したものであるので、現行ＴＩＤをそのグル
ープＩＤ（即ち、３）にセットする。 ｃ）ＳＴＡＣＫ内の反復カウンタを１に初期化し、そし
てデータカウント・アキュムレータを０にセットする。 このグループは識別したものであるので、現行ＴＩＤを
その記述子ＩＤ（即ち、３）に更新する。ＣＵＲＤＥＳ
を、それの最初のメンバ記述子（ＩＤＴ１４５０）にセ
ットする。

【０１２３】 ４．ＩＤＴ１４５０を解釈し、そしてその１バイト値（
４）を将来の参照のためにその項目セーブ領域にセーブ
する。ＣＵＲＳＯＲを１増分して、次の記述子（ＩＤＴ
１４５４）を取り出す。

【０１２４】 ５．可変長項目記述子ＩＤＴ１４５４を前述のように解
釈する。ＩＤＴ１４５４は識別したものであるので、テ
ンプレートＪ（３）内の項目Ｋ（１）に対する項目ベク
トルを更新して、その値（“ＩＥＥＥ”）をコール元に
返す。ＣＵＲＳＯＲを４増分して、次の記述子（ＧＤＴ
１４３６）を取り出す。

【０１２５】 ６．ＧＤＴ１４３６はＳＴＡＣＫの最上部にあり、これ
は、１つのオカレンスの処理が完了したことを示してい
る。各オカレンスをデコードした後の反復項目について
、終了規準を評価して、その最後のオカレンスを処理し
終えたかを判定する。この反復グループに対しては、デ
コードしたバイト数が、その反復グループの初期化中に
計算したグループ長に等しくなった時、処理が完了した
ことになる。この時点では、このグループの１回の反復
によって５バイトを処理したことになって、このグルー
プ内には４バイト残っていることになる。従って、ＬＡ
ＳＴＦＬＡＧを’０’（偽）にセットし、そして制御を
コール元に戻す。パラメータＩＴＥＭＣＯＵＮＴを１に
セットし、ＲＥＱＴＩＤに現行ＴＩＤ（即ち、３）を割
り当てる。

【０１２６】この時点で、コール元のアプリケーション
に戻って、テンプレートＪ（１）のデコード済みオカレ
ンスを処理する。ＬＡＳＴＦＬＡＧがＦＡＬＳＥ（偽）
なので、アプリケーションは結局ＧＤＰＤＥＣＯＤに対
する別のコールを出して、第４のテンプレート・オカレ
ンス（Ｊ（２））をデコードするようにする。

【０１２７】 １．記述子ＩＤＴ１４５０とＩＤＴ１４５４とを処理す
るステップは、前述のインスタンス（Ｊ（１））と同様
である。ＩＤＴ１４５４の後、ＣＵＲＤＥＳ＝１４３６
とする。

【０１２８】 ２．前述の場合のように、反復グループ終了条件を計算
する。この時、しかしながら、蓄積した処理バイト・カ
ウント（９）が前もって計算したグループ長と等しいの
で、ＴＲＵＥ（真）値が得られる。従って、反復限度の
チェック等、必要な全ての終了グループ処理を行い、ス
タックをポップさせ、そしてＬＡＳＴＦＬＡＧを’１’
（真）にセットする。ＣＵＲＤＥＳが現在“終了記述子
”（ＥＤＴ１４６０）を参照しているのを検出した時、
リターンコードを“ＤＥＣＯＤＩＮＧ＿ＣＯＭＰＬＥＴ
Ｅ”にセットし、そして制御をコール元に返す。

【０１２９】コール元は、テンプレートＪの最後のオカ
レンスをデコードし終わり、従ってデコードが完了した
と判断する。

【０１３０】図２１は、本発明を実施することができる
システムの一例である。この図には、別個のプロセッサ
２１００及び２１０２を示してあり、これらは、そのシ
ステムの別々の場所に位置していてもいなくてもよい。 それらプロセッサは、通信チャンネル２１０４によって
接続してある。これらプロセッサは、いつでも実行でき
るある数のアプリケーション・プログラム、例えば２１
０６、２１０８及び２１１０、２１１２を含むことがで
きる。その一方のプロセッサ内のそれらアプリケーショ
ンの内のいくつかまたはその全てのものは、チャンネル
２１０４を介して、他方のプロセッサ内のアプリケーシ
ョン・プログラムと通信するようにすることができる。 このような通信は、双方のプロセッサ内の共通のパーザ
を介して行う。図示したように、それらパーザの各々は
、記述した本発明に従って、エンコード部２１１８、２
１２０とデコード部２１２２、２１２４とに分割してあ
る。プロセッサ２１００内の２１２６のようなメモリ記
憶装置及びプロセッサ２１０２内の２１２８のようなメ
モリ記憶装置は、プロセッサ内のアプリケーション・プ
ログラムと各パーザとの間のＡＰＩの一部を形成してい
る。本図示例では、このメモリは、図１５に示したデー
タ構造を含んでおり、これは、そのチャンネル上のデー
タストリームの詳細の重負担からアプリケーションを大
いに解放し、従って各アプリケーションに好都合な方法
でアプリケーションとパーザとの間で容易にデータを渡
すことができるようになる。

【０１３１】

【発明の効果】本発明のアプリケーション・プログラム
・インターフェース（ＡＰＩ）を用いれば、アプリケー
ション・プログラムは、フォートランにおけるフォート
ラン文のような高水準言語文を用いたプログラマと同様
の形式で、データをパーザに渡しまたパーザから受け取
ることができる。このＡＰＩによって、各アプリケーシ
ョンをデータストリームの複雑さから遮蔽することがで
きる。長さフィールドの計算や自己定義型データストリ
ームに必要なコードポイントの挿入等の詳細は、パーザ
によって自動的に処理するようにする。また、このＡＰ
Ｉによって、そのアプリケーションにとって最も好都合
なフォーマットで、パーザとのデータのやり取りが可能
となる。例えば、そのインターフェース・オプションに
よって、データをアプリケーションが指定し構成したデ
ータ領域に移動させたり、可変長さフィールドに空白を
詰めたり、指定した順番で各フィールドを（データスト
リーム中でのそれらの順序とは関係なく）呈示したりす
る、という特徴を得ることができる。エンコード・フェ
ーズの間ではエンコーダが自動的にフィールドを構築し
、デコード・フェーズの間ではデコーダがフィールドを
解釈し、そしてもしコール元のアプリケーションが必要
としないならそれらを破棄するようにする。また、パー
ザ内のアサーション機能によって、パーズのある段階で
生じなくてはならない有効状態について試験を行うこと
ができる。ネスト状構造及び反復構造に関する試験は、
次に使うべき記述子を決めるためにパーザにデータスト
リーム中を先読みさせる“ルックアヘッド”機能と同様
に、パーズテーブル内に組み込むことができる。また、
複雑な式をコード化して、フィールドの存在規準または
有効規準を指定するようにすることができる。

【図面の簡単な説明】

【図１】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図２】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図３】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図４】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図５】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図６】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図７】種々の例示的なデータストリーム・フォーマッ
トの１つを示す図であり、これは、実際に出くわす可能
性のある種々の異なったデータストリームの１例であっ
て、これに対し本発明を適用することができる。

【図８】アプリケーション・プログラムとデータストリ
ーム・エンコーダ・ルーチンとのインターフェースを概
括的に示す図。

【図９】アプリケーション・プログラムとデータストリ
ーム・デコーダ・ルーチンとのインターフェースを概括
的に示す図。

【図１０】例示的なある１つのパーズテーブルを形成す
るグループ記述子及び項目記述子の論理的組織を示す図
であり、そのパーズテーブルが、パーザのエンコード用
ルーチン及びデコード用ルーチンに対し、ある特定のタ
イプのデータストリームを処理する方法を知らせるよう
になっている。

【図１１】グループ記述子の例示的なレイアウトを示す
図。

【図１２】項目記述子の例示的なレイアウトを示す図。

【図１３】グループ記述子Ａ，Ｄ，Ｇ，Ｊ及び関連する
項目記述子Ｂ，Ｃ，Ｆ，Ｈ及びＫを含む１つのパーズテ
ーブルの概念的組織を示す図。

【図１４】図１３のパーズテーブルを更に詳細に示す図
。

【図１５】そのパーザとアプリケーション・プログラム
との間のデータ・インターフェースを形成する例示的な
データ構造を示す図。このインターフェースは、部分的
に、使用中のある特定のデータストリームについて詳細
に知るという負担からアプリケーション・プログラムを
解放する。

【図１６】図１７と一緒になって、アプリケーション・
プログラムとそのパーザのエンコード用ルーチン及びデ
コード用ルーチンとの間のコール用インターフェースを
より詳細に示す図。

【図１７】図１６と一緒になって、アプリケーション・
プログラムとそのパーザのエンコード用ルーチン及びデ
コード用ルーチンとの間のコール用インターフェースを
より詳細に示す図。

【図１８】図１３及び図１４のパーズテーブルに関連し
た本発明の動作を説明するのに使う例示的な１つのデー
タストリーム・フォーマットを示す図。

【図１９】図１８の総括的なデータストリームに関連す
る具体的なエンコード例を示す図。

【図２０】図１８の具体例に関連する図１５のデータ構
造インターフェースをより詳細に示す図。

【図２１】本発明を実施することができるシステムの１
例を示す図。

【符号の説明】

２１００、２１０２　　　　プロセッサ２１０４　　　
　通信チャンネル ２１０６、２１０８、２１１０、２１１２　　　　アプ
リケーション・プログラム

Claims (10)

【特許請求の範囲】
1. 【請求項１】　　データ通信チャンネルを有する少なく
   とも１つの処理ノードを含むデータ処理システムに用い
   るための、前記チャンネル上で入来するデータをパージ
   ングしそして前記ノード上で実行するプログラムに前記
   データを通信する方法であって、イ）　　パーザと前記
   プログラムとの間のこの通信インスタンスを初期化し、
   この初期化が、パーズテーブル内で定義したテンプレー
   トに対応するデータストリーム内の個々のデータ項目の
   フォーマットを定義するそのパーズテーブルを識別する
   ことと、前記個々の項目に対しプライベートな記憶域を
   割り当てることとを含み、その後、ロ）　　前記プログ
   ラムによって、前記パーズテーブルを識別するコールを
   前記パーザへ発することにより、前記チャンネル上で前
   記パーザが受け取ったデータの１テンプレート分を要求
   し、ハ）　　前記パーザによって、前記識別したパーズ
   テーブルに従って前記入来データをデコードして、個々
   のデータ項目を抽出し、そしてニ）　　該個々のデータ
   項目を、これらのそれぞれに割り当てた前記プログラム
   用の記憶領域に記憶させる、ステップから成る方法。
2. 【請求項２】　　請求項１の方法であって、前記チャン
   ネルに送るために前記プログラムからのデータをパージ
   ングするステップを更に含み、前記パージングは、前記
   プログラムによって、１テンプレート分のデータ項目を
   これらの各々に割り当てた記憶領域内に記憶し、前記パ
   ーズテーブルを識別するコールを前記パーザに発するこ
   と、を含んでいる方法。
3. 【請求項３】　　請求項１または２の方法であって、１
   つの前記パーズテーブルは、１つのデータストリーム内
   の個々のデータ項目の生起順序を定義する複数のデータ
   記述子を含んでいる、方法。
4. 【請求項４】　　請求項３の方法であって、前記データ
   記述子は、更に前記個々のデータ項目の長さを定義して
   いる、方法。
5. 【請求項５】　　請求項３の方法であって、前記データ
   ストリーム内の前記データ記述子及び情報は、更に前記
   個々のデータ項目の長さを定義している、方法。
6. 【請求項６】　　請求項１または２の方法であって、１
   つの前記プログラムと前記パーザとの間のインターフェ
   ースは、前記個々のデータ項目のための前記プライベー
   ト記憶域を前記パーズテーブルと組み合わさって指すデ
   ータ構造を含んでいる、方法。
7. 【請求項７】　　請求項３の方法であって、１つの前記
   プログラムと前記パーザとの間のインターフェースは、
   前記個々のデータ項目のための前記プライベート記憶域
   を前記パーズテーブルと組み合わさって指すデータ構造
   を含んでいる、方法。
8. 【請求項８】　　請求項７の方法であって、前記データ
   記述子はデータグループ記述子とデータ項目記述子とを
   含み、各グループ記述子は１つ以上の他のグループ記述
   子または項目記述子を含み、前記各グループ記述子は、
   該グループ記述子内に含まれている項目記述子が識別す
   るデータ項目の規定した特徴を記述するグループ記述子
   タイプ識別を含み、各前記項目記述子は、これが表すデ
   ータ項目の規定した特徴を記述する項目記述子タイプ識
   別を含んでいる、方法。
9. 【請求項９】　　請求項８の方法であって、前記データ
   構造は更に、前記グループ記述子の内の１つまたはそれ
   以上と個々に連係させた複数のテンプレートを含み、各
   前記テンプレートは、該グループ記述子に関連する前記
   データストリームの前記個々のデータ項目を記述する情
   報を含んでいる、方法。
10. 【請求項１０】　　請求項９の方法であって、前記デー
    タ構造は更に、複数組の項目ベクトルを含み、各前記組
    は、１つのテンプレートと、プライベート記憶域内の複
    数の項目記憶場所とに関連している、方法。