Copyright © 2002-2004 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. All Rights Reserved.
This document is a translation of a Web Services-Interoperability Organization document. In the event of a disagreement between this translation and the English version, or an omission in this translation, the original English document should be considered the definitive source.
この文書は Web Services-Interoperability Organization (WS-I) の文書の翻訳である。 この翻訳と英語版との間に食い違いがあった場合,又は,翻訳に省略がある場合,原文の英語文書が決定版として扱われるべきである。
Copyright © 2002-2004 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. All Rights Reserved.
この文書では WS-I Attachments Profile 1.0 を定義する。 このプロファイルは非占有的 (non-proprietary) な Web サービス仕様の集合で構成され,相互運用性を向上する目的で仕様の明確化と修正を進めたものである。 このプロファイルは, SOAP Messages with Attachments に基づいた Webサービスへのサポートを追加することで, WS-I Basic Profile 1.1 を補完している。
これは最終仕様 (final specification) である。 正誤表に 規定の修正を含むことがあるので,参照されたい。
ここに含まれる内容は,この内容の著者若しくは開発者又は WS-I が所有又は管理する知的財産権に対するライセンスを,明示的にも暗示的にも示すものではない。 ここに含まれる内容はそのまま (AS IS) の形式で提供され,適用可能な法律に許される最大限の範囲において,そのままの形で欠陥を含んだまま (AS IS AND WITH ALL FAULTS) 提供される。 この内容の著者及び開発者並びに WS-I は,ここに,明示的,暗示的,又は法定による, 市場性,特定目的への適用性,応答の精度若しくは完全性,結果,職人的努力,ウィルスがないこと,又は過失のないことについての, 暗示的な保証,義務又は条件を含む (しかし,それに限定されない), その他すべての保証及び条件を否認する。 さらに, この内容に関する権利,安全な居住,安全な所有,記述への対応又は侵害不在性について,いかなる保証又は条件も存在しない。
この内容の著者若しくは開発者又は WS-I のいずれも, 他者に対して, 損害の可能性の事前通告の有無にかかわらず, これ又はこの内容についてのその他のいかなる合意によって起こされる損害に対して, 契約,不法行為,保証その他による, 代替する物資若しくは服務の購入,逸失利益,用途損失,データ損害,又はいかなる偶発的,結果的,直接,間接,若しくは特別な損害を補償する責任を持たない。
可能な限り最良の相互運用性ガイドを提供するため, この仕様に不明確な点がある場合や,誤り又は抜けが発見された場合, WS-I に連絡されたい。
メールの送信又はその他の手段で WS-I に対して通信することによって,あなた (個人を代表する場合はあなた自身,会社を代表してフィードバックを送る場合はあなたの会社) は,WS-I, WS-I のメンバー及びその他あなたのフィードバックをアクセスできる者に対して,この文書についてあなたが提供するフィードバックに対する,使用,公開,複写,ライセンス,修正,サブライセンス,その他いかなる形式による配布及び活用に対しても,非制限的で,譲渡不可能な,国際的で,永続的で,取り消し不可能な,ロイヤリティなしのライセンスを許諾するものとみなされる。 あなたは,あなたが提供するいかなるフィードバックに対しても,秘匿性についていかなる期待ももたないことに同意しなければならない。 あなたは,あなたがフィードバックを送る権利をもつことを表明し,保証しなければならない。あなたが会社を代表してフィードバックを送る場合,あなたが会社を代表してフィードバックを送る権利をもつことを表明し,保証しなければならない。 WS-I には,この文書の将来の版において,あなたのフィードバックの一部又は全部をレビューし,議論し,使用し,検討し,あるいはいかなる方法においても取り入れる義務はないということも,あなたは同意しなければならない。WS-I がこの文書の将来の版にあなたのフィードバックの一部又は全部を取り入れる場合,WS-I は,この文書の貢献者のリストにあなたの名前 (又は,あなたが会社を代表する場合には,会社の名前) を入れるかもしれないが,そうする義務はない。 上記の内容があなた又はあなたが代表する会社にとって受け入れられない場合,いかなるフィードバックも送らないでほしい。
この文書に対するフィードバックは wsbasic_comment@ws-i.org に送ること。
1. Introduction (序文)
1.1. Relationship to other Profiles (他のプロファイルとの関係)
1.2. Notational Conventions (表記)
1.3. Profile Identification and Versioning (プロファイルの識別と版数)
2. Profile Conformance (プロファイルに対する適合性)
2.1. Conformance Requirements (適合性の要件)
2.2. Conformance Targets (適合性の対象)
2.3. Conformance Scope (適合性の適用範囲)
2.4. Claiming Conformance (適合性の表示)
3. Attachments Packaging (添付ファイルのパッケージング)
3.1. Root Part (ルートパート)
3.2. Encoding of Root Part (ルートパートのエンコーディング)
3.3. Media Type of Message (メッセージのメディア型)
3.4. Messages with No Attachments (添付ファイルをもたないメッセージ)
3.5. Dereferencing Attachments (添付ファイルの参照値読出し)
3.6. Carrying Additional SOAP Envelopes (追加の SOAP エンベロープの添付)
3.7. Fault Messages with Attachments (添付ファイルをもつフォルトメッセージ)
3.8. Value-space of Content-Id Header (Content-Id ヘッダーの値空間)
3.9. Ordering of MIME Parts (MIME パートの順序)
3.10. Position of Root Part (ルートパートの位置)
3.11. Content-Transfer-Encoding (Content-Transfer-Encoding)
3.12. MIME Boundary String (MIME 境界文字列)
4. Attachments Description (添付ファイルの記述)
4.1. Use of MIME Binding Extension (MIME バインディング拡張の使用)
4.2. Unbound portType Element Contents (バインドされていない portType 要素の内容)
4.3. Referencing Message Parts (メッセージのパートの参照)
4.4. Referencing Attachments from the SOAP Envelope (SOAP エンベロープからの添付ファイルの参照)
4.5. Specifying Root Part (ルートパートの指定)
4.6. Specifying SOAP Headers in Root Part (ルートパートにおける SOAP ヘッダーの指定)
4.7. MIME Binding Schema Fixes (MIME バインディングスキーマの修正)
4.8. Specifying Alternate Media Types (代替メディア型の指定)
4.9. WSDL Parts (WSDL の part)
4.10. Ordering of Parts (パートの順序)
4.11. Sending Fault Messages (フォルトメッセージの送信)
4.12. Describing Faults (フォルトの記述)
4.13. Sending Additional Parts Not Described in WSDL (WSDL で記述されていない追加のパートの送信)
4.14. Conformance of SOAP Messages (SOAP メッセージの適合性)
Appendix A: Referenced Specifications (参照仕様)
Appendix B: Extensibility Points (拡張点)
Appendix C: Defined Terms (定義された用語)
Appendix D: Acknowledgements (謝辞)
この文書は WS-I Attachments Profile 1.0 (以下,「このプロファイル」と呼ぶ) を定義する。 このプロファイルは非占有的 (non-proprietary) な Web サービス仕様で構成され, 相互運用性を向上させる仕様の明確化及び拡充を含んでいる。このプロファイルは, SOAP Messages with Attachments に基づいた Webサービスへのサポートを追加することで, WS-I Basic Profile 1.1 を補完している。
SOAP Messages with Attachments (SwA) は,SOAP メッセージに添付ファイルをパッケージングするための MIME multipart/related 構造を定義している。このプロファイルは,相互運用可能な SwAに基づくSOAP メッセージの添付ファイル(attachments)の運び方に対する サポートを追加することで,WS-I Basic Profile 1.1 を補完している。
第1節は,このプロファイルを紹介し,他のプロファイルとの関係を説明する。
第2節, "Profile Conformance" (プロファイルに対する適合性) は,このプロファイルに適合するとはどういう意味かを説明する。
それに続く各節は,このプロファイルの構成要素となるそれぞれの仕様について述べるもので,次の2つの部分からなる。 すなわち,構成要素となる仕様及び拡張点 (extensibility point) を列挙した概要説明と, それに続いて,構成要素となる仕様の個別の部分について述べた小節との二つの部分である。
このプロファイルは,SOAP with Attachments と MIME バインディングに対するサポートを追加し,Basic Profile 1.1 と組み合わせて用いることを意図している。
この文書では, 「…しなければならない (MUST, SHALL)」,「…してはならない (MUST NOT, SHALL NOT)」, 「必須の… (REQUIRED)」,「…することが望ましい (SHOULD)」,「…すべきではない (SHOULD NOT)」,「推奨の… (RECOMMENDED)」, 「…してもよい (MAY)」及び「省略可能の… (OPTIONAL)」の用語は, RFC2119 に記述されているとおりに解釈する。
[訳注: この訳文では,該当する用語の訳の直後に,括弧でくくって原文の用語を示している。 また,キーワードの訳語はできる限り JIS Z 8301 規格票の様式 に合わせた。]
このプロファイルにおける要件 (すなわち,"Conformance Requirements" [適合性の要件] の節に説明されている,適合性に影響するもの) は, 次の形式で提示される:
Rnnnn 要件の文章がここに入る。
ただし,ここで "nnnn" は,このプロファイル内で一意の要件番号で置き換えられ, 一意の要件識別子 (unique requirement identifier) を構成する。
要件識別子 (requirement identifier) は, Namespaces in XML (XML 名前空間) と互換性のあるような方法で, 名前空間修飾されている (namespace qualified) とみなすことができる。 ある要件の識別子に明示的な名前空間プレフィックスが存在しない場合 (たとえば,"bp10:R9999" ではなく "R9999" のような場合), その要件が存在する文書の節の適合性 URI (conformance URI) によって識別される 名前空間に属すると解釈されるべきである。 名前空間修飾されている場合, そのプレフィックスは,次に記述するとおり, そこで有効な名前空間の対応付けに則って解釈されるべきである。
いくつかの要件は,参照される仕様を明確化するだけで,実装に対して追加の制約を課さないものである。 便宜のため,仕様の明確化 (clarification) は次のように注記される: C
いくつかの要件は,参照される仕様の標準化されつつある内容を取り入れたものである。 便宜上,そのような仕様の先取りは次のように注記される: xxxx, ただし,ここで "xxxx" は仕様を示す識別子である (たとえば,"WSDL20" は WSDL 2.0 仕様を示す)。 そういう仕様はこの文書の出版時点では完成しておらず,先取りした仕様が変更されることもありうることに注意が必要である。 この情報は,実装者に対する便宜としてのみ含められている。
もととなる仕様にある拡張点 (extensibility point) ("Conformance Scope" [適合性の適用範囲] を参照) は, 同様に表示される:
Ennnn - 拡張点の名前 - 拡張点の記述
ただし,ここで "nnnn" は,このプロファイル内で一意の拡張点番号で置き換えられる。 要件の記述と同様,拡張点の記述は名前空間修飾が可能と解釈される。
この仕様では,全体を通して次に示すいくつかの名前空間プレフィックス (namespace prefix) を使用する。 各プレフィックスに関連付けられた URI を次に示す。 プレフィックスの選択は恣意的なものであり,どのような文字列を選択しても意味的に差異がないことに注意が必要である。
この文書は,名前 (この場合,Attachments 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) の集合を守ることであると定義されている。 この節では,これらの用語について説明し, どのように適合性が定義され使用されるかを説明する。
要件 (requirements) は,このプロファイルに対する適合性の基準を述べている。 要件は典型的には既存の仕様を参照し, そこでの相互運用性を向上する洗練,拡充,解釈及び明確化を具体化したものである。 このプロファイルの全ての要件は規定 (normative) と解釈され, 参照される仕様のうちの適用範囲内の要件 ("Conformance Scope" [適合性の適用範囲] 参照) も 同様に規定と解釈されるべきである。 このプロファイルの要件と参照される仕様の要件とが互いに矛盾する場合, プロファイル適合性の観点からは, このプロファイルの要件が優先される。
要件レベルは,RFC2119 の用語 (たとえば,MUST, MAY, SHOULD) を使い, 要件の性質と適合性に対する影響力とを示す。 個々の要件記述は,便宜上,個別に (R9999 のような) 番号が振られている。
次に例を示す:
R9999 WIDGET は丸い形状であることが望ましい (SHOULD)。
この要件は "R9999" という識別子で識別され, 適合性対象 WIDGET に対して適用され (次を参照), ウィジェットに対する条件付きの要件を課す。 すなわち,大部分の場合には適合性を維持するためにこの要件は満足しなければならないが, それを満足しない正当な理由がある場合もある (それは,要件それ自体又は付随する文章で説明される)。
それぞれの要件は,ちょうど一つの要件レベルキーワード (MUST のような) と適合性対象キーワード (MESSAGE のような) とをもつ。 補足の文章 (根拠や例など) が要件を明確にするために付け加えられることもあるが,要件記述そのものだけが適合性を判定する際に考慮されるべきである。
このプロファイルの用語定義は, 適合性を決定するという用途において権威あるものとみなされる。
このプロファイルの要件はいずれも, 適合性レベルに関わらず, 現実の又は想定される脅威 (たとえば,サービス妨害攻撃 [denial of service attack]) に対応して, それ以外の点では適合している実装が セキュリティ対策を講じる能力を制限するものと解釈してはならない。
適合性対象 (conformance target) は, どの対象物 (artifact) [たとえば,SOAP メッセージ,WSDL 記述,UDDI レジストリーデータ] 又は主体 (party) [たとえば,SOAP 処理系,エンドユーザー] に要件が適用されるかを識別する。
これは, 適合性の定義が, 異なる文脈において, 要件を適用可能であるかを曖昧性なく解釈することを保証し, 対象物 (たとえば,SOAP メッセージや WSDL 記述) 及び 各種の Web サービスの主体 (たとえば,クライアントやサービスのインスタンス) の動作に対する 適合性試験を可能にするものである。
試験を単純にし,曖昧性を排除するため, 要件の適合性対象は可能な限り物理的な対象物である。
このプロファイルでは次の適合性対象を使用する:
wsdl:port
又は uddi:bindingTemplate
を実装するソフトウェア
(Basic Profile 1.0)
このプロファイルの適用範囲 (scope) は,その対象とする技術を詳細化する。 言い換えれば,このプロファイルは,その適用範囲の中での相互運用性を向上することだけを図っている。 一般的には,このプロファイルの適用範囲は,それが参照する仕様によって限定される。
このプロファイルの適用範囲は,拡張点 (extensibility points) によってさらに洗練される。 参照される仕様はたいてい拡張メカニズム及び未規定の若しくは無制限のコンフィギュレーションパラメーターを提供している。 このプロファイルで拡張点と認識された場合, そのようなメカニズム又はパラメーターはこのプロファイルの適用範囲外であり, その使用又は不使用はこのプロファイルに対する適合性において意味をもたない。
このプロファイルは,それでも,拡張点の使用について,その範囲を制限することなく,要件を課すことがある。 また,拡張点の特定の使用方法について,このプロファイルが他のプロファイルと組み合わせて使われた場合に,相互運用性を向上するために,他のプロファイルで制限されることがある。
拡張点の使用は相互運用性を損なうことがあるので, その使用は Web サービスの関係者によって何らかの形で協議又は文書化されるべきである。 たとえば,これは私的な合意 (out-of-band agreement) の形をとるかもしれない。
このプロファイルの適用範囲は Appendix A の参照仕様によって定義され, Appendix B の拡張点によって洗練される。
このプロファイルに対する適合性の表示は, Conformance Claim Attachment Mechanisms [適合性表示添付メカニズム] に記述されているとおり, 次に列挙する対象物に関連付けられた,適用可能なプロファイルの要件が満足された場合に, 次のメカニズムを使って行うことができる:
CCAM [適合性表示添付メカニズム] の URI は,最終版になる前に変更される可能性がある。
このプロファイルに対する適合性表示 URI は "http://ws-i.org/profiles/attachments/1.0" である。
このプロファイルのこの節では次の仕様を参照し,その仕様の範囲内における拡張点を定義する:
SOAP Messages with Attachments
は,SOAPエンベロープを添付ファイルと共にパッケージングするための
MIME multipart/related
構造を定義する。
このプロファイルは,この構造を利用することを必須とし,その利用方法について,
次の制約を定める:
R2931
multipart/related
MESSAGE のルートパート(root part) の本体 (entity body) は,soap:Envelope
でなければならない (MUST)。
R2945 MESSAGE の中の Content-Type HTTP ヘッダーフィールドの値は,"multipart/related" 又は "text/xml" のいずれかでなければならない (MUST)。 C
R2932
MESSAGE の中の Content-Type HTTP ヘッダーフィールドの値が "multipart/related" のメディア型の場合,そのメッセージの中の Content-Type HTTP ヘッダーフィールドの値は type
パラメーターの値が "text/xml" でなければならない (MUST)。
C
いずれの MIME パートも soap:Envelope
を含んでよいが,MIME パッケージのルートパートの本体だけが,基本の SOAP エンベロープとして扱われる。非ルートパート (non-root parts)は,添付ファイルとして参照される。
正しい例:
次のメッセージでは,Content-Type HTTP ヘッダーフィールドの値は, メディア型が "Multipart/Related" で type パラメーターの値が "text/xml" となっている。
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> ... </SOAP-ENV:Envelope> --MIME_boundary ... --MIME_boundary--
R2915
multipart/related
の MESSAGE のルートパート (root part) の本体 (entity body) は,UTF-8 又は UTF-16 のいずれかの文字エンコーディングを用いてシリアライズされなければならない (MUST)。
R2916
multipart/related
の MESSAGE の非ルートパート (non-root parts) では,いかなる文字エンコーディングを用いてもよい (MAY)。
R2925
WSDL 記述が少なくとも 1個の非ルート MIME パートを列挙している場合,対応する MESSAGE は,"multipart/related" のメディア型である Content-Type
HTTP ヘッダーフィールドをもたなければならない (MUST)。
受信側がメッセージに0個以上の添付ファイルを想定している場合,そのメッセージの送信側は,添付ファイルのないメッセージに text/xml メディア型を使うことができる。
R2917
0個の添付ファイルのパートをもつ MESSAGE は,
そのメッセージに対する WSDL 記述が wsdl:binding
の中の対応する wsdl:input
又は wsdl:output
に mime:multipartRelated
要素を指定している場合,
"text/xml" (SOAP HTTP バインディングが使われたときと同様な方式) 又は "multipart/related" のいずれかの content-type を使って送られなければならない (MUST)。
R2902
SENDER は,
WSDL 記述の wsdl:binding
の中の対応する wsdl:input
又は wsdl:output
に MIME バインディングを指定していない場合,
SOAP with Attachments を使ってメッセージを送ってはならない (MUST NOT)。
これは,WSDL 記述が soapbind:body
を含む mime:part
子要素を一つだけもつ mime:multipartRelated
を指定している場合にのみ起こる。
正しい例:
次のような WSDL 記述の場合:
<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdl" xmlns:tns="http://example.com/mimewsdl"> ... <wsdl:binding name="aBinding" type="tns:aPortType"> <soapbind:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="anOperation"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions>
次のような SOAP HTTP バインディングの input メッセージを生成してもよい:
<?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:anOperation> ... </types:anOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
次のような MIME バインディングの output メッセージを生成してはならない:
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<rootpart@example.com>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:anOperationResponse> ... </types:anOpertionResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary--
Web サービスを使うアプリケーションは,ネットワークからコンテンツを取り出すことを含め,さまざまな方法で URI を使用できる。 添付ファイルは,URI で認識されるコンテンツを送り届けるために使用できるが, 実装は, 添付ファイルのコンテンツを優先することや, 添付ファイルのみを使用することや, 添付ファイルをまったく使用しないこと のいずれも要求されない。 同様に,アプリケーションは URI の参照値読出し機能 (たとえば,ネットワークからコンテンツを取ってくること) を無視し,添付されたコンテンツのみを使うことも選択できる。
URI に CID スキームを使用する場合, RFC2392 で定義された構文と規則とが適用される。
R2918 RECEIVER は,エンベロープ中にある添付ファイルへの URI 参照を無視してもよい (MAY)。
このプロファイルでは,添付ファイルパートの内容については何の制約も課さない。
soap:Envelope
を含んだ更なる XML 文書を添付ファイルとして送ってもよいが,MIME メッセージのルートパートだけが,
MIME パッケージの中の SOAP エンベロープとして扱われるべきである。
R2919
MESSAGE は,ルートパート以外のパート中に,添付ファイルとして運ばれる soap:Envelope
をもっていてもよい (MAY)。
R2920
WSDL 記述の wsdl:output
要素が MIME バインディングを使って記述されている場合だけに限り,
INSTANCE は,添付ファイルのついたフォルトを送ってもよい (MAY)。
定義: content-id への part 名エンコーディング (content-id part encoding)
content-id への part 名エンコーディング (content-id part encoding) は,次の構成要素を連結したものである:
mime:content
によって参照される
wsdl:part
要素の name
属性の値。
ただし,content-id ヘッダーで禁止された文字 (0x7F を超えるコードポイントで表現される非 ASCII 文字) は次の方式でエスケープする:
R2933
WSDL 記述が wsdl:message
の part
を mime:content
要素にバインドしている場合,
MESSAGE の中の対応する MIME のパートの Content-Id
フィールドの値は,
content-id への part 名エンコーディング (content-id part encoding) に適合しなければならない (MUST)。
正しい例:
次の WSDL 断片のなかで,mime:content
にバインドされた part の名前が content-id の値に追加される。
<wsdl:message name="fooMsg"> <wsdl:part name="body" type="ns1:Claim"/> <wsdl:part name="fooPart" type="xs:base64binary"/> </wsdl:message> ... <wsdl:binding ... <mime:multipartRelated> <mime:part> <soapbind:body parts="body" use="literal"/> </mime:part> <mime:part> <mime:content part="fooPart" type="application/octet-stream"/> </mime:part> </mime:multipartRelated> ... </wsdl:binding>
次に示すマルチパートのパッケージの断片は fooPart
のバイナリストリームを含み,wsdl:part
の "name" 属性の値がどのように content-id の値に取り込まれるかを強調している。
... --MIME_boundary Content-Type: application/octet-stream Content-Transfer-Encoding: 8bit Content-ID: <fooPart=somereallybignumberlikeauuid@example.com> ...
中継ノード (intermediaries) が multipart/related
メッセージ中のパートの順序を入れ替える可能性がある。よって,メッセージ中のパートの順序に意味付けすることは,明示的にも暗黙的にも,行うべきではない。
R2921 RECEIVER は,メッセージ中の非ルート MIME パートの順序から,いかなる意味も推定してはならない (MUST NOT)。
R2929 MESSAGE は,ルートパートがどれであるかということを変えない限り, MIME パートをどのような順序で並べてもよい (MAY)。
受信側は,WSDL 記述の mime:part
要素の指定された順序が,
メッセージの中の MIME パートの順序と同じであると想定してはならない。
WSDL 記述の中の MIME パートの順序は,メッセージの中の MIME パートの順序とは独立であると解釈されなければならない。
start
パラメーターが存在する場合,start
パラメーターの値がメッセージのルートパートの content-ID
である。start
パラメーターが存在しない場合, RFC2387 の 3.2 節に定義されている通り,ルートパートはパッケージの最初のボディパートである。
R2922
メッセージ中の HTTP ヘッダーの Content-Type
フィールドの値に start
パラメーターが存在しない場合,
RECEIVER は,MIMEパッケージの最初のボディパートをルートパートとして扱わなければならない(MUST)。
C
正しい例:
次のメッセージでは,先頭の MIME パート (Content-ID ヘッダーの値が "<rootpart@example.com>" になっている) がルートパートである。
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:SendClaim> <ClaimDetail>.............................</ClaimDetail> <photo> <href>cid:claimphoto@example.com</href> </photo> </types:SendClaim> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <claimphoto@example.com> ...binary photograph... --MIME_boundary--
Content-Transfer-Encoding 機構は, バイナリーのコンテンツの転送をサポートしていないトランスポートを通してメッセージを送ることを可能にする。 たとえば,いくつかの電子メールシステムでは文字ベースのメッセージ転送しかサポートしていない。 Web サービスのメッセージはそのようなシステムを起点や終点としうるので, このプロファイルではこの機構の使用を許容している。
MIME のマルチパートメッセージのあるパートに Content-Transfer-Encoding フィールドが存在しない場合, そのパートの本体は,RFC2045 に規定されている通り,7ビットの ASCII エンコーディングに適合しなければならない。
R2934 multipart/related のメッセージの1つのパートにおける Content-Transfer-Encoding フィールドは, "7bit","8bit","binary","quoted-printable" 又は "base64" のいずれかの値をもたなければならない (MUST)。
R2935 multipart/related のメッセージの1つのパートの本体のエンコーディングは, RFC2045 に規定されている通り, Content-Transfer-Encoding フィールドの値で示されるエンコーディングに従わなければならない (MUST)。 C
このプロファイルでは,相互運用性を向上するため,有効な値をよく知られているものに限定している。
いくつかの実装は, MIME カプセル化の境界文字列の前に CRLF (carriage-return line-feed [復帰改行]) を置かないメッセージを生成することがある。 これは,境界文字列の前に正しく CRLF が置かれることを想定している実装に対して問題となる。
R2936 MESSAGE の中では,すべての MIME カプセル化境界文字列の前に ASCII 文字の CR (13) と LF (10) とをこの順で置かなければならない (MUST)。 C
RFC 2046 の5.5.1節は,すべてのカプセル化境界の前に CRLF (復帰改行) を置くことを明確に要求している。
このプロファイルのこの節では次の仕様を参照し,その仕様の範囲内における拡張点を定義する:
WSDL 1.1 の第5節は,MIME バインディングを定義している。 このプロファイルは WSDL MIME バインディングの使用を認めるが, それを SOAP Messages with Attachments プロトコルに限定する。 このプロファイルは, その使用に関し次の制限を課す:
送信側が,SOAP with Attachments を使ってメッセージを送信することはできるが, そのようなメッセージを受信して処理することはできないというユースケースは存在しうる。
R2901
DESCRIPTION は,WSDL 1.1 の第5節に記述されている WSDL MIME バインディングか,
WSDL 1.1 の第3節に記述されている WSDL SOAP バインディングかのいずれかを,
wsdl:binding
の wsdl:input
又は wsdl:outout
要素のそれぞれに使用しなければならない (MUST)。
WSDL 1.1 では,
wsdl:binding
が
wsdl:portType
で定義された内容の一部分に対するバインディングを指定しないことについて,
許容されるかどうかが明記されていない。
R2941
DESCRIPTION の中の wsdl:binding
は,
それが参照している wsdl:portType
の中の wsdl:message
の各 wsdl:part
について,
soapbind:body
,
soapbind:header
,
soapbind:fault
,
soapbind:headerfault
又は
mime:content
のいずれかにバインドすることが望ましい (SHOULD)。
portType は,名前を付けられた operation の組と,それに関連付けられた抽象的な message とをもつ抽象的な契約 (abstract contract) を定義する。
禁止されているわけではないが,
portType の中の抽象的な input,output 及び fault の message のそれぞれの part は,
MIME バインディングを使う際は,WSDL 1.1 の第5節に定義されているように,
soapbind:body
,soapbind:header
等や mime:content
に適切にバインドされることが想定されている。
バインドされていない wsdl:part
は利用者 (consumer) から無視されるべきである。
WSDL 中の message の part は,(mime:content
を使って) 特定の MIME パートにバインドできる。
soapbind:header
が wsdl:portType
によって定義される契約 (contract) の一部
ではない message に含まれる part を参照してもよいのとは異なり,mime:content
は,wsdl:operation
から参照される wsdl:message
に定義されていない
wsdl:part
を参照してはならない。
加えて,WSDLの中の message の part は,不可分の単位とみなされる。
複雑な内容をもつ message の part の構成要素を,選択的に特定の MIME パートにバインドすることはできない。
R2903
DESCRIPTION 中の mime:content
要素は,
対応する wsdl:portType
の対応する wsdl:operation
の
対応する wsdl:input
又は wsdl:output
の中に現れない
wsdl:part
を参照してはならない (MUST NOT)。
R2904
DESCRIPTION 中の mime:content
要素は,
wsdl:part
から参照される要素 (element) 又は型 (type) の内部構成要素 (sub-component) にバインドされてはならない (MUST NOT)。
R2946
DESCRIPTION の中では,mime:content
要素は part
属性を含まなければならない (MUST)。
間違っている例:
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"> <types ...> <schema xmlns="http://www.w3.org/2001/XMLSchema/" targetNamespace="http://example.org/foo" xmlns:ns="http://example.org/foo"> <element name='foo'> <complextContent> <sequence> <element ref='bar1'/> <element ref='bar2'/> </sequence> </complexContent> </element> </schema> </types> ... <message name='aMsg'> <part name='apart' element='ns:foo' /> <part name="body" element="ns:bar"/> </message> <portType> <operation> <input> <part name="apart"> </input> ... </operation> </portType> <binding> <operation> <input> <mime:multipartRelated> <mime:part> <soapbind:body part="body" use="literal"/> </mime:part> <mime:part> <mime:content part="ns:bar1"/> </mime:part> </mime:multipartRelated> </input> ... </operation> </binding> </definitions>
添付ファイルを用いることのメリットの一つは,分離された MIME パートにデータを格納して,同じ MIME パッケージのルートパートに含まれる SOAP エンベロープからそれを参照できることである。
このプロファイルは,
WSDL 記述の中で message の part を定義するために使用できるスキーマ型 ref:swaRef
を定義している。
ある message の part が ref:swaRef
型を使って記述された場合,
インスタンス文書では,
その URI は同じ MIME パッケージ内の添付ファイルを指す。
この型は,アプリケーションやツールやプラットフォームの開発者に対して,
WSDL 記述の中に,添付ファイルへの参照であることを指定する相互運用可能な手段を提供する。
かといって,他の手段を用いることが,WSDL を非適合 (non-conformant) にしてしまうということではない。
次に,SOAP エンベロープから添付ファイルを参照することに使われる型の XML Schema を示す:
<?xml version="1.0" encoding="UTF-8" ?> <xsd:schema targetNamespace="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:simpleType name="swaRef"> <xsd:restriction base="xsd:anyURI" /> </xsd:simpleType> </xsd:schema>
利用の便宜を図るため, WS-I はこのスキーマ型のスキーマを次の場所で公開している: http://ws-i.org/profiles/basic/1.1/swaref.xsd
WSDL 1.1 の記述には,
(swaRef を使って定義された) 添付ファイルの参照と,
(mime:content にバインドされた wsdl:part を使って定義された) 添付ファイルとの間を関連付ける手段はないことに注意が必要である。
このプロファイルでは,
ref:swaRef
が使われた場合,
対応する添付ファイルを WSDL に記述しない,
あるいは反対に,添付ファイルが WSDL に記述された場合,
それに対して ref:swaRef
を使わないことをベストプラクティスとして推奨している。
R2940
DESCRIPTION 中で,ref:swaRef
のスキーマ型で定義された wsdl:part
は,
MIME バインディングの soapbind:body
又は soapbind:header
だけにバインドされることが望ましい (SHOULD)。
R2928
ENVELOPE の中において,
ref:swaRef
スキーマ型を使って型付けされた URI 参照は,エンベロープと同じメッセージ中の MIME パートへの参照として解決されなければならない (MUST)。
swaRef 型は,添付ファイルに対する参照を示すのに, (次の例に示すように) 要素として使っても, 属性として使ってもよい。 どちらの方法が望ましいというわけではない。
正しい例:
rpc/literal バインディングに対する WSDL 記述:
<?xml version="1.0"?> <wsdl:definitions xmlns:types="http://example.com/mimetypes" xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdl" xmlns:tns="http://example.com/mimewsdl"> <wsdl:types> <xsd:schema targetNamespace="http://example.com/mimetypes" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" /> <xsd:complexType name="ClaimDetailType"> <xsd:sequence> <xsd:element name="Name" type="xsd:string"/> <xsd:element name="ClaimForm" type="ref:swaRef"/> </xsd:sequence> </xsd:complexType> </xsd:schema> </wsdl:types> <wsdl:message name="ClaimIn"> <wsdl:part name="ClaimDetail" type="types:ClaimDetailType"/> <wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/> </wsdl:message> <wsdl:message name="ClaimOut"> <wsdl:part name="ClaimRefNo" type="xsd:string"/> </wsdl:message> <wsdl:portType name="ClaimPortType"> <wsdl:operation name="SendClaim"> <wsdl:input message="tns:ClaimIn"/> <wsdl:output message="tns:ClaimOut"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="ClaimBinding" type="tns:ClaimPortType"> <soapbind:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="SendClaim"> <soapbind:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soapbind:body use="literal" parts="ClaimDetail" namespace="http://example.com/mimetypes"/> </mime:part> <mime:part> <mime:content part="ClaimPhoto" type="image/jpeg"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions>
結果として生成される "SendClaim" の rpc/literal オペレーションに対する input メッセージ:
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<rootpart@example.com>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:SendClaim> <ClaimDetail> <Name>...</Name> <ClaimForm>cid:claimform@example.com</ClaimForm> </ClaimDetail> </types:SendClaim> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: text/xml Content-Transfer-Encoding: 8bit Content-ID: <claimform@example.com> ...claim form referenced by the swaRef... --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com> ...MIME attachment of binary photograph... --MIME_boundary--
結果として生成される "SendClaim" の rpc/literal オペレーションに対する output メッセージ:
MIME-Version: 1.0 Content-Type: text/xml; charset=UTF-8 <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:SendClaimResponse> <ClaimRefNo>.............................</ClaimRefNo> </types:SendClaimResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
正しい例:
document/literal バインディングに対する WSDL 記述:
<?xml version="1.0" encoding="utf-8" ?> <wsdl:definitions xmlns:types="http://example.com/mimetypes" xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdl" xmlns:tns="http://example.com/mimewsdl"> <wsdl:types> <xsd:schema targetNamespace="http://example.com/mimetypes" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" /> <xsd:element name="ClaimDetail" type="types:ClaimDetailType"/> <xsd:complexType name="ClaimDetailType"> <xsd:sequence> <xsd:element name="Name" type="xsd:string"/> <xsd:element name="ClaimForm" type="ref:swaRef"/> </xsd:sequence> </xsd:complexType> <xsd:element name="ClaimRefNo" type="xsd:string"/> </xsd:schema> </wsdl:types> <wsdl:message name="ClaimIn"> <wsdl:part name="body" element="types:ClaimDetail"/> <wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/> </wsdl:message> <wsdl:message name="ClaimOut"> <wsdl:part name="out" element="types:ClaimRefNo"/> </wsdl:message> <wsdl:portType name="ClaimPortType"> <wsdl:operation name="SendClaim"> <wsdl:input message="tns:ClaimIn"/> <wsdl:output message="tns:ClaimOut"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="ClaimBinding" type="tns:ClaimPortType"> <soapbind:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="SendClaim"> <soapbind:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soapbind:body parts="body" use="literal"/> </mime:part> <mime:part> <mime:content part="ClaimPhoto" type="image/jpeg"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soapbind:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions>
結果として生成される "SendClaim" の document/literal オペレーションに対する input メッセージ:
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<rootpart@example.com>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <rootpart@example.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:ClaimDetail> <Name>...</Name> <ClaimForm>cid:claimform@example.com</ClaimForm> </types:ClaimDetail> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: text/xml Content-Transfer-Encoding: 8bit Content-ID: <claimform@example.com> ...claim form referenced by the swaRef... --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <ClaimPhoto=4d7a5fa2-14af-451c-961b-5c3abf786796@example.com> ...MIME attachment of binary photograph... --MIME_boundary--
結果として生成される "SendClaim" の document/literal オペレーションに対する output メッセージ:
MIME-Version: 1.0 Content-Type: text/xml; charset=UTF-8 <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body xmlns:types="http://example.com/mimetypes"> <types:ClaimRefNo>...............</types:ClaimRefNo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
SOAP Messages with Attachments は multipart/related パッケージのルート パートが SOAP エンベロープを含まなければならないと要求している。しかし, WSDL の MIME バインディングはそれをどう記述するか明確ではない。
R2911
DESCRIPTION 中の mime:multipartRelated
要素は,
その子要素である mime:part
要素の中で,
soapbind:body
を子要素として含む mime:part
を,
厳密に 1個もたなければならない (MUST)。
C
WSDL の MIME バインディングでは,
soapbind:body
を含む mime:part
が,
SOAP Messages with Attachments で要求されているルート MIME パートを記述する。
間違っている例:
<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdl" xmlns:tns="http://example.com/mimewsdl"> ... <wsdl:binding name="aBinding" type="tns:aPortType"> <soapbind:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="anOperation"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </mime:part> <mime:part> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> ... </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions>
WSDL 1.1 仕様は,
soapbind:header
要素が soapbind:body
要素と一緒に
mime:part
要素の子要素として同居することが許されるかどうか規定していない。
SOAP Messages with Attachments 仕様は
マルチパートメッセージのルートパートが SOAP エンベロープを含むことを要求しているが,
WSDL 1.1 仕様はこのパートをどのように記述するべきか明らかではない。
WSDL 1.1 仕様は
mime:part
要素が
multipart/related メッセージの個々のパートを記述するのに使われることを規定しているので,
マルチパートメッセージのルートパートを表す mime:part
要素の内容は,
WSDL MIME バインディング拡張がなかった場合と同様,
soapbind:body
及び soapbind:header
を含めた
SOAP エンベロープを完全に記述しなければならない。
R2905
DESCRIPTION 中の soapbind:header
要素は,
mime:part
要素の子要素として含まれてもよい (MAY)。
C
R2906
DESCRIPTION 中の soapbind:header
要素は,
ルートパート (soapbind:body
要素をもつ) ではない
mime:part
に含まれてはならない (MUST NOT)。
C
間違っている例:
<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://example.com/mimewsdl" xmlns:tns="http://example.com/mimewsdl"> ... <wsdl:binding name="aBinding" type="tns:aPortType"> <soapbind:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="anOperation"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soapbind:body use="literal" namespace="http://example.com/mimetypes"/> </mime:part> <mime:part> <soapbind:header message="tns:headerMessage" part="aPart" use="literal"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> ... </wsdl:output> </wsdl:operation> </wsdl:binding> </wsdl:definitions>
WSDL 1.1 仕様と WSDL の MIME バインディングのスキーマとの間にはいくつかの不整合がある。
mime:part
要素の場合,スキーマは間違ってローカル要素宣言と定義しており,
また間違って WSDL 1.1 仕様には記述がない name
属性を追加している。
R2907
DESCRIPTION 中の MIME パートは,
名前空間 (namespace) が WSDL MIME バインディング拡張で,
ローカル名 (local name) が part
である要素として定義されなければならない (MUST)。
C
R2908
DESCRIPTION 中の mime:part
要素は,
name
属性をもってはならない (MUST NOT)。
WSDL MIME バインディング拡張スキーマに対する,ここで示したものを含む修正は http://schemas.xmlsoap.org/wsdl/mime/xxx.xsd にある改訂版のスキーマに反映されている。
mime:part
の子要素として複数の mime:content
があった場合,
それは参照される wsdl:part
の許容可能な代替シリアライゼーション形式とみなされる。
R2909
DESCRIPTION 中の mime:part
要素の子要素となる複数の mime:content
は,
同一の wsdl:part
を参照しなければならない (MUST)。
間違っている例:
<mime:part> <mime:content part="ns:foo" type="image/jpeg"/> <mime:content part="ns:bar" type="image/jpeg"/> </mime:part>
正しい例:
<mime:part> <mime:content part="ns:foo" type="image/jpeg"/> <mime:content part="ns:foo" type="image/gif"/> </mime:part>
R2910
DESCRIPTION 中の mime:content
は,
type
属性又は element
属性のいずれかの属性を使って定義された
wsdl:part
を参照しなければならない (MUST)。
R2942
MESSAGE 中で,
mime:content
にバインドされた message の part で
(wsdl:part
要素の element
属性を使って) グローバル要素宣言を参照するものは,
その MIME パートの中に,
参照された要素に記述された内容をルート要素としてもつ
XML 情報セット (infoset) のシリアライゼーションとして,
シリアライズされなければならない (MUST)。
R2943
DESCRIPTION 中で,
mime:content
にバインドされた message の part で
(wsdl:part
要素の type
属性を使って) 型宣言を参照する場合,
その type
属性の値を無視し,
mime:content
要素の type
属性のメディア型を優先しなければならない (MUST)。
R2944
DESCRIPTION 中で,
wsdl:part
要素が
(wsdl:part
要素の element
属性を使って) グローバル要素宣言を参照する場合,
その part をバインドする mime:content
要素の type
属性の値は,
XML 化したデータを入れるのに適したものでなければならない (MUST)。
R2912
RECEIVER は,
WSDL 記述の中に指定された mime:part
要素の順序が
メッセージの中の MIME パートの順序と同じであると仮定してはならない (MUST NOT)。
R2947
DESCRIPTION 中で,
soapbind:body
子要素をもつ mime:part
は,
mime:multipartRelated
要素の他の子要素の間のどの位置に現れてもよい (MAY)。
WSDL 記述に指定された MIME パートの順序は, メッセージの中の MIME パートの順序とは独立であるとみなさなければならない。
R2913
フォルトの MESSAGE は,
WSDL 記述の対応する binding 内の operation の wsdl:output
子要素が
mime:multipartRelated
要素を子要素としてもつ場合,
text/xml
又は multipart/related
のいずれの形式でシリアライズされてもよい (MAY)。
R2930
DESCRIPTION 中の wsdl:fault
要素は,
その子要素として mime:multipartRelated
要素を持ってはいけない (MUST NOT)。
WSDL に記述されている範囲を超える追加の MIME パートがメッセージに含まれていてもよい。 また,それらの MIME パッケージ内での位置や順序は重要ではない。
R2923 SENDER は, WSDL MIME バインディングで記述されていない非ルート MIME パートを送信してもよい (MAY)。 C
R2926 MESSAGE は, WSDL MIME バインディングで記述されたすべての MIME パートを含めなければならない(MUST)。
適合性対象を ENVELOPE とするこのプロファイルの適合性要件は, MIME パッケージのルートパートに含まれる SOAP エンベロープに対してのみ適用される。 非ルートパートの SOAP エンベロープは,添付ファイルとして WSDL 記述に記述することができ, その場合, WSDL 記述に列挙された非ルートパートに対する適合性要件が適用される。
R2927 MESSAGE のルートパートは,Basic Profile の 1.1 版における, エンベロープに対するすべての要件に適合しなければならない (MUST)。
次の仕様の要件は,このプロファイルで置き換えられたものを除き, 参照することでこのプロファイルに取り込まれている:
この節では,"Scope of the Profile" で定義されたとおり, このプロファイルの構成要素となる仕様の拡張点を列挙する。
これらのメカニズムはこのプロファイルの適用範囲外である。 これらを使うことが相互運用性に影響するかもしれないし, Web サービスの関係者間での私的な合意が必要かもしれない。
SOAP Messages with Attachments の拡張点:
次に示す用語は,このプロファイルで有効な定義をもつ:
content-id への part 名エンコーディング (content-id part encoding) は,次の構成要素を連結したものである:
mime:content
によって参照される
wsdl:part
要素の name
属性の値。
ただし,content-id ヘッダーで禁止された文字 (0x7F を超えるコードポイントで表現される非 ASCII 文字) は次の方式でエスケープする:
このプロファイルは WS-I Basic Profile Working Group の成果物であり, WG は次のメンバーを含む:
Mark Allerton (Crystal Decisions Corp), Steve Anderson (OpenNetwork), George Arriola (Talking Blocks, Inc.), Siddharth Bajaj (Verisign), Keith Ballinger (Microsoft Corp.), David Baum (Kantega AS), Ilya Beyer (KANA), Rich Bonneau (IONA Technologies), Don Box (Microsoft Corp.), Andrew Brown (Verisign), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Luis Felipe Cabrera (Microsoft Corp.), Maud Cahuzac (France Telecom), Mike Chadwick (Kaiser Permanente), Martin Chapman (Oracle Corporation), Richard Chennault (Kaiser Permanente), Roberto Chinnici (Sun Microsystems), Dipak Chopra (SAP AG), Jamie Clark (OASIS), David Cohen (Merrill Lynch), Ugo Corda (SeeBeyond Tech), Paul Cotton (Microsoft Corp.), Joseph Curran (Accenture), Alex Deacon (Verisign), Mike DeNicola (Fujitsu Limited), Paul Downey (BT Group), Jacques Durand (Fujitsu Limited), Aladin Eajani (Hummingbird, Ltd.), Michael Eder (Nokia), Dave Ehnebuske (IBM), Mark Ericson (Mindreef Inc), Colleen Evans (Microsoft Corp.), Tim Ewald (Microsoft Corp.), Chuck Fay (FileNET Corp.), Chris Ferris (IBM), Daniel Foody (Actional Corporation), Satoru Fujita (NEC Corporation), Shishir Garg (France Telecom), Yaron Goland (BEA Systems Inc), Marc Goodner (SAP AG), Pierre Goyette (Hummingbird, Ltd.), Hans Granqvist (Verisign), Martin Gudgin (Microsoft Corp.), Marc Hadley (Sun Microsystems), Norma Hale (Webify Solutions Inc), Bob Hall (Unisys Corporation), Scott Hanselman (Corillian), Muir Harding (Autodesk Inc.), Loren Hart (Verisign), Andrew Hately (IBM), Harry Holstrom (Accenture), Lawrence Hsiung (Quovadx), Hemant Jain (Tata Consultancy), Steve Jenisch (SAS Institute), Erik Johnson (Epicor Software), Bill Jones (Oracle Corporation), Anish Karmarkar (Oracle Corporation), Dana Kaufman (Forum Systems), Takahiro Kawamura (Toshiba), Oldre Kepka (Systinet), Bhushan Khanal (WRQ Inc.), Sandy Khaund (Microsoft Corp.), Jacek Kopecky (Systinet), Sanjay Krishnamurthi (Informatica), Sundar Krishnamurthy (Verisign), Eva Kuiper (Hewlett-Packard), Sunil Kunisetty (Oracle Corporation), Christopher Kurt (Microsoft Corp.), Lars Laakes (Microsoft Corp.), Canyang Kevin Liu (SAP AG), Ted Liu (webMethods Inc.), Donna Locke (Oracle Corporation), Brad Lund (Intel), Michael Mahan (Nokia), Ron Marchi (EDS), Jonathan Marsh (Microsoft Corp.), Eric Matland (Hummingbird, Ltd.), Barbara McKee (IBM), Derek Medland (Hummingbird, Ltd.), David Meyer (Plumtree Software Inc.), Jeff Mischkinsky (Oracle Corporation), Ray Modeen (MITRE Corp.), Tom Moog (Sarvega Inc.), Gilles Mousseau (Hummingbird, Ltd.), Greg Mumford (MCI), Jim Murphy (Mindreef Inc), Bryan Murray (Hewlett-Packard), Richard Nikula (BMC Software, Inc.), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems Inc), David Orchard (BEA Systems Inc), Vivek Pandey (Sun Microsystems), Jesse Pangburn (Quovadx), Eduardo Pelegri-Llopart (Sun Microsystems), Mike Perham (Webify Solutions Inc), Eric Rajkovic (Oracle Corporation), Shaan Razvi (MITRE Corp.), Rimas Rekasius (IBM), Mark Richards (Fidelity), Graeme Riddell (Bowstreet), Sam Ruby (IBM), Tom Rutt (Fujitsu Limited), Saikat Saha (Commerce One, Inc.), Roger Sanborn (Crystal Decisions Corp), Matt Sanchez (Webify Solutions Inc), Krishna Sankar (Cisco Systems Inc.), Jeffrey Schlimmer (Microsoft Corp.), Don Schricker (Micro Focus), Dave Seidel (Mindreef Inc), AKIRA SHIMAYA (NTT), David Shoaf (Hewlett-Packard), Yasser Shohoud (Microsoft Corp.), David Smiley (Ascential Software), Seumas Soltysik (IONA Technologies), Joseph Stanko (Plumtree Software Inc.), Andrew Stone (Accenture), Julie Surer (MITRE Corp.), YASUO TAKEMOTO (NTT), Nobuyoshi Tanaka (NEC Corporation), Jorgen Thelin (Microsoft Corp.), Sameer Vaidya (Talking Blocks, Inc.), William Vambenepe (Hewlett-Packard), Claus von Riegen (SAP AG), Rick Weil (Eastman Kodak Company), Scott Werden (WRQ Inc.), Ajamu Wesley (IBM), Ian White (Micro Focus), Dave Wilkinson (Vignette), Mark Wood (Eastman Kodak Company), Prasad Yendluri (webMethods Inc.), and Brandon Zhu (NetManage Inc).