Basic Profile - Version 1.0 (Final) [Japanese translation]

この文書は WS-I Basic Profile 1.0 を定義する。WS-I Basic Profile 1.0 は非占有的 (non-proprietary) な Web サービス仕様で構成され，相互運用性を向上させる仕様の明確化を含んでいる。

Status of this Document (この文書の位置付け)

これは最終仕様 (final specification) である。正誤表又は更新版については，WS-I.org のサイトを参照のこと。

Notice (通告)

ここに含まれる内容は，この内容の著者若しくは開発者又は WS-I が所有又は管理する知的財産権に対するライセンスを，明示的にも暗示的にも示すものではない。ここに含まれる内容はそのまま (AS IS) の形式で提供され，適用可能な法律に許される最大限の範囲において，そのままの形で欠陥を含んだまま (AS IS AND WITH ALL FAULTS) 提供される。この内容の著者及び開発者並びに WS-I は，ここに，明示的，暗示的，又は法定による，市場性，特定目的への適用性，応答の精度若しくは完全性，結果，職人的努力，ウィルスがないこと，又は過失のないことについての，暗示的な保証，義務又は条件を含む (しかし，それに限定されない)，その他すべての保証及び条件を否認する。さらに，この内容に関する権利，安全な居住，安全な所有，記述への対応又は侵害不在性について，いかなる保証又は条件も存在しない。

この内容の著者若しくは開発者又は WS-I のいずれも，他者に対して，損害の可能性の事前通告の有無にかかわらず，これ又はこの内容についてのその他のいかなる合意によって起こされる損害に対して，契約，不法行為，保証その他による，代替する物資若しくは服務の購入，逸失利益，用途損失，データ損害，又はいかなる偶発的，結果的，直接，間接，若しくは特別な損害を補償する責任を持たない。

Feedback (フィードバック)

可能な限り最良の相互運用性ガイドを提供するため，この仕様に不明確な点がある場合や，誤り又は抜けが発見された場合， WS-I に連絡されたい。

メールの送信又はその他の手段で WS-I に対して通信することによって，あなた (個人を代表する場合はあなた自身，会社を代表してフィードバックを送る場合はあなたの会社) は，WS-I, WS-I のメンバー及びその他あなたのフィードバックをアクセスできる者に対して，この文書についてあなたが提供するフィードバックに対する，使用，公開，複写，ライセンス，修正，サブライセンス，その他いかなる形式による配布及び活用に対しても，非制限的で，譲渡不可能な，国際的で，永続的で，取り消し不可能な，ロイヤリティなしのライセンスを許諾するものとみなされる。あなたは，あなたが提供するいかなるフィードバックに対しても，秘匿性についていかなる期待ももたないことに同意しなければならない。あなたは，あなたがフィードバックを送る権利をもつことを表明し，保証しなければならない。あなたが会社を代表してフィードバックを送る場合，あなたが会社を代表してフィードバックを送る権利をもつことを表明し，保証しなければならない。 WS-I には，この文書の将来の版において，あなたのフィードバックの一部又は全部をレビューし，議論し，使用し，検討し，あるいはいかなる方法においても取り入れる義務はないということも，あなたは同意しなければならない。WS-I がこの文書の将来の版にあなたのフィードバックの一部又は全部を取り入れる場合，WS-I は，この文書の貢献者のリストにあなたの名前 (又は，あなたが会社を代表する場合には，会社の名前) を入れるかもしれないが，そうする義務はない。上記の内容があなた又はあなたが代表する会社にとって受け入れられない場合，いかなるフィードバックも送らないでほしい。

この文書に対するフィードバックは wsbasic_comment@ws-i.org に送ること。

Table of Contents (目次)

1. Introduction (序文)

この文書は WS-I Basic Profile 1.0 (以下，「このプロファイル」と呼ぶ) を定義する。WS-I Basic Profile 1.0 は非占有的 (non-proprietary) な Web サービス仕様で構成され，相互運用性を向上させる仕様の明確化及び敷衍を含んでいる。

第1節は，このプロファイルを紹介し，相互運用性に対してこのプロファイルがとった考え方を説明する。

第2節，Scope of the Profile (プロファイルの適用範囲) は，このプロファイルが向上させる相互運用性の範囲を限定する。

第3節， Profile Conformance (プロファイルに対する適合性) は，Basic Profile に適合するとはどういう意味かを説明する。

それに続く各節は，このプロファイルの構成要素となるそれぞれの仕様について述べるもので，次の2つの部分からなる。すなわち，構成要素となる仕様及び拡張点 (extensibility point) を列挙した概要説明と，それに続いて，構成要素となる仕様の個別の部分について述べた小節との2つの部分である。この文書の節番号と，参照される仕様のそれとの間には何の関係もないことに注意が必要である。

1.1 Guiding Principles (基本理念)

このプロファイルは，相互運用性を実現することに関係する一連の原則に沿って開発され，それらの原則は，全体として，このプロファイルの原理を構成している。この節ではそれらのガイドラインを説明する。

1.2 Notational Conventions (表記)

この文書では，「～しなければならない (MUST, SHALL)」，「～してはならない (MUST NOT, SHALL NOT)」，「必須の～ (REQUIRED)」，「～することが望ましい (SHOULD)」，「～すべきではない (SHOULD NOT)」，「推奨の～ (RECOMMENDED)」，「～してもよい (MAY)」及び「省略可能の～ (OPTIONAL)」は， RFC2119 に記述されているとおりに解釈する。

[訳注: この訳文では，該当する用語の訳の直後に，括弧でくくって原文の用語を示している。また，キーワードの訳語はできる限り JIS Z 8301 規格票の様式 に合わせた。]

このプロファイルにおける要件 (すなわち，Profile Conformance [プロファイルに対する適合性] の節に説明されている，適合性に影響するもの) は，次の形式で提示される:

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

ただし，ここで nnnn は要件番号で置き換えられる。それぞれの要件は，ちょうど一つの要件レベルキーワード (MUST のような) と適合性対象キーワード (MESSAGE のような) とをもつ。

いくつかの要件記述は，参照される仕様を明確化するだけで，実装に対して追加の制約を課さないものである。便宜のため，仕様の明確化 (clarification) は次のように注記される: C

いくつかの要件記述は，参照される仕様の標準化途中の内容を取り入れたものである。便宜上，そのような仕様の先取りは次のように注記される: xxxx，ただし，ここで xxxx は仕様を示す識別子である (たとえば，"SOAP12" は，現在検討中の SOAP 1.2 仕様を示す)。そういう仕様は完成しておらず，先取りした仕様が変更されることもありうることに注意が必要である。この情報は，実装者に対する便宜としてのみ含められている。

この仕様では，全体を通して次に示すいくつかの名前空間プレフィックス (namespace prefix) を使用する。各プレフィックスに関連付けられた URI を次に示す。プレフィックスの選択は恣意的なものであり，どのような文字列を選択しても意味的に差異がないことに注意が必要である。

2. Scope of the Profile (プロファイルの適用範囲)

このプロファイルの適用範囲 (scope) は，その検討する技術を詳細化する。言い換えれば，このプロファイルは，その適用範囲の中での相互運用性を向上することだけを図っている。最初は，このプロファイルの適用範囲は，それが参照する仕様によって限定される。このプロファイルが参照する仕様の完全なリストは，Appendix I を参照のこと。

このプロファイルの適用範囲は，拡張点 (extensibility points) によってさらに洗練される。参照される仕様はたいてい拡張メカニズム及び未規定の若しくは無制限のコンフィギュレーションパラメーターを提供している。拡張点と認識された場合，そのようなメカニズム又はパラメーターはこのプロファイルの適用範囲外であり，その使用はこのプロファイルに対する適合性表示 (conformance claim) の対象とはならない。

拡張点の使用は相互運用性を損なうことがあるので，その使用は Web サービスの関係者によって何らかの形で協議又は文書化されるべきである。たとえば，これは私的な合意 (out-of-band agreement) の形をとるかもしれない。

このプロファイルは，それでも，拡張点の使用について，その範囲を制限することなく，要件を課すことがある。また，拡張点の特定の使用方法について，このプロファイルが他のプロファイルと組み合わせて使われた場合に，相互運用性を向上するために，他のプロファイルで制限されることがある。

このプロファイルの拡張点の完全なリストは，Appendix II を参照のこと。

3. Profile Conformance (プロファイルに対する適合性)

このプロファイルに対して適合しているということは，このプロファイルの適用範囲内で，特定の対象に対する要件の集合を守ることであると定義されている。

このプロファイルの適用範囲は前節 (Scope of the Profile) で定義されている。このプロファイルに対する適合性は，参照される適用範囲内の仕様に対する適合性に依存するが，参照される仕様がこのプロファイルの要件と対立する場合，このプロファイルの要件が優先される。

要件 (requirements) は，適用範囲内での，このプロファイルに対する適合性の基準を述べている。要件は，そこでの相互運用性を向上する改良，解釈及び明確化を具体化したものである。要件レベルは，RFC2119 の用語 (たとえば，MUST, MAY, SHOULD) を使い，要件の性質と適合性に対する影響力とを示す。個々の要件記述は，便宜上，個別に (R9999 のような) 番号が振られている。

補足の文章 (根拠や例など) が要件を明確にするために付け加えられることもあるが，要件記述そのものだけが適合性を判定する際に考慮されるべきである。

適合性対象 (targets) は，適合性の記述をさまざまな文脈で記述することで， (たとえば SOAP メッセージや WSDL 記述のような) 対象物 (artifacts)，Web サービスのインスタンス，及び Web サービスの利用者 (consumer) に対する適合性試験 (conformance testing) と認定 (certification) とを可能にしている。次の節では，このプロファイルの適合性対象を説明する。

サービスがこのプロファイルに対する適合性を示すために，メッセージ (message)，記述 (description)，及びレジストリーデータ (registry data) は適合性表示 (conformance claims) で注記することができる。適合性表示は，特定のプロファイルに対する適合性を表明するためにある URI を使用する。

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

3.1 Conformance of Artifacts (対象物の適合性)

最も基本的なレベルの適合性は，対象物 (artifact) に対するものである。このプロファイルでは，次の3種類の対象物に対して要件記述を行う:

上記の対象物のインスタンスは，それに対する要件のすべてを満足したときに，適合しているものと見なされる。

3.2 Conformance of Services, Consumers and Registries (サービス，利用者及びレジストリーの適合性)

展開 (deploy) された Web サービスのインスタンス (wsdl:port 又は uddi:bindingTemplate で指定されるもの) は，適合する対象物 (artifact) のみを生成し，適合する対象物を (それが適切な場合には) 受け付ける場合に，適合しているものと見なされる。これは，複数の適合する対象物があり得る場合には，適合するサービスは，そのすべてを受け付けられなければならない (たとえば，送信側は XML をエンコードするのに UTF-8 又は UTF-16 のいずれかを選べるのに対して，受信側はどちらでも受け付けられなければならない) という意味である。

同様に，サービスのインスタンスの利用者 (consumer) は，適合する対象物のみを生成 (produce) し，それが適切な場合には，適合する対象物を受容 (consume) する能力がある場合に，適合しているものとみなされる。

最後に，レジストリーは，REGISTRY という対象物に対するこのプロファイルの要件を満足する場合に，適合しているものとみなされる。

適合する Web サービスのインスタンス (instance) は，INSTANCE に対するすべての要件記述を満足しなければならない。

同様に，適合する利用者 (consumer) は，CONSUMER に対するすべての要件記述を満足しなければならない。

適合する Web サービスのインスタンス (instance) 及び利用者 (consumer) は，いずれも，それが適切な場合には，次に示す適合性対象に対するすべての要件記述を満足しなければならない:

