>サイトトップへ >このカテゴリの一覧へ

X 7363

:2010 (ISO/IEC 29363:2008)

(1)

目  次

ページ

序文

1

1

  適用範囲及び序論

1

1.1

  適用範囲

1

1.2

  他のプロファイルとの関係

1

1.3

  表記法

2

1.4

  プロファイル識別及び版数

3

2

  プロファイルに対する適合性

3

2.1

  適合性の要件

3

2.2

  適合性の対象

4

2.3

  適合性の適用範囲

4

2.4

  適合性の表示

5

3

  メッセージ送受信

5

3.1

  メッセージシリアライゼーション

5

4

  記述

6

4.1

  バインディング

7

附属書 A(規定)引用規格

8

附属書 B(参考)拡張点

9

附属書 C(参考)参考規格

10

附属書 D(参考)謝辞

11

附属書 JA(参考)用語集

12


X 7363

:2010 (ISO/IEC 29363:2008)

(2)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,独立行政法人情報処理推進機構 (IPA) から,

工業標準原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,経

済産業大臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権及び出願公開後の実用新案登録出願にかかわる確認について,責

任はもたない。


日本工業規格

JIS

 X

7363

:2010

(ISO/IEC 29363

:2008

)

Web

サービス相互運用性−

WS-I

シンプル SOAP バインディング

プロファイル 1.0

Information technology

−Web Services Interoperability−

WS-I Simple SOAP Binding Profile Version 1.0

序文

この規格は,2008 年に第 1 版として発行された ISO/IEC 29363 を基に,技術的内容及び対応国際規格の

構成を変更することなく作成した日本工業規格である。

なお,この規格の

附属書 JA は,対応国際規格にはない事項である。

1

適用範囲及び序論

1.1

適用範囲

この規格は,WS-I Simple SOAP Binding Profile 1.0(以下,このプロファイルという。

)を定義する。この

プロファイルは非占有的 (non-proprietary) な Web サービス規格で構成され,相互運用性を向上させる規定

の明確化及び強化 (amplify) を含んでいる。

箇条 は,このプロファイルを紹介し,他のプロファイルとの関係を示す。

箇条 は,このプロファイルに適合するとはどういう意味かを説明する。

それに続く各箇条は,このプロファイルの構成要素となるそれぞれの規格について示すもので,次の二

つの部分からなる。すなわち,構成要素となる規格及び拡張点 (extensibility point) を列挙した概要規定と,

それに続いて,構成要素となる規格の個別の部分について示した細分箇条との二つの部分である。この規

格の箇条番号と,

附属書 に列挙されている)引用規格の箇条番号との間には何の関係もないことに注

意が必要である。

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

ISO/IEC 29363:2008

,Information technology−Web Services Interoperability−WS-I Simple SOAP

Binding Profile Version 1.0 (IDT)

なお,対応の程度を表す記号 (IDT) は,ISO/IEC Guide 21-1 に基づき,

“一致している”こ

とを示す。

1.2

他のプロファイルとの関係

このプロファイルは,エンベロープのシリアライズ及びメッセージの表示に関連した Basic Profile 1.0 の

要求事項に由来しており,これまでの Basic Profile 1.0 の正誤表も反映されている。これらの要件は JIS X 

7361:2010

(Web サー ビス相 互運 用 性− WS-I  ベ ーシ ック プロフ ァイル 1.1)(ISO/IEC 29361:2008,

Information technology

−Web Services Interoperability−WS-I Basic Profile Version 1.1)  から抜き出されたもの


2

X 7363

:2010 (ISO/IEC 29363:2008)

となっており,他のプロファイルをこのプロファイルと組み合わせて構成することができるようになって

いる。

JIS X 7361:2010 (ISO/IEC 29361:2008)

及び Simple SOAP Binding Profile 1.0 の適合性要求を組み合わせた

ものは,おおよそ Basic Profile 1.0 の適合性要求に相当している。

JIS X 7361:2010 (ISO/IEC 29361:2008)

を基に作成されたこのプロファイルは,Basic Profile 1.0 に優先す

