X 0806 : 1999 (ISO 23950 : 1998) 

（1） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

まえがき 

この規格は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，通商産業大臣が制定した日

本工業規格である。 

JIS X 0806には，次に示す附属書がある。 

附属書1（規定） OID：Z39.50のオブジェクト識別子 

附属書2（規定） CTX：応用コンテキスト基本Z39.50-ac 

附属書3（規定） ATR：属性集合 

附属書4（規定） ERR：誤り診断 

附属書5（規定） REC：レコード構文 

附属書6（規定） RSC：資源報告書式 

附属書7（規定） ACC：アクセス制御書式 

附属書8（規定） EXT：この規格で規定する拡張サービス 

附属書9（規定） USR：利用者情報書式 

附属書10（規定） ESP：要素指定書式 

附属書11（規定） VAR：選択可能形集合 

附属書12（規定） TAG：タグ集合定義及びスキーマ 

附属書13（参考） ERS：拡張検索集合モデル 

附属書14（参考） RET：Z39.50検索 

附属書15（参考） PRO：Z39.50プロファイル 

附属書16（参考） この規格の維持機関

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

日本工業規格          JIS 

X 0806 : 1999 

(ISO 23950 : 1998) 

情報検索 

(Z39.50) 応用サービス定義 

及びプロトコル仕様 

Information and documentation−Information retrieval (Z39.50)− 

Application service definition and protocol specification 

1. 序文 この規格は，1998年に発行されたISO 23950, Information and documentation−Information retrieval 

(Z39.50)−Application service definition and protocol specificationを翻訳し，技術的内容を変更することなく日

本工業規格として採用するために作成されたものであり，1.〜3.については，原国際規格の同項目を全文翻

訳し，4.以降については，それぞれ原国際規格の同項目の内容を引用するものとした。 

1.1 

適用範囲 この規格は，情報検索応用サービスを示し（3.参照），情報検索応用のプロトコルを規定

する（4.参照）。サービス定義は，応用の中で実現されるサービスを示し，そのサービスは，Z39.50プロト

コルの中で順次仕様化される。この規格は，計算機システムでの実装を指定したり束縛したりするもので

はない。プロトコル仕様は，プロトコル制御情報の定義，この情報を交換するための規則及びこのプロト

コルの実装が満たすべき適合要件を含む。 

この規格は，情報検索サービスを実現するシステムのため，また情報サービス機関，大学，図書館及び

総合目録センターなどの機関のためのものとする。これは，また，接続指向型のプログラム−プログラム

通信向けのものとする。端末，その他の物理的媒体による情報交換向きのものとはしない。 

1.2 

版 これまでにZ39.50には，1988年版，1992年版及び1995年版の三つの出版物がある。また，探

索及び検索プロトコルには，ISO 10163-1 : 1993がある。ANSI/NISO Z 39.50-1992，ISO 10163-1 : 1993及

びANSI/NISO Z 39.50-1995の三つの出版物は，プロトコルの版の概念を取り入れており，第1版，第2版

及び第3版の三つのプロトコルの版が，規定されている。ISO 10163-1 : 1993はプロトコル第1版に，

ANSI/NISO Z 39.50-1992はプロトコル第2版に，ANSI/NISO Z 39.50-1995はプロトコル第2版及びプロト

コル第3版の双方に，それぞれ基づいている（ANSI/NISO Z 39.50-1988に関してはプロトコルの版はない。）。 

この規格は，第2版及び第3版に基づいている。この規格は第1版と第2版とは同一であることを仮定

する。したがって，第1版に対応している実装は，自動的に第2版にも対応していることとなる（これ以

外，この規格の他の場所では，明示的に第1版に言及していない。）。この規格中の手続で，第2版又は第

3版だけに適用されるものは，その旨記載してある。 

1.3 

引用規格 次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成

する。これらの引用規格は，その最新版を適用する。 

ANSI/NISO Z 39.53-1994 Codes for the Representation of Languages for Information Interchange 

ANSI/NISO Z 39.58-1992 Common Command Language for Online Interactive Information Retrieval

2 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ISO 2709 : 1981 Documentation−Format for Bibliographic Information Interchange on Magnetic Tape 

ISO 4217 : 1990 Codes for the representation of currencies and funds 

JIS X 5003 : 1987 開放型システム間相互接続の基本参照モデル。 

備考 ISO 7498 : 1984, Information Processing Systems−Open Systems Interconnection−Basic 

Reference Modelが，この規格と一致している。 

JIS X 5701 : 1991 開放型システム間相互接続−アソシエーション制御サービス要素のサービス定義 

備考 ISO 8649 : 1987, Information Processing Systems−Open Systems Interconnection−Service 

Definition for the Association Control Service Elementが，この規格と一致している。 

JIS X 5702 : 1991 開放型システム間相互接続−アソシエーション制御サービス要素のプロトコル仕

様 

備考 ISO 8650 : 1987, Information Processing Systems−Open Systems Interconnection−Protocol 

Specification for the Association Control Service Elementが，この規格と一致している。 

JIS X 0803 : 1995 会話型テキスト検索用コマンド 

備考 ISO 8777 : 1993, Information and Documentation−Commands for Interactive Text Searchingが，こ

の規格と一致している。 

JIS X 5601 : 1995 開放型システム間相互接続−プレゼンテーションサービス定義 

備考 ISO/IEC8822 : 1988, Information Processing Systems−Open Systems Interconnection−Connection 

Oriented Presentation Service Definitionが，この規格と一致している。 

JIS X 5603 : 1990 開放型システム間相互接続の抽象構文記法1 (ASN.1) 仕様 

備考 ISO/IEC8824 : 1990, Information Processing Systems−Open Systems Interconnection−

Specification of Abstract Syntax Notation One (ASN.1) が，この規格と一致している。 

JIS X 5604 : 1990 開放型システム間相互接続の抽象構文記法1 (ASN.1) の基本符号化規則仕様 

備考 ISO/IEC8825 : 1990, Information Processing Systems−Open Systems Interconnection−

Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) が，この規格

と一致している。 

ISO 10160 : 1997 Information and Documentation−Open Systems Interconnection−Interlibrary Loan 

Application Service Definition 

ISO 10161-1 : 1997 Information and Documentation−Open Systems Interconnection−Interlibrary Loan 

Application Protocol Specification−Part 1 : Protocol specification 

ISO 10163-1 : 1993 Information and Documentation−Open Systems Interconnection−Search and Retrieve 

Application Protocol Specification−Part 1 : Protocol specification 

備考 この規格は，ISO 10163-1に代わるものである。この規格では，既存の実装のために，ISO 10163-1

との互換性を維持するための箇条が存在する。 

ISO-International register of coded character sets. 

2. 定義 この規格で用いる主な用語の定義は，次による。 

a) (A) アソシエーション (A-association)  応用アソシエーション (application association) の略［j)参照］。 

b) 抽象データベースレコード (abstract database record)  データベースレコード中の情報の抽象的表現。

抽象データベースレコードは，抽象レコード構造（スキーマによって定義される。）をデータベースレ

コードに適用することによって形成することができる。抽象データベースレコードに要素指定を適用

3 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

して別の抽象データベースレコードの実現値を形成することもできる。 

c) 抽象レコード構造 (abstract record structure)  データベーススキーマの一次的要素。抽象レコード構造

をデータベースレコードに適用した結果が，抽象データベースレコードとなる。 

d) 抽象構文 (abstract syntax)  抽象構文記法を用いたあるデータ型の記述。OID（オブジェクト識別子）

によって参照することができる。 

e) 抽象構文記法 (abstract syntax notation)  データ型の記述をその表現方法から独立に行うことのでき

る言語。 

ASN.1が，その一例である。 

f) 

アクセスポイント (access point)  単独又は他のアクセスポイントとの組合せによってレコードの探

索に用いられるキー。一意でも一意でなくともよい。アクセスポイントは，要素（抽象構文によって

定義される。）と等しくても，幾つかの要素から抽出しても，又は要素に関係なくてもよい。 

g) アクセスポイント句 (access point clause)  タイプ1問合せのオペランドの一つ（非公式）。 

h) 集合的表示応答 (aggregate present response)  表示操作での，幾つかのセグメント要求（もしあれば）

と一つの表示応答とを合わせたもの。 

i) 

APDU 応用プロトコルデ−タ単位 (application protocol data unit) の略［l)参照］。 

j) 

応用アソシエ−ション (application association)  データベース利用者とデータベース提供者との間の

通信セション。一つ以上の (Z) アソシエーションからなる。 

k) 応用プロトコル (application protocol)  発信元と受信側との間の情報の形式と交換とを管理する規則。 

l) 

応用プロトコルデータ単位 (application protocol data unit)  発信元と受信側との間を転送される情報

の単位。その形式は，Z39.50プロトコルによって規定され，応用プロトコル情報と場合によって応用

利用者データとからなる。 

m) 応用プロトコル制御情報 (application protocol control information)  応用プロトコルデータ単位によっ

て伝達される情報。 

n) 適用選択可能形 (applied variant)  選択可能形仕様の三つの使用法の一つで，検索レコードに含まれ

る要素に対し受信側が適用する選択可能形仕様。［cr)選択可能形要求 (variantRequest) 及びcb)提供選

択可能形 (supported Variant) も参照］。 

o) ARS 抽象レコード構造 (abstract record structure) の略［c)参照］。 

p) ASN.1 JIS X 5603 (ISO/IEC 8824) 及びJIS X 5604 (ISO/IEC 8825) に規定される抽象構文記法1。 

q) 属性 (attribute)  探索語の一つの特性，又は全体として探索語の一つの特性をなす幾つかの特性成分。 

r) 属性要素 (attribute element)  属性型とその型の値との組によって表現される属性。 

s) 

属性リスト (attribute list)  属性要素の集合及びその所属する属性集合識別子。属性リストは，探索用

語と組み合わされてタイプ1問合せのオペランドとなる。通常，その集合の一つの属性要素が，正規

化されたアクセスポイントに対応し，このアクセスポイントに対して，（他の属性要素によって修飾さ

れた）検索語が，照合される。 

t) 

属性集合 (attribute set)  属性型の集合。各属性型は，それぞれ属性値のリストである。各型は，ある

整数によって表現され，この整数は，その属性集合（属性集合識別子によって識別される。）の中で一

意であり，またある型の中で各々の属性値は，一意である。 

u) 属性集合識別子 (attribute set id)  （属性リストの中の）属性要素の属する属性集合を識別するOID。 

v) 属性型 (attribute type)  属性要素の構成成分。属性集合は，一つ以上の属性型を定義し，各型に対し

整数を割り当てる（また，各型に対する属性値も定義する。）。例えば，属性集合bib1は，属性型 “Use” 

4 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

に対し整数1を割り当てている。 

w) 属性値 (attribute value)  属性要素の構成成分。属性集合は，一つ以上の値を各型に対し定義する。例

えば属性集合 “bib1” は，属性型 “Use” に値 “personal name” を定義している。 

x) クライアント (client)  発信元を含む応用。すなわちデータベース利用者。 

y) クライアントシステム (client system)  クライアントの存在するシステム。 

z) 構成仕様 (composition specification)  検索レコードの望ましい構成（要素及びレコード構文）を指示

するために表示要求に含まれうる仕様。スキーマ識別子，要素指定，及びレコード構文識別子を含む。 

aa) 条件応答付サービス (conditionally confirmed service)  応答付又は応答なしとして呼び出されうるサ

ービス。（発信元又は受信側からの）要求に（同位からの）応答が続きうるものとして定義される。例

えば，資源制御は，条件応答付サービスの一つである。［ax)応答なしサービス (non-confirmed service) 

及びab)応答付サービス (confirmed service) も参照］。 

ab) 応答付サービス (confirmed service)  （発信元又は受信側からの）要求に（同位からの）応答が続く

ものとして定義されるサービス。例えば，探索サービスは，発信元によって起動される応答付サービ

スの一つである。アクセス制御サービスは，受信側によって起動される応答付サービスの一つである

［ax)応答なしサービス (non-confirmed service) 及びaa)条件応答付サービス (conditionally-confirmed 

service) も参照］。 

ac) データベース (database)  関連する情報を含む情報単位の集まり。各情報単位が，データベースレコ

ードである。 

ad) データベースレコード (database record)  データベース中の情報単位を表現する局所的なデータ構造。 

ae) データベーススキーマ (database schema)  データベースのレコードに含まれる情報についての発信

元と受信側との間の共通理解。これによって要素指定を通してその情報の部分を選択することが可能

となる。スキーマは，データベースレコードに適用されて抽象データベースレコードとなる抽象レコ

ード構造を定義する。 

af) データ要素 (data element)  要素 (element) と同義［ag)参照］。 

ag) 要素 (element)  スキーマの定義する情報の単位。 

ah) 要素要求 (ElementRequest)  特定の要素の検索のために要素指定とともに含まれる要求。要素要求は，

要素の望ましい選択可能形を示す選択可能形要求を含むことができる。 

ai) 要素集合名 (element set name)  基本名の形での要素指定。 

aj) 要素指定 (element specification)  要素指定書式の実現値又は要素集合名。要素指定は，一つの抽象デ

ータベースレコードを別の抽象データベースレコードに変換する（この変換は，無変換でもよい。）。

要素指定は，抽象データベースレコードから要素を選択する。さらに，これらの要素に対し選択可能

形形式を指定することもある。 

ak) 要素指定書式 (element specification format)  要素指定を表現する構造。 

al) 要素指定識別子 (element specification identifier)  要素指定書式のオブジェクト識別子又は要素集合

名。 

am) 例外的レコード長 (exceptional record size)  単一の例外的に大きな（すなわち，要望メッセージ長よ

り大きい）レコードが要求される特別な場合に，表示応答に含まれうるレコードの最大長。 

an) 機能群 (facility)  Z39.50サービスの論理的なまとまり，又は単独のサービス。例えば，検索機能群

は，表示サービス及びセグメントサービスからなり，探索機能群は，探索サービスだけからなる。他

に，ある機能群が他の機能群のサービスを使用し，その機能群のサービスをもたないこともある。例

5 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

えば，説明機能群は，サービスをもたず，探索サービス及び表示サービスを使用する。 

ao) （レコードの）最終断片 (final fragment)  レコードの終わりで終了する断片［ap)（レコードの）断

片 (fragment) も参照］。 

ap) （レコードの）断片 (fragment)  レコードの真の部分列（この定義は，3.3.3に示すレベル2セグメ

ント化の文脈でだけ意味をもつ。当該の箇条ではレコードは，バイトの列として考える。）。 

aq) GRS 共通レコード構文。 

ar) 起動要求 (initiating request)  操作を開始する要求。 

as) （レコードの）中間断片 (intermediate fragment)  レコードの終わりでも開始でもない断片［ap)（レ

コードの）断片 (fragment) も参照］。 

at) IR 情報検索 

au) 項目 (item)  (1)検索集合項目 (result set item)。(2)書誌項目 (ISO 10160) 参照。 

av) 最大セグメント長 (maximum segment size)  集合的表示応答（セグメント化が有効な場合）のセグメ

ントの許される最大長。 

aw) 名前 (name)  ある言語で表された言語的構成要素で何らかの実体に対応するもの。名前は，それに

結び付けられた実体を示す（識別する）。 

ax) 応答なしサ−ビス (non-confirmed service)  発信元又は受信側からの要求に対応する応答がないもの

として定義されるサービス。例えばセグメントサービスは，受信側から起動される応答なしサービス

である。［ab)応答付サービス (confirmed service) も参照］。 

ay) オブジェクト識別子 (object identifier)  大域的に一意に認知され，登録機関によって登録されるデー

タ実体を示す識別子。 

az) OID オブジェクト識別子 (object identifier) の略［ay)参照］。 

ba) 操作 (operation)  起動要求及びそれに対応する終了応答，並びにその間にはさまれる関連のメッセー

ジ。例えば，探索操作は，常に探索要求及び探索応答を含み，更にアクセス制御及び資源制御メッセ

ージを含んでもよい。一つの (Z) アソシエーション内には複数の並行操作を含んでもよい。 

bb) 操作型 (operation type)  その操作を起動する要求の名前。例えば，探索要求は，“探索”型の操作を

起動する。 

bc) 発信元 (origin)  (Z) アソシエーションを起動し (Z) アソシエーション中で操作を起動する実体。 

bd) 発信元サービス利用者 (origin service-user)  発信元で要求を発行するクライアントの部分。［by)サ

ービス利用者 (service-user) も参照］。 

be) OSI 開放型システム間相互接続。 

bf) Pコンテキスト (P-context)  プレゼンテーションコンテキスト (presentation context) の略［bh)参照］。 

bg) 要望メッセージ長 (preferred message size)  セグメント化が有効でないときの探索応答又は表示応答

の最大長。プロトコル制御情報を含まない応答レコードの長さの和（バイト数）で表される。 

bh) プレゼンテーションコンテキスト (presentation context)  抽象構文を応用アソシエーションの中で使

用するためにプレゼンテーション層で取り決められた抽象構文と転送構文との組合せ。 

bi) プリミティブ (primitive)  サービスプリミティブ (service primitive) と同義［bw)参照］。 

bj) 基本名 (primitive name)  その内部構造の理解を必要としない，又は利用者にとって理解が重要でな

いような名前。基本名は，プリミティブとは関係がないことに注意。 

bk) レコード構文 (record syntax)  検索レコードを表現するため発信元又は受信側によって要求される

抽象構文。完全な定義については，3.6.3参照。 

6 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

bl) 応答レコード (response record)  データベースレコードを表す探索応答又は（集合的）表示応答での

検索レコード，若しくは代替診断レコード。 

bm) 検索集合 (result set)  転送レコードの選択機構として局所的に用いられるデータ構造。その論理的構

造は，順序づけられた検索集合項目の名前付きのリストであり，更にその検索集合を作成した探索を

代表する何らかの情報をもちうる。 

bn) 検索集合項目 (result set item)  データベース名，データベース中のレコードに対するポインタ，及び

場合によってはレコードに関連づけられた何らかの情報。 

bo) 検索集合レコード (result set record)  検索集合項目で表されるデータベースレコードをさす慣用的

な言い方。［bm)検索集合 (result set) も参照］。 

bp) 検索レコード (retrieval record)  レコード構文をある抽象データベースレコードに適用することによ

って定義される送出可能な構造。 

bq) RPN問合せ (RPN query)  逆ポーランド表記法 (RPN) 形式で表現された探索問合せ。 

br) スキーマ (schema)  データベーススキーマ (database schema) と同義［ae)参照］。 

bs) セグメント (segment)  集合的表示応答，すなわちセグメント要求又は表示応答の一部分として受信

側によって送られる（又は送出のために準備中の）メッセージ。 

bt) サーバ (server)  受信側を含む応用。すなわちデータベース供給側。 

bu) サーバシステム (server system)  サーバの存在するシステム。 

bv) サービス (service)  (1)“探索”サービスのようなZ39.50サービス。(2)“持続性検索集合拡張サービ

ス”のような拡張サービス。(3)サービス提供者。 

bw) サービスプリミティブ (service primitive)  サービス利用者とサービス提供者との間における相互動

作の抽象的で実装から独立した表現。サービスプリミティブの四つの型は，要求，指示，応答，確認

である。 

bx) サービス提供者 (service-provider)  同位のサービス利用者にサービスを提供するエンティティ（発信

元と受信側）全体の抽象概念。サービス提供者の概念は，プロトコル手続の仕様を容易にするために

使われる。これは，プロトコルモデルを示すために4.2.2の中でだけ使用される。 

備考 サービス提供者は，データベース提供者又は通信サービスの提供者とは関係ない。 

by) サービス利用者 (service-user)  発信元サービス利用者又は受信側サービス利用者。クライアント又は

サーバで発信元又は受信側に要求を行う部分。サービス利用者の概念は，プロトコル手続の仕様を容

易にするために使われる。これは，プロトコルモデルを示すために4.2.2の中でだけ使用される。 

備考 サービス利用者は，データベース利用者とは関係ない。 

bz) 単純表示応答 (simple present response)  一つのセグメントからなる集合的表示応答。すなわち，表示

応答だけからなり，セグメント要求を含まないもの。 

ca) （レコードの）開始断片 (starting fragment)  レコードの先頭で開始する断片［ap)（レコードの）断

片 (fragment) も参照］。 

cb) 提供選択可能形 (supportedVariant)  選択可能形仕様の三つの使用法の一つで，特定の要素に対して受

信側が利用可能なものを提示する選択可能形仕様［n)適用選択可能形 (applied Variant) 及びcr)選択可

能形要求 (variantRequest) も参照］。 

cc) 代替診断レコード (surrogate diagnostic record)  データベースレコードを表す検索レコードの代わり

に供給される診断レコード。 

cd) タグ (tag)  要素（又は要素を表すタグ系列のノード）の識別子。タグ型及びタグ値からなる。 

7 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ce) タグ系列 (TagPath)  （レコードの要素が，階層的に木として表現されている場合）木の最上位から

そのタグが表現するノードまでのノードの連り。タグ系列の各ノードは，タグで表される。最終ノー

ドが最下位ノードの場合，タグ系列は，要素を表現する。そうでない場合，タグ系列は，最上位ノー

ドがそのノードであるような部分木を表現する。 

cf) タグ集合 (tagSet)  要素の集合に対するタグ値（及び推奨されるデータ型）の集まり。 

cg) タグ集合識別子 (tagSetId)  タグ集合に対する持続的な識別子として働くオブジェクト識別子。 

ch) タグ型 (tagType)  タグ集合の略式（整数）識別子。スキーマ定義は，（スキーマ定義の文脈中で）特

定のタグ集合を識別するために，タグ型をタグ集合識別子に与えてもよい。 

ci) タグ値 (tagValue)  要素（又は要素を表すタグ系列のノード）の識別子。整数であっても文字列であ

ってもよく，タグ型によって修飾される。 

cj) 受信側 (target)  (Z) アソシエーションを受け入れるエンティティ。 

ck) 受信側サービス利用者 (target seryice-user)  受信側で要求を発行するサーバの部分［by)サービス利用

者 (service-user) も参照］。 

cl) 終了応答 (terminating response)  操作を終了させる応答。 

cm) 転送構文 (transfer syntax)  抽象構文と組になってレコード構文をなす構文。 

cn) 三つ組 (triple)  三つの組（n＝3のn-組）。 

co) タイプ1問合せ (type-1 query)  RPN問合せ (RPN query) と同義［bq)参照］。 

cp) 選択可能形 (variant)  要素を検索する際に利用可能な幾つかありうる形のうちの一つ。発信元は，特

定の選択可能形を要求してもよく，受信側は，特定の選択可能形で表示する。受信側は，ある要素に

ついてどのような選択可能形が利用可能かを指示することもできる。 

cq) 選択可能形リスト (variant list)  受信側によって供給される特定の要素に対する提供選択可能形のリ

スト。 

cr) 選択可能形要求 (variantRequest)  選択可能形仕様の三つの使用法の一つで，要素要求の中で使われ

る選択可能形仕様［n)適用選択可能形 (appliedVariant) 及びcb)提供選択可能形 (supportedVariant) も参

照］。 

cs) 選択可能形集合 (variant set)  クラスの集合の定義。それぞれのクラスについて型の集合，及びそれ

ぞれの型について値の集合。選択可能形仕様は，特定の選択可能形集合の選択可能形指定子の集合か

らなる。 

ct) 選択可能形集合識別子 (variant set identifier)  選択可能形集合を識別するOID。 

cu) 選択可能形仕様 (variant specification)  選択可能形要求，適用選択可能形又は提供選択可能形。選択

可能形仕様は，それぞれが選択可能形指定子である三つ組の列とする。 

cv) 選択可能形指定子 (variant specifier)  選択可能形仕様の構成要素。クラス，そのクラスのために定義

された型及びその型のために定義された値からなる。 

cw) (Z) アソシエーション (Z-association)  Z39.50アソシエーション (Z39.50-association) の略［cx)参照］。 

cx) Z39.50アソシエーション (Z39.50-association)  発信元によって明示的に確立され，発信元若しくは受

信側によって明示的に，又は (A) アソシエーションの終了によって暗黙的に終了するセション。発信

元と受信側との間の通信は，応用アソシエーション中のZ39.50アソシエーションを通して行われる。

一つの (A) アソシエーション中には幾つかの連続した (Z) アソシエーションが存在してよい。 

8 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3. 情報検索サービス 情報検索サービス定義は，起動側応用であるクライアント及び応答側応用である

サーバの，二つの応用間の動作を規定する。サーバは，一つ以上のデータベースに対応している。 

クライアントとサーバとの間の通信は，4.に規定されるZ39.50プロトコルによって実行される。プロト

コル仕様は，論理的にクライアントに属する手続とサーバに属する手続とに分けられる。クライアント及

びサーバのZ39.50プロトコル手続を実行する部分を，それぞれZ39.50発信元及びZ39.50受信側と呼ぶ。 

3.1 

情報検索サービスのモデルと特徴 発信元と受信側との間の通信は，応用アソシエーション［(A) ア

ソシエーション］内のZ39.50アソシエーション［(Z) アソシエーション，4.2.1.2参照］を介して行われる。

(Z) アソシエーションは，発信元によって明示的に確立され，発信元若しくは受信側によって明示的に，

又は (A) アソシエーションの終了によって暗黙的に終了する。 

一つの (A) アソシエーション内に，複数の連続した (Z) アソシエーションが存在してもよい。一つの 

(Z) アソシエーション内に，複数の連続した並行操作（3.5参照）が存在してもよい。 

(Z) アソシエーション内での発信元及び受信側の役割を逆転させることは，できない。(Z) アソシエー

ションは，再始動することができず，したがって，一度終了すると明示的に保存したものを除いて状態情

報は，保持されない。 

サービス定義は，サービス及び操作を規定する。それらのモデルは，3.1.1及び3.1.2に示す。サービス

は，機能群にグループ分けされる。Z39.50機能群及びサービスは，3.2で定義する。 

3.1.1 

Z39.50サービス Z39.50サービスは，発信元と受信側との間のメッセージ交換によって実行され