インスタンスに対する適合性はサービス全体には適用されず，port にのみ適用されることに注意が必要である。したがって，このプロファイルでは wsdl:service の定義にはいかなる制約も課さない。特に，wsdl:service は複数の wsdl:port をもつことができ，それぞれの wsdl:port は適合してもよいし，しなくてもよい。

Web サービスの型 (wsdl:binding 及び wsdl:portType で記述される) は，正しく実装され，動作することを意図された環境に展開された場合に，適合するインスタンスになるときに，適合していると見なされる。

さらに， Web サービスのインスタンスはサービスの運用に用いられる契約 (contract) を何らかの形で開示しなければならない。

R0001 INSTANCE は WSDL 1.1 のサービス記述，UDDI のバインディングテンプレート，又はその両方で記述されなければならない (MUST)。

ここで「記述される」とは，アクセス権のある利用者 (authorized consumer) が適合するサービスインスタンスのサービス記述を WSDL 1.1 文書で欲しいと要求した場合，サービスインスタンスのプロバイダーは， WSDL 文書，UDDI のバインディングテンプレート，又はその両方をその利用者に開示しなければならないという意味である。サービスインスタンスはサーバーから実行時に WSDL 文書を提供してもよいが，これは適合のためには必須ではない。同様に，任意のサービスインスタンスのプロバイダーは UDDI レジストリーにそのインスタンスプロバイダーを登録してもよいが，それは適合のためには必須ではない。上記のすべてのシナリオにおいて， WSDL の契約は存在していなければならないが，状況によっては，別の形態で開示されるかもしれない。

3.3 Conformance Annotation in Descriptions (記述における適合性注記)

適合性表示は特定の要素 (たとえば wsdl:portType) に関連付けて，適用範囲をその構造に限定することも可能である。

R0002 DESCRIPTION は，インスタンスに対する適合性の表示を，適合性表示スキーマ (conformance claim schema) に規定された通りの形で，含んでもよい (MAY)。

R0003 DESCRIPTION の適合性の表示は， wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation (wsdl:portType の子要素の方で，wsdl:binding の子要素ではない) 及び wsdl:message 要素の中の wsdl:documentation 要素の子要素でなければならない (MUST)。

ある要素における適合性の表示は，その要素 (及び port の場合，その要素が代表するインスタンス) が，それが遵守していると表示するプロファイルの要件に (当該要素に適用可能な範囲において) 適合していることを意味する。

ある要素における適合性の表示は，その要素が使用するすべての要素に対して同じ表示がなされていることを暗黙のうちに含み，次に示す継承規則に基づき，再帰的に適用される:

wsdl:port に対する表示は，参照される wsdl:binding に引き継がれる
wsdl:binding に対する表示は，参照される wsdl:portType に引き継がれる
wsdl:portType に対する表示は，参照される wsdl:operation に引き継がれる
wsdl:operation に対する表示は，その子要素である wsdl:output，wsdl:input，又はその両方から参照される wsdl:message に引き継がれる

適合性表示スキーマ (conformance claim schema) は次の通り:

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://ws-i.org/schemas/conformanceClaim/"
  xmlns:tns="http://ws-i.org/schemas/conformanceClaim/"
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified" >

  <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
    schemaLocation="http://schemas.xmlsoap.org/soap/envelope/" />

  <xsd:element name="Claim" >
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any namespace="##any" processContents="lax"
         minOccurs="0" maxOccurs="unbounded" />
      </xsd:sequence>
      <xsd:attribute name="conformsTo" type="xsd:anyURI" use="required"/>
      <xsd:attribute ref="soap:mustUnderstand" use="prohibited" />
      <xsd:anyAttribute namespace="##any" processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

正しい例:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
  xmlns:tns="http://example.org/myservice"
  xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
  xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
  targetNamespace="http://example.org/myservice">
  <wsdl:portType name="MyPortType">
      ...
  </wsdl:portType>
  <wsdl:binding name="MyBinding" portType="MyPortType" >
      ...
  </wsdl:binding>
  <wsdl:service name="MyService" >
    <wsdl:port name="MyPort" binding="tns:MyBinding" >
      <wsdl:documentation>
        <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
      </wsdl:documentation>
      <soapbind:address location="http://example.org/myservice/myport" />
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

3.4 Conformance Annotation in Messages (メッセージにおける適合性注記)

このプロファイルの新しい版や，その他のプロファイルがリリースされるに従い，一つのサービスが複数のプロファイルをサポートする可能性がある。メッセージを受信する際に，メッセージがどのプロファイルに適合しているかを，サービスが識別できるようにしたいと思うかもしれない。 SOAP メッセージがどのプロファイルに適合しているかを示せるようにするために，WS-I は SOAP ヘッダーとしての wsi:Claim 要素の使い方を規定する。

R0004 MESSAGE は，適合性表示を，適合性表示スキーマ (conformance claim schema) に規定された通りの形で，含んでもよい (MAY)。

R0005 MESSAGE の適合性表示は，SOAP ヘッダーブロックに格納しなければならない (MUST)。

R0006 MESSAGE は，一つ以上のプロファイルに対する適合性表示を含んでもよい (MAY)。

R0007 SENDER は，適合性表示を含む SOAP ヘッダーブロックを送る際に， soap:mustUnderstand 属性を使用してはならない (MUST NOT)。

SOAP メッセージは，SOAP ヘッダーブロックとして適合性表示をもち，受信側に対して送信側がメッセージの一つ以上のプロファイルへの適合を表示することができる。メッセージに適合性表示のないことが，メッセージが一つ以上のプロファイルに対する適合の有無を示すものと解釈してはならない。また，適合性表示のヘッダーブロックは参考であるとみなされ，そのため必須ヘッダーブロックであってはならない。そこで，このプロファイルでは soap:mustUnderstand 属性の適合性表示ヘッダーブロックでの使用を禁止している。

正しい例:

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
  <soap:Header>
    <!-- other headers -->
    <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
     xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
    <!-- other headers -->
  </soap:Header>
  <soap:Body>
    <!-- body content -->
  </soap:Body>
</soap:Envelope>

3.5 Conformance Annotation in Registry Data (レジストリーデータにおける適合性注記)

WSDL 記述のさまざまな要素に対してプロファイルの適合性表示を行うことが有用なのと同様に， uddi:tModel 要素にそれを行うことも有用である。 UDDI で uddi:tModel に属性を追加する自然な方法は，カテゴリーシステムを定義して使うことである。このプロファイルは，uddi:tModel が WS-I プロファイルに対する適合性を示すためにこのメカニズムを採用し，特にこのプロファイルへの適合性を示す方法を指定している。

R3020 プロファイルへの適合性を表示する uddi:tModel 型の REGDATA は， ws-i-org:conformsTo:2002_12 のタキソノミーを使用してカテゴライズされなければならない (MUST)。

R3030 プロファイルへの適合性を表示する uddi:tModel 型の REGDATA は， ws-i-org:conformsTo:2002_12 のカテゴライゼーションに，そのプロファイルに対応する適合性表示 URI を使用しなければならない (MUST)。

R3021 REGISTRY は， ws-i-org:conformsTo:2002_12 の tModel 定義をレジストリーの内容として追加することによって， WS-I 適合性カテゴリーシステムをサポートしなければならない (MUST)。

ws-i-org:conformsTo:2002_12 の tModel の内容は次のとおりである:

<tModel tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0">
  <name>ws-i-org:conformsTo:2002_12</name>
  <description xml:lang="EN">Category system used for UDDI entities
  to point to the WS-I concept to which they conform to</description>
  <overviewDoc>
    <overviewURL>http://ws-i.org/schemas/conformanceClaim/</overviewURL>
  </overviewDoc>
  <categoryBag>
  <keyedReference
    keyName="uddi-org:types:categorization"
    keyValue="categorization"
    tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" />
  </categoryBag>
</tModel>

正しい例:

<tModel tModelKey="...">
   <name>BarSOAPService</name>
   <description xml:lang="EN">Bar's SOAP Service</description>
   <overviewDoc>...</overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0"
         keyName="ws-I_conformance:BasicProfile1.0"
         keyValue="http://ws-i.org/profiles/basic/1.0" />
   </categoryBag>

wsdl:service 要素は必ずしも一つの uddi:businessService に対応付けられるわけではなく，また，適合性表示 (conformance claim) の対象になるわけではないので， uddi:businessEntity 又は uddi:businessService 要素がこのプロファイルに対する適合性を表示した場合，それがどういう意味になるかが不明確になるだろう。また， uddi:bindingTemplate 要素は， UDDI V2 の XML Schema がそれに対する categoryBag を提供していないので，カテゴライズすることができない。よって， wsdl:port 要素による適合性の表示は，対応する uddi:bindingTemplate には記述できない。

R3005 適合する Web サービス型を表現する uddi:tModel 要素以外の REGDATA が ws-i-org:conformsTo:2002_12 のタキソノミーと "http://ws-i.org/profiles/basic/1.0" のカテゴライゼーションを使用してカテゴライズされてはならない (MUST NOT)。

uddi:tModel の適合性の表示が，それの使っている wsdl:binding の適合性の表示と矛盾していた場合，解釈に困るだろう。

R3004 uddi:tModel 型の REGDATA は，その uddi:tModel に示される適合性の表示が，それの参照する wsdl:binding に示される適合性の表示と整合するように構成されなければならない (MUST)。

4. Messaging (メッセージング)

プロファイルのこの節では，次の仕様を参照し，その中での拡張点を定義する:

4.1 XML Representation of SOAP Messages (SOAP メッセージの XML 表現)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

SOAP 1.1 ではメッセージ伝送のための XML ベースの構造を定義している。このプロファイルではそれを使用することを必須とし，その使用に際しては次の制約を課す:

4.1.1 SOAP Messages and the Unicode BOM (SOAP メッセージと Unicode の BOM)

XML 1.0 では，UTF-8 エンコーディングにおいても BOM を含めてもよいことになっており，メッセージの受信側はそれを受け入れる用意がなければならない。 BOM は，UTF-16 でエンコードされた XML では必須である。

R4001 RECEIVER は，Unicode の Byte Order Mark (BOM) を含むメッセージを受け付けなければならない (MUST)。 C

4.1.2 SOAP Fault Syntax (SOAP フォルトの構文)

SOAP フォルトとは，soap:Body 要素に1つの子要素があり，それが soap:Fault 要素であるような SOAP メッセージのことである。このプロファイルは，soap:Fault要素の内容を SOAP 1.1 で明示的に記述された要素に制限する。

R1000 MESSAGE が soap:Fault 要素を含む場合，その要素は faultcode, faultstring, faultactor 及び detail以外の子要素をもってはならない (MUST NOT)。

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the message
  that I did not understand
  </detail>
  <m:Exception xmlns:m='http://example.org/faults/exceptions' >
    <m:ExceptionType>Severe</m:ExceptionType>
  </m:Exception>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
     <m:msg xmlns:m='http://example.org/faults/exceptions'>
         There were <b>lots</b> of elements in the message that I did not understand
     </m:msg>
     <m:Exception xmlns:m='http://example.org/faults/exceptions'>
       <m:ExceptionType>Severe</m:ExceptionType>
     </m:Exception>
   </detail>
</soap:Fault>

4.1.3 SOAP Faults and Namespaces (SOAP フォルトと名前空間)

soap:Fault 要素の子要素はローカルであり，名前空間修飾の必要はない。

R1001 MESSAGE が soap:Fault 要素を含む場合，その子要素は名前空間修飾なし (unqualified) でなければならない (MUST)。

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:faultcode>soap:Client</soap:faultcode>
  <soap:faultstring>Invalid message format</soap:faultstring>
  <soap:faultactor>http://example.org/someactor</soap:faultactor>
  <soap:detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that
          I did not understand
      </m:msg>
  </soap:detail>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
			xmlns='' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>
      <m:msg xmlns:m='http://example.org/faults/exceptions'>
          There were <b>lots</b> of elements in the message that
          I did not understand
      </m:msg>
  </detail>