る。

1.3

表記法

この規格では,

“…しなければならない (MUST,SHALL)”

“…してはならない (MUST NOT,SHALL

NOT)

”,“必す(須)の… (REQUIRED)”,“…することが望ましい (SHOULD)”,“…しないほうがよい

(SHOULD NOT)

”,“ 推 奨 の …  (RECOMMENDED) ”,“ … し て も よ い  (MAY) ” 及 び “ 省 略 可 能 の …

(OPTIONAL)

”の用語は,RFC2119 (http://www.ietf.org/rfc/rfc2119.txt)  に記述されているとおりに解釈する。

このプロファイルにおける要件(すなわち,2.1 に説明されている,適合性に影響するもの)は,次の形

式で提示される。

Rnnnn

要件の文章がここに入る。

ただし,ここで  "nnnn"  は,このプロファイル内で一意の要件番号で置き換えられ,一意の要件識別子

(unique requirement identifier)

を構成する。

要件識別子 (requirement identifier) は,Namespaces in XML 1.0(JIS X 4158:2005  XML 名前空間)の

QName

と互換性をもつように,名前空間修飾されている (namespace qualified) とみなすことができる。あ

る要件の識別子に明示的な名前空間接頭辞が存在しない場合(例えば,"bp10:R9999"ではなく"R9999"  の

ような場合。

,その要件が存在する規格の箇条の適合性 URI (conformance URI) によって識別される名前

空間に属すると解釈するのが望ましい。名前空間修飾されている場合,その接頭辞は,次に記述するとお

り,そこで有効な名前空間の対応付けに従って解釈するのが望ましい。

幾つかの要件は,引用規格を明確化するだけで,実装に対して追加の制約を課さないものである。便宜

のため,規定の明確化 (clarification) は,次の例のように規定の後に“

〔明確化〕

”という注意を付けて表現

する。

例  Rnnnn  ……は,……でなければならない。

〔明確化〕

幾つかの要件は,引用規格の標準化されつつある内容を取り入れたものである。便宜上,そのような規

格の先取りは,次のように注記される: xxxx,ただし,ここで "xxxx" は規格を示す識別子である(例えば,

"WSDL20"

は WSDL 2.0 を示す。

。そのような規格は,この規格の対応国際規格の発行時点では完成してお

らず,先取りした規格が変更されることもあり得ることに注意が必要である。この情報は,実装者に対す

る便宜としてだけ含められている。

この規格では,全体を通して次に示す幾つかの名前空間接頭辞 (namespace prefix) を使用する。各接頭

辞に関連付けられた URI を次に示す。名前空間接頭辞は,任意に選択したものであり,どのような文字列

を選択しても意味的に差異がないことに注意が必要である。

・  wsdl−"http://schemas.xmlsoap.org/wsdl/"


3

X 7363

:2010 (ISO/IEC 29363:2008)

・  soapbind−"http://schemas.xmlsoap.org/wsdl/soap/"

・  uddi−"urn:uddi-org:api_v2"

1.4

プロファイル識別及び版数

この規格は,名前(この場合,Simple SOAP Binding Profile)及び版数(ここでは 1.0)で識別される。

両方を合わせて,特定の

プロファイルインスタンス  (profile instance)  を識別する。

版数の番号はメジャー番号及びマイナー番号で構成され,"メジャー番号.マイナー番号"の形式となる。

これらは,

プロファイルの優先度を決定するのに利用できる。

(メジャー番号及びマイナー番号の両方を考

慮して)版数の番号が大きい場合,そのインスタンスは新しく,それ以前のインスタンスを置き換える。

同じ名前のプロファイルの複数のインスタンス(例えば,"Example Profile 1.1","Example Profile 5.0")

は,同じ一般的な適用範囲内にある相互運用性の問題に言及している(もっとも,状況の進展によって,

プロファイルの厳密な適用範囲がインスタンスの間で変わることがある。

この情報は,あるプロファイルの二つのインスタンスが後方互換 (backwards-compatible) であるかどう

か(すなわち,前のプロファイルインスタンスへの適合が後のプロファイルインスタンスへの適合を暗示

するものと想定できるかどうか。

)を判断するために使用できる。同じ名前とメジャー番号とをもつ複数の

プロファイルインスタンス(例えば,"Example Profile 1.0"及び"Example Profile 1.1")は,互換性があると

考えてもよい。これは,逆方向への互換性を暗示するものではないことに注意が必要である。すなわち,

後のプロファイルインスタンスへの適合は,前のプロファイルインスタンスへの適合を暗示するものと想

定することはできない。

2

プロファイルに対する適合性

このプロファイルに対して適合しているということは,このプロファイルの

適用範囲  (scope)  内で,特

定の

対象  (target)  に対する要件  (requirements)  の集合を守ることであると定義されている。この箇条では,

これらの用語について説明し,どのように適合性が定義され使用されるかを説明する。

2.1

適合性の要件

要件 (requirements) は,このプロファイルに対する適合性の基準を提示する。要件は,典型的には既存

の規格を引用し,そこでの相互運用性を向上する詳細化,強化 (amplify),解釈及び明確化を具体化したも

のである。このプロファイルのすべての要件は規定 (normative) と解釈され,引用規格のうちの適用範囲

内の要件(2.3 参照)も同様に規定と解釈するのが望ましい。このプロファイルの要件と引用規格の要件と

が互いに矛盾する場合,プロファイル適合性の観点からは,このプロファイルの要件が優先される。

要件レベルは,RFC2119 (http://www.ietf.org/rfc/rfc2119.txt)  の用語(例えば,MUST,MAY,SHOULD)

を使い,要件の性質と適合性に対する影響力とを示す。個々の要件記述は,便宜上,個別に(R9999  のよ

うな)番号が振られている。

次に例を示す。

R9999  WIDGET

は,丸い形状であることが望ましい

  (SHOULD)

この要件は"R9999"という識別子で識別され,適合性対象 WIDGET に対して適用され(適合性対象につ

いては後述。

,WIDGET に対する条件付きの要件を課す。すなわち,大部分の場合には適合性を維持する

ためにこの要件は満足しなければならないが,それを満足しない正当な理由がある場合もある(それは,

要件それ自体又は付随する文章で説明される。


4

X 7363

:2010 (ISO/IEC 29363:2008)

それぞれの要件は,ちょうど一つの要件レベルキーワード(例えば,"MUST")と適合性対象キーワー

ド(例えば,"MESSAGE")とをもつ。補足の文章(根拠,例など)が要件を明確にするために付け加え

られることもあるが,要件記述そのものだけが適合性を判定するときに考慮されなければならない。

このプロファイルの用語定義は,適合性を決定するという用途において権威あるものとみなされる。

このプロファイルの要件はいずれも,適合性レベルに関係なく,現実の脅威又は想定される脅威[例え

ば,サービス妨害攻撃  (denial of service attack)]に対応して,それ以外の点では適合している実装がセキュ

リティ対策を講じる能力を制限するものと解釈しない方がよい。

2.2

適合性の対象

適合性対象 (conformance target) は,どの対象物 (artifact)(例えば,SOAP メッセージ,WSDL 記述,UDDI

レジストリデータ)又はどの主体 (party)(例えば,SOAP 処理系,エンドユーザ)に要件が適用されるか

を識別するのに使われる。

これによって,異なる文脈における適合性の定義であっても,要件の適用可能性をあいまい(曖昧)性

なく解釈されることが保証され,さらに,対象物(例えば,SOAP メッセージ,WSDL 記述)及び各種の

Web

サービスの主体(例えば,クライアント,サービスのインスタンス)の動作に対する適合性試験が可

能となる。

試験を単純にし,あいまい(曖昧)性を排除するため,要件の適合性対象は可能な限り物理的な対象物

である。

このプロファイルでは,次の適合性対象を使用する。

・  ENVELOPE − soap:Envelope 要 素 及 び そ の 内 容 を シ リ ア ラ イ ズ し た も の 及 び そ の 内 容   [JIS X 

7361:2010 (ISO/IEC 29361:2008)]

・  MESSAGE−ENVELOPE を伝送する,プロトコル構成要素(例えば,SOAP/HTTP  メッセージ)[JIS X 

7361:2010 (ISO/IEC 29361:2008)]

・  DESCRIPTION−データ型の記述,メッセージの記述,インタフェース及びそれらの具体的なプロト

コル・データ形式へのバインディングの記述,並びに Web サービスに関連付けられたネットワーク上

のアクセスポイントの記述(例えば,WSDL 記述)[JIS X 7361:2010 (ISO/IEC 29361:2008)]

・  INSTANCE−wsdl:port 要素又は uddi:bindingTemplate 要素を実装するソフトウェア  [JIS X 7361:2010

(ISO/IEC 29361:2008)]

・  RECEIVER−関連付けされたプロトコルに基づき,メッセージを受信 (consume) するソフトウェア

(例えば,SOAP  処理系)[JIS X 7361:2010 (ISO/IEC 29361:2008)]

2.3

適合性の適用範囲

このプロファイルは,既存の技術を採用(引用)し,その明確化を行う。言い換えれば,このプロファ

イルは,その適用範囲の中での相互運用性を向上することだけを図っている。一般的には,このプロファ

イルの適用範囲は,その引用規格によって限定される。

このプロファイルの適用範囲は,拡張点 (extensibility point) によって更に詳細化される。引用規格は拡

張メカニズム,及び未規定の又は未確定の構成パラメタを提供していることがある。このプロファイルで

拡張点と認識された場合,そのようなメカニズム又はパラメタはこのプロファイルの適用範囲外であり,

それを使っても使わなくてもこのプロファイルに対する適合性において意味をもたない。

このプロファイルは,さらに,拡張点の使用について,その範囲を制限することなく,要件を課すこと

がある。また,拡張点の特定の使用方法について,このプロファイルが他のプロファイルと組み合わせて

使われた場合に,相互運用性を向上するために,他のプロファイルで制限されることがある。


5

X 7363

:2010 (ISO/IEC 29363:2008)

拡張点の使用は相互運用性を損なうことがあるので,その使用は Web サービスの関係者によって何ら

かの形で個別協議するか,文書化するのが望ましい。例えば,これは個別合意 (out-of-band agreement) の

形をとるかもしれない。

このプロファイルの適用範囲は,

附属書 の引用規格によって定義され,附属書 の拡張点によって詳

細化される。

2.4

適合性の表示

こ の プ ロ フ ァ イ ル に 対 す る 適 合 性 の 表 示 は , Conformance Claim Attachment Mechanisms

(http://www.ws-i.org/Profiles/ConformanceClaims-1.0.html,適合性表示添付メカニズム)の記述に従い,次

に示す各メカニズムを使って行うことができる。この場合,各メカニズムが列挙する対象物に関連付けら

れた,このプロファイルの適用可能要件が満足されていることが条件となる。

・  Web

サービスインスタンスに対する WSDL 1.1 適合性表示添付メカニズム−MESSAGE

DESCRIPTION

  INSTANCE  RECEIVER

・  WSDL

記述の構造に対する  WSDL 1.1 適合性表示添付メカニズム−DESCRIPTION

・  Web

サービスインスタンスに対する UDDI 適合性表示添付メカニズム−MESSAGE  DESCRIPTION

INSTANCE

  RECEIVER

このプロファイルの適合性表示 URI は,"http://ws-i.org/Profiles/SimpleSoapBinding/1.0"である。

3

メッセージ送受信

プロファイルのこの箇条では次の規格を引用し,その中での拡張点を定義する。

・  Simple Object Access Protocol (SOAP) 1.1  (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)

・  Extensible Markup Language (XML) 1.0 (Second Edition)

(http://www.w3.org/TR/2000/REC-xml-20001006)

・  Namespaces in XML 1.0(JIS X 4158:2005  XML 名前空間)

(http://www.w3.org/TR/1999/REC-xml-names-19990114/)

・  RFC2616: Hypertext Transfer Protocol−HTTP/1.1(http://www.ietf.org/rfc/rfc2616.txt)

3.1

メッセージシリアライゼーション

SOAP 1.1

は,メッセージを伝送するための XML 構造(エンベロープ)を定義している。このプロファ

イルは,この構造を使用することを必す(須)としており,その利用方法について,次の制約を定める。

3.1.1

XML

エンベロープシリアライゼーション

R9700  MESSAGE

は,エンベロープを

HTTP

実体本体の排他的ペイロードとしてシリアライズ

しなければならない

  (MUST)

R9701  MESSAGE

は,エンベロープを

 XML 1.0

としてシリアライズしなければならない

 

  (MUST)

R9702  MESSAGE

は,

HTTP

ヘッダフィールド

"Content-Type"

をもたなければならない

 

  (MUST)

R9703  MESSAGE

HTTP

ヘッダフィールド

"Content-Type"

は,メディア型が

 "text/xml"

のフ

ィールド値をもたなければならない

  (MUST)

3.1.2

XML

名前空間宣言

公開された正誤表 NE05(http://www.w3.org/XML/xml-names-19990114-errata  参照)ではこの名前空間宣


6

X 7363

:2010 (ISO/IEC 29363:2008)

言が現れてもよいことになっているが,

以前の処理系の中にはこうした宣言をエラーとみなすものもある。

この要件は,適合対象物ができるだけ広範囲の相互運用性をもてるようにしている。

R9704  ENVELOPE

は,名前空間宣言

xmlns:xml="http://www.w3.org/XML/1998/namespace"

を含ま

ないほうがよい

  (SHOULD NOT)

〔明確化〕

3.1.3

Unicode

のバイト順マーク

XML 1.0

では UTF-8 エンコーディングにバイト順マークを含めてもよいことになっているため,エンベ

ロープの受信側はそれを受け入れるように用意されていなければならない。UTF-16 としてエンコードされ

た XML の場合,バイト順マークは必す(須)である。

R4001  RECEIVER

は,

Unicode

のバイト順マーク

  (BOM) 

を含むエンベロープを受け入れなけ

ればならない

  (MUST)

〔明確化〕

 

3.1.4

XML

宣言

XML

宣言の有無は相互運用性に影響しない。ある種の実装は,XML シリアライゼーションの前に常に

XML

宣言を置くかもしれない。

R1010  RECEIVER

は,

XML

宣言を含むエンベロープを使用したメッセージを受け入れなけれ

ばならない。

〔明確化〕

3.1.5

文字エンコーディング

このプロファイルは,相互運用性を促進するために,XML 処理系が"UTF-8"及び"UTF-16"の文字エンコ

ーディングをサポートすることを要求する。

したがって,エンベロープに"text/xml"メディア型(デフォルトの文字エンコーディングは"us-ascii")を

使用するという SOAP 1.1 の要件に合わせ,エンベロープのコンテンツ型には,必ず"charset"パラメタが存

在しなければならない。さらに,この結果として,メッセージ内の XML 宣言のエンコーディング擬似属

性は,XML 1.0 及び RFC3023 "XML Media Types"の両方の要件に基づいて常に無視される。

メッセージの正しい文字エンコーディングを判断するには,HTTP ヘッダフィールド Content-Type の

"charset"

パラメタが使用されなければならない。"charset"パラメタがない場合は,文字セットのデフォルト

値 ("us-ascii") が使用されなければならない。

R1012  MESSAGE

は,

UTF-8

又は

UTF-16

のいずれかの文字エンコーディングを使用してエン

ベロープをシリアライズしなければならない

  (MUST)

R1018  MESSAGE

"Content-Type"HTTP

ヘッダフィールド値は,

"charset"

パラメタを使用し

て正しい文字エンコーディングを示さなければならない

  (MUST)

〔明確化〕

R1019  RECEIVER

は,メッセージ内のエンベロープの

XML

宣言のエンコーディング擬似属性

を無視しなければならない

  (MUST)

4

記述

プロファイルのこの箇条では,次の規格を引用し,その中での拡張点を定義する。

・  WSDL 1.1 の 3 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap-b)


7

X 7363

:2010 (ISO/IEC 29363:2008)

WSDL 1.1

は,SOAP エンベロープとしてシリアライズされたメッセージを記述するための SOAP バイン

ディング拡張を定義している。このプロファイルは,この構造を使用することを必す(須)としており,

その利用方法について,次の制約を定める。

4.1

バインディング

4.1.1

SOAP

バインディング拡張

このプロファイルは,WSDL バインディングの選択肢を,十分に定義され,最も一般的に利用されてい

る WSDL SOAP バインディングに限定している。WSDL 1.1 で定義された,HTTP GET/POST 及び MIME

に対するバインディングの拡張仕様,並びにその他の添付データに関する技術は,このプロファイルでは

許可されない。

R9802  DESCRIPTION

の中の

wsdl:binding

要素は,

WSDL 1.1

3

で定義された

WSDL 

SOAP

バインディングだけを使用しなければならない

  (MUST)

R9800  DESCRIPTION

の中では,伝送時のメッセージがプロファイルに適合しない原因となる

 

WSDL

バインディング拡張の要素及び属性が使用されてはならない

  (MUST NOT)

〔明

確化〕

R9801  DESCRIPTION

の中では,

WSDL

MIME

及び

HTTP GET/POST

,並びに

DIME

バイン

ディング拡張が,

SOAP

バインディングに現れてはならない

  (MUST NOT)

〔明確化〕

ここでは,適合する wsdl:binding 要素の構築についての要件を課していることに注意する。これは,

記述 (description) 全体に対する要件を課しているわけではない。特に,WSDL 文書が,適合しない

wsdl:binding

要素をもつことを禁止しているわけではない。

4.1.2

バインドされていない portType 要素の内容

WSDL 1.1

では,wsdl:binding 要素が wsdl:portType 要素で定義された内容の一部分に対するバイ

ンディングを指定しないことについて,それが許容されるかどうかが明記されていない。

R2209  DESCRIPTION

の中の

wsdl:binding

要素は,そのバインディングが参照する

wsdl:portType

要素に属する

wsdl:message

要素の各

wsdl:part

要素を,

soapbind:body

要素,

soapbind:header

要素,

soapbind:fault

要素,又は

soapbind:headerfault

要素のいずれかにバインドすることが望ましい

  (SHOULD)

portType

は,operation 要素の組とそれに関連付けられた抽象的な message 要素群とをもつ抽象的なイン

タフェース仕様 (abstract contract) に名前を付けたものである。禁止されているわけではないが,portType

の中の抽象的な input 要素,output 要素及び fault 要素から参照される message 要素内のそれぞれの part 要

素 は , SOAP  バ イ ン デ ィ ン グ を 使 用 す る と き に は , WSDL 1.1 の に 定 義 さ れ て い る よ う に ,

soapbind:body

要素,soapbind:header 要素などに適切にバインドされることが想定されている。バ

インドされていない wsdl:part 要素は無視されるのが望ましい。


8

X 7363

:2010 (ISO/IEC 29363:2008)

附属書 A

規定)

引用規格

次の規格の要件は,このプロファイルで置き換えられたものを除き,引用することでこのプロファイル

に取り込まれている。

・  Namespaces in XML 1.0 (http://www.w3.org/TR/1999/REC-xml-names-19990114/)

注記  JIS X 4158:2005  XML 名前空間は,Namespaces in XML 1.0

(http://www.w3.org/TR/1999/REC-xml-names-19990114/)

に対応している。

・  Simple Object Access Protocol (SOAP) 1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)

・  Extensible Markup Language (XML) 1.0 (Second Edition) (http://www.w3.org/TR/2000/REC-xml-20001006)

注記  JIS X 4159:2005  拡張可能なマーク付け言語 (XML) 1.0 は,Extensible Markup Language

(XML) 1.0 (Third Edition)

  (http://www.w3.org/TR/2004/REC-xml-20040204)  に対応している。

・ RFC2616: Hypertext

Transfer

Protocol

−HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt)

・ WSDL

1.1

の 3 (http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap-b)


9

X 7363

:2010 (ISO/IEC 29363:2008)

附属書 B

参考)

拡張点

この規格には,拡張点はない。


10

X 7363

:2010 (ISO/IEC 29363:2008)

附属書 C 

参考)

参考規格

附属書 に列挙されている,このプロファイルに取り込まれた規格に加えて,次の規格が参照される。

・  RFC2119, http://ietf.org/rfc/rfc2119, Key words for use in RFCs to IndicateRequirement Levels, S. Bradner,

March 1997.

・  WS-I Basic Profile 1.0, http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html, K. Ballinger et al.,

April 2004.

・  Namespaces in XML 1.0(XML 名前空間 1.0)(Second Edition),

http://www.w3.org/TR/2006/REC-xml-names-20060816, T. Bray et al.,August 2006.

・  WS-I Conformance Claim Attachment Mechanisms Version 1.0,

http://www.ws-i.org/Profiles/ConformanceClaims-1.0-2004-11-15.html, M.Nottingham et al., November

2004.


11

X 7363

:2010 (ISO/IEC 29363:2008)

附属書 D 

参考) 
謝辞

(対応国際規格では,規格策定の貢献者を列挙しているが,この規格では不要であり,不採用とした。


12

X 7363

:2010 (ISO/IEC 29363:2008)

附属書 JA

参考)

用語集

この附属書は,用語の使用方法の例を示すものであり,規定の一部ではない。

JA.1  

バインディング  (binding)

バインディングは,サービスの仕様を表現したインタフェースと,インタフェースで定義されたメッセ

ージを伝送するための具体的な伝送プロトコル及びデータフォーマットとを関連付けるものである。バイ

ンディングの指定は,SOAP バインディング,HTTP バインディングなどそれぞれの箇所で行う。

JA.2  

バイト順マーク  (BOM)

データの記録・送信を行うときのバイトの並び順パターンであるエンディアン (big-endian,little-endian)

を識別するために,ファイルの先頭に付与される符号。

JA.3

コンテンツ型  (Content-Type)

HTTP

プロトコルにおいて,やり取りされるデータの形式を指定するためのヘッダフィールド。メディ

ア型が指定される。MIME パートのデータ形式を指定する場合にも Content-Type ヘッダフィールドが用い

られるが,この規格で規定しているのは HTTP のヘッダフィールドについてだけである。

JA.4

名前空間  (namespace)

特定の XML 標準スキーマによって定められた要素名及び属性名の集合。XML インスタンスでは,要素

を“名前空間接頭辞:要素名”

,属性を“名前空間接頭辞:属性名”という形式で記述する。名前空間接頭

辞によって,要素及び属性がどの名前空間に属するかを見分ける。この書き方を使って,複数の XML ス

キーマで定義された要素及び属性を,一つの XML インスタンス内で混在させて使うことができる。

JA.5

シリアライゼーション,シリアル化  (serialization)

SOAP

で RPC を行うためには,メソッドの引数及び戻り値に使われる変数,配列,オブジェクトなどを

XML

文書に変換したり,元に戻したりする必要がある。データを XML 文書に変換することを“エンコー

ド”又は“シリアライズ”

,元に戻すことを“デコード”又は“デシリアライズ”という。シリアライゼー

ションは,シリアライズする行為である。


13

X 7363

:2010 (ISO/IEC 29363:2008)

JA.6

抽象的なインタフェース仕様  (abstract contract)

対応国際規格において,WSDL の portType を,abstract contract を定義するものと表現している。WSDL

は,送信者と受信者との間でメッセージをやり取りするときの取決めのようなものなので,contract という

表現となっている。また,portType はオペレーション及び入出力メッセージを抽象的なレベルで定義して

おり,それらは binding によって具体化されるものであるため,abstract が使われている。

この規格においては,文章を分かりやすくするため,portType の意味をくみ取って,

“抽象的なインタフ

ェース仕様”と訳した。