る。メッセージは，要求又は応答のいずれかとする。サービスは，応答付，応答なし，条件応答付のいず

れかとして定義される。 

応答付サービスは，（発信元又は受信側からの）要求に（同位からの）応答が続くものとして定義される。

例えば，探索サービスは，発信元によって起動される応答付サービスの一つである。探索サービスは，発

信元からの探索要求に受信側からの探索応答が続くものとして定義される。アクセス制御サービスは，受

信側から起動される応答付サービスの一例である。 

応答なしサービスは，発信元又は受信側からの要求に対応する応答がないものとして定義される。例え

ば，資源制御トリガサービスは，発信元によって起動される応答なしサービスである。また，セグメント

サービスは，受信側によって起動される応答なしサービスである。 

条件応答付サービスは，応答付又は応答なしとして呼び出されうるサービスであり，（発信元又は受信側

からの）要求に（同位からの）応答が続きうるものとして定義される。例えば，資源制御サービスは，受

信側によって起動される条件応答付サービスである。 

3.1.2 

Z39.50操作 この規格は，8種の操作型を規定する。すなわち開始 (init)，探索 (search)，表示 

(present)，削除 (delete)，走査 (scan)，並び替え (sort)，資源報告 (resouce-report)，及び拡張サービス 

(extended-services) である。 

発信元からの要求のある種の操作型のものは，その型の操作を起動し（例えば，探索要求は，探索操作

を起動する），その操作は，受信側からの対応した応答によって終了する。操作を起動することができるの

は，発信元だけであるが，すべての発信元要求が操作を起動するわけではない（3.4参照）。 

操作を起動する要求は，起動要求と呼ばれ，操作を終了させる応答は，終了応答と呼ばれる。発信元か

らみれば，操作は，起動要求を出したとき始まり，終了応答を受けたときに終わる。受信側から見れば，

操作は，起動要求を受けたときに始まり，終了応答を出したときに終わる。操作は，起動要求及び終了応

答，並びにこの間にはさまれる関連したメッセージによって構成される（3.4参照）。 

9 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.1.3 

データベースのモデル この規格は，クライアントがサーバのデータベースから情報を探索，検索

する応用のため，クライアントとサーバとの間の開放型接続を容易にすることを目的とする。データベー

スを実装する手段は，多様である。システムが異なれば，データの記憶を記述する方式も，アクセスする

ための手段も異なる。このため，データベースを記述する共通の抽象的モデルを用いる。個々のシステム

は，このモデルに対してその実装を写像することができる。これによって，異なるシステムが標準的で相

互に理解できる用語で通信し，データベースから情報を探索，検索することが，可能になる。探索と検索

のモデルは，3.1.4及び3.1.5に示す。 

データベースという用語は，この規格で定義しているように，レコードの集まりをさす。各レコードは，

一つの単位として扱われる関連した情報を集めたものである。データベースレコードという用語は，レコ

ード中の情報を表す局所的なデータ構造を示す。一つのデータベースには，データベースレコードの探索

に指定できる一つ以上のアクセスポイント（3.1.4参照）の集合，及びデータベースレコードから検索でき

る一つ以上の要素（3.1.5参照）の集合が，結び付けられている。アクセスポイントは，レコードの探索に

単独で又は他のアクセスポイントと組み合わせて指定できるキーであり，一意でも一意でなくてもよい。

アクセスポイントは，要素と関連していてもよい。要素と等価であってもよく，一つ以上の要素の集合か

ら作成してもよく，またいかなる要素とも関係なくてもよい。 

3.1.4 

データベースの探索 データベースに対し，そのアクセスポイントに一致すべき値を指定すること

によって問合せが，行われる。問合せに対して得られたレコードからなるデータベースの部分集合を検索

集合と呼ぶ（3.1.6参照）。検索集合は，それに続く問合せによって参照されて新しい検索集合を形成する

ため利用されることもある。 

探索要求は，一つ以上のデータベースを指定し，また問合せを含む。この規格に定義するタイプ1問合

せ（3.7参照）は，一つのアクセスポイント句，又は論理演算子によって結ばれた複数のアクセスポイント

句からなる。 

例 “Books” という名称のデータベースの中で，アクセスポイント “title word” が “evangeline” で，

かつアクセスポイント “author” が “longfellow” という値を含む，すべてのレコードを探す。 

アクセスポイント句は，一つの探索語と属性群からなる。属性群は，探索語を修飾する。通常，属性の

一つが，正規化されたアクセスポイントに対応しており，このアクセスポイントに対して（他の属性によ

って修飾された）探索語との照合が行われる。各属性は，属性型とその型の値との対である（例えば，型 

“access point” と値 “author” であったり，型 “truncation” と値 “left” であったりする。）。 

各属性は，その属性が属している属性集合を識別する属性集合識別子によって修飾される。属性集合は，

属性型の集合であり，その各属性型は，属性値のリストをもつ。 

3.1.5 

データベースからのレコード検索 受信側は，探索処理の後，検索集合を発信元からの検索要求に

対して利用可能とする。発信元は，検索集合からのレコードの検索要求にあたって，データベーススキー

マ識別子，要素仕様，レコード構文識別子を指定することができる。 

検索集合からレコードを検索するために，それぞれのデータベースには，一つ以上のスキーマが，結び

付けられている。スキーマは，データベースのレコードに含まれる情報についての発信元と受信側の共通

理解を表現する。これによって，要素指定を通してその情報の一部を選択することが，可能となる。 

スキーマは，データベースレコードに適用されて抽象データベースレコードとなる抽象レコード構造を

定義する。抽象データベースレコードは，レコード中の情報の抽象的表現である。要素指定は，抽象デー

タベースレコードに適用されて，別の抽象データベースレコードを生み出す（これは，無変換でもよい。）。

要素指定は，抽象データベースレコードから幾つかの要素を選択する。それらの要素に対して選択可能形

10 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

を指定することもできる。 

受信側は，レコード構文を抽象データベースレコードに適用し，検索レコードと呼ばれる送出可能な構

造を作り出す。 

3.1.6 

検索集合のモデル 一般的に，問合せの処理は，必ずしもレコードへの物理的なアクセスを必要と

しないと想定されている。このため検索集合も問合せによって選択された実際のレコードの集合ではなく，

レコードの識別情報（例えばポインタ）の集合と想定される（データベースレコードが，ロックされてい

ることは想定しない）。検索集合レコードの修正や削除を抑止する並行処理制御は，この規格では扱わな

い。）。検索集合は，システム間のレコード転送のための選択に利用できる。しかし検索集合自体は，純粋

に局所的なデータ構造で転送されることはない（レコードは転送されるが，ポインタは局所的なものであ

り，転送されない。）。 

レコードの検索のための検索集合の論理構造は，名前付きの集合で，順序付けられた項目のリストであ

る。各項目は，次のものからなる三つ組となる。 

a) リスト中で三つ組が占める位置の順序番号， 

b) データベース名， 

c) b)で指定されたデータベース内でのレコードの一意な識別子（局所的な意味しかもたない。）。 

検索集合項目は，検索集合中での位置，つまりa)によって参照される。 

探索のため検索集合が問合せの中でオペランドとして使われる場合，その論理構造は，下記のいずれか

となる。 

− 基本モデル：上記モデルのb)とc)からなる対の集合。 

− 拡張モデル：上記モデルのb)，c)及びその検索集合を作成した探索を代表する何らかの情報からなる

三つ組の集合。 

備考 問合せ仕様は，基本モデルが適用されることを指定してもよく，又はどのような条件のもとで

拡張モデルが適用され，どのような情報が加えられるかを指定してもよい。タイプ1問合せに

ついては，第2版では，基本モデルが適用される。 

3.1.7 

拡張サービスのモデル Z39.50サービスの中に，“拡張サービス” (ES) サービスがある。“拡張サ

ービス”とは，この規格で認識はされるが，（3.1.1に規定する）Z39.50サービスではない種類のサービス

を表す。ESサービスは，Z39.50サービスであり，ES操作は，拡張サービスタスクを起動する。このタス

クは，Z39.50ES操作の一部とはしない。 

ES操作は，ES要求を通じて，発信元によって起動される。ES応答は，ES操作を終了させるが，（必ず

しも）タスクの終了を通知するわけではなく，例えばタスクの開始又は待ち行列への登録を示してもよい

（又はタスクの終了を示してもよい。実際，ES要求は，タスクが終了してからES応答を返すよう指定す

ることもできる。）。ESタスクは，(Z) アソシエーションを超える寿命をもちうる。 

拡張サービスの例として検索集合や問合せの保存，及び文書の送出や注文があげられる。 

各ESタスクは，タスクパッケージと呼ばれるデータベースレコードによって代表され，受信側によっ

て “extended services database”（ESデータベース）と呼ばれる特殊なデータベース中に維持される。発信

元がESデータベース上にタスクパッケージを作成するには，ES要求を使用する。発信元は，特定の型の

パッケージを探索したり，特定の利用者によって作成されたパッケージを探索したり，特定の状態（ペン

ディング，活動中，又は終了）のパッケージを探索したり，他の種々の条件によって探索したりすること

ができる。特に，発信元は，ES要求を出した後［同じ (Z) アソシエーション中，又は後続の (Z) アソシ

エーション中に］，ESデータベースを探索し，タスクの状態に関する情報，例えばタスクが開始されてい

11 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

るか，などを確認することができる。 

3.1.8 

説明 発信元は，利用できるデータベース，属性集合，診断集合，レコード構文，要素指定など受

信側の実装の詳細情報を得ることができる。発信元は，Z39.50の説明機能群を通じてこれらの詳細を得る。

受信側は，この情報を発信元からZ39.50探索，表示機能群を通じてアクセスできるようデータベース中に

維持する。 

この “explain” データベースは，受信側によって提供されるその他のデータベースと同じように見える

が，よく知られた名前とあらかじめ定義されたレコード構文とをもつ。さらに，意味的なレベルでの相互

運用性を確保するため，幾つかの探索語が，情報の区分に応じてあらかじめ定義されている。各情報区分

は固有のレコード形式をもつ，またこれらすべては，説明構文に含まれている。 

3.2 

情報検索サービスの機能群 3.2.1から3.2.11までは，情報検索サービスの11の機能群を規定してい

る。大多数は，サービスの論理的なグループから構成されている。一つの機能群が，ただ一つのサービス

から構成されている場合がある。この規格の今後の版では，幾つかの機能群には新しくサービスが付け加

わることもありうる。次に示すのは，11の機能群の要約した記述である。 

a) 初期化機能群 (initialization facility) 開始 (init) サービス 開始操作を起動するために発信元によって

起動される応答付サービス。 

b) 探索機能群 (search facility) 探索 (search) サービス 探索操作を起動するために発信元によって起動

される応答付サービス。 

c) 検索機能群 (retrieval facility)  検索機能群は，二つのサービスによって構成される。 

1) 表示 (present) サービス 表示操作を起動するために発信元によって起動される応答付サービス。 

2) セグメント (segment) サービス 表示操作中に受信側によって起動される応答なしサービス。 

備考 表示操作は，一つの表示要求，それに続くゼロ又は複数のセグメント要求，及びそれに続く一

つの表示要求とから構成される。 

d) 検索結果集合削除機能群 (result-set-delete facility) 削除 (delete) サービス 削除操作を起動するため

に発信元によって起動される応答付サービス。 

e) 通覧機能群 (browse facility) 走査 (scan) サービス 走査操作を起動するために発信元によって起動

される応答付サービス。 

f) 

並び替え機能群 (sort facility) 並び替え (sort) サービス 並び替え操作を起動するために発信元によ

って起動される応答付サービス。 

g) アクセス制御機能群 (access control facility) アクセス制御 (access control) サービス 発信元によって

起動される応答付サービス。これは，操作を起動せず，また一つの活動中の操作の一部であることも

一部でないこともありうる。 

h) 資源制御機能群 (accunting/resource control facility)  資源制御機能群は，三つのサービスから構成され

る。 

1) 資源制御 (resource-control) サービス 発信元によって起動される条件応答付サービス。これは，操

作を起動せず，また活動中の操作の一部であることも一部でないこともありうる。 

2) 資源制御トリガ (trigger-resource-control) サービス ある操作中に発信元によって起動される応答

なしサービス。 

3) 資源報告 (resource-report) サービス 資源報告操作を起動するために発信元によって起動される応

答付サービス。 

i) 

説明機能群 (explain facility)  説明機能群は，いかなるサービスも含まないが，探索及び検索機能群

12 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

のサービスを使用する。 

j) 

拡張サービス機能群 (extended services facility) 拡張サービス (extended services) サービス 拡張サー

ビス操作を起動ずるために発信元によって起動される応答付サービス。 

k) 終了機能群 (termination facility) 完了 (close) サービス 発信元又は受信側によって起動される応答

付サービス。 

これは，いかなる操作も起動せず，いかなる操作の一部でもない。これは，発信元又は受信側にす

べての活動中の操作を強制的に終了させ，(Z) アソシエーション終了処理を起動することを許可する

［(Z) アソシエーションの終了後，発信元は，開始サービスを使用して新たな (Z) アソシエーション

を起動してもよい。］。 

3.2.1 

初期化機能群 初期化機能群は，ただ一つのサービスである開始サービスからなる。 

3.2.1.1 

開始サービス 開始サービスによって発信元は，(Z) アソシエーションを開設することができる。

発信元は，開始要求の中で初期化パラメタの値を提示する。受信側は，開始応答の中でその初期化パラメ

タの値に応答する。その値は，発信元が提示した値と異なることもあるが，応答した値が，この (Z) アソ

シエーションに対して有効となる。 

受信側の反応が肯定的 (result＝ “TRUE”) である場合，(Z) アソシエーションが，開設される。発信元

が受信側応答中の値を受諾したくない場合，完了サービスによって (Z) アソシエーションを終了してもよ

い（続いてもう一度開設を試みることができる。）。受信側の反応が否定的である場合，発信元は，もう一

度開設を試みることができる。 

表1 開始サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

版 (version) 

○ 

○ 

識別番号／認証 (id/authentication) ○（任意選択） 

− 

オプション (options) 

○ 

○ 

要望メッセージ長 
(preferred-message-size) 

○ 

○ 

例外的レコード長 
(exceptional-record-size) 

○ 

○ 

結果 (result) 

− 

○ 

実装識別子 (implementation-id) 

○（任意選択） 

○（任意選択） 

実装名 (implementation-name) 

○（任意選択） 

○（任意選択） 

実装版 (implementation-version) 

○（任意選択） 

○（任意選択） 

利用者情報フィールド 
(user-information-field) 

○（任意選択） 

○（任意選択） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき）

3.2.1.1.1 

版 発信元と受信側の両方とも，その対応しているすべての版を示す。最上位の共通の版の利

用が選択され，(Z) アソシエーションに対して有効であるとされる。共通する版がない場合には，受信側

は，結果パラメタで“拒絶”を返すことが望ましい。 

備考1. 既知の最上位の版よりも上位の版番号は，無視されるのが望ましい。 

2. 第1版と第2版とは，全く同一である。第2版に対応しているシステム（例えばISO 10163 : 

1993 implementationsのような）は，第1版だけへの対応を示しているシステムとの相互運用

のために，第1版をも示すことが望ましい。 

13 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.1.1.2 

識別番号／認証 このパラメタは，この規格外で発信元と受信側が発信元によって供給される

かどうかについて合意する。この値は，発信元が受信側との通信に入ることを認証されたかどうかを決め

るために受信側によって使用される。 

3.2.1.1.3 

オプション 次に列挙した個々の機能に対して，発信元は，1又は0（それぞれ“有効”又は“無

効”を意味する。）のいずれかを提示し，受信側は，それぞれに対して応答する。応答は，その機能が有効

であるかどうかを決める。 

− 探索 (search) 

− 表示 (present) 

− 削除 (delete) 

− 資源報告 (resoure-report) 

− 走査 (scan) 

− 並び替え (sort) 

− 拡張サービス (extended-service) 

− 資源制御トリガ (trigger-resource-control) 

− レベル1セグメント化 (level 1 segmentation) 

− レベル2セグメント化 (level 2 segmentation) 

− 並行操作 (concurrent operations) 

− 名前付検索集合 (named result sets) 

− 資源制御 (resource-control) 

− アクセス制御 (access-control) 

備考 上記の機能のリストは，このプロトコルの今後の版においては拡張されることもある。 

これらの機能を取り決める方法を示した以下の規定は，発信元と受信側が同じ機能を必ずしも実装して

いない場合でも，相互運用ができるようにするためのものである。 

オプションパラメタは，それぞれが個別の機能に対応する論理型フラグの列から構成される。発信元は，

受信側に未知の機能に対して“有効”フラグをセットするかもしれない。この場合には，受信側が応答の

中で対応するフラグに“無効”とセットすることが推奨される。しかし，発信元がフラグを“無効”とセ

ットし，受信側が対応するフラグを“有効”とセットした場合で，発信元がそのフラグの表す機能を知ら

ないときには，発信元は (Z) アソシエーションを終了することを推奨する。 

a) 探索，表示，削除，資源報告，走査，並び替え，拡張サービス これらの操作型のそれぞれに対して，

発信元は，その型の操作を起動したいかどうかを示す。これに対し，受信側は，その型の操作を処理

するかどうかを示す。発信元が特定の操作型に対して“無効”を提示した場合，受信側も“無効”を

示さなければならない。 

備考1. 資源報告操作の処理を行うという受信側指示は，資源報告を応答に含むということを意味す

るものではない。 

2. 上記のどの操作型もどの版に対しても取り決めてよい。特に，走査，並び替え，拡張サービ

スは，ANSI/NISO Z 39.50-1992中で定義されていないが，第2版が有効な場合でも取り決め

てよい。 

b) 資源制御トリガ 発信元は，資源制御トリガ要求の送信を提示してもよい。その場合，受信側は，そ

の資源制御トリガ要求を受諾するかどうかを指示する。発信元が“無効”を提示した場合には，受信

側も“無効”を指定しなければならない。 

14 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

備考1. 受信側が資源制御トリガに対して“有効”，資源制御に対して“無効”を規定した場合，発信

元は，資源制御トリガに対して “cancel” だけを使用してもよい。 

2. 受信側は，資源制御に対して“有効”を規定した場合でも，資源制御トリガ要求の承認をし

ないと指示してもよい。 

3. 資源制御トリガを承認する受信側の指示は，受信側が資源制御トリガ要求の結果として何ら

かの動作をとることを意味しない。 

c) レベル1及びレベル2のセグメント化 発信元は，次のうちの一つを提示する。 

− セグメント化しない。レベル1及びレベル2のセグメント化の両方に対して“無効”を指定する

ことによる。 

− レベル1のセグメント化。レベル1のセグメント化に対して“有効”，レベル2のセグメント化に

対して“無効”を指定することによる。 

− レベル2のセグメント化。レベル2のセグメント化に対して“有効”を指定することによる。 

備考1. 発信元がレベル2セグメント化に対して“有効”を提示した場合，レベル1のセグメント化に

対しても“有効”を提示してよい。受信側がレベル2のセグメント化を利用可能としていない

場合，発信元は，レベル1のセグメント化を“有効”にしたいことを示すためである。 

2. レベル1又はレベル2のセグメント化が有効な場合，“セグメント化”は“有効”とする。 

3. セグメント化は，第3版が有効な場合にだけ有効としてもよい。 

受信側応答は，いずれの場合にも，どの形式のセグメント化を行おうとしているかを指示することがで

きる。 

− 受信側がレベル1もレベル2も指定しない場合には，発信元の提示やその内容にかかわらず“セ

グメント化なし”が有効とする。 

− 受信側がレベル1セグメント化を指定した（レベル2を指定しなかった）場合，受信側は，レベ

ル2のセグメント化を実行しない。発信元は，発信元の提示にかかわらず，レベル1のセグメン

ト化を受諾する準備をしなければならない。 

− 受信側がレベル2セグメント化を指定した場合，発信元は，発信元の提示やその内容にかかわら

ず，レベル2のセグメント化を受諾する準備をしなければならない（受信側のレベル1に対する

値は，“無効”であるほうがよい。）。 

“セグメント化なし”が有効である場合，表示要求に対する受信側応答は，整数個のレコードを含んだ

単一のメッセージから構成されなければならない（単一の“セグメント”，すなわちセグメント要求をはさ

まない表示応答だけ。）。“レベル1セグメント化”が有効である場合，受信側は，複数のセグメントによっ

て一つの表示要求に応答してもよい（一つ又は複数のセグメント要求をはさんだ表示応答。）。この場合，

各セグメントは，整数個のレコードを含まなければならない。“レベル2のセグメント化”が有効である場

合，受信側は，複数のセグメントによって一つの表示要求に応答し，個々のレコードは，複数のセグメン

トにまたがってもよい。セグメント化手順は，3.3に規定する。 

d) 並行操作 発信元は，並行操作を起動することを提示してもよい。その場合，受信側は，並行操作を

受諾するかどうかを指示できる。発信元が“無効”を提示した場合は，受信側は，“無効”を指定しな

ければならない。並行操作が無効である場合，“直列操作 (serial operation)”が有効となる。並行操作

は，第3版が有効な場合にだけ有効となる。 

e) 名前付検索集合 発信元は，名前付検索集合（すなわち，探索要求内の検索集合名の値として “default” 

以外の検索集合名を指定すること。）の使用を提示してもよい。この場合，受信側は，名前付検索集合

15 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

が利用可能かどうかを指定する。発信元が“無効”を提示した場合，受信側も“無効”を指定しなけ

ればならない。 

f) 

資源制御とアクセス制御 発信元は，受信側に資源制御及び／又はアクセス制御を呼び出したいかど

うかを指示する（すなわち，資源制御及び／又はアクセス制御要求を送信する。）。受信側は，資源制

御及び／又はアクセス制御を呼び出すかどうかを指定する。 

備考1. 受信側が，資源制御（又はアクセス制御）に対して“無効”を指定した場合，発信元が”有

効”を提示した場合でも，資源制御（又はアクセス制御）を呼び出さない。 

2. 発信元が資源制御に対して“無効”を提示し，受信側が資源制御要求を抑制しないことを指

示して資源制御に対して“有効”を指定した場合，発信元が資源制御要求の受諾ができない

ならば，発信元は，(Z) アソシエーションを終了することが望ましい。 

3. 発信元がアクセス制御に対して“無効”を提示した場合，受信側システム上の機密保護要求

が，(Z) アソシエーションの開始直後に（識別番号／認証パラメタによって提供される以外

の）機密保護を呼び出すことを必す（須）としているならば，受信側は，（結果パラメタを“拒

絶”にセットし，アクセス制御に対して“無効”を規定することによって）(Z) アソシエー

ションを拒絶することが望ましい。 

しかし，機密保護を別のレベルで呼び出してもよい。(Z) アソシエーションの開始直後の認証に加

えて，機密保護は，特定のデータベース，レコード，結果集合，資源報告書式又は一つの操作の使用

に対してアクセスを制御するために呼び出されることがある。こうして，発信元がアクセス制御に対

して“無効”を提示し，受信側が［(Z) アソシエーションレベル以外で］通常の機密保護を呼び出し

た場合，受信側は，(Z) アソシエーションを拒絶する必要はない。 

受信側は，発信元が提示されている機能を使用するよう認証されているかを決めるために開始操作

中に機密保護を呼び出してもよい。発信元がアクセス制御に対して“無効”を提示した場合，受信側

は，オプションパラメタによって，その特定の操作の使用を単に拒絶してもよい。 

発信元がアクセス制御に対して“無効”を提示し，受信側が (Z) アソシエーションの受諾を選択し

た場合で，発信元が続いてアクセス制御要求を促すような動作（例えば資格の得られていないデータ

ベースを特定した探索を発行するなど）を起動する場合，受信側は，アクセス制御要求を抑止し，そ

の代わりに機密保護確認を要するが発行されなかったことを示す誤り状態として応答することが望ま

しい。 

3.2.1.1.4 

要望メッセージ長と例外的レコード長 開始要求は，発信元が提示した要望メッセージ長及び

例外的レコード長の値（バイト数）を含んでいる。開始応答は，受信側が使用しようとする要望メッセー

ジ長と例外的レコード長を含んでいる。これらの値は，発信元によって提示される値とは異なった値に書

き換えてもよい。要求及び応答の双方に対し，要望メッセージ長は，例外的レコード長と等しいか短くな

ければならない。 

例外的レコード長は，表示操作中に意味をもち，表示要求中に例外的に大きい（すなわち，要望メッセ

ージ長より長い）単一のレコードが要求される特別な場合にだけ，意味をもつ。この特別な場合，例外的

レコード長までの大きさの単一のレコードが表示できるよう，要望メッセージ長を（この表示操作に対し

て）超えることができる。発信元が，セグメント化しない単一のレコードを要求したということは，要望

メッセージ長の書換えを認めたことになる。したがって，例外的レコード長は，要望メッセージ長と等し

いかより大きくなければならない。等しい場合，例外的レコード長は，意味をもたない［これによって (Z) 

アソシエーション中に特別な場合が適用されないことを表すことができる。］。 

16 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

これらのパラメタの使用法は，3.3に規定する。 

備考 例外的レコード長パラメタは，ANSI/NISO Z 39.50-1992の中で定義された最大レコード長パラ

メタ (maximum-record-size) と同じ意味をもっている。意味を明確にするためパラメタ名が変え

られた。 

3.2.1.1.5 

結果 受信側は，結果パラメタ中で “TRUE”（受諾）や “FALSE”（拒絶）の値を指定して，(Z) 

アソシエーションを受諾するかどうかを示す（“拒絶”が示された場合，発信元は，別の開始要求を送信し

てもよい。）。 

3.2.1.1.6 

実装識別子，実装名及び実装版 要求又は応答は，これらの3パラメタのいずれかを含んでも

よい。これらは，それぞれ，発信元又は受信側の実装に対する識別子（クライアントシステム又はサーバ

ーシステム内で一意），名前及び版名とする。これらの三つの実装パラメタは，実装を区別する実装者の便