</soap:Fault>

4.1.4 SOAP Fault Extensibility (SOAP フォルトの拡張性)

拡張性のために， detail 要素に追加の属性が現れること，及び， detail 要素に子要素として追加の要素が現れることが許されている。

R1002 RECEIVER は， detail 要素の子要素として (0 個を含む) いかなる数の要素をもつフォルトメッセージも受け付けなければならない (MUST)。それらの子要素は名前空間修飾されていても，されていなくてもよい。

R1003 RECEIVER は， detail 要素の属性として (0 個を含む) いかなる数の名前空間修飾された又はされていない属性をもつフォルトメッセージも受け付けなければならない (MUST)。名前空間修飾されたそれらの属性の名前空間は， "http://schemas.xmlsoap.org/soap/envelope" でなければ何でもよい。

4.1.5 SOAP Fault Language (SOAP フォルトの言語)

faultstring は，Fault の性質について人間が読めるように示したものである。したがって，それが特定の言語で記述されているとは限らず，xml:lang 属性が faultstring の言語を示すために使用できる。

R1016 RECEIVER は， faultstring 要素に xml:lang 属性をもつフォルトメッセージを受け付けなければならない (MUST)。

4.1.6 SOAP Custom Fault Codes (SOAP の独自フォルトコード)

SOAP 1.1 は，ドット表記 ("dot" notation) を使って独自のフォルトコードが faultcode 要素の内容に現れることを許している。

SOAP 1.1 で定義されたフォルトコードをこのメカニズムを使って拡張することは，名前空間の衝突を引き起こしうる。 "." (ドット) の右側に同じ名前が違う意味で使われた場合に，相互運用上の問題を引き起こすことがあるので，その使用は避けるべきである。

その代わりに，このプロファイルでは， SOAP 1.1 で定義されたフォルトコードを使い，フォルトの性質をあらわすために detail 要素の中に追加の情報を入れる方式を推奨している。

別の方式として，独自のフォルトコードを規定する機関の管理下にある名前空間の中で定義することも許容している。

いくつかの仕様では既にドット表記を使った独自のフォルトコードを定義している。それにもかかわらず，それらを将来の仕様で使うことは推奨しない。

R1004 MESSAGE が SOAP の faultcode 要素を含む場合，要素の内容は SOAP 1.1 仕様で定義されているフォルトコードの一つであるか，又は名前空間修飾されたフォルトコードであることが望ましい (SHOULD)。

R1031 MESSAGE が SOAP の faultcode 要素を含む場合，フォルトの意味を詳細化するために SOAP 1.1 のドット表記を使うべきではない (SHOULD NOT)。

独自のフォルトコードを必要とするアプリケーションは， SOAP 1.1 で定義されたフォルトコードを使い detail 要素に追加の情報を供給するか，それらのコードを規定する機関の管理下にある名前空間で定義するかの，いずれかを推奨する。

間違っている例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>soap:Server.ProcessingError</faultcode>
  <faultstring>An error occurred while processing the message
  </faultstring>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

正しい例:

<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Server</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>

4.1.7 SOAP encodingStyle Attribute (SOAP の encodingStyle 属性)

soap:encodingStyle 属性は，データを XML にエンコーディングする際に特定のスキームを使うことを示すのに使われてきた。しかし，この機能は XML 名前空間を使っても実現できるので，複雑さを導入してしまう。そこで，このプロファイルは，literal の，エンコードされない XML のほうを優先している。

R1005 MESSAGE は，名前空間名 (namespace name) が "http://schemas.xmlsoap.org/soap/envelope/" である要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

R1006 MESSAGE は，soap:Body 要素の子要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

R1007 rpc-literal バインディングで記述される MESSAGE は，soap:Body 要素の孫要素のいずれにも soap:encodingStyle 属性を含んではならない (MUST NOT)。

4.1.8 SOAP's use of XML (SOAP での XML の使用)

XML の DTD 及び PI は，SOAP のメッセージに使用された場合，セキュリティ上の脆弱性，処理のオーバーヘッド及びメッセージのセマンティクスの曖昧さを導入するかもしれない。そのため，XML のこれらの機能の処理は SOAP 1.1 の 3. 節で禁止されている。

R1008 MESSAGE は文書型宣言 (Document Type Declaration) を含んではならない (MUST NOT)。C

R1009 MESSAGE は処理命令 (Processing Instructions) を含んではならない (MUST NOT)。C

4.1.9 SOAP and XML Declarations (SOAP と XML 宣言)

XML 宣言の有無は相互運用性に影響しない。処理系によっては必ず XML 宣言をつけるかもしれない。

R1010 RECEIVER は，XML 宣言 (XML Declaration) を含むメッセージを受け付けなければならない (MUST)。 C

4.1.10 SOAP Trailers (SOAP 後続要素)

soap:Body 要素の後ろに兄弟要素が現れた場合の解釈は明らかではない。よって，そのような要素は禁止する。

R1011 MESSAGE は soap:Envelope 要素の子要素として， soap:Body 要素の後ろにいかなる要素も付加してはならない (MUST NOT)。

この要件は，SOAP 1.1 の，仕様本文と XML Schema 文書との間の食い違いを明確化する。

間違っている例:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' />
  </soap:Body>
  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
  </m:Data>
</soap:Envelope>

正しい例:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p='http://example.org/Operations' >
	  <m:Data xmlns:m='http://example.org/information' >
  Here is some data with the message
      </m:Data>
    </p:Process>
  </soap:Body>
</soap:Envelope>

4.1.11 Acceptable SOAP Character Encodings (許容可能な SOAP 文字エンコーディング)

このプロファイルでは，相互運用性の向上のため，すべての XML 処理系が "UTF-8" 及び "UTF-16" の文字エンコーディングをサポートすることを義務付けている。

この結果として， SOAP 1.1 の text/xml メディア型 (デフォルトの文字エンコーディングは "us-ascii") を使うべきであるという要件と合わせると， SOAP エンベロープのメディア型に charset パラメーターが常に存在しなければならないことになる。さらなる結果として， XML 1.0 及び RFC3023 "XML Media Types" の要件との整合性をとると，メッセージの中の XML 宣言にある encoding 擬似属性は，常に無視されることになる。

R1012 MESSAGE は UTF-8 又は UTF-16 のいずれかの文字エンコーディングでシリアライズされなければならない (MUST)。

R1018 MESSAGE のエンベロープのメディア型は， charset パラメーターを使って正しい文字エンコーディングを指定しなければならない (MUST)。

SOAP が HTTP バインディングで使われる場合，メディア型は HTTP の Content-Type ヘッダーフィールドに格納される。

4.1.12 SOAP mustUnderstand Attribute (SOAP mustUnderstand 属性)

soap:mustUnderstand 属性は "xsd:boolean" 型を制限したものであり，"0" 又は "1" の値のみを取る。よって，この2つの値だけが許されている。

R1013 MESSAGE が soap:mustUnderstand 属性を含む場合，属性の値として 2 種類の形式 "0" 及び "1" のみを使用しなければならない (MUST)。C

4.1.13 SOAP Body and Namespaces (SOAP Body と名前空間)

名前空間修飾のない要素名の使用は名前の衝突を起こすかもしれないので，soap:Body の子要素には修飾された名前を使わなければなければならない。

R1014 MESSAGE の soap:Body 要素の子要素は，名前空間修飾され (namespace qualified) なければならない (MUST)。

4.1.14 SOAP Envelope Namespace (SOAP Envelope の名前空間)

SOAP 1.1 は， Envelope 要素の名前空間名 (namespace name) が "http://schemas.xmlsoap.org/soap/envelope/" でない場合，メッセージを破棄することだけを規定している。このプロファイルは，曖昧でないオペレーションを保証するため，その代わりにフォルトが生成されることを要求している。

R1015 RECEIVER は，メッセージの Envelope 要素の名前空間 URI が "http://schemas.xmlsoap.org/soap/envelope/" でないものに遭遇した場合，フォルトを生成しなければならない (MUST)。

4.1.15 Use of xsi:type Attributes (xsi:type 属性の使用)

多くの場合，送信側と受信側とは，交換されるメッセージについて型情報を何らかの形で共有している。 xsi:type 属性は，そのようなスキーマの存在しない場合にのみ必要であり，それは，両者がすべての交換される内容を "xsd:anyType" と想定している場合である。

R1017 RECEIVER は，派生型を示すために必要な場合 (XML Schema Part 1: Structures, 2.6.1 節を参照) を除き，メッセージに xsi:type 属性の使用を必須としてはならない (MUST NOT)。

4.2 SOAP Processing Model (SOAP 処理モデル)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

SOAP 1.1 ではメッセージ処理のためのメッセージ交換モデルを定義している。特に，メッセージのヘッダーブロックとボディの処理についてのルールを定義している。また，フォルトの生成に関するルールも定義している。このプロファイルでは，その処理モデルに対して次の制約を課す:

4.2.1 Mandatory Headers (必須ヘッダー)

SOAP 1.1 の処理モデルは，必須ヘッダーブロックの処理についての規定が不十分である。必須ヘッダーブロックとは，soap:Header 要素の子要素で， soap:mustUnderstand 属性に "1" の値を設定しているもののことである。

R1025 RECEIVER は，すべての必須ヘッダーブロックに対するチェックが実際の処理の前に行われているように動作しなければならない (MUST)。 SOAP12

これによって，メッセージの一部分を処理した後で必須ヘッダーブロックを見つけることによる，予期せぬ副作用が発生しないことを保証する。

4.2.2 Generating mustUnderstand Faults (MustUnderstand フォルトの生成)

このプロファイルは，受信側が自分宛のヘッダーブロックを理解できない場合，フォルトを生成することを要求している。

R1027 メッセージが (soap:actor によって) 宛先として指定された受信者 (receiver) に理解できない必須ヘッダーブロック (soap:mustUnderstand 属性の値が "1" であるもの) をもつ場合， RECEIVER は "soap:MustUnderstand" フォルトを生成しなければならない (MUST)。

4.2.3 SOAP Fault Processing (SOAP フォルトの処理)

フォルトが生成される場合，それ以降の処理は行われるべきではない。request-response のメッセージ交換では，リクエストメッセージの送信側にフォルトメッセージが伝送され，何らかのアプリケーションレベルのエラーがユーザーに通知される。

R1028 RECEIVER でフォルトが生成される場合，フォルトが生成される前に行われた処理の影響を復元 (rollback) 又は補償 (compensate) するために必要なものを除き， SOAP メッセージに対するそれ以降の処理を行うべきではない (SHOULD NOT)。

R1029 SOAP のメッセージの処理の正常な結果が SOAP レスポンスの伝送になる場合で，その代わりに SOAP フォルトが生成されるとき， RECEIVER はレスポンスの代わりに SOAP フォルトメッセージを伝送しなければならない (MUST)。

R1030 SOAP フォルトを生成する RECEIVER は，実際に SOAP フォルトが生成されたことを，その状況に適切な手段をもってエンドユーザーに通知することが望ましい (SHOULD)。

4.3 Use of SOAP in HTTP (HTTP での SOAP の使用)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

SOAP 1.1 では HTTP に対する一つのプロトコルバインディングを定義している。このプロファイルではそのバインディングの使用を必須とし，その使用に際しては次の制約を課している:

4.3.1 HTTP Versions (HTTP の版数)

HTTP にはいくつかの版が定義されている。 HTTP 1.0 と比較すると，HTTP 1.1 は性能的に有利であり，また，仕様もはっきりと規定されている。

R1140 MESSAGE は HTTP 1.1 を使って送られることが望ましい (SHOULD)。

