- From: Arthur Ryman via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 16 Jun 2005 01:30:41 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv21106/wsdl20
Modified Files:
wsdl20-primer.html
Log Message:
Regenerated documents.
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.67
retrieving revision 1.68
diff -C2 -d -r1.67 -r1.68
*** wsdl20-primer.html 16 Jun 2005 00:34:47 -0000 1.67
--- wsdl20-primer.html 16 Jun 2005 01:30:39 -0000 1.68
***************
*** 96,101 ****
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br>6. <a href="#more-bindings">More on Bindings</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br>8. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br> 1.1 <a href="#Prerequisites">Prerequisites</a><br> 1.2 <a href="#PrimerStructure">Structure of this Primer</a><br> 1.3 <a href="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.2 <a href="#basics-getting-started">Getting Started: Defining a WSDL 2.0 Target Namespace</a><br> 2.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br> 2.3 <a href="#basics-types">Defining Message Types</a><br> 2.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.4 <a href="#bascs-interface">Defining an Interface</a><br> 2.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.5 <a href="#basics-binding">Defining a Binding</a><br> 2.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.6 <a href="#basics-service">Defining a Service</a><br> 2.6.1 <a href="#example-initial-service-explanation">Explanation of Example</a><br> 2.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 3.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> &nbs;3.2 <a href="#wsdl-schema">WSDL 2.0 Schema and Element Ordering</a><br> 3.3 <a href="#component-model">WSDL 2.0 Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br> 4.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 4.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 4.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br> 5.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 5.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 5.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 5.4 <a href="#more-interfaces-operations">Interface Operations</a><br> 5.4.1 <a href="#more-interfaces-opattr">Operation Attributes</a><br> 5.4.2 <a href="#N10919">Operation Message References</a><br> 5.4.2.1 <a href="#N10936">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N1094A">The element Attribute</a><br> 5.4.2.3 <a href="#N10971">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br>6. <a href="#more-bindings">More on Bindings</a><br> 6.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 6.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> .4 <a href="#bindingOperations">Binding Operations</a><br> 6.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 6.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 6.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N10B22">Explanation of
! Example</a><br> 6.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br> 7.1 <a href="#adv-extensibility">Extensibility</a><br> 7.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 7.2 <a href="#adv-FP">Features and Properties</a><br> 7.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 7.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 7.2.3 <a href="#adv-fp-properties">Properties</a><br> 7.3 <a href="#adv-MEP">Defining New MEPs</a><br> 7.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 7.4 <a href="#adv-import-and-athoring">Import mechanism and authoring style</a><br> 7.5 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.6 <a href="#adv-versioning">Web Service Versioning</a><br> 7.6.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.6.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.6.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 7.6.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.7 <a href="#adv-MTOM">MTOM Support</a><br> 7.8 <a href="#adv-RPCstyle">RPC Style</a><br> 7.9 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.10 <a href="#adv-service-refereces">Service and Endpoint References</a><br> 7.10.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br> 7.10.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.10.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.10.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.11 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.11.1 <a href="#N11161">Schemas in Imported Documents</a><br> 7.11.2 <a href="#N111EC">Multiple Inline Schemas in One Document</a><br> 7.11.3 <a href="#adv-schema-location">The schemaLocation Attribute/a><br> 7.11.3.1 <a href="#N1124C">Using the id Attribute to Identify Inline
Schemas</a><br> 7.12 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.12.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.13 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.13.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.13.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.13.3 <a href="#adv-generating-uris">Generating Temporary URIs</a><br>8. <a href="#References">References</a><br> 8.1 <a href="#Normative-References">Normative References</a><br> 8.2 <a href="#Informative-References">Informative References</a><br></p>
<h3><a id="appendix" name="appendix">Appendix</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
--- 96,101 ----
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br>6. <a href="#more-bindings">More on Bindings</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br>8. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br> 1.1 <a href="#Prerequisites">Prerequisites</a><br> 1.2 <a href="#PrimerStructure">Structure of this Primer</a><br> 1.3 <a href="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.2 <a href="#basics-getting-started">Getting Started: Defining a WSDL 2.0 Target Namespace</a><br> 2.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br> 2.3 <a href="#basics-types">Defining Message Types</a><br> 2.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.4 <a href="#bascs-interface">Defining an Interface</a><br> 2.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.5 <a href="#basics-binding">Defining a Binding</a><br> 2.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.6 <a href="#basics-service">Defining a Service</a><br> 2.6.1 <a href="#example-initial-service-explanation">Explanation of Example</a><br> 2.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 3.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> &nbs;3.2 <a href="#wsdl-schema">WSDL 2.0 Schema and Element Ordering</a><br> 3.3 <a href="#component-model">WSDL 2.0 Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br> 4.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 4.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 4.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br> 5.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 5.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 5.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 5.4 <a href="#more-interfaces-operations">Interface Operations</a><br> 5.4.1 <a href="#more-interfaces-opattr">Operation Attributes</a><br> 5.4.2 <a href="#N10912">Operation Message References</a><br> 5.4.2.1 <a href="#N1092F">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N10947">The element Attribute</a><br> 5.4.2.3 <a href="#N1098F">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br>6. <a href="#more-bindings">More on Bindings</a><br> 6.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 6.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> .4 <a href="#bindingOperations">Binding Operations</a><br> 6.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 6.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 6.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N10B4C">Explanation of
! Example</a><br> 6.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br> 7.1 <a href="#adv-extensibility">Extensibility</a><br> 7.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 7.2 <a href="#adv-FP">Features and Properties</a><br> 7.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 7.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 7.2.3 <a href="#adv-fp-properties">Properties</a><br> 7.3 <a href="#adv-MEP">Defining New MEPs</a><br> 7.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 7.4 <a href="#adv-import-and-athoring">Import mechanism and authoring style</a><br> 7.5 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.6 <a href="#adv-versioning">Web Service Versioning</a><br> 7.6.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.6.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.6.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 7.6.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.7 <a href="#adv-MTOM">MTOM Support</a><br> 7.8 <a href="#adv-RPCstyle">RPC Style</a><br> 7.9 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.10 <a href="#adv-service-refereces">Service and Endpoint References</a><br> 7.10.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br> 7.10.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.10.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.10.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.11 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.11.1 <a href="#N1118B">Schemas in Imported Documents</a><br> 7.11.2 <a href="#N11216">Multiple Inline Schemas in One Document</a><br> 7.11.3 <a href="#adv-schema-location">The schemaLocation Attribute/a><br> 7.11.3.1 <a href="#N11276">Using the id Attribute to Identify Inline
Schemas</a><br> 7.12 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.12.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.13 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.13.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.13.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.13.3 <a href="#adv-generating-uris">Generating Temporary URIs</a><br>8. <a href="#References">References</a><br> 8.1 <a href="#Normative-References">Normative References</a><br> 8.2 <a href="#Informative-References">Informative References</a><br></p>
<h3><a id="appendix" name="appendix">Appendix</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
***************
*** 712,717 ****
One way is to inline schema definitions within <code>xs:schema</code> elements that are children of <code>types</code>, as we have already seen. The other way is to use <code>xs:import</code> directly under <code>types</code>. It is perfectly reasonable to use both ways in one WSDL 2.0 document.</p>
! <p>A WSDL 2.0 <code>description</code> must NOT refer to XML Schema components that are neither imported nor
! inlined into that WSDL 2.0 <code>description</code>. In other words, the use of <code>xs:import</code> and/or <code>xs:schema</code> is a necessary condition for making XML Schema components available to a WSDL 2.0 Description component. </p>
<p>The following XML syntax for the <code>types</code> element illustrates the use of <code>xs:import</code> and <code>xs:schema</code>:</p>
--- 712,728 ----
One way is to inline schema definitions within <code>xs:schema</code> elements that are children of <code>types</code>, as we have already seen. The other way is to use <code>xs:import</code> directly under <code>types</code>. It is perfectly reasonable to use both ways in one WSDL 2.0 document.</p>
! <p>
! A WSDL 2.0
! <code>description</code>
! may only refer to XML Schema components that are either
! imported nor inlined into that WSDL 2.0
! <code>description</code>. In other words, the use of
! <code>xs:import</code>
! and/or
! <code>xs:schema</code>
! is a necessary condition for making XML Schema
! components available to a WSDL 2.0 Description
! component.
! </p>
<p>The following XML syntax for the <code>types</code> element illustrates the use of <code>xs:import</code> and <code>xs:schema</code>:</p>
***************
*** 752,760 ****
! <p>The <code>xs:import</code> mechanism is not transitive. Only components defined in the imported schema itself and components the schema includes via <code>xs:include</code> are available to the containing WSDL 2.0 document. Specifically, components that the schema imports via <code>xs:import</code> are NOT available to WSDL 2.0. </p>
!
! <table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-13</td></tr><tr><td valign="top" align="left" colspan="2">Check this. An issue was recently raised about import not being transitive.</td></tr></table>
!
!
<p>Here is an example of importing a schema. Assuming the message types in <a href="#example-initial-types">Example 2-3</a> are defined in a separate schema file named "http://greath.example.com/2004/schemas/resSvc.xsd" with a target namespace "http://greath.example.com/2004/schemas/resSvc", the schema definition can then be imported into the WSDL 2.0 as follows: </p>
<div class="exampleOuter">
--- 763,778 ----
! <p>
! Within the <code>types</code> element, the type components defined in any
! XML Schema namespaces that are imported
! via <code>xs:import</code> elements and any type components defined via <code>xs:schema</code> elements
! are available to the WSDL 2.0 components defined in the containing WSDL 2.0 documents.
! The type components defined in <code>xs:schema</code> elements may by introduced via <code>xs:include</code>
! elements.
! However, the XML Schema namespaces declared via <code>xs:import</code> elements within
! <code>xs:schema</code> elements do not become available to the WSDL 2.0 components defined in the
! containing WSDL 2.0 document.
! </p>
!
<p>Here is an example of importing a schema. Assuming the message types in <a href="#example-initial-types">Example 2-3</a> are defined in a separate schema file named "http://greath.example.com/2004/schemas/resSvc.xsd" with a target namespace "http://greath.example.com/2004/schemas/resSvc", the schema definition can then be imported into the WSDL 2.0 as follows: </p>
<div class="exampleOuter">
***************
*** 781,788 ****
<h3><a name="more-types-import-include-summary"></a>4.3 Summary of Import and Include Mechanisms</h3>
<p>The following table summarizes the similarities and differences
! between the <code>wsdl:</code> and <code>xs:</code>
! <code>include</code> and <code>import</code> mechanisms.</p>
! <a name="imin"></a><br><table border="1"><caption>Table 4-1. Summary of Import and Include Mechanisms</caption><thead><tr><th rowspan="1" colspan="1">Mechanism</th><th rowspan="1" colspan="1">Imported/Included Document Type</th><th rowspan="1" colspan="1">Meaning</th><th rowspan="1" colspan="1">Transitive?</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">wsdl:import</td><td rowspan="1" colspan="1">WSDL 2.0 document</td><td rowspan="1" colspan="1">Merge Interface, Binding and Service components from another WSDL 2.0 document that has a DIFFERENT targetNamespace. (Schema type and element declarations are NOT merged.)</td><td rowspan="1" colspan="1">No</td></tr><tr><td rowspan="1" colspan="1">wsdl:include</td><td rowspan="1" colspan="1">WSDL 2.0 document</td><td rowspan="1" colspan="1">Merge Interface, Binding and Service components from another WSDL 2.0 document that has the SAME targetNamespace. (Schema type and element declarations are NOT merged.)</td><td rowspan="1" colspan="1">Yes</td></tr><tr<td rowspan="1" colspan="1">xs::import</td><td rowspan="1" colspan="1">XML Schema document</td><td rowspan="1" colspan="1">Merge type and element declarations from another XML Schema document that has a DIFFERENT targetNamespace.</td><td rowspan="1" colspan="1">No</td></tr><tr><td rowspan="1" colspan="1">xs:import</td><td rowspan="1" colspan="1">XML Schema document</td><td rowspan="1" colspan="1">Merge type and element declarations from another XML Schema document that has the SAME targetNamespace.</td><td rowspan="1" colspan="1">Yes</td></tr></tbody></table><br>
! <p>More advanced topics on importing schemas are discussed in <a href="#adv-multiple-inline-schemas"><b>7.11 Importing Schemas</b></a></p>
</div>
--- 799,855 ----
<h3><a name="more-types-import-include-summary"></a>4.3 Summary of Import and Include Mechanisms</h3>
<p>The following table summarizes the similarities and differences
! between the WSDL 2.0 and XML Schema
! <code>include</code> and <code>import</code> mechanisms.</p>
! <a name="imin"></a><br><table border="1">
! <caption>Table 4-1.
! Summary of Import and Include Mechanisms
! </caption>
! <thead>
! <tr>
! <th rowspan="1" colspan="1">Mechanism</th>
! <th rowspan="1" colspan="1">Object</th>
! <th rowspan="1" colspan="1">Meaning</th>
! </tr>
! </thead>
! <tbody>
! <tr>
! <td rowspan="1" colspan="1">wsdl:import</td>
! <td rowspan="1" colspan="1">WSDL 2.0 Namespace</td>
! <td rowspan="1" colspan="1">
! Declare that WSDL 2.0 components
! refer to WSDL 2.0 components
! from a DIFFERENT targetNamespace.
! </td>
! </tr>
! <tr>
! <td rowspan="1" colspan="1">wsdl:include</td>
! <td rowspan="1" colspan="1">WSDL 2.0 Document</td>
! <td rowspan="1" colspan="1">
! Merge Interface, Binding and Service
! components from another WSDL 2.0 document
! that has the SAME targetNamespace.
! </td>
! </tr>
! <tr>
! <td rowspan="1" colspan="1">xs:import</td>
! <td rowspan="1" colspan="1">XML Schema Namespace</td>
! <td rowspan="1" colspan="1">
! Declare that XML Schema components
! refer to XML Schema components
! from a DIFFERENT targetNamespace.
! </td>
! </tr>
! <tr>
! <td rowspan="1" colspan="1">xs:include</td>
! <td rowspan="1" colspan="1">XML Schema Document</td>
! <td rowspan="1" colspan="1">
! Merge XML Schema components from
! another XML Schema document that has the
! SAME targetNamespace.
! </td>
! </tr>
! </tbody>
! </table><br>
! <p>More advanced topics on importing schemas are discussed in <a href="#adv-multiple-inline-schemas"><b>7.11 Importing Schemas</b></a></p>
</div>
***************
*** 814,818 ****
<fault name="<em>xs:NCName</em>"
! element="<em>xs:QName</em>"? >
</fault>*
--- 881,885 ----
<fault name="<em>xs:NCName</em>"
! element="<em>xs:QName</em>"? >
</fault>*
***************
*** 823,831 ****
<input messageLabel="<em>xs:NCName</em>"?
! element="<em>union of xs:QName, xs:Token</em>"? >
</input>*
<output messageLabel="<em>xs:NCName</em>"?
! element="<em>union of xs:QName, xs:Token</em>"? >
</output>*
--- 890,898 ----
<input messageLabel="<em>xs:NCName</em>"?
! element="<em>union of xs:QName, xs:Token</em>"? >
</input>*
<output messageLabel="<em>xs:NCName</em>"?
! element="<em>union of xs:QName, xs:Token</em>"? >
</output>*
***************
*** 849,855 ****
<h3><a name="more-interfaces-inheritance"></a>5.2 Interface Inheritance</h3>
! <p>The optional <code>extends</code> attribute allows an interface to extend or inherit from one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines directly. Two things about extending interfaces deserve some attention. </p><p>First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given interface extends must NOT themselves extend that interface either directly or indirectly. </p><p>Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>] "<a href="wsdl20.html#compequiv">Equivalence of Components</a>") then they are considered t be the same operation, i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendents.) In the second case, if two operations have the same name in the same WSDL 2.0 target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely. </p><p>Finally, since faults, features and properties can also be defined as children of the <code>interface</code> element (as described in the following sections), the same name-collision rules apply to those constructs. </p>
!
! <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service,
the content of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p>
--- 916,971 ----
<h3><a name="more-interfaces-inheritance"></a>5.2 Interface Inheritance</h3>
! <p>
! The optional
! <code>extends</code>
! attribute allows an interface to extend or inherit
! from one or more other interfaces. In such cases the
! interface contains the operations of the interfaces
! it extends, along with any operations it defines
! directly. Two things about extending interfaces
! deserve some attention.
! </p>
! <p>
! First, an inheritance loop (or infinite recursion)
! is prohibited: the interfaces that a given interface
! extends must NOT themselves extend that interface
! either directly or indirectly.
! </p>
! <p>
! Second, we must explain what happens when operations
! from two different interfaces have the same target
! namespace and operation name. There are two cases:
! either the component models of the operations are
! the same, or they are different. If the component
! models are the same (per the component comparison
! algorithm defined in WSDL 2.0 Part 1
! [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>]
! "
! <a href="wsdl20.html#compequiv">
! Equivalence of Components
! </a>
! ") then they are considered to be the same
! operation, i.e., they are collapsed into a single
! operation, and the fact that they were included more
! than once is not considered an error. (For
! operations, component equivalence basically means
! that the two operations have the same set of
! attributes and descendents.) In the second case, if
! two operations have the same name in the same WSDL
! 2.0 target namespace but are not equivalent, then it
! is an error. For the above reason, it is considered
! good practice to ensure that all operations within
! the same target namespace are named uniquely.
! </p>
! <p>
! Finally, since faults can
! also be defined as children of the
! <code>interface</code>
! element (as described in the following sections),
! the same name-collision rules apply to those
! constructs.
! </p>
!
! <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service,
the content of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p>
***************
*** 910,914 ****
them, thereby ensuring consistency across all operations that use the faults </p>
! <p>The <code>fault</code> element has a required <code>name</code> attribute that must be unique within the WSDL 2.0 document's target namespace, and permits it to be referenced from operation declarations. The optional <code>element</code> attribute can be used to indicate a schema for the content or payload of the fault message. Its value should be the QName of a global element defined in the <code>types</code> section. Please note that when other type systems are used to define the schema for a fault message, additional attributes may need to be defined via WSDL 2.0's attribute extension mechanism to allow the schema to be associated with the fault.</p>
--- 1026,1048 ----
them, thereby ensuring consistency across all operations that use the faults </p>
! <p>
! The
! <code>fault</code>
! element has a required
! <code>name</code>
! attribute that must be unique within the parent <code>interface</code> element, and permits it to be
! referenced from operation declarations. The optional
! <code>element</code>
! attribute can be used to indicate a schema for the
! content or payload of the fault message. Its value
! should be the QName of a global element defined in
! the
! <code>types</code>
! section. Please note that when other type systems
! are used to define the schema for a fault message,
! additional attributes may need to be defined via
! WSDL 2.0's attribute extension mechanism to allow
! the schema to be associated with the fault.
! </p>
***************
*** 944,956 ****
</li>
- <li>
- <p>An optional <code>safe</code> attribute whose value is a boolean indicating whether the operation is asserted to be "safe" (as defined in Section 3.5 of the Web Architecture [<cite><a href="#webarch">Web Architecture</a></cite>]) for clients to invoke. In essence, a safe operation is any operation that does not give the client any new obligations. For example, an operation that permits the client to check prices on products typically would not obligate the client to buy those products, and thus would be safe, whereas an operation for purchasing products would obligate the client to pay for the products that were ordered, and thus would not be safe. </p><p>An operation should be marked safe (by setting the <code>safe</code> to true) if it meets the criteria for a safe interaction defined in Section 3.5 of the Web Architecture [<cite><a href="#webarch">Web Architecture</a></cite>], because this permits the infrastructure to perform efficiency optimizations, such as pre-fetch, re-fetch and cahing. </p><p>The default value of this attribute is false. If it is false or is not set, then no assertion is made about the safety of the operation; thus the operation may or may NOT be safe.</p>
- </li>
</ul></div><div class="div3">
! <h4><a name="N10919"></a>5.4.2 Operation Message References</h4><p>An <code>operation</code> will also have <code>input</code>, <code>output</code>,<code>infault</code>, and/or <code>outfault</code> element children that specify the ordinary and fault message types to be used by that operation. The MEP specified by the <code>pattern</code> attribute determines which of these elements should be included, since each MEP has placeholders for the message types involved in its pattern. </p><p>Since operations were already discussed in <a href="#basics-interface"><b>2.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div4">
! <h5><a name="N10936"></a>5.4.2.1 The messageLabel Attribute</h5><p>The <code>messageLabel</code> attribute of the <code>input</code> and <code>output</code> elements is optional. It is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] and it has only one message with a given direction. </p></div><div class="div4">
! <h5><a name="N1094A"></a>5.4.2.2 The element Attribute</h5><p>The <code>element</code> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (aka payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: </p><dl><dt class="label"><code>#any</code></dt><dd><p>The message content is any single element.</p></dd><dt class="label"><code>#none</code></dt><dd><p>There is no message content, i.e., the message payload is empty.</p></dd></dl><p>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Sa what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </td></tr></table></p></div><div class="div4">
! <h5><a name="N10971"></a>5.4.2.3 Multiple infault or outfault Elements</h5><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div></div>
--- 1078,1165 ----
</li>
</ul></div><div class="div3">
! <h4><a name="N10912"></a>5.4.2 Operation Message References</h4><p>An <code>operation</code> will also have <code>input</code>, <code>output</code>,<code>infault</code>, and/or <code>outfault</code> element children that specify the ordinary and fault message types to be used by that operation. The MEP specified by the <code>pattern</code> attribute determines which of these elements should be included, since each MEP has placeholders for the message types involved in its pattern. </p><p>Since operations were already discussed in <a href="#basics-interface"><b>2.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div4">
!
! <h5><a name="N1092F"></a>5.4.2.1 The messageLabel Attribute</h5>
! <p>
! The
! <code>messageLabel</code>
! attribute of the
! <code>input</code>
! and
! <code>output</code>
! elements is optional. It is not necessary to
! explicitly set the
! <code>messageLabel</code>
! when the MEP in use is one of the eight MEPs
! predefined in WSDL 2.0 Part 2
! [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
! and it has only one message with a given
! direction.
! </p>
! </div>
! <div class="div4">
!
! <h5><a name="N10947"></a>5.4.2.2 The element Attribute</h5>
! <p>
! The
! <code>element</code>
! attribute of the
! <code>input</code>
! and
! <code>output</code>
! elements is used to specify the message content
! schema (aka payload schema) when the content
! model is defined using XML Schema. As we have
! seen already, it can specify the QName of an
! element schema that was defined in the
! <code>types</code>
! section. However, alternatively it can specify
! one of the following tokens:
! </p><dl>
!
! <dt class="label">
! <code>#any</code>
! </dt>
! <dd>
! <p>
! The message content is any
! single element.
! </p>
! </dd>
!
!
! <dt class="label">
! <code>#none</code>
! </dt>
! <dd>
! <p>
! There is no message content,
! i.e., the message payload is
! empty.
! </p>
! </dd>
!
!
! <dt class="label">
! <code>#other</code>
! </dt>
! <dd>
! <p>
! The message content is described by a non-XML type system.
! Extension attributes specify the type.
! </p>
! </dd>
!
! </dl><p>
! The
! <code>element</code>
! attribute is also optional. If it is not
! specified, then #other.
! </p>
! </div>
! <div class="div4">
! <h5><a name="N1098F"></a>5.4.2.3 Multiple infault or outfault Elements</h5><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div></div>
***************
*** 1019,1022 ****
--- 1228,1233 ----
<input messageLabel="<em>xs:NCName</em>"? > </input>*
<output messageLabel="<em>xs:NCName</em>"? > </output>*
+ <infault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </infault>*
+ <outfault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </outfault>*
</operation>*
***************
*** 1170,1174 ****
</div>
<div class="div3">
! <h4><a name="N10B22"></a>6.6.1 Explanation of
Example</h4><table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</td></tr></table><p></p><dl>
<dt class="label"><code>type="http://www.w3.org/2005/05/wsdl/http"</code></dt>
--- 1381,1385 ----
</div>
<div class="div3">
! <h4><a name="N10B4C"></a>6.6.1 Explanation of
Example</h4><table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</td></tr></table><p></p><dl>
<dt class="label"><code>type="http://www.w3.org/2005/05/wsdl/http"</code></dt>
***************
*** 2743,2747 ****
<div class="div3">
! <h4><a name="N11161"></a>7.11.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
--- 2954,2958 ----
<div class="div3">
! <h4><a name="N1118B"></a>7.11.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
***************
*** 2950,2954 ****
<div class="div3">
! <h4><a name="N111EC"></a>7.11.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
--- 3161,3165 ----
<div class="div3">
! <h4><a name="N11216"></a>7.11.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
***************
*** 3084,3088 ****
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer (see [<cite><a href="#XPTR">XPointer Framework</a></cite>]) can also be used.
</p><div class="div4">
! <h5><a name="N1124C"></a>7.11.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-29</a>
--- 3295,3299 ----
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer (see [<cite><a href="#XPTR">XPointer Framework</a></cite>]) can also be used.
</p><div class="div4">
! <h5><a name="N11276"></a>7.11.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-29</a>
Received on Thursday, 16 June 2005 01:30:49 UTC