宜のためにだけ提供される。 

3.2.1.1.7 

利用者情報フィールド このパラメタは，この規格によって規定されていない付加的情報に対

して発信元又は受信側が使用してもよい。 

3.2.1.1.8 

その他の情報 このパラメタは，この規格によって規定されていない付加的情報に対して発信

元又は受信側が使用してもよい。このパラメタは，第3版が有効な場合にだけ使用してもよい。 

備考 発信元がこのパラメタを使用する場合，注意が必要である。発信元は，開始要求を送信する前

に第3版が有効かどうかを確かめることはできない。 

3.2.1.1.9 

参照識別子 3.4参照。 

3.2.2 

探索機能群 探索機能群は，ただ一つのサービスである探索サービスからなる。 

3.2.2.1 

探索サービス 探索サービスによって，発信元は，受信側システムのデータベースに対する問合

せを行い，その結果に対する情報を受け取ることができる。 

探索要求によって発信元から受信側に対する問合せができる。受信側は，指定されたデータベースの集

合に対し問合せを適用し，その問合せの指定する性質をもつレコードを特定する。受信側は，問合せによ

って特定されたレコードの集合である検索集合を作成し，続く検索要求のために検索集合を保持する。 

検索集合によって識別される一つ以上のレコードは，探索のパラメタによっては，探索応答の一部分と

して直ちに検索される。検索集合は，順序づけられた集合であり，検索集合中の項目によって示されるレ

コードは，検索集合中の（1から始まる）項目の位置によって参照される。表2を参照のこと。 

17 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表2 探索サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

問合せ型 (query-type) 

○ 

− 

問合せ (query) 

○ 

− 

データベース名 

(database-names) 

○ 

− 

検索集合名 

(result-set-name) 

○ 

− 

置換え指示子 

(replace-indicator) 

○ 

− 

小集合要素集合名 

(small-set-element-set-names) 

○（任意選択） 

− 

中集合要素集合名 

(medium-set-element-set-names) 

○（任意選択） 

− 

要望レコード構文 

(preferred-record-syntax) 

○（任意選択） 

− 

小集合上限 

(small-set-upper-bound) 

○ 

− 

大集合下限 

(large-set-lower-bound) 

○ 

− 

中集合表示数 

(medium-set-present-number) 

○ 

− 

応答レコード 

(response-records) 

− 

○（適用されるとき）

結果数 (result-count) 

− 

○ 

返されたレコード数 

(number-of-records-returned) 

− 

○ 

次の検索集合位置 

(next-result-set-position) 

− 

○ 

探索状態 

(search-status) 

− 

○ 

検索集合状態 

(result-set-status) 

− 

○（適用されるとき）

表示状態 

(present-status) 

− 

○（適用されるとき）

付加探索情報 

(additional-search-information) 

○（任意選択） 

○（任意選択） 

その他の情報 

(other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき）

3.2.2.1.1 

問合せ型及び問合せ 問合せ型パラメタは，問合せの型，すなわち，問合せパラメタの構文を

識別する。次の六つの型が，定義されている。 

− タイプ0は，発信元及び受信側がこの規格外であらかじめ合意をもつ場合に限り，使用できる。 

− タイプ1は，3.7で規定する逆ポーランド表記法 (RPN) 問合せとする。 

− タイプ2は，ISO 8777で規定するISO 8777型問合せとする。 

− タイプ100は，ANSI/NISO Z 39.58で規定するZ39.58型問合せとする。 

− タイプ101は，拡張RPN (ERPN) 問合せとする。これは，近接探索，及び検索集合の属性による限定

を認めたタイプ1問合せの拡張形式である。3.7で規定する。 

18 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

備考 タイプ101問合せは，次の例外を除いてタイプ1問合せと同一である。タイプ1では近接及び

限定は，第3版が有効であるときだけ有効である。タイプ101では近接及び限定は，第3版と

第2版両方で有効である（タイプ101問合せの定義は，版とは独立である。）。 

− タイプ102は，この規格の後の版で定義される順位付けリストの可能な問合せとする。 

3.2.2.1.2 

データベース名 発信元は，問合せが適用されるデータベースの集合を指示する。 

備考1. 受信側は，（説明機能群又はこの規格外の幾つかの機構によって）探索要求でどのようなデー

タベースが指定可能か，またどのような組合せで指定可能かについて指示する。例えば，受

信側は，データベースA，B及びCを個々に探索してもよく，AとBとは組み合せて探索し

てもよい（しかし，A及びCの組合せ，B及びCの組合せは，許されない。）というように

指定することができる。 

2. 受信側によって指定される各データベース名は，文字列とする。この文字列では英大小文字

を区別しない。すなわち，ある文字が英字であれば受信側がその文字をどのように指定して

いても，発信元は，大文字を使用しても小文字を使用してもよい。 

3.2.2.1.3 

検索集合名及び置換え指示子 検索集合名パラメタは，（その問合せで作成される）検索集合に

与えられる名前を指定する。その検索集合は，［同じ (Z) アソシエーション内で］この名前で参照するこ

とができる。 

同じ名前の検索集合が受信側に既に存在する場合，受信側のとる動作は，置換え指示子パラメタの値に

よって次のように決められる。 

− 置換え指示子が “TRUE” の場合，問合せの処理後，検索集合名と同じ名前をもつ既存の検索集合は，

削除され，その名前をもつ検索集合が作成される。探索が処理されなかった場合，検索集合の内容は，

空となる。 

− 置換え指示子が “FALSE” の場合，探索は，処理されず，誤り診断結果が受信側から返される。パラ

メタで指定された名前をもつ既存の検索集合は，そのまま残る。 

検索集合名パラメタで指定された名前をもつ検索集合が存在しなかった場合，その名前をもつ検索集合

が，受信側によって作成され，置換え指示子は，無視される。検索集合の初期内容は，空とする。問合せ

によってレコードが見つからなかった場合，検索集合は，空のままとなる。 

一般的には，受信側は，発信元による名前付きを実現する必要はない。しかし，受信側は，最低限 “default” 

という名前の検索集合を提供しなければならない。発信元が検索集合名として “default” を指定する場合，

置換え指示子は，“TRUE” でなければならない。 

探索要求によって作成される検索集合（検索集合名パラメタで指定した名前）は，続く表示要求の中又

は探索要求の（例えばタイプ1問合せの）オペランドで参照することができる。“default” という名前の検

索集合が作成された場合，その時点から (Z) アソシエーションが終了するまで，又は次に示すいずれかの

時点まで，この検索集合は，参照可能となる。 

− 続く探索要求で検索集合名として “default” が指定されて検索集合が作成されるまで。又は， 

− 受信側によって一方的に消去されるか削除されるまで。 

“default” 以外に名付けられた検索集合は，作成された時点から次に示すいずれかの方法によって削除さ

れるまで参照可能となる。 

− 削除操作によって 

− 探索要求の中で同じ名前が指定され，かつ置換え指示子が “TRUE” とされることによって暗黙的に 

− （いつでも）受信側によって一方的に 

19 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− (Z) アソシエーションの終了によって 

3.2.2.1.4 

小集合要素集合名及び中集合要素集合名 これらのパラメタは，探索応答中に期待される望ま

しいレコードの構成を指示する。問合せの結果が小集合（3.2.2.1.6参照）の場合，小集合要素集合名が適

用される。問合せの結果が中集合の場合，中集合要素集合名が適用される。これら二つのパラメタについ

ては，3.6.2で述べる。 

3.2.2.1.5 

要望レコード構文 発信元は，検索レコードに対する望ましいレコード構文を指定することが

できる。受信側が要望レコード構文によって特定のレコードを供給できない場合，受信側は，他の抽象構

文の一つによってレコードを供給する。その抽象構文は，この (A) アソシエーションにとって現在確立さ

れているプレゼンテーションコンテキストの集合から選ばれる。 

受信側が要求された構文又は確立されたプレゼンテーションコンテキストと一致する構文によってレコ

ードを供給できない場合，受信側は，そのレコードに対する代替診断を返す。ただしプレゼンテーション

コンテキストの確立された集合が空でない場合であり，空の場合の受信側の動作について，この規格は，

定めない。 

3.2.2.1.6 

小集合上限，大集合下限及び中集合表示数 検索集合は，探索要求の小集合上限及び大集合下

限パラメタの値，並びに探索応答の結果数（3.2.2.1.8参照）の値によって，“小集合”，“中集合”又は“大

集合”とみなされる。結果数が小集合上限よりも大きくない場合，検索集合は，小集合とする。結果数が

大集合下限よりも大きいか等しい場合，検索集合は，大集合とする。その他の場合，検索集合は，中集合

とする。問合せの結果が小集合の場合，検索集合全体に対応する応答レコードが，発信元に返される（た

だし，メッセージ長制約の対象となることがある。）。問合せの結果が大集合の場合，応答レコードは返さ

れない。問合せの結果が中集合の場合，最大で中集合表示数に指定した個数の応答レコードが，返される。 

備考1. 結果数が小集合上限より大きく大集合下限未満の場合だけ，検索集合は，中集合となる。こ

れは，大集合下限が小集合上限よりも少なくとも2以上大きいときにだけおこりうる。すなわ

ち，大集合下限が小集合上限より1だけ大きい場合，検索集合は，中集合にはならない。例え

ば，大集合下限が11で小集合上限が10の場合，その意味は，“10又はそれ以下のデータベース

レコードが見つかったときは，すべての応答レコードを返し，その他のときは，何も返さな

い”となり，中集合表示数は，適用されない。 

2. 小集合上限は，ゼロでもよい。大集合下限は，小集合上限よりも大きくなければならない。 

3. 発信元が結果数の値にかかわらず応答レコードを要求しない場合，大集合下限を1，小集合

上限をゼロとする。 

3.2.2.1.7 

応答レコード 受信側は，探索を処理し，データベースレコードの集合を識別する検索集合を

作成する。しかし，探索処理にデータベースレコードへの物理的アクセスを仮定することはできない。特

定のレコードがアクセス不能でも，そのことが，検索レコードを作成するためレコードをアクセスしよう

とするまでわからないかもしれない。 

探索の処理後，受信側は，探索応答に含む検索レコードの作成を試みる。これらのレコードは，検索集

合のはじめのN個（3.2.2.1.6で述べるようにNは，要求パラメタ及び結果数に依存する。）のデータベー

スレコードと対応する。データベースレコードに対応する検索レコードを含むことができない場合，代替

診断レコードで置き換えられる。 

応答レコードという用語は，検索レコード又は代替診断レコードのことをいう。応答レコードパラメタ

は，次のいずれかとする。 

− N応答レコード 

20 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− メッセージ長制約によってN未満の場合の応答レコードの数（3.3参照） 

− 探索が実行できなかったこと及び実行されなかった理由を示す一つ以上の非代替診断レコード（備考

参照） 

− レコードが表示できないこと及び，例えば“要素集合名がそのデータベースで有効でない”といった，

その理由を示す一つ以上の非代替診断レコード（備考参照） 

備考 第2版が有効な場合，受信側は，単一の非代替診断レコードを返す。第3版が有効な場合，受

信側は，一つ以上の非代替診断レコードを返す。 

応答レコードパラメタ中の応答レコードの出現順序は，検索集合の中で識別された順序に従う。各応答

レコードには，任意選択としてレコードの属するデータベース名を付けることができる。しかし，返され

る最初の応答レコードには，データベース名を付けなければならない。また，その直前のものと異なるデ

ータベースからの応答レコードにもデータベース名を付けなければならない。 

3.2.2.1.8 

結果数及び返されたレコード数 結果数パラメタは，検索集合によって識別されるデータベー

スレコードの数とする。検索集合が空の場合，結果数は，ゼロとする。返されたレコード数パラメタは，

探索応答で返される全レコードの数とする。 

3.2.2.1.9 

次の検索集合位置 次の検索集合位置パラメタは，M＋1の値をとる。ここでMは，返された

うちの最後の応答レコードに対応するデータベースレコードを識別する検索集合項目の位置とする。又は

M＝結果数の場合，次の検索集合位置パラメタは，値ゼロをとる。 

3.2.2.1.10 探索状態 探索状態パラメタは，応答の中に返され，次の二つの値のいずれかをとる。 

− “success” ：探索は，成功した。 

− “failure” ：検索は，成功していない。 

戻り値 “success” は，応答の一部としてレコードが返されることを意味するものではない（3.2.2.1.11表

示状態を参照）。また，戻り値 “success” は，探索の結果データベースレコードが見つかったことを意味す

るものでもない。 

戻り値 “failure” は，期待される応答レコードが全く返されなかったことを意味するものではない。後者

の場合，受信側は，探索が処理できないことを示す一つ以上の非代替診断レコード（備考参照）を返す。 

備考 第2版が有効な場合，受信側は，単一の非代替診断レコードを返す。第3版が有効な場合，受

信側は，一つ以上の非代替診断レコードを返す。 

3.2.2.1.11 検索集合状態及び表示状態 これらは，検索及び表示操作中に発生しうるあいまいな状況を区

別するために必要な状態記述子とする。 

検索集合状態は，探索状態の値が “failure” の場合だけ存在し，次の値のいずれかをとる。 

− “subset” ：部分的，有効に利用できる結果あり。 

− “interim” ：部分的に利用できる結果あり，有効であるかの保証はない。 

− “none” ：検索集合なし。 

表示状態は，探索状態の値が “success” の場合だけ存在し，次の値のいずれかをとる。 

− “success” ：すべての期待される応答レコードが，利用可能。 

− “partial-1” ：要求は，アクセス制御によって終了し，返せない応答レコードがある。 

− “partial-2” ：要望メッセージ長に入らないため，返せない応答レコードがある。 

− “partial-3” ：要求は，発信元要求の資源制御によって終了し，返せない応答レコードがある。 

− “partial-4” ：要求は，受信側の資源制御によって終了し，返せない応答レコードがある。 

− “failure” ：期待される応答レコードは，全く返せない。一つ以上の非代替診断レコードが，返される

21 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

（3.2.2.1.7の備考参照）。 

3.2.2.1.12 付加探索情報 受信側は，応答に当たってこのパラメタを，例えば，中間結果レコード数，特

定のレコードが返された理由，特定の属性がデータベースの探索に使われた理由などを含む，探索処理の

副産物である情報を伝達するために使用してもよい。発信元は，要求に当たってこのパラメタを，それら

の情報の望ましい書式や内容を指示するために使用してもよい。利用者情報書式 “SearchResult-1” が，附

属書9に定義されている。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.2.1.13 その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.2.1.14 参照識別子 3.4参照。 

3.2.3 

検索機能群 検索機能群は，表示サービス及びセグメントサービスの二つのサービスからなる。 

発信元は，受信側で維持している検索集合中の位置を指定して，応答レコードを要求する表示要求を送

る。受信側は，要求された応答レコードを含む表示応答を送ることによって，これに応答する。又は，セ

グメント化が有効でかつ要求された応答レコードが表示応答メッセージにおさまらない場合，受信側は，

表示応答の前にセグメント要求を一つ以上送って，応答をセグメント化してもよい。セグメント化の手続

は，3.3に規定する。 

セグメント要求（もしあれば）と表示応答とをあわせて集合的表示応答と呼ぶ。個々のセグメント要求

と表示応答とを表示応答のセグメントと呼ぶ。集合的表示応答が単一のセグメント（すなわち，一つの表

示応答だけ）からなる場合は，単純表示応答と呼ばれる。 

3.2.3.1 

表示サービス 表示サービスによって，発信元は，指定した検索集合で表されるデータベースレ

コードに対応する応答レコードを要求することができる。データベースレコードは，検索集合中の相対位

置によって参照される。発信元は，ある範囲を指定する。続いて異なる幾つかの範囲を指定して要求して

もよい。表3参照。 

備考1. 第3版が有効であれば，単一の要求に二つ以上の範囲を含んでもよい。例えば，発信元は，レ

コード1〜レコード5に続いてレコード4〜レコード6を要求してもよい。 

2. この箇条では，“レコードN”の意味は，“検索集合のN番目の項目によって識別されるデー

タベースレコードに対応する応答レコード”とする。 

22 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表3 表示サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

要求レコード数 

(number-of-records-requested) 

○ 

− 

検索集合開始位置 

(result-set-start-position) 

○ 

− 

付加範囲 (additional-ranges) 

○（任意選択） 

− 

検索集合識別子 (result-set-id) 

○ 

− 

要素集合名 (element-set-names) 

○（任意選択） 

− 

要望レコード構文 

(preferred-record-syntax) 

○（任意選択） 

− 

構成仕様 (comp-spec) 

○（任意選択） 

− 

最大セグメント数 

(max-segment-count) 

○（任意選択） 

− 

最大セグメント長 

(max-segment-size) 

○（任意選択） 

− 

最大レコード長 

(max-record-size) 

○（任意選択） 

− 

応答レコード (response-records) 

− 

○（適用されるとき）

返されたレコード数 

(number-of-records-returned) 

− 

○ 

次の検索集合位置 

(next-result-set-position) 

− 

○ 

表示状態 (present-status) 

− 

○ 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき）

3.2.3.1.1 

要求レコード数及び検索集合開始位置 発信元は，レコードMに始まるN個のレコードという

形で，ある範囲のレコードを要求する。ここに，M＝検索集合開始位置，N＝要求レコード数とし，Nは，

（検索結果数−M）＋1より大きくてはならない。 

3.2.3.1.2 

付加範囲 発信元は，このパラメタを使用して付加的なレコード範囲を要求することができる。

付加範囲パラメタは，一つ以上の (M，N) の組からなる。(M，N) は，3.2.3.1.1に示す意味をもつ。最初

の組 (M，N) について，Mは，検索集合開始位置と要求レコード数との和より大きいか等しくなければな

らない。任意の連続した組 (M 1，N 1) と (M 2，N 2) については，M 1＋N 1は，M 2未満でなければなら

ない。このパラメタは，第3版が有効である場合にだけ存在してもよい。 

3.2.3.1.3 

検索集合識別子 発信元は，この (Z) アソシエーション中で作成された，レコードを検索すべ

き，一時的な検索集合の名前を指定する。 

3.2.3.1.4 

要素集合名 発信元は，検索レコードの希望する構成を指定することができる。3.6.2参照。 

3.2.3.1.5 

要望レコード構文 3.2.2.1.5参照。 

3.2.3.1.6 

構成仕様 このパラメタは，要素集合名パラメタを省略した場合で，かつ第3版が有効である

場合だけ含まれてもよい。含まれる場合，このパラメタは，検索レコードの希望する構成を指定する代替

手段を提供する。3.6参照。 

3.2.3.1.7 

最大セグメント数，最大セグメント長及び最大レコード長 この三つのパラメタは，第3版が

有効な場合だけ使用してよい。 

最大セグメント数パラメタは，レベル1又はレベル2のセグメンテーションが有効の場合に含むことが

できる。最大セグメント数は，受信側が集合的表示応答に含めてよいセグメントの最大数を指定する。こ

23 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

の値が1の場合，この操作にセグメント化は適用されず，また，最大レコード長パラメタは含まれないこ

とが望ましい。 

最大セグメント長パラメタ及び／又は最大レコード長パラメタは，レベル2セグメント化が有効な場合

にだけ含まれてもよい。最大セグメント長は，可能なセグメントの長さの最大値とする。このパラメタが

含まれる場合，（この表示操作だけに対し）要望メッセージ長は，無視される。含まれない場合，要望メッ

セージ長と同じ値が，仮定される。 

最大レコード長は，集合的表示応答中に可能な検索レコード長の最大値とする。含まれる場合，最大レ

コード長は，最大セグメント長と等しいか大きくなければならない。 

これら三つのパラメタについての詳細は，3.3.3.2で述べる。 

3.2.3.1.8 

応答レコード このパラメタは，一連の応答レコード，又はレベル2セグメント化が有効な場

合，ゼロ個以上の応答レコードが続く最終断片（3.3.3参照）から構成される。又は（操作にセグメント要

求が含まれない場合），このパラメタは，要求が処理できないこと，及びその理由（次の備考参照）を示す

一つ以上の非代替診断レコードから構成される。 

応答レコードは，集合的表示応答の中で要求された個々のレコードに対して（メッセージ長，アクセス

制御及び資源制御制約のもとで）返される。 

個々の応答レコードは，検索集合項目と対応し，応答レコードによって表される検索集合の順序位置は，

要求が付加範囲パラメタを含まない限り，昇順かつ連続となる。付加範囲のある場合，位置は昇順となる

が，要求された範囲のすき間に一致するすき間を伴うことがある。 

個々の応答レコードには，対応するデータベース名を任意選択で伴うことができる。ただし，集合的表

示応答中の最初のセグメントの最初の応答レコード（又は開始断片）には，データベース名を付加しなけ

ればならない。さらに，集合的表示応答中の直前の応答レコードと異なるデータベースからの応答レコー

ド（又は応答レコードの開始セグメント）にも付加しなければならない。 

発信元が集合的表示応答を受け取った場合，（すべてのセグメントが再構成され，セグメント化された応

答レコードが断片から再構成されれば）その結果は，次のいずれかとなる。 

− N個の応答レコード，ここにN＝要求レコード数， 

− N個未満の数の応答レコード（表示状態によって理由特定），又は， 

− 要求が処理できなかったこと及びその理由を示す一つ以上の診断レコード（備考参照）。 

備考 第2版が有効な場合，受信側は，単一の非代替診断レコードを返す。第3版が有効な場合，受

信側は，一つ以上の非代替診断レコードを返す。 

3.2.3.1.9 

返されたレコード数及び次の検索集合位置 返されたレコード数パラメタは，集合的表示応答

の全レコード数を示す。次の検索集合位置パラメタは，M＋1の値をとる。ここでMは，その応答におけ

る最終レコードに対応する検索集合項目の位置とする。又は，Mが検索集合の最後の項目の位置の場合，

次の検索集合位置パラメタは，値ゼロをとる。 

3.2.3.1.10 表示状態 表示状態パラメタは，表示応答において必す（須）であり，その値は，3.2.2.1.11の

集合的表示応答の表示状態パラメタと同じとする。 

3.2.3.1.11 その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.3.1.12 参照識別子 3.4参照。 

24 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.3.2 

セグメントサービス 表示要求によって要求されたレコードが1セグメントに入らない場合で，

かつセグメント化が有効な場合，受信側は，複数セグメントを返す。個々のセグメントは，レコードの一

部分を含む。最終セグメントを除く各セグメントは，セグメント要求として返される（最終セグメントは，

表示応答として返される。）。 

備考1. セグメントサービスは，論理的には受信側が要求をするわけではないが，要求としてモデル

化されている。 

その理由は，（抽象的サービス定義とそれに基づくプロトコル仕様という目的のために）す

べてのメッセージは，要求又は応答であり，応答は，同じ型の要求が先になければならず，

かつ一つの要求に対しては，最大一つの応答しか許されないからである。これらのモデルの

制約から，(a)セグメントサービスは，応答としてモデル化することはできず（そうであった

なら，セグメント要求への応答となる必要があり，これは応答なしサービスとなるからであ

る。），また，(b)表示操作は，複数の表示応答が続く表示要求としてモデル化することもでき

ない。 

2. このサービスは，第3版が有効な場合にだけ使用してもよい。 

3. セグメント化が有効でない場合，受信側は，セグメント要求を送らず，集合的表示応答は，

ただ一つの単純表示応答からなる。要求されたレコードがセグメントに入らない場合，3.3.1

に規定する手続を適用する。 

4. 要求されたレコードが1セグメントに入る場合，（セグメント化が有効であるかないかにか

かわらず）受信側は，セグメント要求を送らず，集合的表示応答は，一つの表示応答からな

る。 

表4 セグメントサービスのパラメタ 

パラメタ 

受信側要求 

セグメントレコード (segment-records) 

○ 

返されたレコード数 (number-of-records-returned) 

○ 

その他の情報 (other-information) 

○（任意選択） 

参照識別子 (reference-id) 

○（適用されるとき） 

3.2.3.2.1 

セグメントレコード レベル1セグメント化が有効な場合，セグメントレコードパラメタは，

一連の応答レコードからなる。 

レベル2セグメント化が有効な場合，セグメントレコードパラメタは，応答レコードに加えてレコード

の断片（3.3.3参照）を含むことができる。セグメントレコードは，最終断片（集合的表示応答の最初のセ

グメントを除く。）にゼロ個以上の応答レコードが続き，最後に開始断片という構成をとることができる。

最終，開始どちらの断片も必す（須）ではないが，どちらの断片もない場合，最低一つの応答レコードが

なければならない（断片は，検索レコードにだけ使われ，診断レコードは，セグメント化されないことに

注意する。）。 

応答レコード又は検索レコードの断片の出現順序は，検索集合の中で識別された順序に従う。各応答レ

コード又は開始断片には，任意選択としてレコードの属するデータベース名を付けることができる。ただ

し，集合的表示応答中の最初の応答レコード（又は開始断片）には，データベース名を付けなければなら

ない。また，集合的表示応答中の直前のものと異なるデータベースからの応答レコード（又は検索レコー

ドの開始断片）にもデータベース名を付けなければならない。 

3.2.3.2.2 

返されたレコード数 セグメントに含まれる応答レコードと開始断片との総数を示す。 

25 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.3.2.3 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，受信側が使用して

よい。 

3.2.3.2.4 

参照識別子 3.4参照。 

3.2.4 

検索集合削除機能群 検索集合削除機能群は，ただ一つのサービスである削除サービスからなる。 

3.2.4.1 

削除サービス 削除サービスによって，発信元は，その (Z) アソシエーション中に作成された特

定の検索集合又は全検索集合を，受信側が削除することを要求することができる。受信側は，その操作結

果に関する情報を知らせることで応答する。 

表5 削除サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

削除機能 (delete-function) 

○ 

− 

検索集合リスト (result-set-list) 

○（適用されるとき） − 

削除操作状態 (delete-operation-status) 

− 

○ 

削除リスト状態 (delete-list-status) 

− 

○（適用されるとき） 

非削除数 (number-not-deleted) 

− 

○（適用されるとき） 

一括削除状態 (bulk-statuses) 

− 

○（適用されるとき） 

削除メッセージ (delete-msg) 

− 

○（任意選択） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき） 

3.2.4.1.1 

削除機能 発信元は，次のいずれか一つを指定する。 

− “list” 指定した検索集合を削除する（3.2.4.1.2参照），又は， 

− “all” この (Z) アソシエーションで作成された受信側に現在存在する検索集合をすべて削除する。 

3.2.4.1.2 

検索集合リスト このパラメタは，削除機能が “list” の場合にだけ出現する。このパラメタは，

削除されるべき［この (Z) アソシエーションで作成された］検索集合のリストを含む。 

3.2.4.1.3 

削除操作状態 削除操作状態パラメタは，削除要求の状態を示す。削除操作状態は，“success” 又

は表6の “failure-3” から “failure-9” までの値をとる。 

3.2.4.1.4 

削除リスト状態 削除リスト状態パラメタは，要求で削除機能が “list” の場合に，削除応答中

に現れる。削除リスト状態は，削除要求における検索集合リストパラメタと同じ検索集合のリストを含み，

それぞれの検索集合が，状態と対になっている。取りうる値は，“success”，”failure-1” から “failure-6” 又

は “failure-10” とする。 

26 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表6 削除状態 

状態 

内容 

success 

検索集合は，削除された。 

failure-1 

検索集合が，存在しない。 

failure-2 

検索集合は，受信側によって既に削除されている。 

failure-3 

受信側システムの障害（任意のテキストメッセージを削除メッセージパラメタに含みうる）。 

failure-4 

アクセス制御の失敗。削除要求が，アクセス制御要求を受信側に発行させ，発信元が，これ

を満足できなかった，又は発信元が，アクセス制御要求を受け入れられなかった。 

failure-5 

発信元の要求による資源制御によって操作が終了した。 

failure-6 

資源制約のため，受信側によって操作が終了した。 

failure-7 

検索集合の一括削除機能を受信側が提供していない。 

failure-8 

（一括削除要求において）削除されなかった検索集合がある（3.2.4.1.5参照）。 

failure-9 

（リスト要求において）削除されなかった検索集合がある。 

failure-10 

検索集合は，使用中である。 

備考1. 

“failure-7” 及び “failure-8” は，削除操作が “all” の場合にだけ発生しうる。 

2. 

“failure-10” は，第3版が有効な場合にだけ使用される。 

3.2.4.1.5 

非削除数及び一括削除状態 これら二つのパラメタは，削除機能が “all”，かつ削除操作状態＝ 

“failure-8” の場合にだけ出現する。非削除数パラメタは，削除されなかった検索集合の数を示し，一括削

除状態パラメタは，削除されなかった検索集合の個々の状態を示す。 

ただし，受信側が，一括削除において削除されなかったすべての検索集合の状態を通知することは義務

づけられていないことに注意する。例えば，受信側は，一括削除において検索集合の削除の最初の失敗が

あった場合，一括削除処理を打切ってもよい。この場合，一括削除状態パラメタには，一つの状態だけが

含まれるのであってもよい。 

一括削除の結果複数の状態が一つの削除応答メッセージにはおさまらない場合，受信側は，おさまらな

い分を捨ててもよい。 

3.2.4.1.6 

削除メッセージ 削除メッセージパラメタは，存在すれば任意選択のテキストメッセージを含

む。 

3.2.4.1.7 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.4.1.8 

参照識別子 3.4参照。 

3.2.5 

アクセス制御機能群 アクセス制御機能群は，ただ一つのサービスであるアクセス制御サービスか

らなる。 

3.2.5.1 

アクセス制御サービス アクセス制御サービスによって受信側は，発信元へ確認を出すことがで

きる。この確認は，特定の操作又は (Z) アソシエーションに属することができる。アクセス制御要求／応

答の機構は，アクセス制御確認又は認証を実現するために使用することができる。この確認又は認証には，

パスワード確認，パブリックキー暗号システム及びアルゴリズム的認証を含む。 

アクセス制御が有効な場合，発信元は，受信側からのアクセス制御要求を受け，応答しなければならな

い。受信側は，特定の（活動中の）操作の一部分として，又は (Z) アソシエーションに属するものとして

アクセス制御要求を発行することができる。 

− 並行操作が有効な場合， 

− アクセス制御要求が参照識別子を含む場合，与えられた参照識別子は，活動中の操作と対応して

いなければならず，アクセス制御要求は，この操作の部分でなければならない。アクセス制御応

27 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

答も同様に参照識別子を含まなければならない。 

− アクセス制御要求が参照識別子を含まない場合，アクセス制御要求及び応答は，操作の一部では

なく，この (Z) アソシエーションに属する。 

− 直列操作が有効な場合，受信側は，活動中の操作があるときにだけアクセス制御要求を発効すること

ができる。アクセス制御要求とこれに続く応答は，この操作の一部分であり，この操作の参照識別子

（起動要求に参照識別子がないときは，“null” が仮定される。）を含まなければならない。 

操作に属するアクセス制御には，次の手続を適用する。 

a) 発信元は，起動要求を送った後，終了応答を受け取る前に，（その操作のための）アクセス制御要求を