R1141 MESSAGE は HTTP 1.1 又は HTTP 1.0 のいずれかを使って送られなければならない (MUST)。

HTTP 1.1 のサポートには HTTP 1.0 のサポートが含まれており，また中継ノード (intermediaries) がメッセージの版数を変更してしまう可能性があることに注意が必要である。 HTTP の版数については RFC2145 "Use and Interpretation of HTTP Version Numbers" を参照。

4.3.2 Identifying SOAP Faults (SOAP フォルトの識別)

いくつかの利用者 (consumer) の実装は，SOAP フォルトの存在を識別するのに HTTP の状態コードのみを使用する。Web のインフラストラクチャが状態コードを変更するような状況も考えられるし，また，一般的な信頼性のためにも，このプロファイルでは，実装がエンベロープも調べることを要求する。

R1107 RECEIVER は soap:Fault 要素のみを含む SOAP メッセージをフォルトと解釈しなければならない (MUST)。

4.3.3 HTTP Methods and Extensions (HTTP のメソッドと拡張)

SOAP 1.1 仕様は HTTP バインディングに，HTTP の POST メソッドと HTTP 拡張フレームワーク (HTTP Extension Framework) の M-POST メソッドとの，2種類のいずれかが使用可能となるよう規定している。このプロファイルでは HTTP の POST メソッドだけを使用することを要求し，HTTP 拡張フレームワークの使用を禁止している。

R1132 HTTP のリクエスト MESSAGE は，HTTP の POST メソッドを使用しなければならない (MUST)。

R1108 MESSAGE は HTTP 拡張フレームワーク (HTTP Extension Framework) [RFC2774] を使用してはならない (MUST NOT)。

HTTP 拡張フレームワークは HTTP をモジュラーな形で拡張するための実験的なメカニズムである。このメカニズムは広く採用されておらず，また，SOAP での使用による利点は疑問であることから，このプロファイルでは使用を許していない。

4.3.4 SOAPAction Header Syntax (SOAPAction ヘッダーの構文)

テストによって明らかになっているように， HTTP の SOAPAction ヘッダーフィールドの値に引用符を必須とすることが実装の間の相互運用性を向上する。 HTTP 仕様はヘッダーフィールドの値を引用符で囲まないことを許容しているが，いくつかの SOAP 実装は値が引用符で囲まれていることを必須としている。

SOAPAction ヘッダーフィールドは純粋に処理系に対するヒントである。メッセージの処理に本質的な情報はすべて soap:Envelope に含まれる。

R1109 HTTP のリクエスト MESSAGE の SOAPAction ヘッダーフィールドの値は，引用符で囲まれた文字列でなければならない (MUST)。C

R1119 RECEIVER は，HTTP の SOAPAction ヘッダーフィールドの値が引用符で囲まれていない場合，フォルトを返してもよい (MAY)。C

正しい例:

WSDL 記述に次の要素:

<soapbind:operation soapAction="foo" />

を含む場合，対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: "foo"

正しい例:

WSDL 記述に次の要素:

<soapbind:operation />

又は

<soapbind:operation soapAction="" />

を含む場合，対応する SOAPAction HTTP ヘッダーは次のとおり:

SOAPAction: ""

4.3.5 HTTP and TCP Ports (HTTP と TCP のポート番号)

SOAP は HTTP のインフラストラクチャを利用するように設計されている。しかし，有害な副作用をもたらす場合 (たとえば，プロキシー，ファイアウォール，その他の中継ノードがからむ場合) がある。結果として，インスタンスは HTTP のデフォルト (80) とは別のポートを使った方がよい場合もある。

R1110 INSTANCE は，TCP の 80 番ポート (HTTP) での接続を受け付けてもよい (MAY)。C

W3C 及び IETF において， HTTP にバインディングされた SOAP メッセージを 80 番ポートで使うことの妥当性について，相当な議論が続けられてきた。これは許容できるやり方だというのが，結論である。

4.3.6 HTTP Success Status Codes (HTTP の成功状態コード)

HTTP は 2xx の状態コードを成功を示すために使っている。特に 200 は成功メッセージのデフォルトであるが， 202 もメッセージが処理に投入されたことを示すために使用可能である。付け加えて，その他の 2xx 状態コードも，HTTP 通信の性質によっては，適切となることもある。

R1124 INSTANCE は，リクエストの結果が成功であることを示すレスポンスの HTTP 状態コードとして 2xx を使用しなければならない (MUST)。

R1111 INSTANCE は，SOAP フォルトではない内容のレスポンスの HTTP 状態コードとして， "200 OK" を使うことが望ましい (SHOULD)。

R1112 INSTANCE は， SOAP メッセージを内容として含まないが HTTP リクエストの結果としては成功であるレスポンスの HTTP 状態コードとして， "200 OK" 又は "202 Accepted" のいずれかを使うことが望ましい (SHOULD)。

4.3.7 HTTP Redirect Status Codes (HTTP の転送状態コード)

HTTP の転送 (redirect) の状態コードを使う場合，元と同じメソッドを使うか，それとも GET メソッドを使うかという点について相互運用上の問題がある。このプロファイルでは，正しい転送の状態コードとして "307 Temporary Redirect" (同じメソッドでの転送を意味する) を要求している。詳細については，RFC2616 の 3xx 状態コードに関する記述を参照。

R1130 INSTANCE は，リクエストを別のエンドポイントに転送 (redirect) する場合，HTTP の状態コード "307 Temporary Redirect" を使用しなければならない (MUST)。

R1131 CONSUMER は，レスポンスとして "307 Temporary Redirect" を受け取った場合，リクエストを自動的に転送 (redirect) してもよい (MAY)。

RFC2616 は，ユーザーエージェントが自動的にリクエストを転送すべきではないとしている。しかし，この要件はブラウザーを想定したものであり，自動的な処理 (多くの Web サービスもこれにあたる) を想定したものではない。よって，このプロファイルでは，利用者 (consumer) が転送を自動的に行うことを許してはいるが，要求してはいない。

4.3.8 HTTP Client Error Status Codes (HTTP のクライアントエラー状態コード)

HTTP は 4xx の状態コードをクライアントのエラーによる失敗を示すために使っている。これらのうちのいずれかの結果を起こす状況はいろいろあるが，このプロファイルでは，HTTP リクエストのペイロードが正しいメディア型 (すなわち，SOAP/HTTP バインディングで要求されている "text/xml") でなかった場合と，期待されるメディア型 ("POST") が指定されなかった場合とを強調している。

R1125 INSTANCE は，リクエストの形式に問題があることを示すレスポンスの HTTP 状態コードとして 4xx を使用しなければならない (MUST)。

R1113 INSTANCE は，リクエストのメッセージが HTTP リクエストとして正しい形式ではない，又は XML が整形式 (well-formed) ではない場合， HTTP 状態コードとして "400 Bad Request" を使うことが望ましい (SHOULD)。

R1114 INSTANCE は，リクエストのメソッドが "POST" でない場合， HTTP 状態コードとして "405 Method not Allowed" を使うことが望ましい (SHOULD)。

R1115 INSTANCE は，HTTP リクエストの Content-Type ヘッダーの値が input のメッセージに対応するバインディングで指定された値と整合していなかった場合， HTTP 状態コードとして "415 Unsupported Media Type" を返すことが望ましい (SHOULD)。

上記の要件が，インスタンスに対して，リクエストにレスポンスを返すことを強制していないことに注意。場合によっては，たとえばサービス妨害攻撃 (Denial of Service attacks) の場合など，インスタンスがリクエストを無視することを選択することもある。

4.3.9 HTTP Server Error Status Codes (HTTP のサーバーエラー状態コード)

HTTP は 5xx の状態コードをサーバーのエラーによる失敗を示すために使っている。

R1126 INSTANCE は，レスポンスのメッセージが SOAP フォルトである場合， HTTP 状態コードとして "500 Internal Server Error" を使わなければならない (MUST)。

4.3.10 HTTP Cookies (HTTP クッキー)

HTTP 状態管理メカニズム (HTTP State Management Mechanism) は，「クッキー (Cookies)」とも呼ばれ， Web ブラウザーとサーバーとの間で状態をもったセッションを生成することを可能にしている。ハイパーテキストのブラウズを前提に設計されたため，クッキーの Web サービスでの動作の定義は曖昧であり，しかも，クッキーは SOAP エンベロープの外側にあるため，SOAP 1.1 又は WSDL 1.1 のいずれの仕様にも取り込まれていない。しかし，複数のサーバーの負荷分散やクッキーを使う既存のサーバーの統合など，クッキーを使うことが必要な状況もある。そこで，このプロファイルではクッキーを全面否定するのではなく，その用途を限定するにとどめている。

R1120 INSTANCE は HTTP 状態メカニズム [HTTP state mechanism] (クッキー) を使ってもよい (MAY)。

R1122 クッキーを使用する INSTANCE は RFC2965 に適合することが望ましい (SHOULD)。

R1121 INSTANCE は，正常動作のために利用者 (consumer) のクッキーのサポートを必須とすべきではない (SHOULD NOT)。

R1123 クッキーの値は CONSUMER にとって不透明 (opaque) なものとみなされなければならない (MUST)。

このプロファイルでは，クッキーはインスタンスの正常動作に必須とはしないことを推奨している。クッキーはヒントであり，最適化に使われるもので， Web サービスの実行に実質的に影響を与えないものであるべきだ。しかし，既存のサービスの統合などの例外的な用途でクッキーが必要になるかもしれないので，クッキーを要求することでインスタンスが不適合になるわけではない。よって，クッキーはインスタンスにとって意味があるかもしれないが，インスタンスと利用者 (consumer) との間でのデータ通信の抜け道 (out-of-bound data channel) として使われるべきではない。よって，利用者側でクッキーの内容を解釈することは許されていない。クッキーは不透明 (すなわち，利用者にとって意味のないもの) として扱われなければならない。

5. Service Description (サービス記述)

このプロファイルでは，Web Services Description Language (WSDL) を使って，メッセージを操作するエンドポイントの集合として，サービスを記述する。

プロファイルのこの節では，次の仕様を参照し，その中での拡張点を定義する:

5.1 Document Structure (文書構造)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1 は， Web サービスを記述するための XML に基づいた構造を定義する。このプロファイルではこの構造の使用を必須とし，その使用においては次の制約を課す:

5.1.1 WSDL Schema Definitions (WSDL スキーマ定義)

WSDL 1.1 仕様の Appendix 4 で規定されているスキーマは，仕様の本文の規定との間に不整合がある。このプロファイルは，既知の間違いに対する修正を取り入れた新しいスキーマ文書を参照する。

R2028 WSDL の名前空間 (このプロファイルでは "wsdl" のプレフィックスを用いる) を使用する DESCRIPTION は， "http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd" にある XML Schema に対して妥当 (valid) でなければならない (MUST)。

R2029 WSDL SOAP バインディングの名前空間 (このプロファイルでは "soapbind" のプレフィックスを用いる) を使用する DESCRIPTION は， "http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd" にある XML Schema に対して妥当 (valid) でなければならない (MUST)。

このプロファイルでは WSDL 記述がスキーマに対して妥当であることを要求しているが，利用者が WSDL 文書を妥当性検証することを要求しているわけではない。それを保証するのは WSDL 文書の作成者の責任である。

5.1.2 WSDL and Schema Import (WSDL とスキーマの import)

WSDL 1.1 のいくつかの例では， XML Schema 定義の取り込むために用いる WSDL の import 文が間違っている。このプロファイルでは import メカニズムの使用を明確化し，それぞれに整合性をもたせ，守備範囲を限定している。取り込まれたスキーマ文書は，取り込む側の WSDL 文書に対する XML の版数とエンコーディングとに対する要件に整合するよう，制限されている。

