- From: Kevin Liu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 17 Mar 2005 01:52:38 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv23353/ws/desc/wsdl20
Modified Files:
wsdl20-primer.html wsdl20-primer.xml
Log Message:
incorporated contributions from Asir (soap 11 and 12 bindings), Arthur (binding faults), and Jonathan (MTOM support)
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -d -r1.36 -r1.37
*** wsdl20-primer.xml 11 Mar 2005 19:12:44 -0000 1.36
--- wsdl20-primer.xml 17 Mar 2005 01:52:35 -0000 1.37
***************
*** 1052,1055 ****
--- 1052,1079 ----
<div4 id="more-bindings-faults">
<head>Binding Faults</head>
+
+
+ <ednote>
+ <name>KevinL</name>
+ <date>20050310</date>
+ <edtext>Incoporated contribution from Arthur. Need to check back this section for integration with rest of document.
+ </edtext>
+ </ednote>
+
+ <p>Faults are very similar to messages and can be viewed as a special kind of
+ message. Both faults and messages may carry a payload that is normally described
+ by an element declaration. However, WSDL treats faults and messages slighly
+ differently. The messages of an operation directly refer to their element
+ declaration, however the faults of an operation indirectly refer to their
+ element declaration via a fault element that is defined on the interface. </p>
+
+ <p>The reason for defining faults at
+ the interface level is to allow their reuse accross multiple operations. This
+ design is especially beneficial when bindings are defined since in bindings like
+ SOAP there is additional information that is associated with faults. In the case
+ of SOAP, faults have codes and subcodes in addition to a payload. By defining
+ faults at the interface level, common codes and subcodes can be associated with
+ them, thereby ensuring consistency accross all operations that use the faults </p>
+
<p>A binding <code>fault</code> describes a concrete binding of an abstract fault
within an interface to a particular concrete message format. More precisely, it describes how faults that occur within a message exchange of an operation will be formatted since the fault does not occur by itself - it occurs as part of a message
***************
*** 1079,1097 ****
</div4>
</div3>
<div3 id="more-bindings-soap">
<head>Extensions for SOAP Binding</head>
<example id="example-binding-soap">
! <head>SOAP binding example placeholder - to be completed</head>
! <eg xml:space="preserve">
! <description
! targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
! xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! xmlns = "http://www.w3.org/2004/08/wsdl"
! xmlns:xs="http://www.w3.org/2001/XMLSchema">
! </description>
! </eg>
</example>
</div3>
<div3 id="more-bindings-http">
--- 1103,1207 ----
</div4>
</div3>
+
+
<div3 id="more-bindings-soap">
<head>Extensions for SOAP Binding</head>
+
+
+ <ednote>
+ <name>KevinL</name>
+ <date>20050310</date>
+ <edtext>Incoporated contribution from Asir. Need to check back this section for integration with rest of document.
+ </edtext>
+ </ednote>
+
<example id="example-binding-soap">
! <head>SOAP 1.1 and SOAP 1.2 bindings for the reservation interface</head>
! <eg><![CDATA[
! <?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/">
! ....
!
! <!-- SOAP 1.2 Binding -->
! <binding name="reservationSOAPBinding"
! interface="tns:reservationInterface"
! type="http://www.w3.org/@@@@/@@/wsdl/soap"
! wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
!
! <operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
!
! <fault ref="tns:invalidDataFault"
! wsoap:code="soap:Sender"/>
!
! </binding>
!
! <!-- SOAP 1.1 Binding -->
! <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"/>
!
! <fault ref="tns:invalidDataFault"
! wsoap:code="soap11:Client"/>
!
! </binding>
!
!
! <service name="reservationService"
! interface="tns:reservationInterface">
!
! <!-- SOAP 1.2 End Point -->
! <endpoint name="reservationEndpoint"
! binding="tns:reservationSOAPBinding"
! address="http://greath.example.com/2004/reservation"/>
!
! <!-- SOAP 1.1 End Point -->
! <endpoint name="reservationEndpoint2"
! binding="tns:reservationSOAP11Binding"
! address="http://greath.example.com/2004/reservation"/>
!
! </service>
! </description>
!
! ]]></eg>
</example>
+
+
+
+ <p>In this example, I like to highlight the following two constructs (using
+ xpath):</p>
+
+ <ulist>
+ <item> /description/binding[@name="reservationSOAP11Binding"]</item>
+ <item> /description/service/endpoint[@name="reservationEndpoint2"]</item>
+ </ulist>
+
+ <p>In the above example WSDL, reservation service has two endpoints. Of them,
+ one supports SOAP 1.1 message protocol, reservationEndpoint2. This endpoint
+ offers reservationInterface via reservationSOAP11Binding, a SOAP 1.1
+ binding.</p>
+
+ <p>reservationSOAP11Binding uses the version independent SOAP binding
+ extensions, specifies the version of SOAP by assigning 1.1 to wsoap:version
+ attribute and indicates SOAP 1.1 HTTP Binding by assigning
+ http://www.w3.org/@@@@/@@/soap11/bindings/HTTP to wsoap:protocol attribute.
+ This binding also specifies the SOAP 1.1 fault code for transmitting
+ invalidDataFault, an Interface Fault Compontent, by assigning soap11:Client
+ to wsoap:code attribute.
+ </p>
+
</div3>
<div3 id="more-bindings-http">
***************
*** 1172,1176 ****
--- 1282,1426 ----
<div2 id="adv-MTOM"><head>MTOM Support</head>
+
+ <ednote>
+ <name>KevinL</name>
+ <date>20050310</date>
+ <edtext>Incoporated contribution from Jonathan. Need to check back this section for integration with rest of document.
+ </edtext>
+ </ednote>
+ <!-- =============== -->
+ <p>This section shows how the <bibref ref="xxx"/> SOAP Message Transmission Optimization Mechanism may be engaged in the WSDL 2.0 SOAP binding.</p>
+
+ <p>Let’s modify the CheckAvailability operation of the GreatH Hotel Reservation Service [ref] to return not only the room rate, but images of the room and the floorplan. We’ll modify the checkAvailabilityResponse data structure to include binary data representing these two images, indicated by xs:base64Binary data type:</p>
+
+ <example id="example-MTOM-schema">
+ <head>An example XML Schema that contains optimizable elements </head>
+
+ <eg><![CDATA[
+
+ <xs:element name="checkAvailabilityResponse">
+
+ <xs:sequence>
+
+ <xs:element name="rate" type="xs:double"/>
+
+ <xs:element name="photo" type = "xmime:base64Binary" xmime:expectedContentType="image/jpeg image/png" />
+
+ <xs:element name="floorplan" xmime:expectedContentType="image/svg">
+
+ <xs:simpleContent>
+
+ <xs:restriction base="xs:base64Binary">
+
+ <xs:attribute ref="xmime:contentType" fixed="image/svg" />
+
+ </xs:restriction>
+
+ </xs:simpleContent>
+
+ </xs:element>
+
+ </xs:sequence>
+
+ </xs:element>
+
+ ]]></eg></example>
+
+ <p>Note the use of the xmime:expectedContentType and xmime:contentType attributes to declare the expected media type of the encoded data and to allow the client to indicate the type at runtime, respectively. These attributes are defined in Describing Media Content of Binary Data in XML [ref].</p>
+
+ <p>A Response message conforming to this schema might look like this:</p>
+
+ <example id="example-MTOM-soap-message">
+ <head>An example of non-optimized soap message that contains embedded binary data </head>
+
+ <eg><![CDATA[
+
+ <soap:Envelope
+
+ xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
+
+ xmlns:xmime='http://www.w3.org/@@@@/@@/xmlmime'>
+
+ <soap:Body>
+
+ <g:checkAvailabilityResponse
+
+ xmlns:g="http://greath.example.com/2004/schemas/resSvc">
+
+ <g:rate>129.95</g:rate>
+
+ <g:photo xmime:contentType='image/png'>/aWKKapGGyQ=</g:photo>
+
+ <g:floorplan xmime:contentType="image/svg">Faa7vROi2VQ=</g:floorplan>
+
+ </g:checkAvailabilityResponse>
+
+ </soap:Body>
+
+ </soap:Envelope>
+
+ ]]></eg></example>
+
+ <p>While this (non-optimized) message satisfies the schema definition, a service may choose to allow or require that the binary data be sent in an optimized format using the Message Transmission and Optimization feature. The use of this feature by the SOAP binding is indicated as follows:</p>
+
+
+ <example id="example-MTOM-soap-binding">
+ <head>Indicating the use of MTOM in wsdl binding</head>
+
+ <eg><![CDATA[
+
+ <binding name="reservationSOAPBinding"
+
+ interface="tns:reservationInterface"
+
+ type="http://www.w3.org/2004/08/wsdl/soap12"
+
+ wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
+
+
+
+ <operation ref="tns:opCheckAvailability"
+
+ wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response">
+
+
+
+ <input name="checkAvailability" />
+
+ <output name="checkAvailabilityRespone">
+
+ <feature uri="http://www.w3.org/2003/06/soap/features/http-optimization"
+
+ required="true"/>
+
+ </output>
+
+
+
+ </operation>
+
+ ...
+
+
+
+ </binding>
+ ]]></eg></example>
+
+
+ <p>The HTTP Message Transmission Optimization feature is engaged using the <code>feature</code> element. Note that the attribute required=”true” on the feature declaration indicates that the message must be encoded using the HTTP Optimization feature. If the attribute were required=”false” (or this attribute were absent), it would indicate that the service accepts either MTOM-encoded messages, or the embedded base64Binary data directly in the Body, and the client is free to send either form of message. </p>
+
+
+ <p>The example above shows MTOM enabled for a specific message within an operation. Placing the feature declaration as a child of <code>operation</code> would require (or enable if required=”false”) MTOM support for all the messages in that operation. Placing the feature declaration as a child of <code>binding</code> would require (or enable if required=”false”) MTOM support for all the operations in that interface.
+ </p>
+
+
+
+ <!-- =============== -->
+
+
+
<p>This section shows how Features and Properties can be used to indicate the use of MTOM. @@ Example from GlenD: http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0076.html @@</p>
+
+
</div2>
<div2 id="adv-security">
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** wsdl20-primer.html 14 Mar 2005 22:40:16 -0000 1.20
--- wsdl20-primer.html 17 Mar 2005 01:52:35 -0000 1.21
***************
*** 1075,1078 ****
--- 1075,1098 ----
<h5><a name="more-bindings-faults"></a>4.3.1.1 Binding Faults</h5>
+
+
+ <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050310</td></tr><tr><td valign="top" align="left" colspan="2">Incoporated contribution from Arthur. Need to check back this section for integration with rest of document.
+ </td></tr></table>
+
+ <p>Faults are very similar to messages and can be viewed as a special kind of
+ message. Both faults and messages may carry a payload that is normally described
+ by an element declaration. However, WSDL treats faults and messages slighly
+ differently. The messages of an operation directly refer to their element
+ declaration, however the faults of an operation indirectly refer to their
+ element declaration via a fault element that is defined on the interface. </p>
+
+ <p>The reason for defining faults at
+ the interface level is to allow their reuse accross multiple operations. This
+ design is especially beneficial when bindings are defined since in bindings like
+ SOAP there is additional information that is associated with faults. In the case
+ of SOAP, faults have codes and subcodes in addition to a payload. By defining
+ faults at the interface level, common codes and subcodes can be associated with
+ them, thereby ensuring consistency accross all operations that use the faults </p>
+
<p>A binding <code>fault</code> describes a concrete binding of an abstract fault
within an interface to a particular concrete message format. More precisely, it describes how faults that occur within a message exchange of an operation will be formatted since the fault does not occur by itself - it occurs as part of a message
***************
*** 1099,1118 ****
</div>
</div>
<div class="div3">
<h4><a name="more-bindings-soap"></a>4.3.2 Extensions for SOAP Binding</h4>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-binding-soap"></a><i><span>Example 4-4. </span>SOAP binding example placeholder - to be completed</i></p>
! <div class="exampleInner"><pre>
<description
! targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
! xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! xmlns = "http://www.w3.org/2004/08/wsdl"
! xmlns:xs="http://www.w3.org/2001/XMLSchema">
</description>
</pre></div>
</div>
</div>
<div class="div3">
--- 1119,1220 ----
</div>
</div>
+
+
<div class="div3">
<h4><a name="more-bindings-soap"></a>4.3.2 Extensions for SOAP Binding</h4>
+
+
+ <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050310</td></tr><tr><td valign="top" align="left" colspan="2">Incoporated contribution from Asir. Need to check back this section for integration with rest of document.
+ </td></tr></table>
+
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-binding-soap"></a><i><span>Example 4-4. </span>SOAP 1.1 and SOAP 1.2 bindings for the reservation interface</i></p>
+ <div class="exampleInner"><pre>
+ <?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/">
!
! ....
!
! <!-- SOAP 1.2 Binding -->
! <binding name="reservationSOAPBinding"
! interface="tns:reservationInterface"
! type="http://www.w3.org/@@@@/@@/wsdl/soap"
! wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
!
! <operation ref="tns:opCheckAvailability"
! wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
!
! <fault ref="tns:invalidDataFault"
! wsoap:code="soap:Sender"/>
!
! </binding>
!
! <!-- SOAP 1.1 Binding -->
! <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"/>
!
! <fault ref="tns:invalidDataFault"
! wsoap:code="soap11:Client"/>
+ </binding>
+
+
+ <service name="reservationService"
+ interface="tns:reservationInterface">
+
+ <!-- SOAP 1.2 End Point -->
+ <endpoint name="reservationEndpoint"
+ binding="tns:reservationSOAPBinding"
+ address="http://greath.example.com/2004/reservation"/>
+
+ <!-- SOAP 1.1 End Point -->
+ <endpoint name="reservationEndpoint2"
+ binding="tns:reservationSOAP11Binding"
+ address="http://greath.example.com/2004/reservation"/>
+
+ </service>
</description>
+
</pre></div>
</div>
+
+
+
+ <p>In this example, I like to highlight the following two constructs (using
+ xpath):</p>
+
+ <ul>
+ <li> /description/binding[@name="reservationSOAP11Binding"]</li>
+ <li> /description/service/endpoint[@name="reservationEndpoint2"]</li>
+ </ul>
+
+ <p>In the above example WSDL, reservation service has two endpoints. Of them,
+ one supports SOAP 1.1 message protocol, reservationEndpoint2. This endpoint
+ offers reservationInterface via reservationSOAP11Binding, a SOAP 1.1
+ binding.</p>
+
+ <p>reservationSOAP11Binding uses the version independent SOAP binding
+ extensions, specifies the version of SOAP by assigning 1.1 to wsoap:version
+ attribute and indicates SOAP 1.1 HTTP Binding by assigning
+ http://www.w3.org/@@@@/@@/soap11/bindings/HTTP to wsoap:protocol attribute.
+ This binding also specifies the SOAP 1.1 fault code for transmitting
+ invalidDataFault, an Interface Fault Compontent, by assigning soap11:Client
+ to wsoap:code attribute.
+ </p>
+
</div>
<div class="div3">
***************
*** 1200,1204 ****
--- 1302,1442 ----
<div class="div2">
<h3><a name="adv-MTOM"></a>5.6 MTOM Support</h3>
+
+ <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050310</td></tr><tr><td valign="top" align="left" colspan="2">Incoporated contribution from Jonathan. Need to check back this section for integration with rest of document.
+ </td></tr></table>
+
+ <p>This section shows how the [<cite><a href="#">xxx</a></cite>] SOAP Message Transmission Optimization Mechanism may be engaged in the WSDL 2.0 SOAP binding.</p>
+
+ <p>Let’s modify the CheckAvailability operation of the GreatH Hotel Reservation Service [ref] to return not only the room rate, but images of the room and the floorplan. We’ll modify the checkAvailabilityResponse data structure to include binary data representing these two images, indicated by xs:base64Binary data type:</p>
+
+ <div class="exampleOuter">
+ <p class="exampleHead" style="text-align: left"><a name="example-MTOM-schema"></a><i><span>Example 5-1. </span>An example XML Schema that contains optimizable elements </i></p>
+
+ <div class="exampleInner"><pre>
+
+ <xs:element name="checkAvailabilityResponse">
+
+ <xs:sequence>
+
+ <xs:element name="rate" type="xs:double"/>
+
+ <xs:element name="photo" type = "xmime:base64Binary" xmime:expectedContentType="image/jpeg image/png" />
+
+ <xs:element name="floorplan" xmime:expectedContentType="image/svg">
+
+ <xs:simpleContent>
+
+ <xs:restriction base="xs:base64Binary">
+
+ <xs:attribute ref="xmime:contentType" fixed="image/svg" />
+
+ </xs:restriction>
+
+ </xs:simpleContent>
+
+ </xs:element>
+
+ </xs:sequence>
+
+ </xs:element>
+
+ </pre></div></div>
+
+ <p>Note the use of the xmime:expectedContentType and xmime:contentType attributes to declare the expected media type of the encoded data and to allow the client to indicate the type at runtime, respectively. These attributes are defined in Describing Media Content of Binary Data in XML [ref].</p>
+
+ <p>A Response message conforming to this schema might look like this:</p>
+
+ <div class="exampleOuter">
+ <p class="exampleHead" style="text-align: left"><a name="example-MTOM-soap-message"></a><i><span>Example 5-2. </span>An example of non-optimized soap message that contains embedded binary data </i></p>
+
+ <div class="exampleInner"><pre>
+
+ <soap:Envelope
+
+ xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
+
+ xmlns:xmime='http://www.w3.org/@@@@/@@/xmlmime'>
+
+ <soap:Body>
+
+ <g:checkAvailabilityResponse
+
+ xmlns:g="http://greath.example.com/2004/schemas/resSvc">
+
+ <g:rate>129.95</g:rate>
+
+ <g:photo xmime:contentType='image/png'>/aWKKapGGyQ=</g:photo>
+
+ <g:floorplan xmime:contentType="image/svg">Faa7vROi2VQ=</g:floorplan>
+
+ </g:checkAvailabilityResponse>
+
+ </soap:Body>
+
+ </soap:Envelope>
+
+ </pre></div></div>
+
+ <p>While this (non-optimized) message satisfies the schema definition, a service may choose to allow or require that the binary data be sent in an optimized format using the Message Transmission and Optimization feature. The use of this feature by the SOAP binding is indicated as follows:</p>
+
+
+ <div class="exampleOuter">
+ <p class="exampleHead" style="text-align: left"><a name="example-MTOM-soap-binding"></a><i><span>Example 5-3. </span>Indicating the use of MTOM in wsdl binding</i></p>
+
+ <div class="exampleInner"><pre>
+
+ <binding name="reservationSOAPBinding"
+
+ interface="tns:reservationInterface"
+
+ type="http://www.w3.org/2004/08/wsdl/soap12"
+
+ wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
+
+
+
+ <operation ref="tns:opCheckAvailability"
+
+ wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response">
+
+
+
+ <input name="checkAvailability" />
+
+ <output name="checkAvailabilityRespone">
+
+ <feature uri="http://www.w3.org/2003/06/soap/features/http-optimization"
+
+ required="true"/>
+
+ </output>
+
+
+
+ </operation>
+
+ ...
+
+
+
+ </binding>
+ </pre></div></div>
+
+
+ <p>The HTTP Message Transmission Optimization feature is engaged using the <code>feature</code> element. Note that the attribute required=”true” on the feature declaration indicates that the message must be encoded using the HTTP Optimization feature. If the attribute were required=”false” (or this attribute were absent), it would indicate that the service accepts either MTOM-encoded messages, or the embedded base64Binary data directly in the Body, and the client is free to send either form of message. </p>
+
+
+ <p>The example above shows MTOM enabled for a specific message within an operation. Placing the feature declaration as a child of <code>operation</code> would require (or enable if required=”false”) MTOM support for all the messages in that operation. Placing the feature declaration as a child of <code>binding</code> would require (or enable if required=”false”) MTOM support for all the operations in that interface.
+ </p>
+
+
+
+
+
+
+
<p>This section shows how Features and Properties can be used to indicate the use of MTOM. @@ Example from GlenD: http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0076.html @@</p>
+
+
</div>
<div class="div2">
***************
*** 1372,1376 ****
<dt class="label"><a name="WSDL-PART2"></a>[WSDL 2.0 Predefined Extensions] </dt><dd>
! <cite><a href="wsdl20-extensions.html">Web Services Description Language (WSDL)
Version 2.0 Part 2: Predefined Extensions</a></cite>,
M. Gudgin, A. Lewis, and J. Schlimmer, Editors. World
--- 1610,1614 ----
<dt class="label"><a name="WSDL-PART2"></a>[WSDL 2.0 Predefined Extensions] </dt><dd>
! <cite><a href="wsdl20-adjuncts.html">Web Services Description Language (WSDL)
Version 2.0 Part 2: Predefined Extensions</a></cite>,
M. Gudgin, A. Lewis, and J. Schlimmer, Editors. World
***************
*** 1380,1386 ****
This version of the "Web Services Description Language (WSDL)
Version 2.0 Part 2: Predefined Extensions"
! Specification is available at wsdl20-extensions.html. The
! <a href="http://www.w3.org/2002/ws/desc/wsdl20-extensions">latest version of "Web Services Description Language (WSDL)
! Version 2.0 Part 2: Predefined Extensions"</a> is available at http://www.w3.org/2002/ws/desc/wsdl20-extensions.
</dd>
--- 1618,1624 ----
This version of the "Web Services Description Language (WSDL)
Version 2.0 Part 2: Predefined Extensions"
! Specification is available at wsdl20-adjuncts.html. The
! <a href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts">latest version of "Web Services Description Language (WSDL)
! Version 2.0 Part 2: Predefined Extensions"</a> is available at http://www.w3.org/2002/ws/desc/wsdl20-adjuncts.
</dd>
***************
*** 1388,1392 ****
<dt class="label"><a name="WSDL-PART3"></a>[WSDL 2.0 Bindings] </dt><dd>
! <cite><a href="wsdl20-bindings.html">Web Services Description Language (WSDL) Version
2.0 Part 3: Bindings</a></cite>, H. Haas,
P. Le Hégaret,
--- 1626,1630 ----
<dt class="label"><a name="WSDL-PART3"></a>[WSDL 2.0 Bindings] </dt><dd>
! <cite><a href=".html">Web Services Description Language (WSDL) Version
2.0 Part 3: Bindings</a></cite>, H. Haas,
P. Le Hégaret,
***************
*** 1399,1405 ****
This version of the "Web
Services Description Version 2.0: Bindings" Specification
! is available at wsdl20-bindings.html. The <a href="http://www.w3.org/2002/ws/desc/wsdl20-bindings">latest version of "Web Services
Description Language (WSDL) Version 2.0 Part 3:
! Bindings"</a> is available at http://www.w3.org/2002/ws/desc/wsdl20-bindings.
</dd>
--- 1637,1643 ----
This version of the "Web
Services Description Version 2.0: Bindings" Specification
! is available at .html. The <a href="http://www.w3.org/2002/ws/desc/">latest version of "Web Services
Description Language (WSDL) Version 2.0 Part 3:
! Bindings"</a> is available at http://www.w3.org/2002/ws/desc/.
</dd>
Received on Thursday, 17 March 2005 01:52:38 UTC