- From: Hugo Haas via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 03 May 2005 11:56:54 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory homer:/tmp/cvs-serv15173
Modified Files:
wsdl20-primer.xml
Log Message:
Updated namespace URIs
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.78
retrieving revision 1.79
diff -C2 -d -r1.78 -r1.79
*** wsdl20-primer.xml 1 May 2005 22:39:04 -0000 1.78
--- wsdl20-primer.xml 3 May 2005 11:56:52 -0000 1.79
***************
*** 171,175 ****
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
--- 171,175 ----
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
***************
*** 282,286 ****
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
--- 282,286 ----
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
***************
*** 298,302 ****
</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/2005/05/wsdl/style/uri" </code></label><def><p>
--- 298,302 ----
</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/2005/05/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/2005/05/wsdl/style/uri" </code></label><def><p>
***************
*** 741,745 ****
<operation name="opLogMessage"
! pattern="http://www.w3.org/2004/03/wsdl/out">
<output messageLabel="out"
element="ghns:messageLog" />
--- 741,745 ----
<operation name="opLogMessage"
! pattern="http://www.w3.org/2005/05/wsdl/out">
<output messageLabel="out"
element="ghns:messageLog" />
***************
*** 751,755 ****
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2004/03/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
--- 751,755 ----
<operation name="opCheckAvailability"
! pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
safe = "true">
***************
*** 810,816 ****
<p>An optional <att>style</att> attribute whose value is a list of absolute URIs. Each URI identifies a certain set of rules that were followed in defining this <code>operation</code>. It is an error if a particular style is indicated, but the associated rules are not followed. <bibref ref="WSDL-PART2"/> defines a set of styles, including</p>
<ulist>
! <item><p>RPC Style.The RPC style is selected when the <att>style</att> is assigned the value http://www.w3.org/@@@@/@@/wsdl/style/rpc. It places restrictions for Remote Procedure Call-types of interactions. </p></item>
! <item><p>URI Style. The URI style is selected when the <att>style</att> is assigned the value http://www.w3.org/@@@@/@@/wsdl/style/uri. It places restrictions on message definitions so they may be serialized into something like HTTP URL encoded.</p></item>
! <item><p>The Multipart style. The Multipart style is selected when the <att>style</att> is assigned the value http://www.w3.org/@@@@/@@/wsdl/style/multipart. In http binding, for Xform clients, an message must be defined following the Multipart style and serialized as "Multipart/form-data". </p> </item>
</ulist>
--- 810,816 ----
<p>An optional <att>style</att> attribute whose value is a list of absolute URIs. Each URI identifies a certain set of rules that were followed in defining this <code>operation</code>. It is an error if a particular style is indicated, but the associated rules are not followed. <bibref ref="WSDL-PART2"/> defines a set of styles, including</p>
<ulist>
! <item><p>RPC Style.The RPC style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/rpc. It places restrictions for Remote Procedure Call-types of interactions. </p></item>
! <item><p>URI Style. The URI style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/uri. It places restrictions on message definitions so they may be serialized into something like HTTP URL encoded.</p></item>
! <item><p>The Multipart style. The Multipart style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/multipart. In http binding, for Xform clients, an message must be defined following the Multipart style and serialized as "Multipart/form-data". </p> </item>
</ulist>
***************
*** 834,838 ****
other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
<p>A total of 8 MEPs are defined in <bibref ref="WSDL-PART2"/>. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <specref ref="more-interfaces-defining-meps"/> )</p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault maybe generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and MUST be delivered to the originator of the message. If there is no path to this node, the fault MUST be discarded. For details about the common fault generation models used by the 8 WSDL 2.0 MEPs, see <bibref ref="WSDL-PART2"/>. </p>
<p>Depends on how the first message in the MEP is initiated, the 8 WSDL MEPs may be grouped into two groups: in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. (Such Grouping is only for the purpose of easy reference in this primer).</p>
--- 834,838 ----
other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
<p>A total of 8 MEPs are defined in <bibref ref="WSDL-PART2"/>. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <specref ref="more-interfaces-defining-meps"/> )</p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/2005/05/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault maybe generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/2005/05/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and MUST be delivered to the originator of the message. If there is no path to this node, the fault MUST be discarded. For details about the common fault generation models used by the 8 WSDL 2.0 MEPs, see <bibref ref="WSDL-PART2"/>. </p>
<p>Depends on how the first message in the MEP is initiated, the 8 WSDL MEPs may be grouped into two groups: in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. (Such Grouping is only for the purpose of easy reference in this primer).</p>
***************
*** 851,855 ****
<operation name="opLogInquiry"
! <b>pattern="http://www.w3.org/@@@@/@@/wsdl/out"</b>>
<<b>output messageLabel="Out" element="ghns:customerData"</b> />
</operation>
--- 851,855 ----
<operation name="opLogInquiry"
! <b>pattern="http://www.w3.org/2005/05/wsdl/out"</b>>
<<b>output messageLabel="Out" element="ghns:customerData"</b> />
</operation>
***************
*** 948,956 ****
<?xml version="1.0" encoding="utf-8" ?>
<description
! xmlns="http://www.w3.org/@@@@/@@/wsdl"
targetNamespace="http://greath.example.com/@@@@/wsdl/resSvc.wsdl"
xmlns:tns="http://greath.example.com/@@@@/wsdl/resSvc.wsdl"
xmlns:ghns="http://greath.example.com/@@@@/schemas/resSvc.xsd"
! xmlns:wsoap="http://www.w3.org/@@@@/@@/wsdl/soap"
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
--- 948,956 ----
<?xml version="1.0" encoding="utf-8" ?>
<description
! xmlns="http://www.w3.org/2005/05/wsdl"
targetNamespace="http://greath.example.com/@@@@/wsdl/resSvc.wsdl"
xmlns:tns="http://greath.example.com/@@@@/wsdl/resSvc.wsdl"
xmlns:ghns="http://greath.example.com/@@@@/schemas/resSvc.xsd"
! xmlns:wsoap="http://www.w3.org/2005/05/wsdl/soap"
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
***************
*** 961,965 ****
<binding name="reservationSOAPBinding"
interface="tns:reservationInterface"
! type="http://www.w3.org/@@@@/@@/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
--- 961,965 ----
<binding name="reservationSOAPBinding"
interface="tns:reservationInterface"
! type="http://www.w3.org/2005/05/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
***************
*** 975,981 ****
<binding name="reservationSOAP11Binding"
interface="tns:reservationInterface"
! type="http://www.w3.org/@@@@/@@/wsdl/soap"
wsoap:version="1.1"
! wsoap:protocol="http://www.w3.org/@@@@/@@/soap11/bindings/HTTP">
<operation ref="tns:opCheckAvailability"/>
--- 975,981 ----
<binding name="reservationSOAP11Binding"
interface="tns:reservationInterface"
! type="http://www.w3.org/2005/05/wsdl/soap"
wsoap:version="1.1"
! wsoap:protocol="http://www.w3.org/2005/05/soap11/bindings/HTTP">
<operation ref="tns:opCheckAvailability"/>
***************
*** 1008,1012 ****
! <div3 id="more-bindings-soap-example-explanation"><head>Explanation of Example</head><p>Most of this example is the same as previously explained in <specref ref="basics-binding"/>, so we'll only point out lines that are demonstrating something new.<glist><gitem><label><code>xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"></code></label><def><p>This is the namespace for terms defined within the SOAP 1.1 specification <bibref ref="SOAP11"/>.</p></def></gitem><gitem><label><code>wsoap:version="1.1"</code></label><def><p>This line indicates that this binding uses SOAP 1.1, rather than SOAP 1.2.</p></def></gitem><gitem><label><code>wsoap:protocol="http://www.w3.org/@@@@/@@/soap11/bindings/HTTP"></code></label><def><p>This line specifies that HTTP should be used as the underlying transmission protocol. See also <specref ref="adv-get-vs-post"/>.</p></def></gitem><gitem><label><code>wsoap:code="soap11:Client"/></code></label><def><p>This line specifies the SOAP 1.1 fault code that will be ued in transmitting invalidDataFault.</p></def></gitem></glist></p>
</div3></div2>
--- 1008,1012 ----
! <div3 id="more-bindings-soap-example-explanation"><head>Explanation of Example</head><p>Most of this example is the same as previously explained in <specref ref="basics-binding"/>, so we'll only point out lines that are demonstrating something new.<glist><gitem><label><code>xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"></code></label><def><p>This is the namespace for terms defined within the SOAP 1.1 specification <bibref ref="SOAP11"/>.</p></def></gitem><gitem><label><code>wsoap:version="1.1"</code></label><def><p>This line indicates that this binding uses SOAP 1.1, rather than SOAP 1.2.</p></def></gitem><gitem><label><code>wsoap:protocol="http://www.w3.org/2005/05/soap11/bindings/HTTP"></code></label><def><p>This line specifies that HTTP should be used as the underlying transmission protocol. See also <specref ref="adv-get-vs-post"/>.</p></def></gitem><gitem><label><code>wsoap:code="soap11:Client"/></code></label><def><p>This line specifies the SOAP 1.1 fault code that will be ued in transmitting invalidDataFault.</p></def></gitem></glist></p>
</div3></div2>
***************
*** 1020,1025 ****
<description xmlns="http://www.w3.org/2005/05/wsdl"
. . .
! type="http://www.w3.org/@@@@/@@/wsdl/http"
! xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" >
. . .
--- 1020,1025 ----
<description xmlns="http://www.w3.org/2005/05/wsdl"
. . .
! type="http://www.w3.org/2005/05/wsdl/http"
! xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" >
. . .
***************
*** 1046,1050 ****
<div3><head>Explanation of
Example</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>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?</edtext></ednote><p><glist><gitem>
! <label><code>type="http://www.w3.org/@@@@/@@/wsdl/http"</code></label>
<def>
<p>
--- 1046,1050 ----
<div3><head>Explanation of
Example</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>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?</edtext></ednote><p><glist><gitem>
! <label><code>type="http://www.w3.org/2005/05/wsdl/http"</code></label>
<def>
<p>
***************
*** 1053,1057 ****
</def>
</gitem><gitem>
! <label><code>xmlns:whttp="http://www.w3.org/@@@@/@@/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem><gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{checkInDate}" ></code></label><def><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. A sample resulting URI for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></def></gitem></glist></p>
--- 1053,1057 ----
</def>
</gitem><gitem>
! <label><code>xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem><gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{checkInDate}" ></code></label><def><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. A sample resulting URI for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></def></gitem></glist></p>
***************
*** 1274,1278 ****
. . .
<operation name="makeReservation"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="ghns:makeReservation" />
--- 1274,1278 ----
. . .
<operation name="makeReservation"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="ghns:makeReservation" />
***************
*** 1449,1453 ****
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
! xmlns:xmime='http://www.w3.org/@@@@/@@/xmlmime'>
<soap:Body>
--- 1449,1453 ----
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
! xmlns:xmime='http://www.w3.org/2005/05/xmlmime'>
<soap:Body>
***************
*** 1551,1556 ****
<operation name="checkAvailability"
! pattern="http://www.w3.org/@@@@/@@/wsdl/in-out"
! style="http://www.w3.org/@@@@/@@/wsdl/style/rpc"
wrpc:signature=
"checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return">
--- 1551,1556 ----
<operation name="checkAvailability"
! pattern="http://www.w3.org/2005/05/wsdl/in-out"
! style="http://www.w3.org/2005/05/wsdl/style/rpc"
wrpc:signature=
"checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return">
***************
*** 1708,1712 ****
<operation name="retrieve"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
--- 1708,1712 ----
<operation name="retrieve"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
***************
*** 1715,1719 ****
<operation name="update"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In"
element="wdetails:reservationDetails" />
--- 1715,1719 ----
<operation name="update"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In"
element="wdetails:reservationDetails" />
***************
*** 2037,2041 ****
<operation name="retrieve"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out" element="list:reservationList" />
--- 2037,2041 ----
<operation name="retrieve"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out" element="list:reservationList" />
***************
*** 2043,2047 ****
<operation name="retrieveByConfirmationNumber"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In"
element="details:confirmationNumber" />
--- 2043,2047 ----
<operation name="retrieveByConfirmationNumber"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In"
element="details:confirmationNumber" />
***************
*** 2050,2054 ****
<operation name="retrieveByCheckInDate"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="details:checkInDate" />
<output messageLabel="Out" element="list:reservationList" />
--- 2050,2054 ----
<operation name="retrieveByCheckInDate"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="details:checkInDate" />
<output messageLabel="Out" element="list:reservationList" />
***************
*** 2056,2060 ****
<operation name="retrieveByCheckOutDate"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="details:checkOutDate" />
<output messageLabel="Out" element="list:reservationList" />
--- 2056,2060 ----
<operation name="retrieveByCheckOutDate"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="details:checkOutDate" />
<output messageLabel="Out" element="list:reservationList" />
***************
*** 2302,2306 ****
<operation name="retrieveByReservationQuery"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In"
element="details:ReservationQuery" />
--- 2302,2306 ----
<operation name="retrieveByReservationQuery"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In"
element="details:ReservationQuery" />
***************
*** 2429,2433 ****
<operation name="retrieve"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
--- 2429,2433 ----
<operation name="retrieve"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
***************
*** 2544,2548 ****
<operation name="update"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In"
element="details:reservationDetails" />
--- 2544,2548 ----
<operation name="update"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In"
element="details:reservationDetails" />
***************
*** 2666,2670 ****
<operation name="retrieve"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
--- 2666,2670 ----
<operation name="retrieve"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
***************
*** 2760,2764 ****
<operation name="retrieve"
! pattern="http://www.w3.org/2004/03/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
--- 2760,2764 ----
<operation name="retrieve"
! pattern="http://www.w3.org/2005/05/wsdl/in-out">
<input messageLabel="In" element="#none" />
<output messageLabel="Out"
Received on Tuesday, 3 May 2005 11:57:11 UTC