R2001 DESCRIPTION は，他の WSDL 記述を取り込むために WSDL の import 記述だけを使用しなければならない (MUST)。

R2002 XML Schema のスキーマ定義を取り込むために， DESCRIPTION は XML Schema の import 記述を使用しなければならない (MUST)。

R2003 DESCRIPTION は， XML Schema の import 記述を types 要素の中の xsd:schema 要素の内部のみで使用しなければならない (MUST)。

R2004 DESCRIPTION は，ルート要素が "http://www.w3.org/2001/XMLSchema" の名前空間にある schema 要素ではない任意の文書からスキーマ定義を取り込むために XML Schema の import 記述を使用してはならない (MUST NOT)。

R2009 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は， Unicode の Byte Order Mark (BOM) を含んでもよい (MAY)。

R2010 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は， UTF-8 又は UTF-16 のエンコーディングを使用しなければならない (MUST)。

R2011 DESCRIPTION から直接的又は間接的に取り込まれる XML Schema は， Extensible Markup Language (XML) の 1.0 版 W3C 勧告を使用しなければならない (MUST)。

間違っている例:

<definitions name="StockQuote"
   targetNamespace="http://example.com/stockquote/definitions"
   xmlns:xsd1="http://example.com/stockquote/schemas""
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/schemas"
         location="http://example.com/stockquote/stockquote.xsd"/>

   <message name="GetLastTradePriceInput">
        <part name="body" element="xsd1:TradePriceRequest"/>
    </message>
               ...
</definitions>

正しい例:

<definitions name="StockQuote"
      targetNamespace="http://example.com/stockquote/definitions">
      <import namespace="http://example.com/stockquote/definitions"
           location="http://example.com/stockquote/stockquote.wsdl"/>
      <message name="GetLastTradePriceInput">
         <part name="body" element="..."/>
      </message>
                  ...
   </definitions>

正しい例:

<definitions name="StockQuote"
   targetNamespace="http://example.com/stockquote/"
   xmlns:xsd1="http://example.com/stockquote/schemas"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/definitions"
        location="http://example.com/stockquote/stockquote.wsdl"/>

   <message name="GetLastTradePriceInput">
      <part name="body" element="xsd1:TradePriceRequest"/>
   </message>
               ...
</definitions>

5.1.3 WSDL Import location Attribute Syntax (WSDL import の location 属性の構文)

WSDL 1.1 は，wsdl:import 要素に location 属性が必須かどうか，あるいは，その内容がどうあるべきかについて，明確ではない。

R2007 DESCRIPTION は wsdl:import 要素の location 属性に空ではない値を指定しなければならない (MUST)。

wsdl:import は xsd:import に倣ったものであるが， wsdl:import には location 属性が必須であるのに対して， xsd:import の対応する属性である schemaLocation は省略可能である。 location が必須であることと整合性を取るために，その内容は空であってはならない。

5.1.4 WSDL Import location Attribute Semantics (WSDL import の location 属性のセマンティクス)

WSDL 1.1 は，WSDL 処理系が wsdl:import を見つけた場合，その要素の location 属性に指定された URI から実際に WSDL 文書を取り出して処理しなければならないのかどうか，明確ではない。

R2008 DESCRIPTION の中では， wsdl:import 要素の location 属性の値はヒントとして扱うことが望ましい (SHOULD)。C

これは，WSDL 処理系が WSDL 記述を wsdl:import 要素の location 属性に指定された URI から取り出してもよいが，必ずしもそうする必要はないことを意味する。というのも，WSDL 処理系は与えられた名前空間の WSDL 記述の位置を特定する，別の手段をもっていてもよいからである。たとえば，WSDL 処理系は WSDL 記述をキャッシュ又は組み込みでもっていてもよいし，メタデータリポジトリー又は UDDI サーバーから取り出してもよい。

5.1.5 Placement of WSDL import Elements (WSDL import 要素の位置)

WSDL 1.1 の 3.1 節の例 3 は，wsdl:import の位置についての混乱を引き起こす。

R2022 DESCRIPTION の中に wsdl:import 要素が現れる場合，それは， wsdl:documentation を除く， WSDL 名前空間の他のすべての要素よりも前になければならない (MUST)。

R2023 DESCRIPTION の中に wsdl:types 要素が現れる場合，それは， wsdl:documentation 及び wsdl:import を除く， WSDL 名前空間の他のすべての要素よりも前になければならない (MUST)。

間違っている例:

<definitions name="StockQuote"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://example.com/stockquote/definitions"
         location="http://example.com/stockquote/stockquote.wsdl"/>

   <message name="GetLastTradePriceInput">
       <part name="body" type="tns:TradePriceRequest"/>
   </message>
               ...
   <service name="StockQuoteService">
      <port name="StockQuotePort" binding="tns:StockQuoteSoap">
           ....
      </port>
   </service>

   <types>
      <schema targetNamespace="http://example.com/stockquote/schemas"
               xmlns="http://www.w3.org/2001/XMLSchema">
           .......
      </schema>
   </types>
</definitions>

正しい例:

   <definitions name="StockQuote"
      targetNamespace="http://example.com/stockquote/definitions">

     <import namespace="http://example.com/stockquote/base"
       location="http://example.com/stockquote/stockquote.wsdl"/>

      <message name="GetLastTradePriceInput">
         <part name="body" element="..."/>
      </message>
                  ...
   </definitions>

正しい例:

<definitions name="StockQuote"
           	 ...
   xmlns="http://schemas.xmlsoap.org/wsdl/">

  <types>
     <schema targetNamespace="http://example.com/stockquote/schemas"
          xmlns="http://www.w3.org/2001/XMLSchema">
           .......
     </schema>
   </types>

   <message name="GetLastTradePriceInput">
        <part name="body" element="tns:TradePriceRequest"/>
   </message>
               ...
   <service name="StockQuoteService">
      <port name="StockQuotePort" binding="tns:StockQuoteSoap">
           ....
      </port>
   </service>
</definitions>

5.1.6 XML Version Requirements (XML 版数の要件)

WSDL 1.1 又は XML Schema 1.0 のどちらも，XML の特定の版数を要求してはいない。相互運用性のため， WSDL 文書及びそれらが取り込むスキーマは XML の 1.0 版を使わなければならない。

R4004 DESCRIPTION は， Extensible Markup Language (XML) の 1.0 版 W3C 勧告を使用しなければならない (MUST)。

5.1.7 WSDL and the Unicode BOM (WSDL と Unicode の BOM)

XML 1.0 では，UTF-8 文字エンコーディングにおいても BOM を含めてもよいことになっており，WSDL 処理系はそれを受け入れる用意がなければならない。

R4002 DESCRIPTION には Unicode の Byte Order Mark (BOM) を含めてもよい (MAY)。C

5.1.8 Acceptable WSDL Character Encodings (許容可能な WSDL 文字エンコーディング)

このプロファイルでは SOAP と WSDL との両方に一貫して UTF-8 又は UTF-16 のいずれかを要求している (R1012 参照)。

R4003 DESCRIPTION は UTF-8 又は UTF-16 のいずれかの文字エンコーディングを使わなければならない (MUST)。

5.1.9 Namespace Coercion (名前空間の強制変更)

wsdl:import における名前空間の強制変更 (namespace coercion) は，このプロファイルでは許されない。

R2005 取り込まれる (imported) 側の記述 (description) の wsdl:definitions 要素の targetNamespace 属性の値は，取り込む (importing) 側の DESCRIPTION の wsdl:import 要素の namespace 属性の値と一致しなければならない (MUST)。

5.1.10 WSDL documentation Element (WSDL の documentation 要素)

WSDL 1.1 仕様のスキーマと本文とは，wsdl:documentation 要素をどこに置くべきかについて整合性がとれていない。

R2020 wsdl:documentation 要素は，DESCRIPTION の wsdl:import 要素の子要素として現れてもよい (MAY)。WSDL12

R2021 wsdl:documentation 要素は，DESCRIPTION の wsdl:part 要素の子要素として現れてもよい (MAY)。WSDL12

R2024 wsdl:documentation 要素は， DESCRIPTION の wsdl:definitions 要素の最初の子要素として現れてもよい (MAY)。WSDL12

5.1.11 WSDL Extensions (WSDL 拡張)

この，又は他の WS-I プロファイルで明示的に規定されていない WSDL 拡張のサポートを要求することは，それらの拡張を理解するように作られていない開発ツールとの間の，相互運用性の問題に発展する。

R2025 WSDL 拡張を含む DESCRIPTION は，このプロファイルの他の要件と矛盾する拡張を使用してはならない (MUST NOT)。

R2026 DESCRIPTION は，このプロファイルへの適合性を表示するいかなる要素 (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types 又は wsdl:import) にも wsdl:required 属性の値が "true" である拡張要素を含むべきではない (SHOULD NOT)。

R2027 記述 (description) の中の WSDL 名前空間の要素の処理の最中に，利用者 (consumer) がその子要素の中に WSDL 拡張要素を発見し，それが wsdl:required 属性に "true" の値を指定されており，かつそれが理解できない又は処理できない場合， CONSUMER は，その WSDL 名前空間内の要素の処理を失敗 (fail) しなければならない (MUST)。

WSDL 記述を読み込んで Web サービスのソフトウェアのインスタンスを生成する開発ツールは，未知の WSDL 拡張に対する解釈を組み込まれていないかもしれない。よって，必須の (required) WSDL 拡張は避けるべきである。利用方法及び意味について仕様が公開されていない必須の WSDL 拡張を使用することは，その拡張の作者を除く全員に対して，潜在的に克服不可能な相互運用上の問題を課してしまう。利用方法及び意味について仕様が公開されている必須の WSDL 拡張を使用することは，ここでの要件を規定するに至った相互運用上の問題を軽減するが，解消するものではない。

次に示す要素は，属性による拡張だけが有効である:

wsdl:import
wsdl:part
wsdl:portType
wsdl:input (portType の operation について)
wsdl:output (portType の operation について)
wsdl:fault (portType の operation について)

次に示す要素は，属性のほかに，要素による拡張も有効である:

wsdl:definitions
wsdl:types
wsdl:message
wsdl:operation
wsdl:binding
wsdl:input (binding の operation について)
wsdl:output (binding の operation について)
wsdl:fault (binding の operation について)
wsdl:service
wsdl:port

5.2 Types (型)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1 の wsdl:types 要素は，記述される Web サービスに適用されるデータ型定義を記述する。このプロファイルでは，このプロファイルに対する適合性を表示する WSDL の要素に参照される wsdl:types 要素の内容の，該当する部分に対して次の制約を課す:

5.2.1 QName References (QName 参照)

XML Schema は，各 QName 参照が，対象名前空間 (target namespace) 又は取り込まれた名前空間 (imported namespace) [xsd:import 要素で明示的に指定されたもの] のいずれかを使うことを要求している。入れ子の取り込み (nested imports) のみによって表現された名前空間への QName 参照は許されていない。

WSDL 1.1 は，WSDL 要素からの QName 参照にどのスキーマ対象名前空間が適しているかについて，明らかではない。このプロファイルでは， xsd:schema 要素で定義された対象名前空間と，取り込まれた名前空間との両方に対して， WSDL 要素からの QName 参照を許している。 XML Schema と同様に， (xsd:schema の targetNamespace 属性を通して，又は， xsd:import の namespace 属性を通して) WSDL ファイルから直接に参照されていない名前空間も，QName 参照して使うことができる。入れ子の取り込みを通してのみ定義された名前空間を QName 参照することは，許されていない。

R2101 DESCRIPTION は，取り込まれて (imported) もいなければ，参照する側の (referring) WSDL 文書に定義されてもいない名前空間に属する要素を QName で参照してはならない (MUST NOT)。