受け取り，アクセス制御応答で応答し，その後で更にアクセス制御要求を受け取るなどに備えなけれ

ばならない。受信側は，アクセス制御要求を送ってからアクセス制御応答を受け取るまでの間この操

作を一時中断する。この確認は，他のいかなる操作をも中断しない。発信元の応答が受信側に受入れ

可能な場合，操作は，確認がなかったときと同じように続行する。発信元がこの確認に正しく応答す

ることに失敗した場合，受信側のこの中断された操作への終了応答は，操作がアクセス制御の失敗の

ために終了したことを示すものであってよい。 

b) 発信元が開始操作の間の確認に正しく応答することに失敗した場合，受信側は，この (Z) アソシエー

ションを拒絶してよい（この場合，開始応答の結果パラメタを “reject” にし，利用者情報フィールド

パラメタに説明的なメッセージを任意選択で付加する。）。しかし，受信側は，必ずしも (Z) アソシエ

ーションを拒絶する必要はない。例えば受信側は，開始操作中に発信元が提示した機能を使用する権

限があるかどうか決定するために，機密保護確認を呼び出してもよい。発信元が適切に応答すること

に失敗した場合，受信側は，（オプションパラメタを通して）単に特定の操作の利用を拒否するだけで

もよい。 

c) 受信側は，探索又は表示操作中に表示するレコードを準備している場合，特定のレコードに関するア

クセス制御要求を送ってもよい。発信元がこの確認に正しく応答することに失敗した場合，受信側は，

単に“機密保護確認の失敗，レコードは含まれない”という代替診断で代用してもよい。 

(Z) アソシエーションに属するアクセス制御には，次の手続を適用する。 

a) 並行操作が有効な場合，発信元は，アソシエーションの起動後操作が活動中かどうかにかかわらずい

つでも，その (Z) アソシエーションに関するアクセス制御要求を受け取り，アクセス制御応答を応答

し，その後で更にアクセス制御要求を受け取るなどに備えなければならない。 

b) 受信側は，アクセス制御要求を送った時点からアクセス制御応答を受け取るまでの間に，幾つかの又

はすべての活動中操作の処理を一時中断してもよい。発信元の応答が受信側に受入れ可能な場合，中

断した操作は，確認がなかったときと同じように続行する。 

c) 発信元がこの確認に正しく応答することに失敗した場合，受信側は，一つ以上の操作を終了し，(Z) ア

ソシエーションを終了しないというようにしてもよい。この場合，終了したすべての操作に対する受

信側の終了応答は，アクセス制御の失敗によって操作が終了したことを示す。別法として，受信側は，

(Z) アソシエーションを終了してもよい。 

28 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表7 アクセス制御サービスのパラメタ 

パラメタ 

受信側要求 

発信元応答 

機密保護確認 (security-challenge) 

○ 

− 

機密保護確認応答 

(security-challenge-response) 

○ 

− 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（適用されるとき） ○（適用されるとき） 

3.2.5.1.1. 機密保護確認及び機密保護確認応答 確認と応答の書式及び内容の定義は，登録制となってい

る。幾つかの定義が，附属書7に定義，登録されている。又は，これら二つのパラメタの内容は，受信側

／発信元の間の同意によってもよい。 

3.2.5.1.2 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.5.1.3 

参照識別子 直列操作が有効か，又は並行操作が有効であり，かつ確認が特定の操作に属する

場合，参照識別子の使用は，3.4に従う。並行操作が有効で確認が (Z) アソシエーションに属する場合，

参照識別子は，要求と応答の双方において省略される。 

3.2.6 

資源制御機能群 資源制御機能群は，次の三つのサービスからなる。 

a) 資源制御サービス。（あらゆる種類の）活動中の操作の一部分として，又は (Z) アソシエーションに

属するものとして，受信側によって呼び出される。 

b) 資源制御トリガサービス。（開始操作を除き，あらゆる種類の）活動中の操作の一部として，発信元に

よって呼び出される。 

c) 資源報告サービス。発信元によって呼び出され，資源報告操作を起動する。 

資源制御サービスによって，受信側は，資源制御要求を送ることができる。これには資源報告も含める

ことができる。この報告は，実際の資源消費又はその予測値が，同意された限界（又は受信側に設定され

た限界）を超えることを発信元に対して知らせることもできる。また，この報告によって，操作の継続に

ついての発信元の承諾を，資源制御応答を通じて求めることもできる。例えば，受信側は，探索操作を通

じて受信側上に生成された検索集合の現状について，発信元に知らせることができる。また，操作の進行

状況に関する情報を指示することもできる。 

トリガ資源制御サービスによって，発信元は，受信側に資源制御サービスの開始又は中止を要求するこ

とができる。 

資源報告サービスによって，発信元は，完了した操作又は (Z) アソシエーションに関する資源報告を送

るように受信側に要求することができる。 

3.2.6.1 

資源制御サービス 発信元は，受信側からの資源制御要求が有効な場合，それを受諾し，応答す

るようにしなければならない。受信側は，ある特定の（活動中の）操作の一部としての資源制御要求又は (Z) 

アソシエーションに属する資源制御要求を発行することができる。 

− 並行操作が有効な場合， 

− 資源制御要求が参照識別子を含む場合，与えられた参照識別子は，活動中の操作に対応していな

ければならない。この場合，資源制御要求は，操作の一部となる。資源制御応答（もしあれば）

もまた，参照識別子を含まなければならない。 

− 資源制御要求が参照識別子を含まない場合，資源制御要求と応答は，どの操作の一部分でもなく，

それらは，(Z) アソシエーションに属するものとなる。 

29 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 直列操作が有効な場合，受信側は，活動中の操作があるときだけ資源制御要求を発行することができ

る。資源制御要求と（可能な）それに続く応答は，この操作の一部であり，この操作の参照識別子（起

動要求に参照識別子がないときは，“null” が仮定される。）を含まなければならない。 

資源制御要求は，応答が必要かどうかを指示する。 

− 必要ならば，発信元は，資源制御応答を発行しなければならない。資源制御要求がある操作の一部で

あった場合，その応答も同じ操作の一部となる。受信側は，資源制御応答を待ち，その操作の処理が

終了した後で終了応答を発行する。 

− 必要でないならば，発信元は，資源制御応答を発行する必要はない。資源制御要求がある操作の一部

であった場合，受信側は，その操作の処理が終了した後で終了応答を発行する。 

発信元は，ある操作の一部としての資源制御要求（その操作が活動中の間）又は (Z) アソシエーション

に属する資源制御要求が複数の場合にも，その受信及び（条件次第での）応答に対する準備をしておくこ

とが望ましい。 

発信元が，ある資源制御要求に対する資源制御応答において，ある操作を終了するように応答する場合，

発信元は，終了応答を受け取ることを予測できる。この終了応答は，その操作が発信元の要求で終了した

ことを示しているかもしれない。しかし，そうでなく操作が終了したことを示していてもよい。受信側の

操作が継続され，資源制御応答が受信側に届く前に，その操作が完了した可能性があるためである。 

表8 資源制御サービスのパラメタ 

パラメタ 

受信側要求 

発信元応答 

資源報告 (resource-report) 

○（任意選択） 

− 

部分的結果利用可能性 

(partial-results-available) 

○（適用されるとき） − 

一時停止フラグ (suspended-flag) 

○（適用されるとき） − 

応答必要性 (response-required) 

○ 

− 

トリガ要求フラグ (triggered-request-flag)  ○（任意選択） 

− 

継続フラグ (continue-flag) 

− 

○ 

検索集合必要性 (result-set-wanted) 

− 

○（適用されるとき） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（適用されるとき） ○（適用されるとき） 

3.2.6.1.1 

資源報告 このパラメタは，サーバでの現在の資源消費及びその見積りについての情報を伝達

するのに用いてよい。資源報告書式 “resource-1” 及び “resource-2” が，附属書6で定義されている。 

3.2.6.1.2 

部分的結果利用可能性 受信側は，部分的結果利用可能性フラグを通じて検索集合の状態を示

す。そのフラグの値は，次のいずれかとする。 

− “subset” ：部分的，有効に利用できる結果あり。 

− “interim” ：部分的に利用できる結果あり，有効であるかの保証はない。 

− “none” ：検索集合なし。 

このパラメタは，探索操作の一部としてだけ意味をもつ。その値が “subset” 又は “interim” の場合，発

信元が（継続フラグを通じて）その操作を終了させることを指示し，かつ検索集合要求パラメタの値が 

“TRUE” のときは，受信側は，それに続くこの検索集合に対する表示要求を受諾する。 

部分的結果利用可能性の値が “none” の場合，発信元が（継続フラグを通じて）その操作を終了させる

ことを指示したとき，受信側は，それに続く表示要求を受諾する必要はない。 

一時停止フラグパラメタが “FALSE” である場合，探索操作の処理は継続するため，部分的結果利用可

能性の値の状況は変化することに注意する。すべての場合において，探索応答における探索状態及び検索

30 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

集合状態の値は，命令的情報として扱われることが望ましい。 

3.2.6.1.3 

一時停止フラグ このパラメタは，要求がある操作に属するときだけ有効とする。受信側が資

源制御応答を待つ間に，その操作の処理を一時停止させるかどうかを示す。このフラグは，応答必要性パ

ラメタの値が “TRUE” のときだけ出現する。 

3.2.6.1.4 

応答必要性 この要求に対する（発信元からの）応答が必要であるかどうかを，受信側が，指

定する。 

3.2.6.1.5 

トリガ要求フラグ このパラメタは，要求がある操作に属するときだけ有効とする。受信側は，

この要求が発信元による資源制御トリガ要求からのものであるかどうかを任意選択で示してもよい。 

3.2.6.1.6 

継続フラグ このパラメタは，要求がある操作に属するものであるときだけ有効とする。発信

元は，その操作の処理を受信側が継続するかどうかを指示する。 

3.2.6.1.7 

検索集合必要性 このフラグは，次のときだけ有効とする。 

− 探索操作中 

− 部分的結果利用可能性パラメタの値が，“subset” 又は “interim” であるとき 

− 継続フラグパラメタの値が，“do not continue” のとき 

このフラグの値が “TRUE” の場合，受信側は，それに続く表示操作のために，（場合によっては部分的

な）検索集合を保持しておく。このフラグの値が “FALSE” の場合，受信側は，検索集合を削除する。そ

の後の探索応答において，検索集合状態が “none” ということは，受信側が検索集合を破棄したことを示

している。すべての場合において，探索応答での探索状態と検索集合状態の値は，受信側によって行われ

た実際の決定及び探索の終了の仕方を示している。 

3.2.6.1.8 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.6.1.9 

参照識別子 3.4参照。 

3.2.6.2 

資源制御トリガサービス 発信元は，（開始操作を除く）ある操作の間に，その操作の一部とし

て資源制御トリガ要求を発行できる。このサービスは，発信元が次の事柄を受信側に望んだときの受信側

への合図として機能する。 

− 単に資源報告を送る。すなわち，応答必要性が “FALSE” である資源制御要求を発行する。 

− 完全な資源制御を呼び出す。すなわち，応答必要性が “TRUE” である資源制御要求を発行する。 

− その操作を中止する。 

受信側は，資源制御トリガ要求を受け取っても，何らかの特別な動作をする義務はない。手順の記述と

いう目的からいえば，この要求に対する応答は，存在しない。受信側が資源制御要求を発行したい場合，

一方的に行う（発信元が資源制御トリガ要求を発行し，それに続いて同一操作の一部として資源制御要求

を受け取った場合，発信元は，後者の要求が資源制御トリガ要求の結果であるかどうかを必ずしも特定す

ることはできない。ただし，受信側は，そのことを示すために資源制御要求にトリガ要求フラグを含める

ことができる。）。 

発信元が操作の中止を求める資源制御トリガ要求を発行した場合で，かつ受信側がそれを受諾したとき，

発信元は，操作が発信元の要求で終了することを示す終了応答を受け取ることを予測できる。 

発信元は，活動中の操作の一部として資源制御トリガ要求を発行しても，受信側は，その操作を終了し

た後にその要求を受け取る可能性がある。この場合，受信側は，資源制御トリガを無視することになる。

更にいえば，受信側が資源制御要求をある操作に関して発行し，その資源制御応答を待つ間に，同一操作

に属する資源制御トリガ要求を受け取る可能性もある。この場合もまた，受信側は，資源制御トリガ要求

31 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

を無視することが望ましい（一般に，受信側は，あらゆる資源制御トリガ要求を無視できることに注意す

る。）（表9参照）。 

表9 資源制御トリガサービスのパラメタ 

パラメタ 

発信元要求 

要求された動作 

(requested-action) 

○ 

要望資源報告書式 

(preferred-resource-report-format) 

○（適用されるとき）

検索集合必要性 

(result-set-wanted) 

○（適用されるとき）

その他の情報 (other-information) 

○（任意選択） 

参照識別子 (reference-id) 

○（適用されるとき）

3.2.6.2.1 

要求された動作 発信元は，次のいずれか一つを指示する。 

− “resource-report” ：資源制御要求を発行し，応答必要性を “FALSE” に設定する。 

− “resource-control” ：資源制御要求を発行し，応答必要性を “TRUE” に設定する。 

− “cancel” ：その操作を終了する。 

3.2.6.2.2 

要望資源報告書式 発信元は，望ましい資源報告書式を指定することができる。 

3.2.6.2.3 

検索集合必要性 このフラグは，探索操作に対して，かつその要求された動作が “cancel” であ

るときにだけ意味をもつ。このフラグの値が “TRUE” の場合，発信元は，受信側がそれに続く表示操作の

ために，（場合によっては部分的な）検索集合を保持することを要求する。3.2.6.1.7参照。 

3.2.6.2.4 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元が使用して

よい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.6.2.5 

参照識別子 3.4参照。 

3.2.6.3 

資源報告サービス 資源報告サービスによって，発信元は，ある特定の終了した操作，又は (Z) ア

ソシエーション全体に関して資源報告を要求することができる。 

備考 資源報告サービスは，次の点で，資源制御トリガサービスとは異なる。すなわち，資源制御ト

リガは，応答なしサービスであり，要求はあっても応答はない。その要求は，ある操作の一部

で，新しい操作を開始せず，活動中の操作に関する報告を要求する。一方，資源報告は，応答

付サービスであり，要求に対して応答が存在する（受信側は，応答の中に資源報告を含める義

務はないが，応答はしなければならない。）。その要求は一つの操作を開始し，応答はそれを終

了する。その要求は，ある完了した操作を特定し，その操作に関する報告を求める［又は，(Z) 

アソシエーション全体に関する報告を求める場合もある。］（表10参照）。 

表10 資源報告サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

要望資源報告書式 

(preferred-resource-report-format) 

○（任意選択） 

− 

操作識別子 (op-id) 

○（任意選択） 

− 

資源報告状態 (resource-report-status) 

− 

○ 

資源報告 (resource-report) 

− 

○（任意選択） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき） 

3.2.6.3.1 

要望資源報告書式 発信元は，望ましい資源報告書式を指示することができる。 

32 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.6.3.2 

操作識別子 このパラメタは，資源報告の要求の対象となる完了した操作を識別するために，

発信元が与えることができる。このパラメタは，第3版が有効なときだけ用いることができる。 

− 操作識別子が存在する場合，それは，参照識別子で，その参照識別子を用いて最も新しく完了した操

作を指す。 

備考1. 操作が終了したとき，発信元がその操作に関する資源報告要求を後に発行しようとするなら

ば，参照識別子がその間に再使用されていないかを確認するのは，発信元の責任とする。 

2. 発信元は，資源報告操作の参照識別子に，操作識別子として指定されているものと同一の値

を使ってもよい（そうしなければならないわけではない。）。その場合，操作識別子は，完了

した操作だけに属するものとなる。しかし，発信元は，この資源報告操作以外の他の活動中

の操作に対して用いられている参照識別子の値を，操作識別子値として指定しないことが推

奨される。発信元がそのようにした場合，受信側は，その要求を誤りとして考えてもよい（誤

りとしなければならない）わけではない。資源報告状態の “failure-6” 参照）。 

3. 発信元が活動中の操作についての情報を求める場合，資源報告サービスを用いるべきではな

く，その代わりに，その操作の一部としての資源制御トリガサービスを用いる。受信側が資

源制御トリガ要求を受け取る前にその操作が終了している場合，発信元は，終了応答を受け

取り，それに続いて，その（完了した）操作に関する資源報告要求を発行することができる。 

− 操作識別子が存在しない場合，発信元は，その (Z) アソシエーションに関する資源報告を要求してい

る。 

3.2.6.3.3 

資源報告状態 受信側は，次の状態値のいずれか一つを与える。 

− “success”：資源報告が含まれる（かつ，要求の中に要望資源報告書式が含まれていたならば，その要

望書式による。）。 

− “partial”：資源報告が含まれるが，要望書式ではない（要望資源報告書式パラメタが要求に含まれてい

る場合にだけ，要望書式を適用する。）。 

− “failure-1”：受信側は，資源報告を提供できない。 

− “failure-2”：資源制約のため，受信側によって操作が終了させられた。 

− “failure-3”：アクセス制御での失敗。 

− “failure-4”：特定されない失敗。 

− “failure-5”：指定された識別子に対して既知の操作がない。 

− “failure-6”：指定された識別子に対して活動中の操作が存在する。 

備考 “failure-5” と “failure-6” は，第3版が有効なときだけ適用される。 

3.2.6.3.4 

資源報告 3.2.6.1.1参照。 

3.2.6.3.5 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。このパラメタは，第3版が有効なときだけ使用してもよい。 

3.2.6.3.6 

参照識別子 3.4参照。 

3.2.7 

並び替え機能群 並び替え機能群は，ただ一つのサービスである並び替えサービスからなる。 

3.2.7.1 

並び替えサービス 並び替えサービスによって，発信元は，受信側にある検索集合の並び替え（又

は複数の検索集合の併合とその後の並び替え）を要求できる。発信元は，並び替え用要素の列を指定する。

検索集合は，指定された順序に並び替えられる。これ以降，受信側は，その検索集合中の項目位置による

要求を，並び替えられた検索集合に対して適用する。 

33 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表11 並び替えサービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

入力検索集合 (input-result-set) 

○ 

− 

並び替えられた検索集合 

(sorted-result-set) 

○ 

− 

並び替え順序 (sort-sequence) 

○ 

− 

並び替え状態 (sort-status) 

− 

○ 

検索集合状態 (result-set-status) 

− 

○（適用されるとき） 

診断 (diagnostics) 

− 

○（適用されるとき） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき） 

3.2.7.1.1 

入力検索集合 このパラメタは，並び替えられる検索集合の名前，若しくは併合される検索集

合と並び替えられたその結果の名前を指定する。 

3.2.7.1.2 

並び替えられた検索集合 このパラメタは，並び替えられた検索集合の名前を指定する。現存

する検索集合の名前でもよい（複数の入力検索集合の名前の一つでもよい。）。この場合，並び替え処理の

後，既存の検索集合は削除され，その名前による新しい検索集合が，作成される。すなわち，その内容は，

並び替えの結果となる。並び替えられた検索集合が既存の検索集合の名前でない場合，その並び替え処理

の後，指定された名前による検索集合が受信側によって作成され，その内容が，並び替えの結果となる。

すなわち，入力検索集合の内容は，そのまま変えられずに残される。どちらの場合でも，並び替え処理が

行われないならば，並び替えられた検索集合の最終的な内容は，検索集合状態パラメタによって示される。 

3.2.7.1.3 

並び替え順序 並び替え順序パラメタは，並び替えに使用される要素，及び順序の方向（昇順

又は降順），（適用可能な場合）大文字と小文字の区別，要素が並び替えられた検索集合中のレコードから

欠損していた場合の受信側の処置からなる。並び替え用各要素は，受信側が並び替えキーとして用いるこ

とができると指示した属性の集合，並び替えフィールド指示子，又は要素指定とする。 

備考 受信側は，説明機能群又はこの規格外の機構を通じて，この情報を指定する。 

3.2.7.1.4 

並び替え状態 受信側から戻される並び替え状態パラメタは，次にあげる値のいずれかをとる

ことを想定している。 

− “success”：並び替えは，首尾よく実行された。 

− “partial-1”：一つ以上の並び替え用要素の値が欠落するレコードがあったが，並び替えは，実行された。 

− “failure”：並び替えは，実行されなかった。受信側は，診断パラメタに，一つ以上の診断を提供する。 

3.2.7.1.5 

検索集合状態 並び替え状態が “failure” の場合に限り，受信側が，このパラメタを提供する。

並び替えられた検索集合の内容を対象とし，値は，次のいずれかをとる。 

− “empty”：検索集合が，空である。 

− “interim”：部分的に利用できる結果あり，有効であるかの保証はない。 

− “unchanged”：検索集合の内容は，変わっていない（並び替えられた検索集合が入力検索集合の一部の

場合に限り適用される。）。 

− “none”：検索集合が，作成されていない（並び替えられた検索集合が入力検索集合の一部でない場合

