- From: Kevin Liu via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 26 Apr 2005 23:19:45 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv21329/ws/desc/wsdl20
Modified Files:
wsdl20-primer.html wsdl20-primer.xml
Log Message:
changed opCheckAvailability to use uri style and GET, removed related editor note
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.62
retrieving revision 1.63
diff -C2 -d -r1.62 -r1.63
*** wsdl20-primer.xml 25 Apr 2005 12:13:38 -0000 1.62
--- wsdl20-primer.xml 26 Apr 2005 23:19:42 -0000 1.63
***************
*** 170,174 ****
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2004/03/wsdl/in-out"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 170,175 ----
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2004/03/wsdl/in-out"
! style="http://www.w3.org/2004/08/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 189,193 ****
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
</binding>
--- 190,194 ----
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</binding>
***************
*** 203,208 ****
</description>]]></eg>
! </example><ednote><name>dbooth</name><date>205-04-12</date><edtext>ToDo: Make opCheckAvailability use GET instead of POST,
! and set the safe="true" on it.</edtext></ednote><ednote><name>dbooth</name><date>2005-04-12</date><edtext>ToDo: Should we add line numbers to the examples, to make it clearer in the explanations when we refer to specific portions? I think this may be helpful. If so, we should: 1. Add them to the complete example above; 2. When showing excerpts, use the same line numbers from the complete example above (for consistency); 3. Explain that the line numbers are not a part of the XML or WSDL 2.0 document, but are merely shown in this primer for ease of reference.</edtext></ednote></div2><div2 id="basics-getting-started"><head>Getting Started: Defining a WSDL Target Namespace</head><p>Before writing our WSDL 2.0 document, we need to decide on a <emph>WSDL target namespace</emph> URI for it. The WSDL target namespace is analogous to an XML Schema target namespace: interface, binding and service names that we define in our WSDL document will be associated with the WSDL target namespace, and thus will be distingishable from similar names in a different WSDL target namespace. (This will become important if using WSDL 2.0's import or interface inheritance mechanisms.) </p><p>The value of the WSDL target namespace MUST be an absolute URI. Furthermore, it SHOULD be dereferenceable to a WSDL 2.0document that describes the Web service that the WSDL target namespace is used to describe. For example, the GreatH owners SHOULD make the WSDL document available from this URI. (And if a WSDL description is split into multiple documents, then the WSDL target namespace should resolve to a master document that includes all the WSDL documents needed for that service description.) However, there is no absolute requirement for this URI to be dereferenceable, so a WSDL processor must not depend on it being dereferenceable. </p><p>This recommendation may sound circular, but bear in mind that the client might have obtained the WSDL document from anywhere -- not necessarily an authoritative source. But by dereferencing the WSD target namespace URI, a user SHOULD be able to obtain an authoritative version. Since GreatH will be the owner of the service, the WSDL target namespace URI should refer to a location on the GreatH Web site or otherwise within its control.</p><p>Once we have decided on a WSDL target namespace URI, we can begin our WSDL 2.0 document as the following empty shell.</p><example id="example-empty-shell">
<head>An Initial Empty WSDL 2.0 Document</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
--- 204,213 ----
</description>]]></eg>
! </example>
!
!
! <ednote><name>dbooth</name><date>2005-04-12</date><edtext>ToDo: Should we add line numbers to the examples, to make it clearer in the explanations when we refer to specific portions? I think this may be helpful. If so, we should: 1. Add them to the complete example above; 2. When showing excerpts, use the same line numbers from the complete example above (for consistency); 3. Explain that the line numbers are not a part of the XML or WSDL 2.0 document, but are merely shown in this primer for ease of reference.</edtext></ednote>
!
! </div2><div2 id="basics-getting-started"><head>Getting Started: Defining a WSDL Target Namespace</head><p>Before writing our WSDL 2.0 document, we need to decide on a <emph>WSDL target namespace</emph> URI for it. The WSDL target namespace is analogous to an XML Schema target namespace: interface, binding and service names that we define in our WSDL document will be associated with the WSDL target namespace, and thus will be distinguishable from similar names in a different WSDL target namespace. (This will become important if using WSDL 2.0's import or interface inheritance mechanisms.) </p><p>The value of the WSDL target namespace MUST be an absolute URI. Furthermore, it SHOULD be dereferenceable to a WSDL 2.0document that describes the Web service that the WSDL target namespace is used to describe. For example, the GreatH owners SHOULD make the WSDL document available from this URI. (And if a WSDL description is split into multiple documents, then the WSDL target namespace should resolve to a mster document that includes all the WSDL documents needed for that service description.) However, there is no absolute requirement for this URI to be dereferenceable, so a WSDL processor must not depend on it being dereferenceable. </p><p>This recommendation may sound circular, but bear in mind that the client might have obtained the WSDL document from anywhere -- not necessarily an authoritative source. But by dereferencing the WSDL target namespace URI, a user SHOULD be able to obtain an authoritative version. Since GreatH will be the owner of the service, the WSDL target namespace URI should refer to a location on the GreatH Web site or otherwise within its control.</p><p>Once we have decided on a WSDL target namespace URI, we can begin our WSDL 2.0 document as the following empty shell.</p><example id="example-empty-shell">
<head>An Initial Empty WSDL 2.0 Document</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
***************
*** 285,290 ****
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
! save = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 290,296 ----
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
! style="http://www.w3.org/2004/08/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 298,302 ****
. . .
</description>]]></eg></example><div3 id="example-initial-interface-explanation"><head>Explanation of Example</head><glist><gitem><label><code><interface name = "reservationInterface" ></code></label><def><p>Interfaces are declared directly inside the <code>description</code> element. In this example, we are declaring only one interface, but in general a WSDL 2.0 document may declare more than one interface. Thus, each interface must be given a name that is unique within the set of interfaces defined in this WSDL target namespace. Interface names are tokens that must not contain a space or colon (":").</p></def></gitem><gitem><label><code><fault name = "invalidDataFault"
! </code></label><def><p>The <code>name</code> attribute defines a name for this fault. The name is required so that when an operation is defined, it can reference the desired fault by name. Fault names must be unique within an interface.</p></def></gitem><gitem><label><code>element = "ghns:invalidDataError"/></code></label><def><p>The <code>element</code> attribute specifies the schema type of the fault message, as previously defined in the <code>types</code> section. </p></def></gitem><gitem><label><code><operation name="opCheckAvailability"</code></label><def><p>The <code>name</code> attribute defines a name for this operation, so that it can be referenced later when bindings are defined. Operation names must also be unique within an interface. (WSDL 2.0 uses separate symbol spaces for operation and fault names, so operation name "foo" is distinct from fault name "foo".)</p></def></gitem><gitem><label><code>pattern="http://www.w3.org/2004/03/wsdl/in-out" </code></label><def><p>Thi line specifies that this operation will use the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref> pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. (However, just because someone defines a new pattern and creates a URI to identify it, that does <emph>not</emph> mean that other WSDL processors will automatically recognize or understand that pattern. As with any other extension, it can be used among processors that <i>do</i> recognize and understand it.)</p></def></gitem><gitem><label><code>safe="true" ></code></label><def><p>This line indicates that this operation will not obligate the client in any way, i.e., the client can safely invoke this operation without fear that it may be incurring an obligation (such as agreeing to buy something). This is further explained in <specref ref="mor-interfaces-operations"/>. </p></def></gitem><gitem><label><code><input messageLabel="In"</code></label><def><p>The <code>input</code> element specifies an input message. Even though we have already specified which message exchange pattern the operation will use, a message exchange pattern represents a template for a message sequence, and in theory could consist of multiple input and/or output messages. Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the <code>messageLabel</code> attribute. Since the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref> pattern that we've chosen to use only has one input message, it is trivial in this case: we simply fill in the message label "In" that was defined in <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.2.3 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">InOut</xspecref> for the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref> pattern. However, if a new pattern is defined that involve multiple input messages, then the different input messages in the pattern could then be distinguished by having different labels.</p></def></gitem><gitem><label><code>element="ghns:checkAvailability" /></code></label><def><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></def></gitem><gitem><label><code><output messageLabel="Out" . . .</code></label><def><p>This is similar to defining an input message.</p></def></gitem><gitem><label><code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></label><def><p>This associates an output fault with this operation. Faults are declared a little differently than normal messages. The <code>ref</code> attribute refers to the name of a previously defined fault in this interface -- not a message shema type directly. Since message exchange patterns could in general involve a sequence of several messages, a fault could potentially occur at various points within the message sequence. Because one may wish to associate a different fault with each permitted point in the sequence, the messageLabel is used to indicate the desired point for this particular fault. It does so indirectly by specifying the message that will either trigger this fault or that this fault will replace, depending on the pattern. (Some patterns use a <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">message-triggers-fault rule</xspecref>; others use a <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">fault-replaces-message</xspecref> rule. See <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.1.2 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">Message Triggers Fault</xspecref> and ection 2.1.1 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">Fault Replaces Message</xspecref>.) </p></def></gitem></glist><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div3></div2>
--- 304,316 ----
. . .
</description>]]></eg></example><div3 id="example-initial-interface-explanation"><head>Explanation of Example</head><glist><gitem><label><code><interface name = "reservationInterface" ></code></label><def><p>Interfaces are declared directly inside the <code>description</code> element. In this example, we are declaring only one interface, but in general a WSDL 2.0 document may declare more than one interface. Thus, each interface must be given a name that is unique within the set of interfaces defined in this WSDL target namespace. Interface names are tokens that must not contain a space or colon (":").</p></def></gitem><gitem><label><code><fault name = "invalidDataFault"
! </code></label><def><p>The <code>name</code> attribute defines a name for this fault. The name is required so that when an operation is defined, it can reference the desired fault by name. Fault names must be unique within an interface.</p></def></gitem><gitem><label><code>element = "ghns:invalidDataError"/></code></label><def><p>The <code>element</code> attribute specifies the schema type of the fault message, as previously defined in the <code>types</code> section. </p></def></gitem><gitem><label><code><operation name="opCheckAvailability"</code></label><def><p>The <code>name</code> attribute defines a name for this operation, so that it can be referenced later when bindings are defined. Operation names must also be unique within an interface. (WSDL 2.0 uses separate symbol spaces for operation and fault names, so operation name "foo" is distinct from fault name "foo".)</p></def></gitem>
!
! <gitem><label><code>pattern="http://www.w3.org/2004/03/wsdl/in-out" </code></label><def><p>This line specifies that this operation will use the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref> pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. (However, just because someone defines a new pattern and creates a URI to identify it, that does <emph>not</emph> mean that other WSDL processors will automatically recognize or understand that pattern. As with any other extension, it can be used among processors that <i>do</i> recognize and understand it.)</p></def></gitem>
!
! <gitem><label><code>style="http://www.w3.org/2004/08/wsdl/style/uri" </code></label><def><p>
! This line indicates that the XML schema defining the input message of this operation follows a set of rules as specified in <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#_operation_uri_style">URI Style</xspecref> that ensures the message can be serialized as an URI.
! </p></def></gitem>
!
! <gitem><label><code>safe="true" ></code></label><def><p>This line indicates that this operation will not obligate the client in any way, i.e., the client can safely invoke this operation without fear that it may be incurring an obligation (such as agreeing to buy something). This is further explained in <specref ref="more-interfaces-operations"/>. </p></def></gitem><gitem><label><code><input messageLabel="In"</code></label><def><p>The <code>input</code> element specifies an input message. Even though we have already specified which message exchange pattern the operation will use, a message exchange pattern represents a template for a message sequence, and in theory could consist of multiple input and/or output messages. Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the <code>messageLabel</code> attribute. Since the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#inout">in-out</xspecref> pattern that we've chosen to use only has one input message, it is trivial in this case: we simply fill in the message label "In" that was defined in <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.2.3 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">In-Out</xspecref> for the <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref> pattern. However, if a new pattern is defined that involve multiple input messages, then the different input messages in the pattern could then be distinguished by having different labels.</p></def></gitem><gitem><label><code>element="ghns:checkAvailability" /></code></label><def><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></def></gitem><gitem><label><code><output messageLabel="Out" . . .</code></label><def><p>This is similar to defining an input message.</p></def></gite><gitem><label><code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></label><def><p>This associates an output fault with this operation. Faults are declared a little differently than normal messages. The <code>ref</code> attribute refers to the name of a previously defined fault in this interface -- not a message schema type directly. Since message exchange patterns could in general involve a sequence of several messages, a fault could potentially occur at various points within the message sequence. Because one may wish to associate a different fault with each permitted point in the sequence, the messageLabel is used to indicate the desired point for this particular fault. It does so indirectly by specifying the message that will either trigger this fault or that this fault will replace, depending on the pattern. (Some patterns use a <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">message-triggers-fault rule</xspecref>; others use a <xspecef href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">fault-replaces-message</xspecref> rule. See <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.1.2 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">Message Triggers Fault</xspecref> and section 2.1.1 <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">Fault Replaces Message</xspecref>.) </p></def></gitem></glist><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div3></div2>
***************
*** 387,391 ****
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
<fault ref="tns:invalidDataFault"
--- 401,405 ----
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
<fault ref="tns:invalidDataFault"
***************
*** 411,415 ****
</xspecref>.)
</p>
! </def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. It specifies the SOAP message exchange pattern (MEP) that will be used to implement the abstract WSDL 2.0 message exchange pattern (<xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p><p>When HTTP is used as the underlying transport protocol (as in this example) the <code>wsoap:mep</code> attribute also controls whether GET or POST will be used as the underlying HTTP method. See also <specref ref="adv-get-vs-post"/>.</p></def></gitem><gitem><label><code><fault ref="tns:invalidDataFault"</code></label><def><p>As with a binding operation, this is not declaring a new fault; rather, it is referencing a fault (<code>invalidDataFault</code>) that was previously defined in the <ode>opCheckAvailability</code> interface, in order to specify binding details for it.</p></def></gitem><gitem><label><code>wsoap:code="soap:Sender"/></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. This specifies the SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list of subcodes can also be specified using the optional <att>wsoap:subcodes</att> attribute.</p></def></gitem></glist></div3></div2><div2 id="basics-service"><head>Defining a Service</head><p>Now that our binding has specified <emph>how</emph> messages will be transmitted, we are ready to specify <emph>where</emph> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <emph>service</emph> specifies a single interface that the service will support, and a list of <emph>endpoint</emph> locations where that service can be accessed. Each endpoint must also reference a previously defined binding to indicate what protocols an transmission formats are to be used at that endpoint. A service is only permitted to have one interface. (See <specref ref="adv-multiple-docs-describing-same-service"/> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service.</p><example id="example-initial-service">
<head>GreatH Service Definition</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
--- 425,430 ----
</xspecref>.)
</p>
! </def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. It specifies the SOAP message exchange pattern (MEP) that will be used to implement the abstract WSDL 2.0 message exchange pattern (<xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p>
! <p>When HTTP is used as the underlying transport protocol (as in this example) the <code>wsoap:mep</code> attribute also controls whether GET or POST will be used as the underlying HTTP method. In this case, the use of <code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"</code> causes GET to be used by default. See also <specref ref="adv-get-vs-post"/>.</p></def></gitem><gitem><label><code><fault ref="tns:invalidDataFault"</code></label><def><p>As with a binding operation, this is not declaring a new fault; rather, it is referencing a fault (<code>invalidDataFault</code>) that was previously defined in the <code>opCheckAvailability</code> interface, in order to specify binding details for it.</p></def></gitem><gitem><label><code>wsoap:code="soap:Sender"/></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. This specifies the SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list of subcodes can also be speified using the optional <att>wsoap:subcodes</att> attribute.</p></def></gitem></glist></div3></div2><div2 id="basics-service"><head>Defining a Service</head><p>Now that our binding has specified <emph>how</emph> messages will be transmitted, we are ready to specify <emph>where</emph> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <emph>service</emph> specifies a single interface that the service will support, and a list of <emph>endpoint</emph> locations where that service can be accessed. Each endpoint must also reference a previously defined binding to indicate what protocols and transmission formats are to be used at that endpoint. A service is only permitted to have one interface. (See <specref ref="adv-multiple-docs-describing-same-service"/> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service.</p><example id="example-initial-service">
<head>GreatH Service Definition</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.42
retrieving revision 1.43
diff -C2 -d -r1.42 -r1.43
*** wsdl20-primer.html 22 Apr 2005 06:51:33 -0000 1.42
--- wsdl20-primer.html 26 Apr 2005 23:19:42 -0000 1.43
***************
*** 94,98 ****
<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></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 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="#basics-nterface">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> 3. <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-embed">Embedding 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-op-att">Operation Attributes</a><br> 5.4.2 <a href="#N1089A">Operation Message References</a><br> 5.4.2.1 <a href="#N108B7">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N108CB">The element Attribute</a><br> 5.4.2.3 <a href="#N108F2">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br> 5.4.4 <a href="#more-interfaces-defining-meps">Defining New 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-bindins-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> 6.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="#N10B3A">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> &nsp; 7.1.2 <a href="#adv-scope-of-wsdl-required">Scoping of the wsdl:required Attribute</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-import-and-authoring">Import mechanism and authoring style</a><br> 7.4 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.5 <a href="#adv-versioning">Web Service Versioning</a><br> 7.5.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.5.2 <a href="#adv-vrsioning-big-bang">Big Bang</a><br> 7.5.3 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.6 <a href="#adv-MTOM">MTOM Support</a><br> 7.7 <a href="#adv-RPCstyle">RPC Style</a><br> 7.8 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.9 <a href="#adv-service-references">Service References</a><br> 7.9.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br> 7.9.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.9.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.9.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br>   7.10 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.10.1 <a href="#N11041">Schemas in Imported Documents</a><br> 7.10.2 <a href="#N110CC">Multiple Inline Schemas in One Document</a><br> 7.10.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 7.10.3.1 <a href="#N11129">Using the id Attribute to Identify Inline
Schemas</a><br> 7.11 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.11.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.12 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.12.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.12.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.12.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></div><hr><div class="body">
--- 94,99 ----
<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></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 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="#basics-nterface">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> 3. <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-embed">Embedding 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-op-att">Operation Attributes</a><br> 5.4.2 <a href="#N108AB">Operation Message References</a><br> 5.4.2.1 <a href="#N108C8">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N108DC">The element Attribute</a><br> 5.4.2.3 <a href="#N10903">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br> 5.4.4 <a href="#more-interfaces-defining-meps">Defining New 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-bindins-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> 6.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="#N10B4B">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.1.2 <a href="#adv-scope-of-wsdl-required">Scoping of the wsdl:required Attribute</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-import-and-authoring">Import mechanism and authoring stye</a><br> 7.4 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.5 <a href="#adv-versioning">Web Service Versioning</a><br> 7.5.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.5.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.5.3 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.6 <a href="#adv-MTOM">MTOM Support</a><br> 7.7 <a href="#adv-RPCstyle">RPC Style</a><br> 7.8 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.9 <a href="#adv-service-references">Service References</a><br> 7.9.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br>nbsp; 7.9.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.9.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.9.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.10 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.10.1 <a href="#N1104A">Schemas in Imported Documents</a><br> 7.10.2 <a href="#N110D5">Multiple Inline Schemas in One Document</a><br> 7.10.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 7.10.3.1 <a href="#N11132">Using the id Attribute to Identify Inline
Schemas</a><br> 7.11 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.11.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.12 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.12.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.12.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.12.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></div><hr><div class="body">
***************
*** 191,195 ****
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2004/03/wsdl/in-out"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 192,197 ----
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2004/03/wsdl/in-out"
! style="http://www.w3.org/2004/08/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 210,214 ****
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
</binding>
--- 212,216 ----
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</binding>
***************
*** 224,229 ****
</description></pre></div>
! </div><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">205-04-12</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Make opCheckAvailability use GET instead of POST,
! and set the safe="true" on it.</td></tr></table><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-12</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Should we add line numbers to the examples, to make it clearer in the explanations when we refer to specific portions? I think this may be helpful. If so, we should: 1. Add them to the complete example above; 2. When showing excerpts, use the same line numbers from the complete example above (for consistency); 3. Explain that the line numbers are not a part of the XML or WSDL 2.0 document, but are merely shown in this primer for ease of reference.</td></tr></table></div><div class="div2">
<h3><a name="basics-getting-started"></a>2.2 Getting Started: Defining a WSDL Target Namespace</h3><p>Before writing our WSDL 2.0 document, we need to decide on a <em>WSDL target namespace</em> URI for it. The WSDL target namespace is analogous to an XML Schema target namespace: interface, binding and service names that we define in our WSDL document will be associated with the WSDL target namespace, and thus will be distinguishable from similar names in a different WSDL target namespace. (This will become important if using WSDL 2.0's import or interface inheritance mechanisms.) </p><p>The value of the WSDL target namespace MUST be an absolute URI. Furthermore, it SHOULD be dereferenceable to a WSDL 2.0document that describes the Web service that the WSDL target namespace is used to describe. For example, the GreatH owners SHOULD make the WSDL document available from this URI. (And if a WSDL description is split into multiple documents, then the WSDL target namespace should resolve to a master doument that includes all the WSDL documents needed for that service description.) However, there is no absolute requirement for this URI to be dereferenceable, so a WSDL processor must not depend on it being dereferenceable. </p><p>This recommendation may sound circular, but bear in mind that the client might have obtained the WSDL document from anywhere -- not necessarily an authoritative source. But by dereferencing the WSDL target namespace URI, a user SHOULD be able to obtain an authoritative version. Since GreatH will be the owner of the service, the WSDL target namespace URI should refer to a location on the GreatH Web site or otherwise within its control.</p><p>Once we have decided on a WSDL target namespace URI, we can begin our WSDL 2.0 document as the following empty shell.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-empty-shell"></a><i><span>Example 2-2. </span>An Initial Empty WSDL 2.0 Document</i></p>
--- 226,235 ----
</description></pre></div>
! </div>
!
!
! <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-12</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Should we add line numbers to the examples, to make it clearer in the explanations when we refer to specific portions? I think this may be helpful. If so, we should: 1. Add them to the complete example above; 2. When showing excerpts, use the same line numbers from the complete example above (for consistency); 3. Explain that the line numbers are not a part of the XML or WSDL 2.0 document, but are merely shown in this primer for ease of reference.</td></tr></table>
!
! </div><div class="div2">
<h3><a name="basics-getting-started"></a>2.2 Getting Started: Defining a WSDL Target Namespace</h3><p>Before writing our WSDL 2.0 document, we need to decide on a <em>WSDL target namespace</em> URI for it. The WSDL target namespace is analogous to an XML Schema target namespace: interface, binding and service names that we define in our WSDL document will be associated with the WSDL target namespace, and thus will be distinguishable from similar names in a different WSDL target namespace. (This will become important if using WSDL 2.0's import or interface inheritance mechanisms.) </p><p>The value of the WSDL target namespace MUST be an absolute URI. Furthermore, it SHOULD be dereferenceable to a WSDL 2.0document that describes the Web service that the WSDL target namespace is used to describe. For example, the GreatH owners SHOULD make the WSDL document available from this URI. (And if a WSDL description is split into multiple documents, then the WSDL target namespace should resolve to a master doument that includes all the WSDL documents needed for that service description.) However, there is no absolute requirement for this URI to be dereferenceable, so a WSDL processor must not depend on it being dereferenceable. </p><p>This recommendation may sound circular, but bear in mind that the client might have obtained the WSDL document from anywhere -- not necessarily an authoritative source. But by dereferencing the WSDL target namespace URI, a user SHOULD be able to obtain an authoritative version. Since GreatH will be the owner of the service, the WSDL target namespace URI should refer to a location on the GreatH Web site or otherwise within its control.</p><p>Once we have decided on a WSDL target namespace URI, we can begin our WSDL 2.0 document as the following empty shell.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-empty-shell"></a><i><span>Example 2-2. </span>An Initial Empty WSDL 2.0 Document</i></p>
***************
*** 311,316 ****
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
! save = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 317,323 ----
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
! style="http://www.w3.org/2004/08/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 325,329 ****
</description></pre></div></div><div class="div3">
<h4><a name="example-initial-interface-explanation"></a>2.4.1 Explanation of Example</h4><dl><dt class="label"><code><interface name = "reservationInterface" ></code></dt><dd><p>Interfaces are declared directly inside the <code>description</code> element. In this example, we are declaring only one interface, but in general a WSDL 2.0 document may declare more than one interface. Thus, each interface must be given a name that is unique within the set of interfaces defined in this WSDL target namespace. Interface names are tokens that must not contain a space or colon (":").</p></dd><dt class="label"><code><fault name = "invalidDataFault"
! </code></dt><dd><p>The <code>name</code> attribute defines a name for this fault. The name is required so that when an operation is defined, it can reference the desired fault by name. Fault names must be unique within an interface.</p></dd><dt class="label"><code>element = "ghns:invalidDataError"/></code></dt><dd><p>The <code>element</code> attribute specifies the schema type of the fault message, as previously defined in the <code>types</code> section. </p></dd><dt class="label"><code><operation name="opCheckAvailability"</code></dt><dd><p>The <code>name</code> attribute defines a name for this operation, so that it can be referenced later when bindings are defined. Operation names must also be unique within an interface. (WSDL 2.0 uses separate symbol spaces for operation and fault names, so operation name "foo" is distinct from fault name "foo".)</p></dd><dt class="label"><code>pattern="http://www.w3.org/2004/03/wsdl/in-out" </code></dt><dd><p>This line specifies that this opertion will use the <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a> pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. (However, just because someone defines a new pattern and creates a URI to identify it, that does <em>not</em> mean that other WSDL processors will automatically recognize or understand that pattern. As with any other extension, it can be used among processors that <i>do</i> recognize and understand it.)</p></dd><dt class="label"><code>safe="true" ></code></dt><dd><p>This line indicates that this operation will not obligate the client in any way, i.e., the client can safely invoke this operation without fear that it may be incurring an obligation (such as agreeing to buy something). This is further explained in <a href="#more-interfaces-operations"><b>5.4 Interface Operations</b></a>. </p></dd><dt class="label"><code><input messageLabel="In"</code></dt><dd><p>The <code>input</code> element specifies an input message. Even though we have already specified which message exchange pattern the operation will use, a message exchange pattern represents a template for a message sequence, and in theory could consist of multiple input and/or output messages. Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the <code>messageLabel</code> attribute. Since the <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a> pattern that we've chosen to use only has one input message, it is trivial in this case: we simply fill in the message label "In" that was defined in <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 2.2.3 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">In-Out</a> for the <a href="http//www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a> pattern. However, if a new pattern is defined that involve multiple input messages, then the different input messages in the pattern could then be distinguished by having different labels.</p></dd><dt class="label"><code>element="ghns:checkAvailability" /></code></dt><dd><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></dd><dt class="label"><code><output messageLabel="Out" . . .</code></dt><dd><p>This is similar to defining an input message.</p></dd><dt class="label"><code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></dt><dd><p>This associates an output fault with this operation. Faults are declared a little differently than normal messages. The <code>ref</code> attribute refers to the name of a previously defined fault in this interface -- not a message schema type directly. Since message exchange patterns could in general involvea sequence of several messages, a fault could potentially occur at various points within the message sequence. Because one may wish to associate a different fault with each permitted point in the sequence, the messageLabel is used to indicate the desired point for this particular fault. It does so indirectly by specifying the message that will either trigger this fault or that this fault will replace, depending on the pattern. (Some patterns use a <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">message-triggers-fault rule</a>; others use a <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 2.1.2 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">Message Triggers Fault</a> and section 2.1.1 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacment">Fault Replaces Message</a>.) </p></dd></dl><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div></div>
--- 332,344 ----
</description></pre></div></div><div class="div3">
<h4><a name="example-initial-interface-explanation"></a>2.4.1 Explanation of Example</h4><dl><dt class="label"><code><interface name = "reservationInterface" ></code></dt><dd><p>Interfaces are declared directly inside the <code>description</code> element. In this example, we are declaring only one interface, but in general a WSDL 2.0 document may declare more than one interface. Thus, each interface must be given a name that is unique within the set of interfaces defined in this WSDL target namespace. Interface names are tokens that must not contain a space or colon (":").</p></dd><dt class="label"><code><fault name = "invalidDataFault"
! </code></dt><dd><p>The <code>name</code> attribute defines a name for this fault. The name is required so that when an operation is defined, it can reference the desired fault by name. Fault names must be unique within an interface.</p></dd><dt class="label"><code>element = "ghns:invalidDataError"/></code></dt><dd><p>The <code>element</code> attribute specifies the schema type of the fault message, as previously defined in the <code>types</code> section. </p></dd><dt class="label"><code><operation name="opCheckAvailability"</code></dt><dd><p>The <code>name</code> attribute defines a name for this operation, so that it can be referenced later when bindings are defined. Operation names must also be unique within an interface. (WSDL 2.0 uses separate symbol spaces for operation and fault names, so operation name "foo" is distinct from fault name "foo".)</p></dd>
!
! <dt class="label"><code>pattern="http://www.w3.org/2004/03/wsdl/in-out" </code></dt><dd><p>This line specifies that this operation will use the <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a> pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. (However, just because someone defines a new pattern and creates a URI to identify it, that does <em>not</em> mean that other WSDL processors will automatically recognize or understand that pattern. As with any other extension, it can be used among processors that <i>do</i> recognize and understand it.)</p></dd>
!
! <dt class="label"><code>style="http://www.w3.org/2004/08/wsdl/style/uri" </code></dt><dd><p>
! This line indicates that the XML schema defining the input message of this operation follows a set of rules as specified in <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#_operation_uri_style">URI Style</a> that ensures the message can be serialized as an URI.
! </p></dd>
!
! <dt class="label"><code>safe="true" ></code></dt><dd><p>This line indicates that this operation will not obligate the client in any way, i.e., the client can safely invoke this operation without fear that it may be incurring an obligation (such as agreeing to buy something). This is further explained in <a href="#more-interfaces-operations"><b>5.4 Interface Operations</b></a>. </p></dd><dt class="label"><code><input messageLabel="In"</code></dt><dd><p>The <code>input</code> element specifies an input message. Even though we have already specified which message exchange pattern the operation will use, a message exchange pattern represents a template for a message sequence, and in theory could consist of multiple input and/or output messages. Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the <code>messageLabel</code> attribute. Since the <a href="http://www.w3.org/TR/2004/WD-wsdl20-extension-20040803/#in-out">in-out</a> pattern that we've chosen to use only has one input message, it is trivial in this case: we simply fill in the message label "In" that was defined in <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 2.2.3 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">In-Out</a> for the <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a> pattern. However, if a new pattern is defined that involve multiple input messages, then the different input messages in the pattern could then be distinguished by having different labels.</p></dd><dt class="label"><code>element="ghns:checkAvailability" /></code></dt><dd><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></dd><dt class="label"><code><output messageLabel="Out" . . .</code></dt><dd><p>This is similar to defining an input message.</p></dd><dt class="label">code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></dt><dd><p>This associates an output fault with this operation. Faults are declared a little differently than normal messages. The <code>ref</code> attribute refers to the name of a previously defined fault in this interface -- not a message schema type directly. Since message exchange patterns could in general involve a sequence of several messages, a fault could potentially occur at various points within the message sequence. Because one may wish to associate a different fault with each permitted point in the sequence, the messageLabel is used to indicate the desired point for this particular fault. It does so indirectly by specifying the message that will either trigger this fault or that this fault will replace, depending on the pattern. (Some patterns use a <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">message-triggers-fault rule</a>; others use a <a href="http://www.w3.org/TR/2004/WD-wsl20-extensions-20040803/#fault-replacement">fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 2.1.2 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-trigger">Message Triggers Fault</a> and section 2.1.1 <a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#fault-replacement">Fault Replaces Message</a>.) </p></dd></dl><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div></div>
***************
*** 415,419 ****
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
<fault ref="tns:invalidDataFault"
--- 430,434 ----
<operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
<fault ref="tns:invalidDataFault"
***************
*** 440,444 ****
</a>.)
</p>
! </dd><dt class="label"><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"></code></dt><dd><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. It specifies the SOAP message exchange pattern (MEP) that will be used to implement the abstract WSDL 2.0 message exchange pattern (<a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p><p>When HTTP is used as the underlying transport protocol (as in this example) the <code>wsoap:mep</code> attribute also controls whether GET or POST will be used as the underlying HTTP method. See also <a href="#adv-get-vs-post"><b>6.7 HTTP GET Versus POST: Which to Use?</b></a>.</p></dd><dt class="label"><code><fault ref="tns:invalidDataFault"</code></dt><dd><p>As with a binding operation, this is not declaring a new fault; rather, it is referencing a fault (<code>invalidDataFault</code>) that was previously defned in the <code>opCheckAvailability</code> interface, in order to specify binding details for it.</p></dd><dt class="label"><code>wsoap:code="soap:Sender"/></code></dt><dd><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. This specifies the SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list of subcodes can also be specified using the optional <code>wsoap:subcodes</code> attribute.</p></dd></dl></div></div><div class="div2">
<h3><a name="basics-service"></a>2.6 Defining a Service</h3><p>Now that our binding has specified <em>how</em> messages will be transmitted, we are ready to specify <em>where</em> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <em>service</em> specifies a single interface that the service will support, and a list of <em>endpoint</em> locations where that service can be accessed. Each endpoint must also reference a previously defined binding to indicate what protocols and transmission formats are to be used at that endpoint. A service is only permitted to have one interface. (See <a href="#adv-multiple-docs-describing-same-service"><b>7.4 Multiple Interfaces for the Same Service</b></a> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-initial-service"></a><i><span>Example 2-6. </span>GreatH Service Definition</i></p>
--- 455,460 ----
</a>.)
</p>
! </dd><dt class="label"><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"></code></dt><dd><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. It specifies the SOAP message exchange pattern (MEP) that will be used to implement the abstract WSDL 2.0 message exchange pattern (<a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</a>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p>
! <p>When HTTP is used as the underlying transport protocol (as in this example) the <code>wsoap:mep</code> attribute also controls whether GET or POST will be used as the underlying HTTP method. In this case, the use of <code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"</code> causes GET to be used by default. See also <a href="#adv-get-vs-post"><b>6.7 HTTP GET Versus POST: Which to Use?</b></a>.</p></dd><dt class="label"><code><fault ref="tns:invalidDataFault"</code></dt><dd><p>As with a binding operation, this is not declaring a new fault; rather, it is referencing a fault (<code>invalidDataFault</code>) that was previously defined in the <code>opCheckAvailability</code> interface, in order to specify binding details for it.</p></dd><dt class="label"><code>wsoap:code="soap:Sender"/></code></dt><dd><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. This specifies the SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list f subcodes can also be specified using the optional <code>wsoap:subcodes</code> attribute.</p></dd></dl></div></div><div class="div2">
<h3><a name="basics-service"></a>2.6 Defining a Service</h3><p>Now that our binding has specified <em>how</em> messages will be transmitted, we are ready to specify <em>where</em> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <em>service</em> specifies a single interface that the service will support, and a list of <em>endpoint</em> locations where that service can be accessed. Each endpoint must also reference a previously defined binding to indicate what protocols and transmission formats are to be used at that endpoint. A service is only permitted to have one interface. (See <a href="#adv-multiple-docs-describing-same-service"><b>7.4 Multiple Interfaces for the Same Service</b></a> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service.</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example-initial-service"></a><i><span>Example 2-6. </span>GreatH Service Definition</i></p>
***************
*** 853,861 ****
</li>
</ul></div><div class="div3">
! <h4><a name="N1089A"></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="N108B7"></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="N108CB"></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 (a/k/a 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: ay 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="N108F2"></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>
--- 869,877 ----
</li>
</ul></div><div class="div3">
! <h4><a name="N108AB"></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="N108C8"></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="N108DC"></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 (a/k/a 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: ay 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="N10903"></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>
***************
*** 1111,1114 ****
--- 1127,1131 ----
<description xmlns="http://www.w3.org/2004/08/wsdl"
. . .
+ type="http://www.w3.org/@@@@/@@/wsdl/http"
xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" >
***************
*** 1119,1123 ****
<operation ref="tns:opCheckAvailability"
! whttp:location="{tCheckAvailability}" >
</binding>
--- 1136,1140 ----
<operation ref="tns:opCheckAvailability"
! whttp:location="{checkInDate}" />
</binding>
***************
*** 1135,1139 ****
</div>
<div class="div3">
! <h4><a name="N10B3A"></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>xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" ></code></dt><dd><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></dd><dt class="label"><code>whttp:methodDefault="GET"></code></dt><dd><p>The default method for operations in this interface will be HTTP GET.</p></dd><dt class="label"><code>whttp:lcation="{tCheckAvailability}" ></code></dt><dd><p>The <code>whttp:location</code> attribute specifies a pattern for serializing input message instance data into the path component of the request URI. The default binding rules for HTTP specify that the default input
serialization for GET is <code>application/x-www-form-urlencoded</code>. Curly braces are used to specify the name of a schema type in the input message schema, which determines what input instance data will be inserted into the path component of the request URI. The curly brace-enclosed name will be replaced with instance data in constructing the path component. Remaining input instance data (not specified by <code>whttp:location</code>) will either be serialized into the query string portion of the URI or into the message body, as follows: if a "/" is appended to a curly brace-enclosed type name, then any remaining input message instance data will be serialized into the message body. Otherwise it will be serialized into query parameters.</p><p>Thus, in this example, each of the elements in the <code>tCheckAvailability</code> type will be serialized into
the query parameters.
--- 1152,1165 ----
</div>
<div class="div3">
! <h4><a name="N10B4B"></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/@@@@/@@/wsdl/http"</code></dt>
! <dd>
! <p>
! This declares the binding as being an HTTP binding.
! </p>
! </dd>
!
! <dt class="label"><code>xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" ></code></dt><dd><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></dd><dt class="label"><code>whttp:methodDefault="GET"></code></dt><dd><p>The default method for operations in this interface will be HTTP GET.</p></dd><dt class="label"><code>whttp:location="{checkInDate}" ></code></dt><dd><p>The <code>whttp:location</code> attribute specifies a pattern for serializing input message instance data into the path component of the request URI. The default binding rules for HTTP specify that the default input
serialization for GET is <code>application/x-www-form-urlencoded</code>. Curly braces are used to specify the name of a schema type in the input message schema, which determines what input instance data will be inserted into the path component of the request URI. The curly brace-enclosed name will be replaced with instance data in constructing the path component. Remaining input instance data (not specified by <code>whttp:location</code>) will either be serialized into the query string portion of the URI or into the message body, as follows: if a "/" is appended to a curly brace-enclosed type name, then any remaining input message instance data will be serialized into the message body. Otherwise it will be serialized into query parameters.</p><p>Thus, in this example, each of the elements in the <code>tCheckAvailability</code> type will be serialized into
the query parameters.
***************
*** 1142,1146 ****
resulting URI for would therefore be
! <code>http://greath.example.com/2004/?checkInDate=5-5-5&checkOutDate=6-6-5&roomType=foo</code>
. </p></dd></dl><p></p><p>Here is an alternate example that serializes appends "/" to the type name in order to serialize the remaining instance data into the message body:</p><div class="exampleOuter">
--- 1168,1172 ----
resulting URI for would therefore be
! <code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>
. </p></dd></dl><p></p><p>Here is an alternate example that serializes appends "/" to the type name in order to serialize the remaining instance data into the message body:</p><div class="exampleOuter">
***************
*** 2207,2214 ****
<p class="exampleHead" style="text-align: left"><a name="reservationDetails_HTTP_example"></a><i><span>Example 7-19. </span>
Reservation Details Web Service Using HTTP Transfer</i></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-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check/fix this example. Shouldn't it specify what protocol to use?</td></tr></table><div class="exampleInner"><pre>
. . .
<binding name="reservationDetailsHTTPBinding"
! interface="tns:reservationDetailsInterface" >
<operation ref="tns:retrieve"
--- 2233,2241 ----
<p class="exampleHead" style="text-align: left"><a name="reservationDetails_HTTP_example"></a><i><span>Example 7-19. </span>
Reservation Details Web Service Using HTTP Transfer</i></p>
! <div class="exampleInner"><pre>
. . .
<binding name="reservationDetailsHTTPBinding"
! type="http://www.w3.org/2004/08/wsdl/http"
! interface="tns:reservationDetailsInterface" >
<operation ref="tns:retrieve"
***************
*** 2229,2235 ****
<p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET"></a><i><span>Example 7-20. </span>
Reservation List Web Service Using HTTP GET</i></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-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check/fix this example. Shouldn't it specify what protocol to use?</td></tr></table><div class="exampleInner"><pre>
. . .
<binding name="reservationListHTTPBinding"
interface="tns:reservationListInterface"
whttp:methodDefault="GET">
--- 2256,2263 ----
<p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET"></a><i><span>Example 7-20. </span>
Reservation List Web Service Using HTTP GET</i></p>
! <div class="exampleInner"><pre>
. . .
<binding name="reservationListHTTPBinding"
+ type="http://www.w3.org/2004/08/wsdl/http"
interface="tns:reservationListInterface"
whttp:methodDefault="GET">
***************
*** 2239,2249 ****
<operation ref="tns:retrieveByConfirmationNumber"
! whttp:location="/ConfirmationNumber/{confirmationNumber/}" />
<operation ref="tns:retrieveByCheckInDate"
! whttp:location="/CheckInDate/{checkInDate/}" />
<operation ref="tns:retrieveByCheckOutDate"
! whttp:location="/CheckOutDate/{checkOutDate/}" />
</binding>
. . .
--- 2267,2277 ----
<operation ref="tns:retrieveByConfirmationNumber"
! whttp:location="reservationList/ConfirmationNumber/{confirmationNumber/}" />
<operation ref="tns:retrieveByCheckInDate"
! whttp:location="reservationList/CheckInDate/{checkInDate/}" />
<operation ref="tns:retrieveByCheckOutDate"
! whttp:location="reservationList/CheckOutDate/{checkOutDate/}" />
</binding>
. . .
***************
*** 2284,2288 ****
</div><p>The WSDL service that offers this type serialized as a parameter would look like this:</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET_single_wsdl"></a><i><span>Example 7-22. </span>WSDL for Using a Single Query Type</i></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-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check/fix this example. Shouldn't it specify what protocol to use?</td></tr></table><div class="exampleInner"><pre>
. . .
<interface name="reservationListInterfaceWithQuery">
--- 2312,2316 ----
</div><p>The WSDL service that offers this type serialized as a parameter would look like this:</p><div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET_single_wsdl"></a><i><span>Example 7-22. </span>WSDL for Using a Single Query Type</i></p>
! <div class="exampleInner"><pre>
. . .
<interface name="reservationListInterfaceWithQuery">
***************
*** 2299,2307 ****
<binding name="reservationListQueryHTTPBinding"
interface="tns:reservationListInterfaceWithQuery"
whttp:methodDefault="GET">
<operation ref="tns:retrieveByReservationQuery"
! whttp:location="/{ReservationQuery}}" />
</binding>
--- 2327,2336 ----
<binding name="reservationListQueryHTTPBinding"
+ type="http://www.w3.org/2004/08/wsdl/http"
interface="tns:reservationListInterfaceWithQuery"
whttp:methodDefault="GET">
<operation ref="tns:retrieveByReservationQuery"
! whttp:location="reservationList/{ReservationQuery}}" />
</binding>
***************
*** 2351,2355 ****
<div class="div3">
! <h4><a name="N11041"></a>7.10.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
--- 2380,2384 ----
<div class="div3">
! <h4><a name="N1104A"></a>7.10.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
***************
*** 2558,2562 ****
<div class="div3">
! <h4><a name="N110CC"></a>7.10.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
--- 2587,2591 ----
<div class="div3">
! <h4><a name="N110D5"></a>7.10.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
***************
*** 2692,2696 ****
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer can also be used.
</p><div class="div4">
! <h5><a name="N11129"></a>7.10.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-26</a>
--- 2721,2725 ----
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer can also be used.
</p><div class="div4">
! <h5><a name="N11132"></a>7.10.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-26</a>
Received on Tuesday, 26 April 2005 23:19:56 UTC