R2102 DESCRIPTION の中でのスキーマの構成要素に対する QName 参照は， xsd:schema 要素の targetNamespace 属性に定義された名前空間か， xsd:schema 要素の中にある xsd:import 要素の namespace 属性で定義された名前空間かの，いずれかを使わなければならない (MUST)。

5.2.2 Schema targetNamespace Syntax (スキーマの targetNamespace 構文)

wsdl:types 要素の子供であるすべての xsd:schema 要素に targetNamespace を要求することはよい方法であり， WSDL 文書の作成者に対する負担も最小限で済み，明確に定義されていない状況に落ちることを避けられる。

R2105 DESCRIPTION の wsdl:types 要素に含まれるすべての xsd:schema 要素は， targetNamespace 属性に有効な null でない値をもたなければならない (MUST)。ただし，xsd:schema 要素が，xsd:import, xsd:annotation 又はその両方だけを子要素としてもつ場合を除く。

5.2.3 soapenc:Array (配列)

WSDL 1.1 の 2.2 節にある，配列 (array) 型を宣言することについての推奨は，多様な解釈をされてきたため，相互運用性の問題となっている。さらに，配列を宣言するにはもっと明確な方法がある。

R2110 DESCRIPTION の中では配列 (array) 宣言は soapenc:Array 型を拡張又は制限してはならない (MUST NOT)。

R2111 DESCRIPTION の中では配列 (array) 宣言は型宣言に wsdl:arrayType 属性を使用してはならない (MUST NOT)。

R2112 DESCRIPTION の中では配列 (array) 宣言のラッパー要素の名前は ArrayOfXXX の形式で名前付けすべきではない (SHOULD NOT)。

R2113 シリアライズされた配列をもつ MESSAGE は soapenc:arrayType 属性を含んではならない (MUST NOT)。

間違っている例:

次の WSDL 記述が与えられた場合:

<xsd:element name="MyArray2" type="tns:MyArray2Type"/>
<xsd:complexType name="MyArray2Type"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
  <xsd:complexContent>
     <xsd:restriction base="soapenc:Array">
       <xsd:sequence>
          <xsd:element name="x" type="xsd:string"
           minOccurs="0" maxOccurs="unbounded"/>
       </xsd:sequence>
       <xsd:attribute ref="soapenc:arrayType"
        wsdl:arrayType="tns:MyArray2Type[]"/>
   </xsd:restriction>
 </xsd:complexContent>
</xsd:complexType>

SOAP メッセージは次のようにシリアライズされる (名前空間宣言は明確化のため省略):

<MyArray2 soapenc:arrayType="tns:MyArray2Type[]" >
  <x>abcd</x>
  <x>efgh</x>
</MyArray2>

正しい例:

次の WSDL 記述が与えられた場合:

<xsd:element name="MyArray1" type="tns:MyArray1Type"/>
<xsd:complexType name="MyArray1Type">
  <xsd:sequence>
   <xsd:element name="x" type="xsd:string"
    minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

SOAP メッセージは次のようにシリアライズされる (名前空間宣言は明確化のため省略):

<MyArray1>
  <x>abcd</x>
  <x>efgh</x>
</MyArray1>

5.2.4 WSDL and Schema Definition Target Namespaces (WSDL とスキーマ定義の対象名前空間)

スキーマで定義された名前と， WSDL 定義で割り当てられた名前とは，別々のシンボル空間に属している。

R2114 DESCRIPTION の中で， WSDL 定義の対象名前空間 (target namespace) と，スキーマ定義の対象名前空間 (target namespace) とは，同じであってもよい (MAY)。 WSDL12

5.3 Messages (メッセージ)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1 では wsdl:message 要素が伝送されるデータの抽象的な定義を表現する。 wsdl:binding 要素が抽象的な定義を特定の伝送路上の形式 (wire format) に結びつける。このプロファイルでは wsdl:message 要素の使用と，適合する wsdl:binding 要素が wsdl:message 要素を使用する方法とに関して次の制約を課す:

この節では，要件を簡略化し分かりやすくするため，次の定義が使われる。

「rpc-literal バインディング」とは，その子要素の wsdl:operation がすべて rpc-literal オペレーションである wsdl:binding 要素のことである。

「rpc-literal オペレーション」とは， wsdl:binding の子要素である wsdl:operation で，その子孫である soapbind:body 要素のそれぞれが use 属性に "literal" の値を指定しており，そのそれぞれが次のいずれかであるもののことである:

「document-literal バインディング」とは，その子要素の wsdl:operation がすべて document-literal オペレーションである wsdl:binding 要素のことである。

「document-literal オペレーション」とは， wsdl:binding の子要素である wsdl:operation で，その子孫である soapbind:body 要素のそれぞれが use 属性に "literal" の値を指定しており，そのそれぞれが次のいずれかであるもののことである:

5.3.1 Bindings and Parts (バインディングと part)

何個の wsdl:part 要素が document-literal 及び rpc-literal バインディングに許容又は要求されているか，そして，それらはどのように定義されるべきかについて，多様な解釈が存在する。

R2201 DESCRIPTION の中の document-literal バインディングは，それぞれの soapbind:body 要素に parts 属性が指定された場合，その値として，多くとも 1 個の part をもたなければならない (MUST)。

R2210 DESCRIPTION の中の document-literal バインディングが soapbind:body 要素に parts 属性を指定しない場合，対応する抽象的な wsdl:message は，0個又は1個の wsdl:part を定義しなければならない (MUST)。

R2202 DESCRIPTION の中の wsdl:binding は，soap:Body を構成する0個の part を指定する soapbind:body 要素をもってもよい (MAY)。

R2203 DESCRIPTION の中の rpc-literal バインディングは，その soapbind:body 要素の中で， type 属性を使って定義された wsdl:part だけを参照しなければならない (MUST)。

R2211 rpc-literal バインディングで記述された MESSAGE は， part のアクセサー要素に対して xsi:nil 属性に "1" 又は "true" の値を指定したものをもってはならない (MUST NOT)。

R2207 DESCRIPTION の中の wsdl:message は， rpc-literal バインディングで wsdl:part が soapbind:body に参照されていない限りにおいて， element 属性を使う wsdl:part をもってもよい (MAY)。

R2204 DESCRIPTION の中の document-literal バインディングは，その soapbind:body 要素のそれぞれにおいて， element 属性を使って定義された wsdl:part 要素だけを参照しなければならない (MUST)。

R2208 DESCRIPTION の中のバインディングは，その soapbind:body 要素によって参照されるのと同じ wsdl:message の中の wsdl:part を参照する soapbind:header 要素をもってもよい (MAY)。

Document スタイルでの part が 0 個の wsdl:message 要素の使用は，空の soap:Body を含むメッセージを送受信するオペレーションを許容するために，許されている。 RPC スタイルでの part が 0 個の wsdl:message 要素の使用は，引数，返却値，又はその両方が存在しないオペレーションを許容するために，許されている。

document-literal バインディングでは，このプロファイルは，多くとも1つの part が，抽象レベルにおいて element 形式を用いて定義され， soap:Body にシリアライズされることを要求している。

wsdl:part 要素が type 属性を使って定義された場合，その part の伝送路上の形式は， (XML Schema で) 暗黙的に， minOccurs 属性の値を "1" に， maxOccurs 属性の値を "1" に，そして nillable 属性の値を "false" に，それぞれ指定したものと同等である。

5.3.2 Bindings and Faults (バインディングとフォルト)

soapbind:fault, soapbind:header 及び soapbind:headerfault を記述する wsdl:part 要素をどう定義すべきかについて，いくつかの解釈がある。

R2205 DESCRIPTION の中の wsdl:binding は，その soapbind:header, soapbind:headerfault 及び soapbind:fault 要素のそれぞれにおいて， element 属性を使って定義された wsdl:part 要素だけを参照しなければならない (MUST)。

フォルトやヘッダーにはパラメーターが含まれないため， soapbind:fault, soapbind:header 及び soapbind:headerfault は， WSDL 1.1 に従い， style 属性の値が "document" であることを想定している。 R2204 は， style 属性の値が "document" である wsdl:part 要素で soapbind:body にバインドされたものはすべて element 属性で定義されることを要求している。この要件は，soapbind:fault, soapbind:header 及び soapbind:headerfault においても同様である。

5.3.3 Unbound portType Element Contents (バインディングされていない portType 要素の内容)

WSDL 1.1 は， wsdl:binding が wsdl:portType で定義される内容のバインディングを指定しないままでおいておくことが許されるのかどうか，明らかではない。

R2209 DESCRIPTION の中の wsdl:binding は，そのバインディングが参照する先の wsdl:portType に属する wsdl:message の各 part を， soapbind:body, soapbind:header, soapbind:fault 又は soapbind:headerfault のいずれか一つにバインドすることが望ましい (SHOULD)。

portType は名前付けされたオペレーション一式とそれに関連付けられた抽象的なメッセージとをもつ抽象的な契約 (abstract contract) を定義する。禁止されているわけではないが， portType に指定される抽象的な input, output 及び fault メッセージの各 part は， WSDL 1.1 の 3 節で定義されている SOAP バインディングを使う場合， soapbind:body, soapbind:header 等の適切な部分にバインドされることが想定されている。

5.3.4 Declaration of part Elements (part 要素の宣言)

WSDL 1.1 の 3.1 節の例 4 及び 5 は，間違って wsdl:part 要素の element 属性の有効な値としてスキーマのデータ型 ("xsd:string" など) を示している。

R2206 DESCRIPTION の中の wsdl:message が element 属性を使う wsdl:part をもつ場合，その属性の中で，グローバル要素宣言を参照しなければならない (MUST)。

間違っている例:

  <message name="GetTradePriceInput">
      <part name="tickerSymbol" element="xsd:string"/>
      <part name="time" element="xsd:timeInstant"/>
  </message>

間違っている例:

  <message name="GetTradePriceInput">
      <part name="tickerSymbol" element="xsd:string"/>
  </message>

正しい例:

  <message name="GetTradePriceInput">
      <part name="body" element="tns:SubscribeToQuotes"/>
  </message>

5.4 Port Types (ポート型)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1 では wsdl:portType 要素が抽象的なオペレーションの集合をグループ化するために使われる。このプロファイルでは wsdl:portType 要素の使用に関して次の制約を課す:

5.4.1 Ordering of part Elements (part の並び順)

parameterOrder 属性を許すことは，コードジェネレーターがメソッドシグネチャと伝送路上のメッセージのインスタンスとを対応づける助けになる。

R2301 MESSAGE の soap:Body の中での要素の並び順は，それを記述した wsdl:message の中の wsdl:part の並び順と同じでなければならない (MUST)。

R2302 DESCRIPTION は wsdl:operation 要素の parameterOrder 属性を，コードジェネレーターに対するヒントとして，返却値及びメソッドシグネチャを示すために使用してもよい (MAY)。

5.4.2 Allowed operations (許容されるオペレーション)

Solicit-Response 及び Notification は WSDL 1.1 では十分に規定されておらず，さらに，WSDL 1.1 はそれらに対するバインディングも定義していない。

R2303 DESCRIPTION は wsdl:portType の定義に Solicit-Response 及び Notification 型のオペレーションを使用してはならない (MUST NOT)。

5.4.3 Distinctive operations (区別できるオペレーション)

一つの wsdl:portType の中でのオペレーション名のオーバーロードは，このプロファイルでは禁止している。

R2304 DESCRIPTION の中の一つの wsdl:portType の定義を取り出したとき，その中に定義される operation の name 属性は，それぞれ別の値をもたなければならない (MUST)。

この要件は，一つの wsdl:portType の中の wsdl:operation に対してのみ適用されることに注意。 wsdl:portType は他の wsdl:portType に属する wsdl:operation と同じオペレーション名を使ってもよい。