に限り適用される。）。 

3.2.7.1.6 

診断 並び替え状態が "failure" の場合，受信側は，このパラメタを含める。これには，一つ以

上の診断レコードが含まれる。 

34 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.7.1.7 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。 

3.2.7.1.8 

参照識別子 3.4参照。 

3.2.8 

通覧機能群 通覧機能群は，ただ一つのサービスである走査サービスからなる。 

3.2.8.1 

走査サービス 走査サービスは，順序付けられた用語リスト（主題語，名前，タイトルなど）を

走査するために用いられる。用語リストの順序は，受信側で定義される。発信元は，走査すべき用語リス

ト及び開始語（暗黙的に，属性・用語の組合せ，及びデータベース識別子を特定することによって），走査

増分量，要求項目数，並びに応答における開始語の位置を指定する（表12参照）。 

表12 走査サービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

データベース名 (database-names) 

○ 

− 

用語リスト及び開始位置 

(term-list-and-start-point) 

○ 

− 

増分量 (step-size) 

○（任意選択） 

○（適用されるとき） 

項目数 (number-of-entries) 

○ 

○ 

応答位置 (position-in-response) 

○（任意選択） 

○（任意選択） 

走査状態 (scan-status) 

− 

○ 

項目 (entries) 

− 

○（任意選択） 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき） 

3.2.8.1.1 

データベース名 データベース名パラメタは，用語リスト（用語リスト及び開始位置で指定さ

れたもの）が属するデータベースの集合を特定する。 

3.2.8.1.2 

用語リスト及び開始位置 発信元は，属性リストと用語を与える。属性リストは，どの用語リ

ストを走査すべきかを示す属性からなる。これらの属性によって修飾された用語は，どこから走査を始め

るかを示し，これが用語リストの項目の一つとなることが想定される。該当する項目がない場合，より高

い値をもつ最初の項目が開始点となる。 

例として個人名リストを走査する場合をあげる。属性リストを型が “use” で値が “personal name” の属

性とし，用語にある人の個人名を指定し，データベース識別子に個人名リストが属する一つ以上のデータ

ベースを指定すればよい。 

3.2.8.1.3 

増分量 発信元は，用語リスト中の用語を希望語数飛ばして，応答中の隣り合う用語とするよ

う指定できる。値ゼロは，“用語を一つも飛ばさない”を意味する。受信側が要求された増分量に応えられ

ない場合，受信側は，走査状態を “failure” にし，“増分量はゼロだけ利用可能”又は“要求された増分量

は利用可能でない”のような非代替診断を含める。発信元がこのパラメタを省略した場合，受信側が増分

量を選択し，選ばれた増分量を応答に含める。 

3.2.8.1.4 

項日数 発信元は，返される項目の数を提示する。受信側は，実際に返される項目数を示す。

実際に返される項目数が提示した数より少ない場合，その理由は，走査状態に示される。 

3.2.8.1.5 

応答位置 発信元は，指定した開始位置の値の，返される項目中での要望位置を任意選択で指

示してもよい。値1は，返される項目の最初をさす。値ゼロは，返される項目が開始位置語の直後の用語

から始まることを意味する。値が項目数＋1の場合，発信元は，開始位置語の直前の用語までを要求した

ことを意味する。 

受信側は，返される項目の中，選択した開始点の実際の位置を示してもよい。 

例えば，要求パラメタの項目数が10，応答位置が3の場合，発信元は，開始位置の値の直前の2語，続

35 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

いて開始位置の値，更に続いて直後の7つの語を要求している。 

備考 応答パラメタでの応答位置が要求時に提示した値未満の場合，発信元は，用語リストの前方に

は期待より少ない語しかなかったと判断してよい。しかし，応答位置の値が応答時と要求時の

提示とで等しいのに，応答時の項目数パラメタが要求時に提示した値未満の場合，発信元は，

走査状態の値が “partial-5” でない限り，用語リストの後方に期待より少ない語しかないと判断

してはいけない。期待より少ない用語が返された理由は，走査状態に示されている。 

3.2.8.1.6 

走査状態 受信側は，操作の結果を示す。定義されている値は，次のとおり。 

− “success”：応答には要求された数の項目（用語リスト項目又は代替診断）を含む。 

− “partial-1”：操作がアクセス制御によって終了したため，期待された項目すべてを返すことはできない。 

− “partial-2”：期待された項目すべてを応答メッセージに入れることができなかった。 

− “partial-3”：操作が発信元要求の資源制御によって終了したため，期待された項目すべてを返すことは

できない。 

− “partial-4”：操作が受信側の資源制御によって終了したため，期待された項目すべてを返すことはでき

ない。 

− “partial-5”：用語リストが要求された用語より少ない項目数（用語リストの先頭，最後，又は，その両

方）しかなかったため，期待された項目すべてを返すことはできない。 

− “failure”：期待された項目が，全く返されない。一つ以上の非代替診断が，返される。 

3.2.8.1.7 

項目 受信側によって返される項目パラメタは，次のいずれかとする。 

− N項目。ここで，Nは，要求の項目数。各項目は，用語リスト項目又は代替診断。 

− Nよりも少ない項目。ゼロもありうる（理由は走査状態で指定。）。 

次のものを含むこともある。 

− 一つ以上の非代替診断レコード（操作が処理できないこと，及びその理由を示すこともある。）。 

各用語リスト項目は，（データベース名パラメタで指定されたデータベースに出現する）一つの用語，及

び任意選択で次のものを含む。 

− 一つの表示用語（実際の用語が表示に適さないと受信側が判断した場合。）。 

− 走査要求結果使用のための推奨属性リスト（複数の索引，例えば同時に著者とタイトルを走査する場

合に有用。）。 

− 推奨代替用語。 

− 出現情報。これには，その用語が出現したレコードの総計を含んでもよい。また，特定の属性ごとの

出現数をリストしてもよいし，さらに，これを個々のデータベースごとに分けてリストしてもよい。

又は，出現数を出さず，用語が出現したデータベース，その出現した属性をリストしてもよい。 

− その他の情報，項目に関連する付加情報。 

3.2.8.1.8 

その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。 

3.2.8.1.9 

参照識別子 3.4参照。 

3.2.9 

拡張サービス機能群 拡張サービス機能群は，ただ一つのサービスである拡張サービスサービスか

らなる。 

3.2.9.1 

拡張サービスサービス 拡張サービス (ES) サービスによって発信元は，受信側のタスクパッケ

ージを作成，変更，削除することができる。受信側は，3.2.9.2で示すとおり特別なデータベースを維持し

ている。タスクパッケージは，ESタスクに属する。 

36 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

拡張サービスは，タスク型であり，情報検索に関係するが，Z39.50サービスとしては定義されない。受

信側によるタスク実行はこの規格の範囲外とする。この規格で定義した拡張サービスは，3.2.9.1.2にリス

トされている。それらのサービス定義は，附属書8に示す。 

発信元は，ES要求を受信側に送りタスクを実行するよう要求する。その要求には，受信側がタスクパッ

ケージを構築するためのパラメタを含む。受信側は，要求の妥当性，利用者のアクセス特権の整合性，ま

た，その他受信側依存の制限事項があれば，それを検査する。受信側は，要求が受諾されたことを示すか，

又は，要求が拒絶された理由を示すES応答を送信する。 

ESサービスは，発信元によって起動される応答付サービスとする。ES操作は，発信元からの要求と受

信側からの応答とからなり，アクセス制御又は資源制御メッセージがその間に入ることもある。要求の結

果は，タスクの起動になることもあるが，タスク自体は，Z39.50ES操作の一部とはみなされない。受信側

の応答は，ES操作を完了させるが，必ずしもタスクの完了を知らせるものではない。タスクは，単一の

Z39.50アソシエーションを超える寿命をもつことがある。 

ES操作の実行の結果は，タスクパッケージの作成となるが，タスクパッケージは，ESデータベースの

データベースレコードによって表される。 

例えば，受信側が “PersistentResultSet”（持続性検索集合）型のタスクパッケージを作成した場合，（持

続性）検索集合が作成されるが，これは，拡張サービスデータベース中のレコードという形態をとって作

成されたタクスパッケージとして表現される。このタスクパッケージが発信元によって同一又は別の (Z) 

アソシエーション中で検索された場合，この持続性検索集合のコピーが，その (Z) アソシエーションに利

用可能なように作られ，Z39.50検索集合とされる［これは，一時的な検索集合であり，その (Z) アソシエ

ーションの間使われる検索集合名は，タスクパッケージ内に含まれる。］。発信元がタスクパッケージを削

除した場合，その持続性検索集合も削除される。 

タスクパッケージは，パラメタを含む。その幾つかは，パッケージタイプが何であれすべてのタスクパ

ッケージに共通であり，他のものは，特定の拡張サービスに特有のものからなる。共通パラメタの中には，

発信元がES要求のパラメタとして供給し，受信側がタスクパッケージを作るために使うもの（表13の右

欄“タスクパッケージパラメタ”の下にリストされている。）がある。発信元の供給したものは，受信側が

書き換える場合もある。他のパラメタは，受信側が供給する。特有の幾つかのパラメタは，ES要求のパラ

メタであるタスク特有パラメタによって供給される［附属書8（規定）参照］。 

備考 表13にあげた応答パラメタのタスクパッケージは，実タスクを参照しており，それが存在した

場合（3.2.9.1.13参照）“タスクパッケージパラメタ”欄の下に記したパラメタの幾つか，又は

すべて（要素パラメタに依存）を含む。 

37 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表13 拡張サービスサービスのパラメタ 

パラメタ 

発信元要求 

受信側応答 

タスクパッケージパラメタ 

機能 (function) 

○ 

− 

− 

パッケージ型 (package-type) 

○ 

− 

− 

パッケージ名 (package-name) 

○（任意選択） 

− 

○（任意選択） 

利用者識別子 (user-id) 

○（任意選択） 

− 

○（任意選択） 

保留時間 (retention-time) 

○（任意選択） 

− 

○（任意選択） 

許可 (permissions) 

○（任意選択） 

− 

○（任意選択） 

記述 (description) 

○（任意選択） 

− 

○（任意選択） 

受信側参照 (target-reference) 

− 

− 

○（任意選択） 

作成日時 (creation-date-time) 

− 

− 

○（任意選択） 

タスク状態 (task-status) 

− 

− 

○ 

パッケージ診断 

(package-diagnostics) 

− 

− 

○（任意選択） 

タスク特有パラメタ 

(task-specific-parameters) 

○ 

− 

* 

待ち動作 (wait-action) 

○ 

− 

− 

要素 (elements) 

○（適用されるとき） − 

− 

操作状態 (operation-status) 

− 

○ 

− 

操作診断 (operation-diagnostics) 

− 

○（適用されるとき） − 

タスクパッケージ 

(task-package) 

− 

○（適用されるとき） − 

その他の情報 

(other-information) 

○（任意選択） 

○（任意選択） 

− 

参照識別子 (reference-id) 

○（任意選択） 

○（適用されるとき） − 

注* 

タスク特有パラメタは，拡張サービスごとに定義される。各定義の中でタスクパッケージ内にこのパラ
メタが出現するかどうかを宣言する。 

3.2.9.1.1 

機能 発信元は，“create”（作成），“delete”（削除）及び “modify”（変更）を指定する。 

機能が作成の場合，受信側は，タスクパッケージを作成し，パッケージ名パラメタで指定した名前（も

しあれば）をつける。 

機能が削除又は変更の場合，受信側は，パッケージ名パラメタで指定されたタスクパッケージを削除，

変更する。受信側が削除，変更を可能としていても，なお要求を拒否することがある。例えば，タスクが

既に進行している，パッケージが使用中などの理由からである。 

機能が削除の場合，発信元の要求は，指定したタスクが動いていないときは，それを始動させず，タス

クが活動中のときは，受信側がタスクを打切るか要求を拒否する，ということになる。 

機能が変更の場合，発信元の要求は，タスクパッケージ内の対応する値を，この要求のパラメタの値（タ

スク特有パラメタ内のものも含む。）で置き換えるということになる。任意選択のパラメタが省略されたと

き，受信側は，タスクパッケージ内のパラメタを変更しない（したがって，省略値にもどすためには，発

信元は，明示的に省略値を与えなければならない。）。 

3.2.9.1.2 

パッケージ型 パッケージ型は，要求する拡張サービスを特定する。この規格（附属書8）で

定義されている拡張サービスには，次のものがある。 

− 後に使用するための検索集合の保存 

− 後に使用するための問合せの保存 

− 定期的な探索スケジュール定義 

− 発注 

38 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− データベースの更新 

− 送出指定の作成 

− 以前に作成された送出指定の呼出し 

3.2.9.1.3 

パッケージ名 発信元は，作成されるタスクパッケージに名前を付けてもよい。その場合，三

つ組（パッケージ型，利用者識別子及びパッケージ名）は，一意でなければならない（すなわち，同じ型

で同じ利用者の同じ名前のタスクパッケージは，他に存在してはならない。一意でない要求は，誤りとな

る。）。この三つ組は，その後の参照でタスクパッケージを識別する。発信元がタスクパッケージを参照し

ようとする場合，パッケージ名パラメタを含むことが望ましい。 

3.2.9.1.4 

利用者識別子 利用者識別子は，タスクパッケージと結びついた利用者を識別する。与えられ

ない場合，現在の利用者の識別子をこのパラメタの省略値としてもよい。受信側は，発信元が自身のもの

と異なる利用者識別子を使用するのを許可してもしなくてもよい。 

3.2.9.1.5 

保留時間 発信元は，任意選択で保留期間（例えば2時間，3日，一週間など）を指定できる。

受信側は，この値を書き換えてもよい。保留時間が経過した場合，受信側は，保持していたタスクパッケ

ージを削除してもよい。保留時間ゼロは，タスクが完了した後タスクパッケージは保持されない，という

ことを意味する。 

3.2.9.1.6 

許可 発信元は，だれがタスクパッケージにアクセスしてよいか指示できる。発信元がこのパ

ラメタを供給しない場合，作成利用者だけが，アクセスできる（3.2.9.3参照）。 

3.2.9.1.7 

記述 発信元は，記述パラメタを含めてよい。このパラメタは，例えば，持続性検索集合タス

クに対して検索集合，持続性問合せタスクに対して問合せと記述するなどしてよい。 

3.2.9.1.8 

受信側参照 受信側は，タスクパッケージに対して一意の識別子を提供してもよい。 

3.2.9.1.9 

作成日時 受信側は，タスクパッケージが作成された日時を提供する。 

3.2.9.1.10 タスク状態 受信側は，タスクの状態を指示できる。値は，“pending”（実行待），“active”（活

動中），“complete”（完了）及び “aborted”（中止）とする。 

3.2.9.1.11 パッケージ診断 受信側は，タスクパッケージ中に一つ以上の診断を含めてもよい。 

3.2.9.1.12 タスク特有パラメタ 特有の拡張サービスで定義された付加的なパラメタ。 

3.2.9.1.13 待ち動作 発信元は，受信側がES応答にタスクパッケージを含むべき（含んでもよい）かどう

かを指示する。この即時応答機構により，おって探索，表示操作を行う必要性を回避できる。また，一般

的には，タスクパッケージを拡張サービスデータベース（3.2.9.2参照）を通して利用可能とする必要性が，

回避できる。 

このパラメタは，四つの値をとりうる。 

− “wait”（待ち）：受信側は，ES応答を発行する前に（3.2.9.4参照の操作打切りでない限り）タスクを

実行しなければならない。受信側が応答を発行する前にタスクを実行したくない場合は，failure状態

及び適切な診断をもって要求を拒否しなければならない。受信側が要求を受け付けた場合，応答にタ

スクパッケージパラメタを含める。 

− “wait-if-possible”（可能なら待ち）：発信元は，受信側が，可能な場合，ES応答を発行する前にタスク

を実行させ，応答にタスクパッケージを含めるよう要求する。可能でない場合，受信側は，値が “do not 

wait”（待ちなし）であるかのように実行する。 

− “do-not-wait”（待ちなし）：発信元は，受信側がES応答を発行する前にタスクを実行しようとするこ

とを要求しない。ただし，受信側が応答を発行する前にタスクを実行した場合，応答の中にタスクパ

ッケージが，含まれてもよい。 

39 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− “do-not-send-task-package”（タスクパッケージ送信不可）：受信側は，受信側の選んだ時点にタスクを

実行する。どのような状況でも，応答にタスクパッケージは含まない。 

3.2.9.1.14 要素 待ち動作が “do-not-send-task-package” 以外の場合，発信元は，このパラメタを任意選択

で含むことができる。これは，応答中のタスクパッケージパラメタとして返される場合の，そのタスクパ

ッケージに対する要素集合名とする。 

3.2.9.1.15 操作状態 これは，ES操作の状態で，次のいずれかをとる。 

− “done”：要求は，受諾された。タスクは，完了し，結果は，タスクパッケージパラメタに含まれる。 

− “accepted”：要求は，受諾された。タスクは，処理待ち又は処理中である。 

− “failure”：要求は，拒絶された。一つ以上の診断が，（操作診断パラメタで）与えられる。 

3.2.9.1.16 操作診断 操作状態が “failure” の場合，受信側は，追加の診断情報を提供してもよい。 

3.2.9.1.17 タスクパッケージ 操作状態が “done” の場合，受信側は，タスクパッケージを含む。実際の

タスクパッケージのどの部分を含むかは，要素パラメタによる。 

3.2.9.1.18 その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。 

3.2.9.1.19 参照識別子 3.4参照。 

3.2.9.2 

拡張サービスデータベース 拡張サービス機能群を提供する受信側は，“IR-Extended-1”（拡張サ

ービスデータベース又はESデータベースと呼ぶ。）の名前でデータベースへのアクセスを提供する。拡張

サービスデータベースの中のレコードは，ES要求の中のタスクパッケージパラメタから作られるタスクパ

ッケージとする（受信側は，要求を受け付けた後，いつタスクの実行を開始してもよい。データベースに

タスクパッケージを記憶する前であってもよい。）。受信側は，要求されたタスクが完了するまでタスクパ

ッケージを保持してもよいし（保持しなければならないわけではない。），発信元が削除を要求するまでタ

スクパッケージを保持してもよい。受信側は，いつでもESデータベースから一方的にタスクパッケージ

を削除してよい。 

備考 実際問題として，受信側は，タスクが即座に実行される場合は特に，タスクに対してタスクパ

ッケージを作成する必要がないことを意味している。しかし，タスクの状態が “pending”，

“active” 又は “aborted” の場合，タスクパッケージが存在することが望ましい。 

受信側は，ES要求を受け取って要求の妥当性検証がすべて終わるより前，直ちにタスクパッケージを 

“pending” の状態として作成してもよい。このようにすれば発信元は，要求を渡した後［同一又は後続の (Z) 

アソシエーション中］いつでも，データベースからそのタスクパッケージを探索できる。特に，ES操作が

打切られた（3.2.9.4参照）場合でも，発信元は，その操作に対する要求が受け取られたと判断することが

できる。 

受信側の説明データベースの中に，受信側が提供する拡張サービスのリスト，許されうる送出先，発信

元が送出タスクに与えるオプションなどとともに，ESデータベースをリストしてもよい。 

拡張サービスデータベースは，受信側の提供する他のデータベースと同じように発信元に見える（その

レコードは，Z39.50の探索及び検索機能群によって探索や検索ができ，探索処理は，受信側によって局所

的に定義され，受信側は，アクセス制御を課したり発信元がアクセスを許可されていないレコードを除外

してもよい。）。ただし，意味的なレベルでの相互運用性を確保するため，幾つかの探索語があらかじめ定

義されている。データベースを探索するために使われる属性集合は，附属書3（規定）で定義し登録して

いる。タスクパッケージの構造は，附属書8（規定）で定義し登録している。 

ESデータベースは，次の特別の要素集合（“F” に加えて）を提供することができる。 

40 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− “Identification”：タスクパッケージ作成者の利用者識別子，発信元が付けたタスクパッケージの名称，

及び他の利用者に対するアクセス要求の許可を含む。作成時刻など他の識別用情報を含んでもよい。 

− “UniqueName”：作成者の利用者識別子及びタスクパッケージ名 

− “Permissions”：“UniqueName” 要素集合の内容に加えてタスクパッケージに関して与えられた許可。受

信側は，タスクパッケージの作成者だけに完全な許可リストを提供し，他の利用者に対しては，彼ら

に与えられている許可だけのリストを提供するようにしてもよい。 

− “Status”：要求の現在の状態の短い要約で，場合によっては，料金及び他の資源の使用量を含む。 

− “Brief”：“Identification” 要素集合に加えて “Status” 要素集合の最も重要な要素群を含む。 

3.2.9.3 

所有者及び許可 タスクパッケージの作成利用者は，パッケージ全体の（検索機能群を通じての）

検索及び他の拡張サービスを通じてパッケージを呼び出すのと同様に，そのパッケージに対するどのよう

な拡張機能も適用できる［パッケージの呼出は，例えば，定期問合せ (Periodic Query) タスクが保存され

ている問合せを参照したときに生じる。］。 

ES要求の修正機能を使って，発信元は，新しい許可リストを提供し，タスクパッケージのアクセス許可

を変えることができる。許可リストは，ユーザ識別子の並びで，その各ユーザ識別子について次に示すう

ちから許される操作を列挙したものとする。 

− 削除 (delete) 

− 内容の修正 (modify-contents) 

− 許可の修正 (modify-permissions) 

− 表示 (present) 

− 呼出し (invoke) 

呼出し許可の使用例として，受信側は，クライアント利用者のため持続性問合せ (PersistentQuery) 型の

タスクパッケージを作成する場合を考える。持続性問合せが，それを表すタスクパッケージによって作成

される。引き続いて受信側は，この持続性問合せタスクパッケージを参照する（呼び出す）定期問合せス

ケジュール (PeriodicQuerySchedule) 型のタスクパッケージを異なる利用者のために作成することを要求

されるかもしれない。受信側は，この利用者が，その持続性問合せに対する呼出し権限をもっているとき

だけ作成を行う。もう一つの例として，受信側がある利用者のために送出仕様 (ExportSpecification)（パッ

ケージ）を作成した場合をあげる。その後，異なる利用者は，その送出仕様に対する呼出し権限をもって

いれば，送出仕様呼出 (InvokeExportSpecification) パッケージを作成してその送出仕様を呼び出すことがで

きる。 

受信側は，許可リストの中でグループ名を指定してもよい。グループ名は，文法的には利用者識別子と

同じとする（受信側は，グループの構成を報告してもよいが，そのための機構は，この規格では規定しな

い。）。 

3.2.9.4 

打切り操作 発信元は，（他のどんなZ39.50操作とも同じく）要求を発行した (Z) アソシエーシ

ョンの中でだけES要求に対する応答を受け取る。ES操作が［明示的に，又は (Z) アソシエーションが閉

じられたため又は (A) アソシエーションが終了したために］打ち切られた場合，発信元は，終了応答を受

け取らない。このことは，要求での待ち動作パラメタの値にかかわらず，タスクの処理又は処置に何の影

響も及ぼさない。ES操作が打ち切られた場合，待ち動作は，自動的に値 “do-not-send-task-package” が仮

定される。 

ES操作が打ち切られた場合，発信元は，応答の中で戻されるはずだった情報を得るために［場合によっ

ては，後続する (Z) アソシエーションの中で］ESデータベースを検索することができる。 

41 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.10 説明機能群 説明機能群によって発信元は，探索可能なデータベース，受信側が使用する属性集合

及び診断集合，検索のためのスキーマ・レコード構文・要素指定の定義などの，受信側での実装の詳細を

得ることができる。説明機能群を実現する受信側は， 

− “IR-Extended-1”（説明データベースと呼ぶ。）の名前でデータベースへのアクセスを（Z39.50探索及び

表示サービスを通じて）提供する。 

− 附属書3（規定）で定義されている説明属性集合 “exp-1”（“Use” 型の属性集合を定義し，属性集合 

“bib-1” の “Use” 以外の属性を輸入している。）を利用可能とする。さらに， 

− 附属書5（規定）に定義登録されている “Explain” 構文を利用可能とする。 

説明データベースの中のレコード（又はレコードを表す検索集合項目）は，説明レコードと呼ぶ。 

3.2.10.1 説明データベースの探索 説明データベースは，受信側によって提供されるその他のデータベー

スと同じように見える。ただし，意味的なレベルでの相互運用性を確保するため，幾つかの探索語が，情

報の区分に応じてあらかじめ定義されている。探索語では大小文字を区別する。 

“exp-1” 属性集合は，説明データベースの探索に使う。“Use” 属性と用語の組合せによって情報区分を

探すことができる。発信元は，“Use” 属性の明確に定義された組合せによって，より細かい指定をし，直

接興味のあるレコードに限定することもできる。“exp-1” “Use” 属性の探索の共通集合を実行する組合せは，

3.2.10.1.1及び3.2.10.1.4に列挙されている。説明データベースは，他のデータベースと同じように一つ以

上の属性集合からの属性を使って探索することができるため，このリストは，すべてを尽くしているわけ

ではない。しかし説明機能群を提供する受信側は，このリストにある共通探索を実現することが望ましい。

3.2.10.1.2及び3.2.10.1.3に示されているように，“HumanStringLanguage”，“DateAdded”，“DateChanged” 及

び “DateExpires” の属性は，3.2.10.1.1及び3.2.10.1.4に列挙されているいかなる組合せに対しても，これ

らの属性を組み合わせて使用してよい。 

“exp-1” 属性集合は，“Use” 型の属性集合を定義し，属性集合 “bib-1” の “Use” 以外の属性を輸入して

いる。説明機能群を提供する受信側は，“bib-1” の “Relation” 属性 “equal”（備考参照），“Position” 属性 “any 

position infield” 及び “Structure” 属性 “key” を実現することが望ましい。 

備考 受信側が日付の範囲（特定の日付より以前若しくは以後，又は二つの日付の間に作成されたレ

コードに検索を限定する。）を実現しようとする場合，“less than”，“less than or equal”，“greater 

