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

 

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 

適用範囲 

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

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

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

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

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

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

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

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

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

意が必要である。 

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

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) から抜き出されたもの


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/"  


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")は,互換性があると

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

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

定することはできない。 

 

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

このプロファイルに対して適合しているということは,このプロファイルの適用範囲 (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に対する条件付きの要件を課す。すなわち,大部分の場合には適合性を維持する

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

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


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) によって更に詳細化される。引用規格は拡

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

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

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

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

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

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


X 7363:2010 (ISO/IEC 29363:2008) 

 

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

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

形をとるかもしれない。 

このプロファイルの適用範囲は,附属書Aの引用規格によって定義され,附属書Bの拡張点によって詳

細化される。 

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"である。 

 

メッセージ送受信 

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

 

・ 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 参照)ではこの名前空間宣


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)。 

 

記述 

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

 

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


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の3に定義されているように,

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

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

 


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)  

 

 


X 7363:2010 (ISO/IEC 29363:2008) 

 

附属書B 

(参考) 

拡張点 

 

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


10 

X 7363:2010 (ISO/IEC 29363:2008) 

 

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

 

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

 

・ 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の意味をくみ取って,“抽象的なインタフ

ェース仕様”と訳した。