5.5 Bindings (バインディング)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1, Section 2.5

WSDL 1.1 では wsdl:binding 要素が，特定の wsdl:portType で定義された operation 及び message に対する具体的なプロトコル及びデータ形式を提供している。このプロファイルでは適合する binding の使用に次の制約を課す:

5.6 SOAP Binding (SOAP バインディング)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1, Section 3.0

WSDL 1.1 は SOAP 1.1 のエンドポイントに対するバインディングを定義する。このプロファイルでは WSDL 1.1 で定義されている SOAP バインディングの使用を必須とし，その使用に関して次の制約を課す:

5.6.13 Describing headerfault Elements (headerfault 要素の記述)

soapbind:headerfault について，WSDL の仕様本文とスキーマとの間の矛盾がある。

R2719 DESCRIPTION の中の wsdl:binding は，既知のヘッダーフォルトが存在しない場合， soapbind:headerfault 要素を指定しなくてもよい (MAY)。

WSDL 1.1 のスキーマは，オペレーションの wsdl:input 及び wsdl:output 要素に soapbind:headerfault を指定することを必須としているが， WSDL 1.1 の仕様本文では省略可能になっている。本文が正しい。

5.6.21 Namespaces for Children of Part Accessors (part アクセサーの子要素の名前空間)

rpc-literal の SOAP メッセージにおいて， WSDL 1.1 は，対応する抽象的な part が WSDL 記述の targetNamespace とは違う名前空間に属する型であると定義される場合に， part のアクセサー要素の子要素の正しい名前空間修飾は何なのか，明確ではない。

R2737 rpc-literal バインディングに記述された MESSAGE は，パラメーター及び返却値に使用される part アクセサー要素の子要素を，それらの型が定義された targetNamespace に属するものとして名前空間修飾しなければならない (MUST)。

WSDL 1.1 の 3.5 節は次のように規定している:

パートの name、type、および namespace 属性の値は、すべてエンコードに対する入力ですが、namespace 属性は、抽象型によって明示的に定義されなかった内容に適用されるだけです。
[訳注: http://www.microsoft.com/japan/developer/workshop/xml/general/wsdl.asp で公開されている参考訳より引用。]

しかし，抽象型 (complexType) の要素及び属性の内容は，それらの定義された targetNamespace で修飾されると明示的に規定していない。 WSDL 1.1 は XML Schema とかなりの部分で同様に機能することを意図して規定されている。よって，実装は XML Schema と同じルールに従わなければならない。 targetNamespace "A" で定義された complexType が targetNamespace "B" のスキーマに取り込まれ，その中の要素宣言で参照された場合，その complexType の子要素の要素及び属性の内容は名前空間 "A" で修飾され，その要素自体は名前空間 "B" で修飾されるだろう。

正しい例:

次の WSDL では，wsdl:types で "http://example.org/foo/" の名前空間のスキーマを定義しているが，その定義は targetNamespace 属性の値が "http://example.org/bar/" になっている wsdl:definitions に含まれる。 (よって，ここではある名前空間で定義された型が，別の名前空間で定義された要素に含まれていることになる。):

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bar="http://example.org/bar/"
targetNamespace="http://example.org/bar/"
xmlns:foo="http://example.org/foo/">
<types>
   <xsd:schema targetNamespace="http://example.org/foo/"
       xmlns:tns="http://example.org/foo/"
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">
       <xsd:complexType name="fooType">
          <xsd:sequence>
             <xsd:element ref="tns:bar"/>
             <xsd:element ref="tns:baf"/>
          </xsd:sequence>
       </xsd:complexType>
       <xsd:element name="bar" type="xsd:string"/>
       <xsd:element name="baf" type="xsd:integer"/>
   </xsd:schema>
</types>
<message name="BarMsg">
   <part name="BarAccessor" type="foo:fooType"/>
</message>
<portType name="BarPortType">
   <operation name="BarOperation">
     <input message="bar:BarMsg"/>
   </operation>
</portType>
<binding name="BarSOAPBinding" type="bar:BarPortType">
   <soapbind:binding
    transport="http://schemas.xmlsoap.org/soap/http/"
    style="rpc"/>
   <operation name="BarOperation">
     <input message="bar:BarMsg">
       <soapbind:body use="literal" namespace="http://example.org/bar/"/>
     </input>
   </operation>
</binding>
<service name="serviceName">
  <port name="BarSOAPPort" binding="bar:BarSOAPBinding">
    <soapbind:address location="http://example.org/myBarSOAPPort"/>
  </port>
</service>
</definitions>

結果として生成される BarOperation の SOAP メッセージを次に示す:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://example.org/foo/">
  <s:Header/>
    <s:Body>
      <m:BarOperation xmlns:m="http://example.org/bar/">
         <BarAccessor>
            <foo:bar>String</foo:bar>
            <foo:baf>0</foo:baf>
         </BarAccessor>
      </m:BarOperation>
    </s:Body>
</s:Envelope>

5.7 Use of XML Schema (XML Schema の使用)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

WSDL 1.1 は XML Schema を型付けシステムの一つとして使用する。このプロファイルでは WSDL による Web サービスの記述に対する型付けシステムとして XML Schema を使用することを必須とする。

R2800 DESCRIPTION は XML Schema 1.0 の任意の構文を使用してもよい (MAY)。

R2801 DESCRIPTION は， XML Schema 1.0 勧告を利用者定義のデータ型及び構造の基盤として使用しなければならない (MUST)。

6. Service Publication and Discovery (サービスの公開と発見)

UDDI は，公開 (publication) 及び発見 (discovery) が必要な場合のためにこのプロファイルが採用した， Web サービスプロバイダーとその提供する Web サービスとを記述するためのメカニズムである。ビジネス，想定される用途，及び Web サービス型の記述は UDDI の用語で行われ，詳細な技術的記述は WSDL の用語で行われる。これら2つの仕様は重なり合うデータの記述を定義しており，両方の形式の記述が使われるが，このプロファイルは，これらの記述が衝突しないよう規定している。

Web サービスインスタンスを UDDI レジストリーに登録することは必須ではない。すべての利用シナリオが UDDI の提供する種類のメタデータと発見とを必要とするわけでは全くないが，そういう機能が必要な場合は，UDDI はそのために使用すべきメカニズムである。

UDDI V2 を構成する Web サービスは Basic Profile 1.0 に完全に適合するとはいえないことに注意が必要である。なぜならば，プロファイルに要求されているように，UTF-8 及び UTF-16 の両方の文字エンコーディングのメッセージを受け付けないからだ。(UTF-8 だけを受け付ける。) UDDI V2 がこのプロファイル以前に設計され，多くの場合実装されていることを考えれば，そのような食い違いがあることは別に不思議ではない。 UDDI の設計者は UDDI V2 の不適合を意識しており，将来考慮に入れるだろう。

プロファイルのこの節では，次の仕様を参照し，その中での拡張点を定義する:

6.1 bindingTemplates (bindingTemplate)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

UDDI Version 2.03 Data Structure Reference, Section 7

UDDI は Web サービスの INSTANCE を uddi:bindingTemplate 要素として表現する。 uddi:bindingTemplate は wsdl:port にほぼ相当する役割を果たすが， WSDL では表現できないオプションを提供する。 INSTANCE の WSDL 記述と UDDI 記述との間の整合性を保つために，このプロファイルは uddi:bindingTemplate 要素の構成方法に対して次の制約を課す:

6.2 tModels (tModel)

プロファイルのこの節では，次の仕様 (又はその節) を参照する:

UDDI Version 2.03 Data Structure Reference, Section 8

UDDI は Web サービスの型を uddi:tModel 要素で表現する。 (UDDI Data Structures 8.1.1 節参照。) それらは (URI を使って) 実際の記述を含む文書を指し示すことができるが，そうしなくてもよい。さらに，UDDI は Web サービスの型を記述するのに使われるメカニズムには何も規定していない。しかし， Web サービスの記述がなかったり，記述形式がバラバラだったりすると相互運用が複雑になるので，プロファイルで何も規定しないわけには行かない。

UDDI Specification, Appendix I.1.2.1.1 では uddi:tModel が Web サービスの記述に WSDL を使用することを許しているが，それを要求しているわけではない。しかし，それを要求しないことは，どの記述言語が使われるか分からないことになるので，相互運用上問題になる。

そこでこのプロファイルでは， Web サービスを記述する uddi:tModel 要素の書き方に次の制約を課している:

7. Security (セキュリティ)

ネットワーク指向のすべての情報技術にいえることだが，セキュリティの問題は Web サービスにおいても重大である。 Web サービスでは，セキュリティは，他の情報技術と同様，攻撃者がとりうる潜在的な脅威を理解することと，攻撃が成功するリスクを許容可能なレベルまで下げるために，作業的，物理的及び技術的な対抗手段をとることとから成り立っている。「リスクの許容可能なレベル」がアプリケーションによって大きく変わることと，対抗手段を実現するためのコストも同様に大きく変わることから， Web サービスをセキュアにするための，どこにでも適用できる「正解」などというものはあり得ない。対抗手段と許容可能なリスクとの間の完全なバランスを取ることは，個別の場合ごとにしかできないだろう。

それでも，多くの Web サービスにおいてリスクを許容可能なレベルに下げる経験的な対抗手段の共通パターンというものは存在する。Basic Profile は，それらのうち最も広く使われているものを，使用を強制はしないが，採用している。それは TLS 1.0 又は SSL 3.0 のいずれかで暗号化された HTTP (HTTPS) である。すなわち，適合する Web サービスは HTTPS を使用してもよい。他の対抗手段と併用してもよいし，何も使わなくてもよい。

HTTPS は，基本的なレベルの秘匿性を実現する，暗号化トランスポート接続の枯れた標準であると，広く認められている。HTTPS は，よって，多くの現実世界の Web サービスアプリケーションが必要とする基本的なセキュリティ機能を実現する，最も単純な手段となっている。 HTTPS は，クライアント証明書を使うことにより，クライアント認証に使用してもよい。

プロファイルのこの節では，次の仕様を参照し，その中での拡張点を定義する:

RFC2818: HTTP over TLS
RFC2246: The TLS Protocol Version 1.0
拡張点:
- TLS 暗号化スイート — TLS は任意の暗号化アルゴリズムの使用を許している。
- TLS 拡張 — TLS はハンドシェイク段階で拡張を許している。
The SSL Protocol Version 3.0
拡張点:
- SSL 暗号化スイート — SSL は任意の暗号化アルゴリズムの使用を許している。
RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
拡張点:
- 認証局 — 認証局の選択は通信当事者間の私的な合意による。
- 証明書拡張 — X509 は任意の証明書拡張を許している。

7.1 Use of HTTPS (HTTPS の使用)

Appendix I: Referenced Specifications (参照仕様)

次の仕様の要件は，このプロファイルで置き換えられたものを除き，参照することでこのプロファイルに取り込まれている。

Appendix II: Extensibility Points (拡張点)

この節では，Scope of the Profile で定義されたとおり，このプロファイルの構成要素となる仕様の拡張点を列挙する。

これらのメカニズムはこのプロファイルの適用範囲外である。これらを使うことが相互運用性に影響するかもしれないし， Web サービスの関係者での私的な合意が必要かもしれない。

Simple Object Access Protocol (SOAP) 1.1:

ヘッダーブロック — ヘッダーブロックは SOAP の根本的な拡張メカニズムである。
処理順序 — SOAP メッセージの構成要素 (たとえば，ヘッダー) の処理順序は未規定であり，別途調整 (out-of-band negotiation) が必要かもしれない。
中継ノード (intermediaries) の使用 — SOAP の中継ノードは SOAP 1.1 では規定が不十分であり，その利用には別途調整 (out-of-band negotiation) が必要かもしれない。また，その使用に際しては，どこでプロファイルの適合性を測定するかについて注意深い検討が必要になるかもしれない。
soap:actor の値 — soap:actor 属性の値は Web サービスの関係者の私的な合意による。
Fault の detail — Fault の detail 要素の内容は規定されていない。

RFC2616: Hypertext Transfer Protocol -- HTTP/1.1:

HTTP 認証 — HTTP の認証は，拡張スキーム，任意のダイジェストハッシュアルゴリズム，及びパラメーターを許容している。
未規定のヘッダーフィールド — HTTP は任意のヘッダーがメッセージに現れることを許容している。
Expect 拡張 — HTTP の Expect/Continue メカニズムは Expect 拡張を許容している。
内容エンコーディング — HTTP で許容される内容エンコーディング (content-encoding) は無制限である。
伝送エンコーディング — HTTP で許容される伝送エンコーディング (transfer-encoding) は無制限である。
Upgrade — HTTP は，Upgrade ヘッダーを使うことで，接続を任意のプロトコルに切り替えることを許容している。

Web Services Description Language (WSDL) 1.1:

WSDL 拡張 — WSDL は特定の位置に拡張要素を入れることを許す。そのような拡張の使用には別途調整 (out-of-band negotiation) が必要である。
相対 URI — WSDL は相対 URI の使い方について適切に規定していない。その使用については，さらに調整が必要である。詳細については XML Base を参照のこと。
妥当性検証モード — WSDL 及び XML Schema 文書を読み込むパーサーが DTD の妥当性検証を行うかどうか。
外部資源の取り込み — WSDL 及び XML Schema 文書を読み込むパーサーが外部実体及び DTD を取り込むかどうか。

XML Schema Part 1: Structures:

スキーマの注記 — XML Schema は注記 (annotation) を許しており，データ構造についての追加の情報を記述するために使われうる。

RFC2246: The TLS Protocol Version 1.0:

TLS 暗号化スイート — TLS は任意の暗号化アルゴリズムの使用を許している。
TLS 拡張 — TLS はハンドシェイク段階で拡張を許している。

The SSL Protocol Version 3.0:

SSL 暗号化スイート — SSL は任意の暗号化アルゴリズムの使用を許している。

RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile:

認証局 — 認証局の選択は通信当事者間の私的な合意による。
証明書拡張 — X509 は任意の証明書拡張を許している。

Appendix III: Acknowledgements (謝辞)

このプロファイルは WS-I Basic Profile Working Group の成果物であり，WG は次のメンバーを含む:

Mark Allerton (Crystal Decisions Corporation), George Arriola (Talking Blocks, Inc.), Keith Ballinger (Microsoft Corporation), Ilya Beyer (KANA), Rich Bonneau (IONA Technologies), Don Box (Microsoft Corporation), Andrew Brown (Verisign), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Luis Felipe Cabrera (Microsoft Corporation), Maud Cahuzac (France Telecom), Bhaskar Chakrabarti (United Airlines), Chia Chao (IONA Technologies), Martin Chapman (Oracle Corporation), Richard Chin (Avinon), Roberto Chinnici (Sun Microsystems), Sergio Compean (Avanade, Inc.), Tim Cooke (Onyx Software), Ugo Corda (SeeBeyond Tech), Paul Cotton (Microsoft Corporation), Joseph Curran (Accenture), Ayse Dilber (AT&T), Dave Ehnebuske (IBM), Mark Ericson (Mindreef Inc.), Colleen Evans (Sonic Software), Tim Ewald (Microsoft Corporation), Chuck Fay (FileNet Corporation), Chris Ferris (IBM), Daniel Foody (Actional Corporation), Toru Fujii (NTT), Satoru Fujita (NEC Corporation), Shishir Garg (France Telecom), Yaron Goland (BEA Systems), Hans Granqvist (Verisign), Martin Gudgin (Microsoft Corporation), Marc Hadley (Sun Microsystems), Bob Hall (Unisys Corporation), Scott Hanselman (Corillian), Muir Harding (Autodesk, Inc.), Loren Hart (Verisign), Harry Holstrom (Accenture), Larry Hsiung (Quovadx), Hemant Jain (Tata Consultancy), Steve Jenisch (SAS Institute), Erik Johnson (Epicor Software Corporation), Bill Jones (Oracle Corporation), Menno Jonkers (Tryllian BV), Anish Karmarkar (Oracle Corporation), Takahiro Kawamura (Toshiba), Bhushan Khanal (WRQ, Inc.), Sunil Kunisetty (Oracle Corporation), Canyang Kevin Liu (SAP AG), Jonathan Marsh (Microsoft Corporation), David Meyer (Plumtree Software, Inc.), Jeff Mischkinsky (Oracle Corporation), Tom Moog (Sarvega Inc.), Gilles Mousseau (Hummingbird Ltd.), Richard Nikula (BMC Software, Inc.), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Jesse Pangburn (Quovadx), TJ Pannu (ContentGuard, Inc.), Eduardo Pelegri-Llopart (Sun Microsystems), Vijay Rajan (Novell), Eric Rajkovic (Oracle Corporation), Graeme Riddell (Bowstreet), Claus von Riegen (SAP AG), Tom Rutt (Fujitsu Limited), Roger Sanborn (Crystal Decisions Corporation), Krishna Sankar (Cisco Systems, Inc.), Don Schricker (Micro Focus), Dave Seidel (Mindreef Inc.), Akira Shimaya (NTT), Yasser Shohoud (Microsoft Corporation), David Smiley (Mercator Software, Inc.), Seumas Soltysik (IONA Technologies), Joseph Stanko (Plumtree Software, Inc.), Keith Stobie (Microsoft Corporation), Yasuo Takemoto (NTT), Nobuyoshi Tanaka (NEC Corporation), Jorgen Thelin (Cape Clear Software), Sameer Vaidya (Talking Blocks, Inc.), William Vambenepe (Hewlett-Packard), Rick Weil (Eastman Kodak Company), Scott Werden (WRQ, Inc.), Ajamu Wesley (IBM), Shannon Wheatley (Kinzan, Inc.), Ian White (Micro Focus), Sue Worthman (Tryllian BV), Prasad Yendluri (webMethods Inc.).

以上

Cover Page for the Japanese Translation

Basic Profile Version 1.0a

Final Specification

Date: 2003/08/08 17:00:01

Basic Profile Version 1.0a

Final Specification

Date: 2003/08/08 17:00:01

Abstract (概要)

Status of this Document (この文書の位置付け)

Notice (通告)

Feedback (フィードバック)

Table of Contents (目次)

4.1.1 SOAP Messages and the Unicode BOM (SOAP メッセージと Unicode の BOM)

4.1.2 SOAP Fault Syntax (SOAP フォルトの構文)

4.1.3 SOAP Faults and Namespaces (SOAP フォルトと名前空間)

4.1.4 SOAP Fault Extensibility (SOAP フォルトの拡張性)

4.1.5 SOAP Fault Language (SOAP フォルトの言語)

4.1.6 SOAP Custom Fault Codes (SOAP の独自フォルトコード)

4.1.7 SOAP encodingStyle Attribute (SOAP の encodingStyle 属性)

4.1.8 SOAP's use of XML (SOAP での XML の使用)

4.1.9 SOAP and XML Declarations (SOAP と XML 宣言)

4.1.10 SOAP Trailers (SOAP 後続要素)

4.1.11 Acceptable SOAP Character Encodings (許容可能な SOAP 文字エンコーディング)

4.1.12 SOAP mustUnderstand Attribute (SOAP mustUnderstand 属性)

4.1.13 SOAP Body and Namespaces (SOAP Body と名前空間)

4.1.14 SOAP Envelope Namespace (SOAP Envelope の名前空間)

4.1.15 Use of xsi:type Attributes (xsi:type 属性の使用)

4.2.1 Mandatory Headers (必須ヘッダー)

4.2.2 Generating mustUnderstand Faults (MustUnderstand フォルトの生成)

4.2.3 SOAP Fault Processing (SOAP フォルトの処理)

4.3.1 HTTP Versions (HTTP の版数)

4.3.2 Identifying SOAP Faults (SOAP フォルトの識別)

4.3.3 HTTP Methods and Extensions (HTTP のメソッドと拡張)

4.3.4 SOAPAction Header Syntax (SOAPAction ヘッダーの構文)

4.3.5 HTTP and TCP Ports (HTTP と TCP のポート番号)

4.3.6 HTTP Success Status Codes (HTTP の成功状態コード)

4.3.7 HTTP Redirect Status Codes (HTTP の転送状態コード)

4.3.8 HTTP Client Error Status Codes (HTTP のクライアントエラー状態コード)

4.3.9 HTTP Server Error Status Codes (HTTP のサーバーエラー状態コード)

4.3.10 HTTP Cookies (HTTP クッキー)

5.1.1 WSDL Schema Definitions (WSDL スキーマ定義)

5.1.2 WSDL and Schema Import (WSDL とスキーマの import)

5.1.3 WSDL Import location Attribute Syntax (WSDL import の location 属性の構文)

5.1.4 WSDL Import location Attribute Semantics (WSDL import の location 属性のセマンティクス)

5.1.5 Placement of WSDL import Elements (WSDL import 要素の位置)

5.1.6 XML Version Requirements (XML 版数の要件)

5.1.7 WSDL and the Unicode BOM (WSDL と Unicode の BOM)

5.1.8 Acceptable WSDL Character Encodings (許容可能な WSDL 文字エンコーディング)

5.1.9 Namespace Coercion (名前空間の強制変更)

5.1.10 WSDL documentation Element (WSDL の documentation 要素)

5.1.11 WSDL Extensions (WSDL 拡張)

5.2.1 QName References (QName 参照)

5.2.2 Schema targetNamespace Syntax (スキーマの targetNamespace 構文)

5.2.3 soapenc:Array (配列)

5.2.4 WSDL and Schema Definition Target Namespaces (WSDL とスキーマ定義の対象名前空間)

5.3.1 Bindings and Parts (バインディングと part)

5.3.2 Bindings and Faults (バインディングとフォルト)

5.3.3 Unbound portType Element Contents (バインディングされていない portType 要素の内容)

5.3.4 Declaration of part Elements (part 要素の宣言)

5.4.1 Ordering of part Elements (part の並び順)

5.4.2 Allowed operations (許容されるオペレーション)

5.4.3 Distinctive operations (区別できるオペレーション)

5.4.4 parameterOrder Attribute Construction (parameterOrder 属性の構築)

5.4.5 Exclusivity of type and element Attributes (type 及び element 属性の排他性)

5.5.1 Use of SOAP Binding (SOAP バインディングの使用)

5.6.1 Specifying the transport Attribute (transport 属性の指定)

5.6.2 HTTP Transport (HTTP トランスポート)

5.6.3 Consistency of style Attribute (style 属性の整合性)

5.6.4 Encodings and the use Attribute (エンコーディングと use 属性)

5.6.5 Default for use Attribute (use 属性のデフォルト)

5.6.6 Multiple bindings for portType Elements (portType 要素への複数のバインディング)

5.6.7 Wire Signatures for operations (オペレーションの伝送路シグネチャ)

5.6.8 Multiple ports on an Endpoint (一つのエンドポイントに対する複数の port)

5.6.9 Child Element for Document-Literal Bindings (document-literal バインディングの子要素)

5.6.10 One-Way Operations (one-way オペレーション)

5.6.11 Namespaces for soapbind Elements (soapbind 要素の名前空間)

5.6.12 Consistency of portType and binding Elements (portType 及び binding 要素の整合性)

5.6.13 Describing headerfault Elements (headerfault 要素の記述)

5.6.14 Enumeration of Faults (フォルトの列挙)

5.6.15 Type and Name of SOAP Binding Elements (SOAP バインディング要素の型と名前)