than”，“greater or equal” のうち一つ以上の “Relation” 属性も実現することが望ましい。 

発信元は，一般的には，説明データベースを “bib-1 の “truncation” 属性，“Completeness” 属性，又は 

“Relation”，“Position”，“Structure” の属性の上記以外のものを使って検索できると期待しないほうがよい。

しかし，受信側がこれら並びに他の属性及び属性値を使った説明データベースへのアクセスを提供するこ

とは自由とする。 

3.2.10.1.1 あらかじめ定義された情報区分の検索 特定の説明情報区分に対するレコードは，その区分の

名称を用語としたオペランドによって探索する。例えば，区分 “TargetInfo” に対するすべてのレコードは，

“TargetInfo” という用語を使って探索する。各区分には，一つ以上のキー要素が定義されており，（適切な

属性のもとで）探索用語として提供されているかもしれない。“Use” 属性が “ExplainCategory” で用語が

区分であるオペランドによる探索と，“Use” 属性の値がキーでその区分の各キーに対応した付加オペラン

ドによる探索結果は，（多くても）1レコードとなる。 

説明データベースから情報を探索・検索する基本的な機構は，発信元が “Use” 属性 “Explain Category” 

を使ってある区分のレコードを選択し，これらのレコードから必要な情報を取り出して後続する探索を組

み立てることによる。例えば，発信元は，“Explain Category” の用語 “DatabaseInfo” でレコードを探索し，

42 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

これらのレコードから要約情報（3.2.10.2.2参照）を検索することができる。各要約レコードは，データベ

ース名を収録しており，これをキーとして後続する探索を行うこともできる。 

表14に説明情報区分（及び探索用語）のリスト及び簡単な説明，並びに各区分のキーを示す。3.2.10.3

に各区分の詳細を示す。 

発信元は，あらかじめ定義された情報区分によって説明データベースを探索するとき，次の規則を守っ

たほうがよい。 

− 受信側についての情報を探索するには，“ExplainCategory”＝“TargetInfo” を使用する。 

− 特定のデータベースについての情報を探索するには，“ExplainCategory”＝“DatabaseInfo” と組み合わせ

て “DatabaseName” 属性に必要な “DatabaseInfo” レコードのキーを指定する。 

− 特定のスキーマについての情報を探索するには，“ExplainCategory”＝“SchemaInfo” と組み合わせて 

“SchemaOID” 属性に必要なスキーマを指定する。 

− 特定のタグ集合についての情報を探索するには，“ExplainCategory”＝“TagSetInfo” と組み合わせて 

“TagSetOID” 属性に必要なタグ集合を指定する。 

− 特定のレコード構文についての情報を探索するには，“ExplainCategory”＝“RecordSyntaxInfo” と組み合

わせて “RecordSyntaxOID” 属性に必要なレコード構文を指定する。 

− 特定の属性集合についての情報を探索するには，“ExplainCategory”＝“AttributeSetInfo” と組み合わせ

て “AttributeSetOID” 属性に必要な属性集合を指定する。 

− あるデータベースに対する用語リストについての情報を探索するには，“ExplainCategory”＝

“TermList-Info” と組み合わせて “DatabaseName” 属性に必要なデータベース名を指定する。 

− 特定の拡張サービスについての情報を探索するには，“ExplainCategory”＝“ExtendedServicesInfo” と組

み合わせてその拡張サービスに対する “oid” を使用する。 

− あるデータベースの探索に使える属性及び属性の組合せを探索するには，“ExplainCategory”＝

“AttributeDetails” と組み合わせて “DatabaseName” 属性に属性情報を希望するデータベース名を指定

する。 

− 特定の用語リストについての情報を探索するには，“ExplainCategory”＝“TermListDetails” と組み合わ

せてその用語リスト名前を使用する。 

− あるデータベースのレコード構文に対して定義された要素集合名を探索するには，“ExplainCategory”

＝“ElementSetDetails”と組み合わせて “RecordSyntaxOID” 属性に希望するレコード構文を指定し，

“DatabaseName” 属性に希望するデータベース名を指定する。 

− 特定の要素集合名の定義を探索するには，“ExplainCategory”＝“ElementSetDetails” と組み合わせて 

“ElementSetName” 属性に希望する要素集合名を指定する。この結果は，複数のレコードとなるかもし

れない。説明データベースは，各データベースの各レコード構文の各要素集合名ごとに1レコードを

含むためである。 

− あるデータベースのレコード構文に対して定義されたある要素集合名を探索するには，

“ExplainCategory”＝“ElementSetDetails”と組み合わせて “ElementSetName” 属性に希望する要素集合名

を指定し，“RecordSyntaxOID” 属性に希望するレコード構文を指定し，“DatabaseName” 属性に希望す

るデータベース名を指定する。 

− あるデータベースの特定のスキーマのあるレコード構文で検索したレコードの要素の記述を探索する

には，“ExplainCategory”＝“RetrievalRecordDetails” と組み合わせて “RecordSyntaxOID” 属性に希望す

るレコード構文を指定し，“SchemaOID” 属性に必要なスキーマを指定し，“DatabaseName” 属性に希

43 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

望するデータベース名を指定する。 

表14 説明区分 

区分 

その区分の説明レコードの内容 

キー 

受信側情報 (Target-Info) 

受信側。探索制約を含む。 

受信側名 
(target name) 

データベース情報 
(Database-Info) 

データベース。利用可能な問合せ型，属性集合，レコー
ド構文，スキーマ，診断集合，資源制御書式，及びアク
セス制御書式の情報。性質の同じデータベースのグルー
プを論理的に一つのデータベースとして記述してもよ
い。この場合，このグループに含まれるデータベース名
のリストも供給する。 

データベース名 
(database name) 

スキーマ情報 
(Schema-Info) 

スキーマ。 

スキーマOID 
(schema oid) 

タグ集合情報 
(Tag-Set-Info) 

タグ集合。 

タグ集合OID 
(tagSet oid) 

レコード構文情報 
(Record-Syntax-Info) 

レコード構文。 

レコード構文OID 
(recordSyntax oid) 

属性集合情報 
(Attribute-Set-Info) 

属性集合。その中で受信側がどの属性が利用可能かを含
む。 

属性集合OID 
(attributeSet oid) 

用語リスト情報 
(TermList-Info) 

データベースの中で実現されている用語リスト。 

データベース名 
(database name) 

拡張サービス情報 
(Extended-Services-Info) 

拡張サービス。 

拡張サービスOID 
(extended service oid) 

属性詳細 
(Attribute-Details) 

データベース探索に使える属性。組み合わせて使える他
の属性を含む。 

データベース名 
(database name) 

用語リスト詳細 
(Term-list-Details) 

用語リスト。 

用語リスト名 
(termList name) 

要素集合詳細 
(Element-Set-Details) 

（特定のデータベースの特定のレコード構文用の）要素
集合。 

データベース名 
(database name)， 
要素集合名 
(elementSet name)， 
レコード構文OID 
(recordSyntax oid) 

検索レコード詳細 
(Retrieval-Record-Details) 

（特定のスキーマで定義された特定のレコード構文用
の）検索レコードの要素。 

データベース名 
(database name)， 

スキーマOID 
(schema oid)， 

レコード構文OID 
(recordSyntax oid) 

並び替え詳細 
(Sort-Details) 

データベース用の並び替え仕様。 

データベース名 
(database name) 

処理情報 
(Processing-Info) 

データベースのある処理文脈用の処理命令，命令の名前，
外部で定義された命令の抽象構文のオブジェクト識別
子。 

データベース名 
(database name)， 
処理文脈名 
(processingContext 
name)，OID 

選択可能形集合情報 
(Variant-set-Info) 

選択可能形集合定義（受信側が提供している特定の選択
可能形集合のクラス，型，及び値）。ある選択可能形集合
定義の実現は，それが特定のデータベース又は要素に対
して実現されていることを意味するわけではない。 

選択可能形集合OID 
(variantSet oid) 

44 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

区分 

その区分の説明レコードの内容 

キー 

単位情報 (Unit-Info) 

受信側で利用可能としている単位定義。 

単位系名 
(unitSystem name) 

区分リスト 
(Category-list) 

受信側で利用可能としている説明区分。 

キーなし 

3.2.10.1.2 特定の言語における情報の探索 発信元から利用者に与えられる要素は，“人間の読めるテキ

スト”から構成されると想定する。各レコードは，レコード中のテキストの言語を示す言語要素をもつ。

説明データベースは，異なった言語で全く同じ情報をもつ複数のレコードをもってもよい。ある言語での

レコードを探索するためには，“HumanStringLanguage” 属性を用いることができる（用語として3文字言

語コードを用いる。ANSI/NISO Z39.53-1994参照）。 

例えば，英語で記述されたレコードをもったデータベースのリストを探索するには，次のような問合せ

で行う。 

(Category＝ʻDatabaseInfoʼ) AND 

(HumanStringLanguage＝ʻengʼ). 

“HumanStringLanguage” 属性は，本来第2版で用いることを想定している。第3版が有効な場合は，選

択可能形の使用が望ましい。 

3.2.10.1.3 制御日付による情報の探索 説明データベースで新規レコードを探索するためには，

“DateAdded” 属性を用いる。更新されたレコードを探索するためには，“DateChanged” 属性を用いる。期

限満了の日付に基づくレコードを探索するためには，“DateExpires” 属性を用いる。これら三つのどれにつ

いても，上で述べた探索を組み合わせて用いてよい。 

3.2.10.1.4 内容値を用いた情報の探索 説明レコードの幾つかは，属する説明レコード中の要素から値を

とった属性を用いて探索をすることができる。これらの “Use” 属性は，特定の情報区分のレコードの部分

集合を選択するために用いることができる。例えば，入手可能性の “Use” 属性 “Availability” は，現在利

用できるデータベースに関するデータベース情報レコードを選択するために用いることができる。発信元

によるこれらの属性の利用は，次の規則に従うことが望ましい。 

− 現在利用できるデータベースを探すには，“ExplainCategory” 属性を用語 “DatabaseInfo” とし，

“Availability” 属性の用語 “yes” と組み合わせて用いる。 

− 特定の供給者から提供されているデータベースを探すには，“ExplainCategory” 属性を用語 

“DatabaseInfo” とし，“Supplier” 属性の用語を供給者の名前として組み合わせて用いる。 

− 特定の製作者から提供されているデータベースを探すには，“ExplainCategory” 属性を用語 

“DatabaseInfo” とし，“Producer” 属性の用語を製作者の名前として組み合わせて用いる。 

− 所有権のないデータベースを探すには，“ExplainCategory” 属性を用語 “DatabaseInfo” とし，“Propriety” 

属性の用語 “no” と組み合わせて用いる。 

− 無料で利用できるデータベースを探すには，“ExplainCategory” 属性を用語 “DatabaseInfo” とし，

“UserFee” 属性の用語 “no” と組み合わせて用いる。 

3.2.10.2 説明レコードの検索 説明レコードの表示要求は，要望レコード構文として，“Explain” 構文を

指定することが望ましい。各説明情報区分は，それ自身のレコード構成をもち，それらは，“Explain” 構文

定義に示されている［附属書5（規定）のREC1参照］。 

説明レコードは，各レコードを一意に識別するキー要素をもつ。各説明区分は，キー要素，キーとなら

ない“簡略”要素（3.2.10.2.2参照），“非簡略”要素，場合によっては，他の区分として定義される。キー

45 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

要素は，常に簡略要素の部分とする。 

3.2.10.2.1 検索とテキスト 説明データベースは，テキスト情報について選択可能な別形を提供してもよ

い（ただし言語の別形については，備考参照）。例えば，あるテキスト要素が，ASCII，SGML，又はPostScript

で検索可能かもしれない。特定の形式を要求する場合は，第3版の選択可能形機能を使う。 

備考 言語別形については，3.2.10.1.2参照。説明データベースは，論理的には，異なる言語では異な

ったレコードをもつ。したがって，言語の選択は，探索時に行われる。 

3.2.10.2.2 要約及び記述情報の検索 説明機能群は，要約，すなわち，“簡略”情報の検索を提供する。例

えば，発信元は，受信側の提供するすべてのデータベースについての情報をレコード全体ではなく要約情

報で要求できる。各区分の定義の中で，要素には，“簡略”又は“非簡略”の指示が行われる。“簡略”と

指示された要素は，要素集合名 “B” を使用して得られる。“非簡略”と指示された要素は，要素集合名 “F” 

を使用した場合に，（簡略要素とともに）得られる。 

説明機能群は，ある区分についての記述情報の検索も提供する。これには，要素集合名 “description” を

使用する（詳細については，“Explain” 構文のASN.1定義参照）。例えば，ある “DatabaseInfo” レコードは，

（テキストで）データベースについて記述した要素をもつ。簡略要素及び記述要素だけを検索するために

は，要素集合名 “description” を用いてもよい。 

“Explain” 構文で定義されている各区分は，他の要素集合名をその区分中の情報の特定の部分集合として

指示してもよい。 

3.2.10.3 情報区分の詳細記述 この箇条は，各情報区分のすべての記述を示す。列挙した情報に加えて各

レコードは， 

− レコードそれ自身についての情報をもつ。例えば，レコードの作成及び期限満了日。さらに， 

− レコードのテキスト要素の言語を示した要素をもつ。 

これらは，論理的な記述で，レコードの言語選択可能形又は要素の構文選択可能形の存在可能性は示さ

ない。 

説明要素の多くは，任意選択であるが，次の記述ではそれを示さない。特定の情報に関しては，ASN.1

定義を参照。 

3.2.10.3.1 受信側情報 受信側についての情報。この説明レコードは，説明データベース中に一つある。 

簡略要素は，次のものとする。 

− 受信側の名前（一つだけ）を示すテキスト。 

− この受信側を使う人々にとっての重要な最近のニュースを表示するテキスト。 

− この受信側を表すのに用いるアイコン（機械表示可能形式）。 

− 名前付き結果集合が利用可能かどうか。 

− 複数データベースが，一つの探索要求で探索できるか。 

− 実現できる並行検索集合の最大数。 

− 検索集合の最大の大きさ（レコード数）。 

− 一つの探索要求で使用できる用語の最大数。 

− その間何の活動もなかった場合，受信側が事象を発生させるタイムアウト時間。 

− 発信元で表示するための受信側からの歓迎メッセージ。 

非簡略要素は，次のものとする。 

− 受信側を運用している組織の連絡先。 

− 受信側について記述するテキスト。 

46 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 受信側のニックネーム又は別名の集合。 

− 受信側に関する制限を示すテキスト。 

− 受信側を運用している組織の支払先住所（例えば事務所）。 

− 運用時間。 

− 提供しているデータベースの組合せのリスト。 

− インターネットアドレスとポート番号。 

− OSIアドレス。 

− メッセージ文字列の言語。 

− 次の各要素，ただし列挙された各項目が，一つ以上のデータベースで実現されている場合（あるデー

タベースで実現されているかを知るには，そのデータベースのレコードを検索する。）。 

− 利用可能な問合せ型，各型についての詳細。 

− 利用可能な診断集合。 

− 利用可能な属性集合。 

− 利用可能なスキーマ。 

− 利用可能なレコード構文。 

− 利用可能な資源確認。 

− 利用可能なアクセス確認。 

− 料金情報。 

− 利用可能な選択可能形集合。 

− 利用可能な要素集合名。 

− 利用可能な単位系。 

3.2.10.3.2 データベース情報 データベース及びデータベースに関連した制限，パラメタについての詳細

な記述。この説明レコードは，提供する各データベースごとに一つずつある。 

簡略要素は，次のものとする。 

− データベースの正式名（一つだけ）。 

− 説明データベースであるかどうか（異なるサーバ用にいる場合もある。）。 

− データベースの短縮名（又は別名）のリスト。 

− このデータベースを表すのに用いられるアイコン（機械表示可能形式）。 

− このデータベースにアクセスするための料金が，必要かどうか。 

− このデータベースが，現在アクセスして利用できるかどうか。 

− データベースの人間の読む名前又はタイトル（データベース名とは異なるものである。データベース

名は，典型的には短い文字列で，人間が読んでわかることを重視したものではない。また，言語によ

って変わらない。）。 

非簡略要素は，次のものとする。 

− このデータベース用のキーワードリスト。 

− データベースを記述したテキスト。 

− 受信側がこのデータベースと組み合わせて探索することを認めている（場合によっては推奨している）

提携データベース。 

− 概念上一つのこのデータベースに属する下位データベース群。 

− このデータベースに関する権利放棄を表示するテキスト。 

47 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− このデータベースについてのニュースを表示するテキスト。 

− データベースのレコード数（正確な数か，又は概略の数か）。 

− レコードが表示される省略時の順序を記述するテキスト。 

− 平均レコード長の概算値（バイト数）。 

− 最大レコード長（バイト数）。 

− このデータベースにアクセスできる運用時間。 

− データベースにアクセスする最良の時間を示すテキスト。 

− このデータベースの最終更新時刻。 

− このデータベースの更新周期／間隔。 

− このデータベースがカバーしている期間を示すテキスト。 

− このデータベースが所有権情報をもっているか。 

− このデータベースの著作権表示について記述するテキスト。 

− 発信元で可能な場合，利用者に表示することを期待する受信側からの著作権関連表示テキスト。 

− データベース製作者，データベース提供者，及びこのデータベース中の資料の包含申込についての記

述と連絡先を表すテキスト。 

− このデータベースについて利用可能な問合せ型，各型についての詳細。 

− このデータベースについて利用可能な診断集合。 

− このデータベースについて利用可能な属性集合。 

− このデータベースについて定義されているスキーマ。 

− このデータベースについて利用可能なレコード構文。 

− このデータベースについて利用可能な資源報告。 

− このデータベースのアクセス制御について記述したテキスト。 

− このデータベースに関する接続，表示，探索料金情報についての機械可読形式，及びテキストの両方。 

− このデータベースについて利用可能な選択可能形集合。 

− このデータベースについて利用可能な要素集合名，テキストによる名前及び記述を含む。 

− このデータベースについて利用可能な単位系。 

3.2.10.3.3 スキーマ情報 データベーススキーマについての記述的情報。この説明レコードは，受信側で

利用可能としている各スキーマごとに一つずつある。 

備考 これは，データベースごとにあるわけではない。 

簡略要素は，次のものとする。 

− このスキーマ定義のオブジェクト識別子。 

− このスキーマの名前。 

非簡略要素は，次のものとする。 

− このスキーマついて記述したテキスト。 

− このスキーマによって用いられるタグ集合，及び各タグ集合に指定されたタグ型。 

− このスキーマによって定義される抽象レコード構造。 

3.2.10.3.4 タグ集合情報 各タグ集合についての記述的情報。この説明レコードは，受信側で利用可能と

している各タグ集合ごとに一つずつある。 

簡略要素は，次のものとする。 

− このタグ集合のオブジェクト識別子。 

48 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− このタグ集合の名前。 

非簡略要素は，次のものとする。 

− このタグ集合を記述したテキスト。 

− タグ集合で定義された各要素について， 

− 要素の名前。 

− 要素のニックネーム。 

− 要素に割り当てられたタグ。 

− 要素の記述。 

− そのデータ型。 

3.2.10.3.5 レコード構文情報 レコード構文についての記述的情報。この説明レコードは，受信側で利用

可能としている各抽象レコード構文ごとに一つずつある。 

備考 これは，データベースごとにあるわけではない。 

簡略要素は，次のものとする。 

− 抽象レコード構文のオブジェクト識別子。 

− この構文の名前。 

非簡略要素は，次のものとする。 

− この抽象構文のための転送構文（のオブジェクト識別子）。 

− この抽象レコード構文を記述したテキスト。 

− この構文を規定しているASN.1モジュール。 

− この構文によって定義されるレコード構造。 

3.2.10.3.6 属性集合情報 属性集合についての記述的情報。このレコードは，受信側で利用可能としてい

る各属性集合ごとに一つずつある。 

簡略要素は，次のものとする。 

− この属性集合の属性集合識別子（オブジェクト識別子）。 

− その名前。 

非簡略要素は，次のものとする。 

− 各属性型について，その名前，記述，その型用の整数値及び属性のリスト，各属性について 

− その名前。 

− 記述。 

− その値。 

− 同値の属性の名前。同値は，（受信側の動作にではなく）属性集合定義に由来する。 

− 属性集合の記述。 

3.2.10.3.7 用語リスト情報 用語リストについての記述的情報。この説明レコードは，提供する各データ

ベースごとに一つずつある。 

簡略要素は，次のものとする。 

− データベースの正式名（一つだけ）。 

− このデータベースに結びついている各用語リストについての要約情報（記述された各用語リストにつ

いて，一つずつ用語リスト詳細レコードがある。）。 

− 用語リストの名前。データベースについて一意でなければならない。この名前をこの用語リストの用

語リスト詳細レコードの探索に用いる。 

49 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− そのタイトル。利用者が見るためで，一意である必要はない。 

− 結びついた属性を使う場合の，探索にどれだけかかるかの表示。受信側が次のうちの一つで示す。 

− このリストと結びついた属性（組合せ）は，高速サーチとなる。 

備考 属性組合せを得るためには，結びつけられた用語リスト詳細レコードを検索する。 

− この属性（組合せ）には，索引又は類似の機構が実現されていて，探索は，期待したとおり働く。 

− 属性（組合せ）を使うことは，可能だが，満足できる結果は，与えられないかもしれない。恐ら

く索引がない，又はレコードの後処理が必要となる。 

− この属性（組合せ）だけでは，探索できない。 

− 用語リストが走査できるかどうか。 

− 代替の名前のリスト，上位用語リスト。 

− 代替の名前のリスト，下位用語リスト。 

（非簡略要素なし）。 

3.2.10.3.8 拡張サービス情報 拡張サービスについての記述的情報。この説明レコードは，受信側で利用

可能としている各拡張サービスごとに一つずつある。 

簡略要素は，次のものとする。 

− この拡張サービスのオブジェクト識別子。 

− この拡張サービスの名前。 

− 次のものを示す論理型フラグ。 

− 私用拡張サービスかどうか。 

− 制限があるかどうか。 

− 料金がかかるかどうか。 

− サービスが利用可能かどうか。 

− 結果の保留が実現されているか。 

− どのレベルのウェイト動作が利用可能か。 

非簡略要素は，次のものとする。 

− 記述テキスト。 

− この拡張サービス特有の説明要素（特有の拡張サービス定義の中で定義される。）。 

− “Explain” 構文定義のASN.1モジュール。 

3.2.10.3.9 属性詳細 各属性についての情報。この説明レコードは，提供する各データベースごとに一つ

ずつある。 

簡略要素は，次のものとする。 

− この属性情報を適用するデータベースの名前。 

非簡略要素は，次のものとする。 

− このデータベース用に受信側で利用可能としている各属性集合ごとに，属性集合のオブジェクト識別

子，及び集合の中の各属性ごとに， 

− 属性型。 

− 属性が省略された場合の既定値。及びテキストでの既定の動作の記述。 

− 属性の各値ごとに， 

− 属性値。 

− テキストでのその値の記述。 

50 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 下位属性（“Use” 属性に関する），レコードの同じ側面からのより詳細なアクセスを可能にす

る代替値のリスト。 

− 上位属性（“Use” 属性に関する），レコードの同じ側面からのより粗いアクセスを可能にする

代替値のリスト。 

− 値が“部分的実現”かどうか，すなわち，その値は，受け付けられるが，期待された結果を

与えないかもしれない。 

− データベースについて利用可能なすべての属性の組合せのリスト。 

3.2.10.3.10 用語リスト詳細 用語リストのための記述的情報。このレコードは，用語リスト情報レコード

がリストする各用語リストごとに一つずつある。 

簡略要素は，次のものとする。 

− 用語リストの名前。 

非簡略要素は，次のものとする。 

− 記述。 

− この用語リストで利用可能な属性組合せ。このリストが走査できる場合，走査によって使われる属性

組合せ。 

− 実現できる最大増分量。 

− 照合順番（例えば，ASCII，EBCDIC）を示すテキスト。 

− 順序（昇順又は降順）。 

− 用語数の見積り。 

− 標本用語のリスト（必ずしも正しいものでなくともよい。当該リストの一様に分布した標本を最適と

する。）。 

3.2.10.3.11 要素集合詳細 要素集合についての記述的情報。この説明レコードは，各データベースの各レ

コード構文の各要素集合ごとに一つずつある。 

簡略要素は，次のものとする。 

− このレコードが属しているデータベース。 

− このレコードが記述する要素集合の要素集合名。 

− このレコードが属しているレコード構文。 

− この要素集合が属しているスキーマ。 

非簡略要素は，次のものとする。 

− この要素集合を記述したテキスト。 

− 要素集合の個々の要素ごとに，検索レコード詳細区分によって個々の要素に提供される情報。 

3.2.10.3.12 検索レコード詳細 検索レコードの要素についての記述情報。要素は，あるデータベーススキ

ーマに相対的であることに注意する。この説明レコードは，各データベースの各スキーマの各レコード構

文ごとに一つずつある。 

簡略要素は，次のものとする。 

− この説明レコードが属している，データベース，スキーマ及びレコード構文。 

非簡略要素は，構文が規定する個々の要素ごとに次のものとする。 

− 要素の名前。 

− 要素のタグ，もしあれば。 

− この要素を含むこのレコード構文内のスキーマ要素のリスト。 

51 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− この要素の最大長。 

− この要素の最小長。 

− この要素の平均長。 

− 固定長の場合，要素の長さ。 

− 要素が繰り返されるか繰り返されないか。 

− 要素が必す（須）か必す（須）でないか。 

− この要素を記述したテキスト。 

− この要素の内容の記述したテキスト。 

− この要素に関する課金／請求を示すテキスト。 

− この要素の使用とアクセスに関する制限（著作権，所有権など）を示すテキスト。 

− この要素の別名。 

− この要素テキストについての総称的な名前（例えば，“地名件名”要素は，総称的な名前“件名”の下

にあるかもしれない。）。 

− この要素に対応する属性組合せ。 

3.2.10.3.13 並び替え詳細 受信側が実現する並び替え機能の記述。このレコードは，各データベースごと

に一つずつある。 

簡略要素は，次のものとする。 

− この並び替え記述が属しているデータベース。 

非簡略要素は，次のものとする。 

− 各並び替えキーについて， 

− 記述。 

− キーがレコード要素の場合，要素の仕様。 

− キーが属性組合せの場合，組合せの仕様。 

− キーの型：文字，数値，構造体。 

− キーが大小文字を区別するかどうか。 

3.2.10.3.14 処理情報 発信元でデータをどのように処理して利用者に表示すべきかを表す命令。命令は，

外部で定義される。あるデータベースの処理文脈（アクセス，探索，検索，レコード表示及びレコード操

作）に対し，受信側が提供する処理情報の命令は，一組以上あってもよい。これらは，名前で区別される。

各命令の組は，一つ以上の抽象構文で利用できてもよい。これらは，オブジェクト識別子によって区別さ

れる。したがって，この型の説明レコードは，データベース，処理コンテキスト，名前及びオブジェクト

識別子によって区別される。 

簡略要素は，次のものとする。 

− この処理情報レコードが属するデータベースの正式名。 

− この処理情報が属する文脈。 

− この処理情報の名前。 

− 外部で定義された命令の抽象構文のオブジェクト識別子。 

非簡略要素は，次のものとする。 

− 命令を記述したテキスト。 

− 外部で定義された機械処理可能な命令（何に属する抽象構文かは，上記のオブジェクト識別子によっ

て識別される。）。 

52 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.2.10.3.15 選択可能形集合情報 受信側で利用可能としている選択可能形集合定義についての記述情報。

すなわち，選択可能形集合で実現されているクラス，型及び値。ある選択可能形集合定義の実現は，それ

が特定のデータベース又は要素に対して実現されていることを意味するわけではない。 

簡略要素は，次のものとする。 

− 選択可能形集合定義のオブジェクト識別子。 

− その名前。 

非簡略要素は，次のものとする。 

− 実現されている各クラスの名前と記述のリスト，各クラスについて実現されている各型の名前と記述

のリスト，加えて，各型について実現されている値のリスト。 

3.2.10.3.16 単位情報 受信側で利用可能としている単位系定義についての記述情報。 

簡略要素は，次のものとする。 

− 単位系の名前。 

非簡略要素は，次のものとする。 

− 記述。 

− 各単位型の名前及び記述のリスト，並びに各単位型について含まれる各単位の名前及び記述のリスト。 

3.2.10.3.17 区分リスト 受信側で利用可能としている説明区分のリスト。このレコードは，説明データベ

ースに一つある。各区分ごとに次の情報から成っている。 

簡略要素は，次のものとする。 

− この区分のレコードを探索するために，“Use” 属性の “ExplainCategory” で使われる探索用語。 

備考 次のものは，受信側がこの規格の定義していない区分を採用する場合だけ必要になる。 

− 元の探索用語（これは，受信側がこの規格の区分定義を改訂して使用している情報区分のためにある。）。 

− 記述。 

− この区分のレコードのASN.1定義。 

3.2.11 終了機能群 終了機能群は，ただ一つのサービスである完了サービスからなる。 

3.2.11.1 完了サービス 完了サービスによって，発信元又は受信側の両方は，すべての活動中の操作を突

然に終了させ，(Z) アソシエーションの終了を起動することができる（表15参照）。 

完了サービスは，第3版が有効な場合にだけ使用することができる。この場合，初期化後完了要求が発

信又は受信されるまでいつでも発信元又は受信側は， 

− 完了要求を発信してもよい。これに当たって，すべての活動中の操作が突然に終了することを考慮し，

（間にはさまれるすべてのメッセージを破棄して）完了要求を待ち，(Z) アソシエーションの完了を

考慮する。さらに， 

− 完了要求を受信できるようにしておくことが望まれる。これに応じて，すべての活動中の操作が突然

に終了することを考慮し，完了要求を発信し，(Z) アソシエーション完了の考慮をする。 

53 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表15 完了サービスのパラメタ 

パラメタ 

要求 

応答 

備考 

完了理由 (close-reason) 

○ 

○ 

− 

診断情報 (diagnostic-information) 

○（任意選択） 

○（任意選択） 

− 

資源報告書式 (resource-report-format) 

○（任意選択） 

− 

発信元だけ 

資源報告 (resource-report) 

○（任意選択） 

○（任意選択） 

受信側だけ 

その他の情報 (other-information) 

○（任意選択） 

○（任意選択） 

− 

参照識別子 (reference-id) 

○（適用されるとき） ○（適用されるとき） − 

3.2.11.1.1 完了理由 このパラメタは，発信元又は受信側が (Z) アソシエーションを完了させる理由を示

す。 

その値は，次のいずれかをとる， 

− “finished”：完了 

− “shutdown”：閉鎖 

− “system problem”：システム問題 

− “cost limits”：コスト限界 

− “resources”：資源 

− “security violation”：機密保護違反 

− “protocol error”：プロトコル誤り 

− “lack of activity”：活動の不足 

− “unspecified”：不特定 

− “response to Close request”：完了要求への応答 

備考 完了要求及び完了応答は，同じプロトコルメッセージ（終了APDU）を使用する。両方のシス

テムが，完了要求を同時に発信したとすると，双方が同位メッセージを完了応答（応答として

送られなかったにもかかわらず）として受信することになる。この潜在的なあいまいさは，プ

ロトコル操作として正しい結果をもたらさない。しかし，メッセージが実際に完了応答として

送られる場合，上記リストの最後 “response to Close request” が与えられるので，これを使うこ

ともできる。 

3.2.11.1.2 診断情報 受信側は，付加的な診断情報を提供する任意のテキストメッセージを含んでもよい。 

3.2.11.1.3 資源報告書式と資源報告 発信元が完了要求を発信する場合，発信元は，受信側が資源報告

（3.2.6.1.1参照）を応答に含めるよう要求するために，資源報告書式パラメタを含めることができる。受

信側が資源報告を応答に含めるか（及び書式）の決定は一方的である。すなわち，発信元が資源報告書式

パラメタを入れたかどうかにかかわらず，受信側は，報告を含めても省略してもよい。 

受信側が完了要求を発信する場合，受信側は，資源報告を一方的に含めてもよい。 

3.2.11.1.4 その他の情報 このパラメタは，この規格で規定しない付加情報のために，発信元も受信側も

使用してよい。 

3.2.11.1.5 参照識別子 発信元からの完了要求又は完了応答は，参照識別子パラメタを含んでも省略して

もよい。 

受信側の完了要求では参照識別子を省略することが望ましい。完了応答では，参照識別子を含んでいる

完了要求に応答する場合，受信側は，同じ値の参照識別子を含んでもよいし，パラメタを省略してもよい。

参照識別子を含まない完了要求に応答する場合，受信側は，パラメタを省略することが望ましい。 

54 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.3 

メッセージ／レコード長及びセグメント化 “セグメント”は，集合的表示応答，すなわち，セグ

メント要求又は表示応答，の一部分として受信側によって送られる（又は送出のために準備中の）メッセ

ージとする。 

3.3では，“レコード”は，次のように使用される。 

− 別に修飾しない限り，レコードは，“応答レコード”，すなわち，検索レコード又は代替診断レコード

を意味する。 

− 3.3.3内を除いて，レコード長が要望メッセージ長を超える場合，レコードは，“代替診断レコード”

を意味する。 

− “レコードN”は，“検索集合項目Nによって識別されるデータベースレコードと対応する応答レコ

ード”を意味する。 

− レコードは，（セグメント化処理を規定する目的のために）一連のバイトであるとみなされる。 

− “レコード長”は，バイトでレコードの長さを示す。 

1群の応答レコード長の総計が，プロトコル制御情報を含まないで，要望メッセージ長を超えないとき，

3.3.3内を除いて，それらは，“セグメントにおさまる”といわれる。表示操作に当たって，受信側は，レ

コード又はメッセージ長の制限のため，要求されたレコードを単一セグメントにおさめることができない

かもしれない。その場合（セグメント化が有効であるならば），受信側は，複数のセグメント（幾つかのセ

グメント要求及びそれに続く表示応答）を送って，表示応答のセグメント化を実行してもよい。 

レベル1及びレベル2のセグメント化の二つのレベルは，取決めの対象となる。どちらのレベルも有効

でない場合，表示要求に対して，受信側は，整数個のレコードを含む単純表示応答（単一セグメント）で

応答する。レベル1セグメント化が有効な場合，表示要求に対する受信側の応答は，複数のセグメント（幾

つかのセグメント要求及びそれに続く表示応答）からなってもよい。ただし，個々のセグメントは，整数

個のレコードを含まなければならない。すなわち，レコードは，複数のセグメントにまたがってはならな

い。レベル2セグメント化が有効な場合，表示要求に対する受信側の応答は，複数のセグメントからなっ

てもよい。さらに，レコードは，複数のセグメントにまたがってもよい。 

3.3.1 

セグメント化が有効でないときの手続 この箇条(3.3.1)の手続は，セグメント化が有効でないとき

に適用する（セグメント化が有効でないときの表示操作に適用するだけでなく，セグメント化が有効であ

るかどうかにかかわらず，一般に探索操作にも適用される。探索応答は，セグメント化の対象とはならな

い。）。 

受信側は，表示要求に対して，整数個のレコードを含む単純表示応答で（又は探索要求に対して探索応

答で）応答する。受信側がメッセージ長制限のために，要求されたレコードのすべてを戻すことができな

い場合，できる限り多くのレコードをおさめることが望ましい。 

手続 受信側がMからNまでのレコードを戻そうとしていると想定する。MからNまでのレコードが

応答におさまる場合，受信側は，それらのレコードを戻す。おさまらない場合，受信側は，MからPまで

のレコードを戻す。ここにPは，MからPまでのレコードはおさまるが，MからP＋1までのレコードは

おさまらないような値とする。 

説明 受信側が1から10までのレコードを戻そうとしていると想定する。1から6までのレコードは，

応答におさまるが，1から7までの検索レコードは，おさまらない。 

探索レコード7それ自体の長さは， 

a) 要望メッセージ長を超えていない，又は 

b) 要望メッセージ長を超えているが，例外的レコード長を超えていない，又は 

55 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

c) 例外的レコード長を超えている。 

a)の場合，受信側は，1から6までのレコードを戻す。b)の場合，次の条件のとき（例外参照）を除いて，

受信側は，探索レコード7の代わりに診断レコードを使って，レコードが要望メッセージ長を超えている

ことを示す。c)の場合，受信側は，探索レコード7の代わりに診断レコードを使って，レコードが例外的

メッセージ長を超えていることを示す（例外的レコード長が要望メッセージ長と等しい場合，二つの診断

の意味の区別はない。）。 

b)又はc)の場合， 

− 診断レコードが1から6までのレコードと一緒におさまらないとき，受信側は，1から6までのレコ

ードを戻す（要望メッセージ長は，どのような診断レコードでも含むようにいつも十分に大きくなけ

ればならない。したがって，レコード7から始まる次の表示要求は，診断を検索する。）。 

− さもなければ，受信側は，診断レコードを挿入し，8から10までのレコードをおさめる試みを続行す

る。 

例外 表示要求が単一レコード（すなわち，要求レコード数が1)を指定した場合，検索レコードのサイ

ズが要望メッセージ長を超えていても例外的レコード長を超えていないとき，受信側は，その一つの検索

レコードを戻す。この例外は，表示操作にだけ適用され探索操作には適用されないことに注意する。 

したがってb)の場合，発信元は，続いて検索レコード7を検索するのに，そのレコード一つだけを要求

する表示要求を発信してもよい。 

要望メッセージ長と例外的レコード長との区別の目的は，局所的な緩衝域（ローカルバッファ）を最長

レコード用に割り当てて常時保持することを受信側に要求せず，都合のよい大きさの緩衝域で通常の長さ

のレコードの転送をルーチン的に続行することを許し，一方，例外的に大きな検索レコードの転送も可能

にする点にある，ということに注意する。また，受信側がルーチン的に単一レコードを要求するときは，

この意図された目的が破られることにも注意する。 

3.3.2 

レベル1セグメント化 レベル1セグメント化が有効な場合，受信側は，集合的表示応答を複数の

セグメント（幾つかのセグメント要求とそれに続く表示応答）にセグメント化してもよい。個々のセグメ

ントは，整数個のレコードを含む（すなわち，レコードは，複数のセグメントにまたがってはならない。）。

この箇条(3.3.2)の手続は，レベル1セグメント化が有効なときに適用する。 

受信側は，要求された最初のレコードから隣りあう後のレコードへ，要求されたレコード内容が含まれ

るようにセグメントを構成する。各セグメントは，セグメント要求として送られるが，最後のセグメント

は，セグメント要求としてではなく表示応答として送られる。 

セグメント数は，（任意選択の）表示要求の最大セグメント数パラメタが提示されている場合，その値を

超えてはならない。 

最大セグメント数が提示され，その値が1である場合，3.3.1の手続が適用される。さらに，表示要求が

単一レコードを要求してきた場合，3.3.1で規定する例外が，適用される。 

手続 発信元が検索集合レコードMからNまでを要求したと想定する。 

a) M < N（すなわち，レコードが2個以上要求された場合） 

1) P＝Mと設定する。 

2) レコードPからレコードNまでが一つのセグメントにおさまる場合， 

2.1) レコードPからレコードNまでをそのセグメントにおさめる。 

2.2) 3)へ進む。 

そうでなければ， 

56 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

2.3) レコードPからQまでをおさめる。ここにQ（N未満）は，レコードPからQまでは1セグメン

トにおさまるが，レコードPからQ＋1はおさまらないような値とする。 

2.4) 最大セグメント数に到達した場合，3)へ進む。 

2.5) セグメントをセグメント要求として送信する。 

2.6) P＝Q＋1と設定する。 

2.7) 2)から繰り返す。 

3) セグメントを表示応答として送信する。 

b) M＝N（すなわち，単一レコードが要求された場合） 

受信側は，単純表示応答（単一セグメント）を送信する。セグメント長は，要望メッセージ長を超

えてもよい。セグメントには，要求された検索レコードが一つ，又はレコードの長さが例外的レコー

ド長を超えている場合は，代替診断レコードが含まれる。 

説明 発信元がレコード1からレコード10までを要求してきた場合を想定する。 

a) 10のレコードすべてが一つのセグメントにおさまるとき，集合的表示応答は，要求されたレコードを

含む一つの表示応答からなる。表示状態は，“success”（すべての期待される応答レコードが利用可能）

となる。 

b) レコード1から4までは，一つのセグメントにおさまるが，レコード1から5までは，おさまらない，

また，レコード5から9までは，一つのセグメントにおさまるが，レコード5から10までは，おさま

らない場合を想定する（表示要求では最大セグメント数パラメタに3以上の値を指定していたとす

る。）。この場合，集合的表示応答は，次のものから構成される。 

1) レコード1から4までを含むセグメント要求 

2) レコード5から9までを含むセグメント要求，及び 

3) レコード10を含む表示応答。 

表示状態は，“success”（すべての期待される応答レコードが利用可能）となる。受信側は，1セグ

メントにできるだけ多くのレコードをおさめることを期待されていることに注意する。したがって，

最初のセグメントを例えばレコード1から3とはしない。レコード1から4までがおさまるためであ

る。 

c) b)の条件の，表示要求での最大セグメント数パラメタが値2の場合を想定する。この場合，集合的表

示応答は，次のものから構成される。 

1) レコード1から4までを含むセグメント要求，及び 

2) レコード5から9までを含む表示応答。 

表示状態は，“partial-2”（要望メッセージ長に入らないため，返せない応答レコードがある。）とな

る。 

3.3.3 

レベル2セグメント化 レベル2セグメント化が有効な場合，受信側は，集合的表示応答を複数の

セグメントにセグメント化してもよい（レベル1セグメント化の場合と同様），さらにレコードは，セグメ

ントをまたがることができる。この箇条(3.3.3)の手続は，レベル2セグメント化が有効なときに適用する。 

検索レコードが一つのセグメントに（既にそのセグメントにおさめられているレコードとともに）おさ

まらない場合，この検索レコードを3.3.3.2及び3.3.3.3に規定する手続に従って，隣接する複数の断片

（3.3.3.1参照）にセグメント化し，連続したセグメントに詰め込むことができる。 

57 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.3.3.1 

断片 断片は，レコードの真の部分列とする（上に示したとおり3.3.3内では，レコードは，バ

イトの列として扱われる。）。あるレコードのセグメント化の結果は，（プロトコル制御情報を除いて）連結

するとそのレコードと同一となる，二つ以上の断片の並びとなる。しかし，あるレコードのセグメント化

には様々な例が考えられ，発信元は，あるレコードが受信側によってどのように断片に分割されるのかを

必ずしも予測できない。 

手続の規定(3.3.3.3)のため，開始断片をレコードの先頭で開始する断片と定義する。中間断片はレコード

の終わりでも開始でもない断片とし，最終断片は，レコードの終わりで終了する断片とする（セグメント

化されていない。）。レコード全体は，断片とは呼ばない。 

1セグメント内のレコード長及びレコード断片長の，プロトコル制御情報を含まない総和は，最大セグ

メント長を超えてはならない（3.3.3.2参照）。 

3.3.3.2 

セグメント長，レコード長及びセグメント数 レベル2セグメント化が有効な場合，表示要求は，

任意選択で次の三つのパラメタを含むことができる。 

a) 最大セグメント長 可能なセグメントの長さの最大値。最大セグメント長が含まれる場合，要望メッ

セージ長は，（この表示操作においてだけ）無効となる。含まれない場合，要望メッセージ長と同じ値

が仮定される。 

b) 最大レコード長 集合体プレゼント応答中に可能な検索レコード長の最大値。含まれる場合，最大レ

コード長は，最大セグメント長と等しいか大きくなければならない（レベル2セグメント化が有効な

場合，最大レコード長が含まれていてもいなくても，最大セグメント数の値が1でない限り，初期化

の間に取り決められた例外的レコード長パラメタは，無効となる。）。 

c) 最大セグメント数 受信側が集合体プレゼント応答に含めてよいセグメントの最大数。その値が1の

場合，この操作にセグメント化は，適用されず，3.3.1に示した手続が適用され，最大レコード長パラ

メタは，含まれないことが望ましい。 

最大レコード長及び最大セグメント数の両方が含まれる場合，最大レコード長は，最大セグメント長と

最大セグメント数との積を超えてはならない。 

最大レコード長が含まれ，最大セグメント数が含まれない場合，発信元は，要求したレコードを検索す

るのに必要な数のセグメントを受け取れるようにしておくことが望ましい。 

最大セグメント数（値は2以上）が含まれ，最大レコード長が含まれない場合，最大セグメント長と最

大セグメント数との積は，この操作での最大レコード数となる。 

最大レコード長及び最大セグメント数の両方とも省かれている場合，発信元は，どんな大きさのレコー

ドも，どんな個数のセグメントも受け取れるようにしておくことが望ましい。 

3.3.3.3 

セグメント化手続 次の手続は，レベル2セグメント化に適用される。受信側は，最初のセグメ

ントにできるかぎり多くの分割しないレコードをおさめる。要求されたレコードすべてがおさまる場合，

このセグメントを単純表示応答として送信する。そうでない場合，そのセグメント内に残っている領域に，

受信側は，続くレコードの開始断片をその領域に（可能ならば）おさめ，そのセグメントをセグメント要

求として送信する。さらに，受信側は，そのレコードの残りが次のセグメントにおさまる場合にはおさめ，

おさまらない場合，中間断片を必要なだけセグメント要求として送信し，最終断片（もしあれば）を次の

セグメントの最初の部分におさめ，そのセグメントの残りの領域にできるだけ多くの分割しないレコード

をおさめる。要求されたレコードの最後がそのセグメント内にきた場合（又は最大セグメント数に達した

場合），そのセグメントを表示応答として送信する。そうでない場合，受信側は，要求されたレコードの最

後がセグメントにくるまで，又は最大セグメント数に達するまでこのような方法でセグメントを埋めなが

58 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ら，各セグメントをセグメント要求として送信する。最後のセグメントは，表示応答として送る。この手

続をより正式に繰り返すと次の形となる。 

手続 発信元が検索集合レコードMからNまでを要求したと想定する（“レコード”は，レコード長が

最大レコード長を超える場合，又は各断片が1セグメント内におさまらなくて受信側がレコードをセグメ

ント化できない場合“代替診断レコード”を意味することに注意。）。 

a) R＝Mと設定する（最初の断片の準備開始）。 

b) レコードRが現在のセグメント内におさまる場合， 

1) レコードRからレコードPまでの分割しないレコードをおさめる。ここに，（Nを超えない）Pは，

レコードRからPまでがおさまるような最大数とする。 

2) PとNが等しい場合，又は最大セグメント数に達している場合，h)へ進む。 

3) R＝P＋1と設定する。 

c) この段階にきたとき，レコードRは，現在のセグメントにおさまらないことに注意する。表示要求に

最大セグメント数が含まれていて，受信側がレコードRを集合的表示応答の残りにおさまるかどうか

決定できない場合， 

1) 代替診断レコードを挿入する。これは，実際には再びレコード検索を試みることを発信元に示唆す

る。ただし最大セグメント数は，指定しない。 

2) g)へ進む。 

d) レコードRが集合的表示応答の残りにおさまらない場合，h)へ進む。 

e) レコードRが集合的表示応答の残りにおさまるが，開始断片が現在のセグメントにおさまらない場合， 

1) この条件は，セグメントが空になる可能性を除外することに注意する。a)の前に書かれた注意内容

参照。 

2) セグメント要求の送信（次のセグメントの準備開始）。 

3) b)へ進む。 

f) 

この段階にきたとき，レコードRは，残りのセグメントにおさまり，現在のセグメント内にはおさま

らないが，開始断片は，現在のセグメントにおさまることに注意する。 

1) レコードRに可能なかぎり大きな開始断片をおさめ，セグメント要求を送信する。 

2) レコードRの中間断片を必要な数（ゼロでもよい。）の完全なセグメントにおさめ，セグメント要

求を送信する。 

3) レコードRの最終断片を挿入して次のセグメントの準備を開始する。 

g) R＝R＋1と設定。 

1) RがN以下の場合，b)へ進む。 

h) 表示応答を送信する。 

説明 発信元がレコード1から12までを要求したと想定する。各レコードは，レコード5を除いてすべ

て500バイト，レコード5は，10 000バイトとする。最大セグメント長は，3 200。 

a) レコード5は，10の要素からなっていて，各要素は，1 000バイトとする。受信側は，レコード5を

セグメント化できるが，要素ごとでだけ可能であり，要素が断片をまたぐことはない。 

備考 これは，断片がM*1 000＋1から (M＋N)*1 000バイト，M＝0，1，...9；N＝1，2，...，10−M

となるように，受信側がセグメントを分割することを意味する。例えば1から1 000バイト，1

から2 000バイト，1から3 000バイト，1 001から2 000バイト，1 001から3 000バイト，1 001

から4 000バイトなどである。 

59 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

さらに，受信側は，他のどのレコードも分割できないとする。集合的表示応答は，次のよう

になる。 

− セグメント1セグメント要求。レコード1から4まで，及び開始断片でレコード5の最初の1 000

バイトを含む。 

備考 このセグメントは，3 000バイトで最大セグメント長の3 200未満であるが，受信側は，次の断

片をこのセグメントにおさめることができない。なぜならば，そうするとセグメント長が最大

値3 200バイトを超える（断片の最小値は1 000バイト）ためである。 

− セグメント2セグメント要求。中間断片でレコード5の1 001から4 000バイトまでを含む。 

− セグメント3セグメント要求。中間断片でレコード5の4 001から7 000バイトまでを含む。 

− セグメント4セグメント要求。最終断片でレコード5の7 001から10 000バイトまでを含む。 

− セグメント5セグメント要求。レコード6からレコード11までを含む。 

− セグメント6表示応答。レコード12を含む。 

b) さらに，受信側が小さいレコードを100バイト（又はその倍数）の断片にセグメント化できるとする。

セグメント1からセグメント3は，説明a)と同じ。 

− セグメント4セグメント要求。最終断片でレコード5の7 001から10 000バイト，及び開始断片

でレコード6の1から200バイトまでを含む。 

− セグメント5セグメント要求。最終断片でレコード6の201から500バイトまで，及びレコード

7からレコード11まで，さらに開始断片でレコード12の最初の400バイトを含む。 

− セグメント6表示応答。最終断片でレコード12の401から500バイトまでを含む。 

c) 受信側が任意のバイト境界でレコードをセグメント化できるとする。 

− セグメント1セグメント要求。レコード1からレコード4まで，及び開始断片でレコード5の最

初の1200バイトを含む。 

− セグメント2セグメント要求。中間断片でレコード5の1 201から4 200バイトまでを含む。 

− セグメント3セグメント要求。中間断片でレコード5のバイト4 201から7 400までを含む。 

− セグメント4セグメント要求。最終断片でレコード5のバイト7 401から10 000まで，及びレコ

ード6，さらに開始断片でレコード7の最初の100バイトを含む。 

− セグメント5表示応答。最終断片でレコード7の101から500バイトまで，及びレコード8から

レコード12までを含む。 

3.4 

操作と参照識別子 発信元からの要求のある種の操作型のものは，操作を起動し，それに対する受

信側の応答で，その操作は，終了する。操作型は，起動，探索，表示，削除，資源報告，走査及び拡張サ

ービスが定義されている（したがって，資源制御トリガ及び完了を除く発信元からの各要求型は，操作型

に対応する。）。操作は，起動要求及び終了応答と，それに加えて，中間におこるアクセス制御要求，資源

制御要求及びそれらの応答，資源制御トリガ要求並びにセグメント要求とからなる。操作には，発信元に

よって参照識別子が指定される。発信元は，起動要求の中で参照識別子を指定し，この操作の各メッセー

ジもそれを含まなくてはならない。“直列操作”が有効な場合，起動要求の参照識別子パラメタは，省略し

てもよい。この場合，この操作の参照識別子は，空とみなされ，その操作の他のメッセージすべてにおい

ても参照識別子パラメタを省略しなければならない。 

発信元から受信側へ，又はその逆に送られるメッセージ（すなわち，このサービス定義で定義されるす

べての要求及び応答）は，次に示す例外を除いて（参照識別子によって識別される）ある操作の一部とな

る。 

60 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 完了要求又は完了応答は，いかなる操作の一部でもない。 

備考 完了要求又は完了応答は，3.2.11.1.5に示す手続に従って参照識別子を含んでもよい。 

− “並行操作”が有効である場合，資源制御又はアクセス制御の要求又は応答が，参照識別子を含まな

いとき，操作の一部としない。 

この規格は，ある操作とその後に続く操作が同じ参照識別子を使っていても，それらの操作間に関係を

想定しない。この規格は，参照識別子パラメタの内容も，操作を参照するために使用するという以外の意

味も定めない。参照識別子は，常に発信元によって指定され，発信元のシステム内でだけ意味をもつ。参

照識別子は，意味を与えられていないので意味を含むデータ型はもたず，単に2進データとして規定され

る（したがってそのASN.1型は，“OCTETSTRING” である。）。 

3.5 

並行操作 “並行操作”が有効な場合，起動要求の中で参照識別子パラメタは，必す（須）（備考参

照）とし，発信元は，異なる参照識別子によって識別される複数の並行操作を起動することができる。 

備考 参照識別子は，開始要求の中では常に任意選択とする。オプションパラメタの“並行操作”は，

取決めが終わるまで効果をもたないので，開始操作中では有効とならない。 

操作が一度起動されるとその操作が終わるまで，同じ参照識別子で別の操作を起動してはならない。こ

の規格は，受信側で処理される並行操作の順序は指定しない。受信側は，その選択した方法で並行操作を

処理してよい。 

例 発信元は，参照識別子 “100” を用いて探索要求を発行し，最初の探索要求の探索応答を受け取る

前に，参照識別子 “101” を使って次の探索要求を出すことが可能である。そこでは，二つの並行

操作が行われていることになる。発信元が，（参照識別子 “101” で識別される）2番目の探索要

求に対する応答を受けると，2番目の操作は，終了するが，それは，（参照識別子 “100” で識別

される）最初の操作が終了する前に起こることもある。その後，発信元は，（第2の操作の検索集

合に対して）表示要求を出し，新しい操作を起動するかもしれない。その場合，発信元は，“100” 

以外の参照識別子を与えなくてはならない（なぜならば，その参照識別子で活動中の操作が存在

する。）。新しい参照識別子は，“101” であってもよい（あえてそうする必要はない。）。その場合

でも，受信側は，この新しい操作と前回同じ参照識別子 “101” を使った操作との間に何らかの関

係をもたせることはできない。 

開始操作の進行中に他の操作を起動することはできない。完了要求が送信又は受信された後，その (Z) 

アソシエーション内では操作は起動できない。 

すべての検索集合は，原則として，どの操作からも利用できる。二つ以上の並行操作が同じ検索集合を

参照することもありうる。この規格は，その状態で何が起こるかは規定しない。発信元は，同じ検索集合

識別子の値で並行探索操作を起動しないほうがよい。 

上の制約（発信元がある参照識別子を使用して操作を起動したとき，その操作が終了するまで，その参

照識別子を使って別の操作を起動することはできない。）以外に，発信元が参照識別子を再利用したり管理

することに関する制約はない。発信元は，参照識別子を利用者の間で適当に繰り返し使用することができ

るし，異なった参照識別子を末端利用者ごとに指定して局所的なスレッドを管理することもできる。受信

側は，発信元がどのように参照識別子を管理しているか，又は特に，どのように参照識別子で異なった末

端利用者を区別しているかということを知る必要はない。受信側は，発信元の複数の末端利用者を知る必

要はなく，ただ（一つの）発信元とやりとりをする。 

61 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3.6 

構成仕様 受信側は，提供する各データベースについて，一つ以上のスキーマ（3.1.5参照）を定義

し，一つを省略時スキーマに指定する。各スキーマについて，受信側は，一つ以上の要素指定識別子を指

定する。 

要素指定識別子は，要素指定書式（要素指定を表現するため用いられる構造）のオブジェクト識別子か，

又は要素集合名とする。後者は，基本名となる。要素指定は，要素指定書式の実現値であるか，又は要素

集合名である。 

省略時スキーマについて，少なくとも要素指定識別子の一つは，要素集合名でなければならず，受信側

は，一つをデータベースについての省略時要素集合名に指定する。 

備考 受信側は，説明機能群又はこの規格外の機構を通じて，この情報を指定する。 

探索又は集合的表示応答の中で返される各レコードについて，受信側は，抽象レコード構造（そのレコ

ードが属するデータベースについてのスキーマが定義する。）を適用して，抽象データベースレコードを形

成する。受信側は，抽象データベースレコードに対して要素指定を適用し，抽象データベースレコードの

別の実現値（後者は，無変換でもよい。）を形成する。さらに，これに対してレコード構文を適用し，検索

レコードを形成する。 

発信元が（表示要求の中で）構成仕様パラメタを含む場合は，3.6.1の手続を適用する。探索操作又は構

成仕様パラメタが省かれたときの表示操作では，各レコードに省略時スキーマを想定して3.6.2の手続を適

用する。 

3.6.1 

構成仕様の指定 表示要求の構成仕様パラメタは，データベース名とそれに結びつけられた構成仕

様の一つ以上の対の集合を含む。各構成仕様は，スキーマ識別子（ない場合は，データベースについての

省略時スキーマが仮定される。）及び要素指定を含んでもよい。集合的表示応答の中で返される各レコード

について， 

− そのレコードが属するデータベースが（対の一つを構成する要素として）指定されている場合，それ

に対応する構成仕様を適用することによって，受信側は，可能であれば，抽象データベースレコード

を形成する（すなわち，データベースレコードに対し，スキーマで定義された抽象レコード構造を適

用して抽象データベースレコードを形成し，次いで要素指定を適用する。これらのスキーマ及び要素

指定は，その構成仕様に含まれるものである。）。 

− そうでない場合，受信側は，省略時スキーマによって定義される抽象レコード構造と，レコードが属

するデータベースの省略時要素集合名とを適用することによって，抽象データベースレコードを形成

する。 

構成仕様パラメタは，一方，指定されたデータベースを伴わない単独の構成仕様からなりたっていても

よい。この場合，返される各レコードについて，受信側は，その構成仕様にしたがって抽象データベース

レコードを形成できるときはそのようにし，そうでないときはそのレコードが属するデータベースについ

ての省略時スキーマと省略時要素集合名とに従って抽象データベースレコードを構成する。 

受信側は，レコード構文（これは，構成仕様の中に含まれても又は要望レコード構文パラメタにあって

もよい。）を，結果として生じる抽象データベースレコードに適用して検索レコードを形成する。 

3.6.2 

構成仕様の省略 検索集合に対してレコード集合の検索を要求するとき，構成仕様パラメタが省略

されている場合は，この箇条の手続を適用する。 

備考1. 探索要求では，常に適用される。構成仕様パラメタは，探索要求の定義中に含まれていない

からである。 

2. 第2版が有効なとき常に適用される。構成仕様パラメタは，第2版では定義されていないか

62 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

らである。 

探索要求の小集合要素集合名パラメタ，中集合要素集合名パラメタ及び表示要求の要素集合名パラメタ

は，データベース名とそれに結びつけられた要素集合名との一つ以上の対の集合の形をとる。探索又は集

合的表示応答の中で返される各レコードについて，受信側は，まず，レコードが属するデータベースの省

略時スキーマが定義する抽象レコード構造を適用して抽象データベースレコードを形成し，次いで，次の

ように要素集合名を適用する。 

− レコードが属するデータベースが（対の一つを構成する要素として）指定されている場合，対応する

要素集合名がデータベースの省略時スキーマに対して有効なときは，受信側は，その要素集合名を適

用する。 

− そうでない場合，受信側は，そのデータベースの省略時要素集合名を適用する。 

これらの各パラメタは，一方，データベース指定を伴わない単独の要素集合名からからなりたっていて

もよい。この場合，返される各レコードについて，要素集合名がレコードが属するデータベースの省略時

スキーマに対して有効なときは，受信側は，その要素集合名を適用する。有効でなければ，受信側は，デ

ータベースの省略時要素集合名を適用する。 

受信側は，“F” を全体 (full) を意味する要素集合名として常に認識しなければならない。これは，抽象

データベースレコードに適用すると，結果として同一の抽象データベースレコードとなる（すなわち，無

変換）。 

受信側は，文字列 “B” を簡略 (brief) レコードを意味する要素集合名として常に認識しなければならな

い。この規格では，簡略の意味は定義しない。発信元が，受信側のあるスキーマの簡略の定義を知らない

場合，特定の要素が含まれることを仮定しないほうがよい。 

発信元は，要望レコード構文パラメタを指定してもよい。受信側は，これを（要素集合名を適用して形

成された抽象データベースレコードに）適用して検索レコードを形成する。発信元が要望レコード構文パ

ラメタを指定しない場合，受信側は，ある一つを選択してもよい（3.2.2.1.5参照）。 

3.6.3 

レコード構文 探索又は集合的表示応答の中で返される各レコードについて，要素集合名又はスキ

ーマ及び構成仕様中の要素指定は，上に示したように，結果的として抽象データベースレコードを生む。

この抽象データベースレコードに対して，受信側は，上に示したように，レコード構文を適用する。レコ

ード構文という用語は，次の意味をもつ。 

− 発信元が（要望レコード構文の値として，又は構成仕様の中で）指定しているとき，それは，OIDの

形をとり，ある抽象構文（対となっているか，又は受信側によって転送構文と対にされる。）を参照す

る。この抽象構文は，発信元が受信側に検索レコードに用いることを要求するものである。 

− 受信側が指定しているとき，それは，探索又は表示応答においてOID又は検索レコードを伴うPコン

テキストの形をとる。それは，転送構文と対になった抽象構文を参照する。 

3.7 

タイプ1及びタイプ101問合せ ここでは，問合せ型がタイプ1（又は101：下の備考2.参照）のと

きの手続を規定する。タイプ1は，“逆ポーランド表記法” (RPN) 問合せとなる。これは，次の構造をも

つ。 

RPN問合せ::＝引数 

            ｜引数＋引数＋演算子 

引数::＝オペランド｜RPN問合せ 

オペランド::＝属性リスト＋用語 

            ｜検索集合識別子｜限定 

63 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

限定::＝検索集合識別子＋属性リスト 

演算子::＝AND｜OR｜AND-NOT｜Prox 

上の表記法は，次のとおり用いる， 

::＝は，“として定義する”を意味する 

｜は，“又は”を意味する 

＋は，“が続く”を意味し，｜より優先度が高い（すなわち，＋は｜の前に評価される。）。 

備考1. タイプ1について，近接演算子及び限定オペランドは，第3版のためにだけ定義される。第2

版が有効な場合，タイプ1問合せの中に近接演算子又は限定オペランドを含むとプロトコル誤

りになる。 

2. タイプ101問合せは，近接演算子及び限定オペランドが第3版のためだけでなく，第2版の

ためにも同様に定義されていることを除いて，タイプ1問合せと同一のものと定義される。 

Z39.50に従う受信側は，タイプ1問合せを利用可能としなければならないが，タイプ1問合せを利用可

能とすることは，定義された演算子又はオペランドのすべてを利用可能とすることを意味しない。 

受信側は，どの問合せ型を利用可能としているか，どの演算子及びオペランドを利用可能としているか

を指示する。 

備考 受信側は，説明機能群又はこの規格外の機構を通じて，この情報を指示する。 

受信側が近接演算を利用可能としている場合，受信側は，近接演算に関して拡張検索集合モデル（3.1.6

に示す探索用拡張検索集合モデル，及び3.7.2.2に示す近接演算用のその特殊化）が利用可能かどうかも指

示することが望ましい。受信側が限定オペランドを利用可能としている場合，限定用拡張検索集合モデル

（3.7.3に示す探索用拡張検索集合モデルと限定用のその特殊化）も利用可能としなければならない。 

備考 近接演算子を利用可能とすることが，近接演算用拡張検索集合モデルを必要とするのは，特定

の状況（下に示す）においてだけである。しかし，限定オペランドを利用可能とすることは，

常に限定用拡張検索集合モデルを必要とする。 

3.7.1 

タイプ1及びタイプ101の問合せの表現及び評価 発信元では，問合せは，木で表現される。各部

分木は，オペランドを表す。オペランドは，単純オペランド又は複合オペランドのどちらかとする。各最

下位ノードは，単純オペランド，すなわち，検索集合識別子，属性リスト＋用語，又は限定を表す。最下

位でない各ノードは，複合オペランドを表す。これは，その最上位ノードが，一つの演算子である部分木

であり，左方のオペランドと右方のオペランドとの二つの部分木を含む。 

発信元は，左後順横断に従ってこの木をたどり，（単純）オペランド及び演算子の列を生成して，これを

受信側に送信する。 

受信側では，このオペランドと演算子の列の評価は，スタックの使用によって説明される。オペランド

がくると常にスタックに置く。演算子がくると常にスタックに置かれていた最後の二つのオブジェクトが

引き出され，次のように演算子が適用される。 

各オペランドは，データベースレコードの集合を表し，それぞれは，次のうちの一つとする。 

a) 属性リスト＋用語：データベースレコードの集合であり，探索要求の中で，指定されたデータベース

の集まりに対して，指定された属性集合及び用語を評価することによって得られる。 

b) 検索集合識別子：データベースレコードの集合であり，検索集合識別子で識別される一時的な検索集

合によって表される。 

c) 限定オペランド（検索集合識別子＋属性リスト）：データベースレコードの集合であり，検索集合識別

子で識別される検索集合によって表され，指定された属性集合によって限定される（3.7.3参照）。 

64 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

備考 限定オペランドが出現する場合，受信側は，限定用拡張検索集合モデルを利用可能としていな

ければならない。そうでない場合，問合せは，誤りとなる。 

d) 中間的な検索集合（スタック上に置かれた以前の評価結果）：その検索集合によって識別されるレコー

ドを表す。 

説明 S1及びS2をそれぞれ左及び右のオペランドによって表される集合とする。Sは，次のように定

義されるものとする。 

− 演算子がANDの場合，Sは，S1とS2の論理積とする。 

− 演算子がORの場合，Sは，S1とS2の論理和とする。 

− 演算子がAND-NOTの場合，Sは，S1にあり，S2にはない要素の集合とする。 

− 演算子がProxの場合， 

− 両オペランドがa)の形をしているとき，Sは，(S1 AND S2) 集合の部分集合でA ProxTest Bが真

となる（3.7.2.1参照）ものとする。ここにAとBとは，二つのオペランドとする。 

− その他の場合， 

− 受信側は，近接演算用拡張検索集合モデルを利用可能としていなければならない，そうでない場

合，問合せが誤りとなる。 

− R1及びR2は，集合S1及びS2を表す検索集合とする（すなわち，それぞれが次のいずれかと想

定する。）。 

− b)の形をしている場合，対応するオペランドが指定する検索集合。又は， 

− そうでない場合，そのオペランドで表現されるレコード集合を表す架空の検索集合。 

どちらの場合でも，R1及びR2の両方が近接用拡張検索集合モデルに適合していると想定する。 

R1及びR2の各項目は，位置ベクトル形式で位置情報を含む。R1及びR2の両者に含まれる各

レコードについて，R1の表すレコードと結びつけられた位置ベクトルとR2の表すレコードと結

びつけられた位置ベクトルとからなる順序対を考える。これらの各対でProxTestが真となるもの

について， 

− レコードは，集合Sに入れられ，かつ， 

− このレコードに対する演算結果集合での位置ベクトルが，対から作成される。 

集合S内のレコードを表す中間的な検索集合を作成しスタックに置く。問合せの評価が完了した（すな

わち，すべての問合せ用語が処理された）とき，スタック上にはただ一つのオブジェクトが，残っており

（そうでなければ問合せは，誤りとなる。），データベースレコードの集合を表し，これが，問合せの結果

となる。 

3.7.2 

近接 

3.7.2.1 

近接試験 近接試験ProxTestは，距離 (distance)，関係 (relation)，単位 (unit) 並びに順序 (ordered) 

及び除外 (exclusion) の二つの論理型フラグを含む。 

− 距離 二つのオペランドの位置を表す順序の差（例えば，単位が“段落”の場合，距離0は，“同一の

段落”を意味する。）。距離は，負数にはならない。 

− 関係 未満 (lessThan)，以下 (lessThanOrEqual)，等しい (equal)，以上 (greaterThanOrEqual)，より大 

(greaterThan)，等しくない (notEqual)。 

− 単位 文字 (character)，語 (word)，文 (sentence)，段落 (paragraph)，節 (section)，章 (chapter)，文書 

(document)，要素 (element)，部分要素 (subelement)，要素型 (elementType)，バイト (byte)，又は私的

に定義された単位 (private)。 

65 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 順序フラグ これがセットされた場合，試験は，“右方”近接だけとなる（左オペランドの順序数は，

右オペランドの順序数を超えてはならず，距離は，右オペランドと左オペランドとの順序数間の差に

相当する。）。そうでない場合，試験は，“右方”近接又は“左方”近接とする（距離は，左オペランド

及び右オペランドの順序数の差の絶対値に相当する。）。 

− 除外フラグ これがセットされると，演算に “not” が適用される（例えば，除外フラグ “FALSE” で

の試験が“hatから5語以内のcat”である場合，除外フラグ “TRUE” での試験は，“hatから5語以内

にないcat”と同一となる。）。 

例 A及びBが，それぞれ“個人名＝McGraw, J.”及び“個人名＝Stengel, C.”であり，かつ 

− 距離は0 

− 関係は“等しい” 

− 近接単位は“段落” 

− 順序フラグは “FALSE” 

− 除外フラグは “FALSE” 

と想定する。 

このときの結果は，同一段落内に両方の個人名が出現するレコード集合となる。同一の例を用いて，除

外フラグを “TRUE” に設定すると，その結果は，同一段落内にこの二つの個人名が同時に出現しないレコ

ードの集合となる。 

順序フラグを “TRUE”（除外フラグは，“FALSE”）に設定すると，その結果は，個人名 ʻMacGraw, J.ʼが，

個人名 ʻStengel, C.ʼと同一の段落内で，それより前に出現するレコードの集合となる。 

距離を1（順序及び除外フラグはともに “FALSE”）に変えると，その結果は，二つの個人名が隣接する

段落に存在するレコードの集合となる。さらに，関係種別が“以下”とすると，その結果は，二つの人名

が同一又は隣接した段落内に出現するレコードの集合となる。 

3.7.2.2 

近接用拡張検索集合モデル 近接用拡張検索集合モデルでは，受信側は，検索集合によって表現

される各レコードと結びつけられた一つ以上の位置ベクトルの形式で，位置情報を保持する。この位置情

報は，近接演算において，検索集合を作成した探索の代理として用いることができる。 

例 R1及びR2を ʻcatʼ 及び ʻhatʼ という用語のタイプ1問合せの探索によって作り出された検索集

合とする。近接用拡張検索集合モデルでは，受信側は，“R1近接R2”という近接演算の結果が“cat

近接hat”という近接演算の結果と等価の検索集合を与えるために，R1の各項目及びR2の各項

目と結びつけられた十分な情報を保持する（“近接”は，ここでは非公式に近接試験をさすために

用いている。）。 

受信側がこの情報を保持する方式は，この標準では規定しない。附属書13（参考）が事例を提供してい

る。 

3.7.3 

限定及び拡張検索集合モデル 限定オペランドは，一つの検索集合識別子と属性の集合とを指定す

る。それは，指定された検索集合によって識別され，指定された属性によって限定されるデータベースレ

コードの集合を表す。 

例 Rを “cat” という用語での探索によって生成された検索集合で，次の三つのレコードを表すとす

る， 

1) “cat” が，タイトル中に出現する， 

2) “cat” が，タイトル中に著者として出現する， 

3) “cat” が，タイトル中に著者として及び主題として出現する 

66 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ここで，“＜著者＞に限定されたR”は，Rの項目2と項目3からなる検索集合を生成する。 

限定用拡張検索集合モデルでは，受信側は，検索集合によって表現された各レコードと結びつけられた

情報を維持する。この情報は，限定オペランドの評価の際に，検索集合を作成した探索の代理として用い

ることができる。受信側がこの情報を維持する方式は，この規格では規定しない。附属書13（参考）で諸

例を示す。 

4. プロトコル仕様 ISO 23950 : 1998の4.Protocol Specificationによる。 

附属書1（規定） OID：Z39.50のオブジェクト識別子 ISO 23950 : 1998のAnnex 1 OID : Z39.50 Object 

Identifiersによる。 

附属書2（規定） CTX：応用コンテキスト基本Z39.50-ac ISO 23950 : 1998のAnnex 2 CTX : 

Application Contextbasic−Z39.50-acによる。 

附属書3（規定） ATR：属性集合 ISO 23950 : 1998のAnnex 3 ATR : Attribute Setsによる。 

附属書4（規定） ERR：誤り診断 ISO 23950 : 1998のAnnex 4 ERR : Error Diagnosticsによる。 

附属書5（規定） REC：レコード構文 ISO 23950 : 1998のAnnex 5 REC : Record Syntaxesによる。 

附属書6（規定） RSC：資源報告書式 ISO 23950 : 1998のAnnex 6 RSC : Resource Report Formats

による。 

附属書7（規定） ACC：アクセス制御書式 ISO 23950 : 1998のAnnex 7 ACC : Access Control Formats

による。 

附属書8（規定） EXT：この規格で規定する拡張サービス ISO 23950 : 1998のAnnex 8 EXT : Extended 

Services Defined by This Standardによる。 

附属書9（規定） USR：利用者情報書式 ISO 23950 : 1998のAnnex 9 USR : User Information Formats

による。 

附属書10（規定） ESP：要素指定書式 ISO 23950 : 1998のAnnex 10 ESP : Element Specification 

Formatsによる。 

附属書11（規定） VAR：選択可能形集合 ISO 23950 : 1998のAnnex 11 VAR : Variant Setsによる。 

附属書12（規定） TAG：タグ集合定義及びスキーマ ISO 23950 : 1998のAnnex 12 TAG : TagSet 

Definitions and Schemasによる。 

附属書13（参考） ERS：拡張検索集合モデル ISO 23950 : 1998のAnnex 13 ERS : Extended Result Set 

Modelによる。 

附属書14（参考） RET：Z39.50検索 ISO 23950 : 1998のAnnex 14 RET : Z39.50 Retrievalによる。 

附属書15（参考） PRO：Z39.50プロファイル ISO 23950 : 1998のAnnex 15 PRO : Z39.50 Profiles

による。 

附属書16（参考） この規格の維持機関 ISO 23950 : 1998のAnnex 16 Designation of Maintenance 

Agencyによる。 

参考 ISO 23950 : 1998 Information and documentation−Information retrieval (Z39.50) −Application 

service definition and protocol specification 

67 

X 0806 : 1999 (ISO 23950 : 1998) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

データベース表記・表現専門委員会 構成表（順不同） 

氏名 

所属 

（委員長） 

宮 澤   彰 

学術情報センター研究開発部 

糸 賀 雅 児 

慶應義塾大学文学部 

上 田 修 一 

慶應義塾大学文学部 

牛 崎   進 

立教大学図書館 

長 田 孝 治 

株式会社日本総合技術研究所情報システム部 

加 藤 信 哉 

東京大学附属図書館 

神 門 典 子 

学術情報センター研究開発部 

菊 地 亮 一 

明治大学図書館事務部 

岸 田 和 明 

駿河台大学文化情報学部 

北 原 圀 彦 

日外アソシエーツ株式会社編集局編集第一部 

倉 田 敬 子 

慶応義塾大学文学部 

荘 司 雅 之 

早稲田大学図書館 

菅 野 育 子 

愛知淑徳大学文学部 

杉 山 時 之 

国立国会図書館総務部 

鈴 木 正 紀 

文教大学越谷図書館 

田 村 貴代子 

国立国会図書館専門資料部 

橋 爪 邦 隆 

工業技術院標準部情報電気規格課 

長谷川 豊 祐 

鶴見大学図書館 

平 井 邦 造 

株式会社KMKデジテックスC･E･O 

松 本 浩 一 

図書館情報大学図書館情報学部 

村 上 正 志 

国立国会図書館総務部 

森   宗 正 

規格調整専門委員会委員 

門 條   司 

株式会社三洋ソフトウェアサービス経営企画部 

安 江 明 夫 

国立国会図書館総務部 

渡 辺 信 一 

大日本印刷株式会社C＆I企画開発センター 

栗 原 晃 雄 

工業技術院標準部情報電気規格課 

（事務局） 

芝 山 茂 男 

財団法人日本規格協会 

データベース表記・表現専門委員会JIS原案作成分科会 構成表（順不同） 

氏名 

所属 

（主査） 

田 村 貴代子 

国立国会図書館収集部 

宮 澤   彰 

学術情報センター研究開発部 

上 田 修 一 

慶應義塾大学文学部 

長 田 孝 治 

株式会社日本総合技術研究所情報システム部 

加 藤 信 哉 

東京大学附属図書館 

菊 地 亮 一 

明治大学図書館事務部 

岸 田 和 明 

駿河台大学文化情報学部 

荘 司 雅 之 

早稲田大学図書館 

杉 山 時 之 

国立国会図書館総務部 

鈴 木 正 紀 

文教大学越谷図書館 

長谷川 豊 裕 

鶴見大学図書館 

平 井 邦 造 

株式会社KMKデジテックスC･E･O 

村 上 正 志 

国立国会図書館総務部 

森   宗 正 

規格調整専門委員会委員 

栗 原 晃 雄 

工業技術院標準部情報電気規格課 

（事務局） 

芝 山 茂 男 

財団法人日本規格協会