- From: Jonathan Marsh via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 30 Oct 2006 23:40:29 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20 In directory hutz:/tmp/cvs-serv13189/wsdl20 Modified Files: wsdl20-primer.xml wsdl20-primer.html Log Message: Removed Features and Properties section. Removed MTOM descirption (relied on Features and Properties). Index: wsdl20-primer.xml =================================================================== RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v retrieving revision 1.148 retrieving revision 1.149 diff -C 2 -d -r1.148 -r1.149 *** wsdl20-primer.xml 20 Oct 2006 22:18:16 -0000 1.148 --- wsdl20-primer.xml 30 Oct 2006 23:40:26 -0000 1.149 *************** *** 905,909 **** ! <p>Below is the XML syntax summary of the <code>interface</code> element, simplified by omitting optional <code><documentation></code> elements and <code><feature></code> and <code><property></code> extension elements:</p> <eg xml:space="preserve"> <description targetNamespace="<emph>xs:anyURI</emph>" > --- 905,909 ---- ! <p>Below is the XML syntax summary of the <code>interface</code> element, simplified by omitting optional <code><documentation></code> elements:</p> <eg xml:space="preserve"> <description targetNamespace="<emph>xs:anyURI</emph>" > *************** *** 1247,1251 **** <div3 id="more-bindings-wsdl"> <head>Syntax Summary for Bindings</head> ! <p>Since bindings are specified using extensions to the WSDL 2.0 language (i.e., binding extensions are not in the WSDL 2.0 namespace), the XML for expressing a binding will consist of a mixture of elements and attributes from WSDL 2.0 namespace and from the binding extension's namespace, using WSDL 2.0's open content model. </p><p>Here is a syntax summary for <code>binding</code>, simplified by omitting optional <code>documentation</code>, <code>feature</code> and <code>property</code> elements. Bear in mind that this syntax summary only shows the elements and attributes defined within the WSDL 2.0 namespace. When an actual binding is defined, elements and attributes from the namespace of the desired binding extension will also be intermingled as required by that particular binding extension.</p> <eg xml:space="preserve"> <description targetNamespace="<emph>xs:anyURI</emph>" > --- 1247,1251 ---- <div3 id="more-bindings-wsdl"> <head>Syntax Summary for Bindings</head> ! <p>Since bindings are specified using extensions to the WSDL 2.0 language (i.e., binding extensions are not in the WSDL 2.0 namespace), the XML for expressing a binding will consist of a mixture of elements and attributes from WSDL 2.0 namespace and from the binding extension's namespace, using WSDL 2.0's open content model. </p><p>Here is a syntax summary for <code>binding</code>, simplified by omitting optional <code>documentation</code> elements. Bear in mind that this syntax summary only shows the elements and attributes defined within the WSDL 2.0 namespace. When an actual binding is defined, elements and attributes from the namespace of the desired binding extension will also be intermingled as required by that particular binding extension.</p> <eg xml:space="preserve"> <description targetNamespace="<emph>xs:anyURI</emph>" > *************** *** 2071,2181 **** <div2 id="adv-extensibility"> <head>Extensibility</head> ! <p>WSDL 2.0 provides two extensibility mechanisms: an open content model, which allows XML elements and attributes from other (non-WSDL 2.0) XML namespaces to be interspersed in a WSDL 2.0 document; and <xspecref href="&w3c-designation-part1;#Feature">Features</xspecref> and <xspecref href="&w3c-designation-part1;#Property">Properties</xspecref>. Both mechanisms use URIs to identify the semantics of the extensions. For extension XML elements and attributes, the namespace URI of the extension element or attribute acts as an unambiguous name for the semantics of that extension. For Features and Properties, the Feature or Property is named by a URI.</p><p>In either case, the URI that identifies the semantics of an extension should be dereferenceable to a document that describes the semantics of that extension. As of this writing, there is no generally accepted standard for what kind of document that should be. However, the <loc href="http://www.w3.org/2001/tag/">W3C TAG</loc> has been discussing th issue (see TAG issue <loc href="http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</loc>) and is likely to provide guidance at some point.</p><div3 id="adv-optional-versus-required"><head>Optional Versus Required Extensions</head><p>Extensions can either be required or optional.</p><p>An <emph>optional</emph> extension is one that the client may either engage or ignore, entirely at its discretion, and is signaled by <code>wsdl:required="false"</code> or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). Thus, a WSDL 2.0 processor, acting on behalf of the client, that encounters an unknown optional extension can safely ignore it and continue to process the WSDL 2.0 document. However, it is important to stress that optional extensions are only optional to the <emph>client</emph> -- not the service. A service must support all optional and required extensions that it advertises in its WSDL 2.0 document. </p><p>A <emph>required</emph extension is one that must be supported and engaged by the client in order for the interaction to proceed properly, and is signaled by <code>wsdl:required="true"</code>. If a WSDL 2.0 processor, acting on behalf of the client, encounters a required extension that it does not recognize or does not support, then it cannot safely continue to process the WSDL 2.0 document. In most practical cases, this is likely to mean that the processor will require manual intervention to deal with the extension. For example, a client developer might manually provide an implementation for the required extension to the WSDL 2.0 processor. </p></div3> ! <!-- removed per minutes 5-12-2005 AI div3 id="adv-scope-of-wsdl-required"><head>Scoping of the wsdl:required Attribute</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Need to check the scoping rules to see if this is correct.</edtext></ednote><p>As a convenience mechanism, the <code>wsdl:required</code> attribute need not be specified on every extension element. If it is omitted from an extension element, its effective value is inherited from the smallest enclosing scope that explicitly sets its value. If there is no enclosing scope that explicitly sets its value, then its value defaults to <code>false</code>. </p><p>Because portions of a Web service description can be written in different physical documents by different people, one should be cautious about setting <code>wsdl:required="false"</code> when an outer scope, written by someone else, had set <code>wsdl:required="true"</code>.</p></div3 --> ! ! </div2> ! <div2 id="adv-FP"> ! <head>Features and Properties</head> ! ! <ednote> ! <name>KevinL</name> ! <date>20050519</date> ! <edtext> ! The section is subject to change. Pending on the resolution of the minority opinions filed about Feature and Property. ! </edtext> ! </ednote> ! <p>After a few successful trials of the reservation service, GreatH decides that it is time to make the makeReservation operation secure, so that sensitive credit-card information is not being sent across the public network in a snoopable fashion. We will do this using the WSDL 2.0 Features and Properties mechanisms <bibref ref="WSDL-PART1"/>, which is modeled after the Features and Properties mechanism defined in SOAP 1.2 <bibref ref="SOAP12-PART1"/>.</p><p>To facilitate presentation, this section will assume the existence of a hypothetical security feature named "<code>http://features.example.com/2005/securityFeature</code>", which defines, in the abstract, the idea of message confidentiality. This feature has an associated property, named "<code>http://features.example.com/2005/securityFeature/securityLevel</code>", which defines various safety levels (from 0 meaning clear text, all the way through 10, involving highly complex cryptographic algorithms with keys in the tens of thousands of bits). We also assume that a SOAP module (for more about SOAP module, see <loc href="http://www.w3.org/TR/soap12-part1/#soapmodules"> SOAP1.2 spec</loc> and <specref ref="adv-FP-soap-modules"/>), named "<code>http://features.example.com/2005/modules/Security</code>", has been defined, which implements the security feature described above.</p><p>GreatH has chosen an abstract security feature which is standard in the fictitious hotels community, and has integrated both a SOAP module and a new secure HTTP binding into its infrastructure – both of which implement the security feature (the SOAP module does this inside the SOAP envelope using headers, and the secure binding does it at the transport layer). Now they'd like to advertise and control the usage of these extensions using WSDL 2.0.</p> ! ! <div3 id="adv-FP-soap-modules"><head>SOAP Modules</head><p>The first step GreatH takes is to require the usage of the SOAP module in their normal SOAP/HTTP endpoint, which looks like this:</p><example id="example-fp-requiring-soap-module"> ! <head>Requiring a SOAP Module in an Endpoint</head> ! <eg xml:space="preserve"> ! <![CDATA[ ! . . . ! <service name="reservationService" ! interface="tns:reservationInterface"> ! ! <endpoint name="reservationEndpoint" ! binding="tns:reservationSOAPBinding" ! address ="http://greath.example.com/2004/reservation"> ! <wsoap:module uri="http://features.example.com/2005/modules/Security" ! required="true"/> ! </endpoint> ! ! </service> ! . . . ! ]]></eg> ! </example><p>This syntax indicates that a SOAP Module is required by this endpoint. This means that anyone using this endpoint must both understand the specification that the module URI references, and must use that specification when communicating with the endpoint in question, which typically means including appropriate SOAP headers on transmitted messages. ! </p><p>If the "required" attribute was not present, or if it was set to "<code>false</code>", then the <code><wsoap:module></code> syntax would indicate optional the availability of the referenced module, rather than a requirement to engage it, as explained in <specref ref="adv-optional-versus-required"/>.</p></div3><div3 id="adv-FP-abstract-features"><head>Abstract Features</head><p>Since GreatH began the web service improvements, they have been talking to several travel agents. The possibility of making their simple hotel interface an industry standard amongst a consortium of hotels has come up, and as such they would like to enable specifying the requirement for the "makeReservation" operation to be secure at the interface level – in other words indicating that the operation must be secure, but without specifying exactly how that should concretely be achieved (to enable maximal reuse of the interface). The next example uses the WSDL 2.0 Feature element to indicate this.</p><example id="exampl-fp-declaring-abstract-feature"> ! <head>Declaring an Abstract Feature Requirement</head> ! <eg xml:space="preserve"> ! <![CDATA[. . . ! <interface name="reservationInterface"> ! <operation name="makeReservation"> ! <feature uri="http://features.example.com/2005/securityFeature" ! required="true"/> ! . . . [The rest of the operation is unchanged] . . . ! </operation> ! </interface> ! . . .]]></eg> ! </example><p>This declaration indicates that understanding of, and compliance with, the specified security feature is required for all uses of the "makeReservation" operation. The security feature is <emph>abstract</emph>, which means that although it defines semantics and a level of detail about its general operation, it expects a concrete component (like a SOAP module or binding) to actually realize the functionality.</p><p>By definition, if you understand a SOAP module, you understand which (if any) abstract features it implements. Therefore, since the security module in this example is defined as an implementation of the abstract security feature, we know that the use of this module satisfies the requirement to implement the feature. Therefore users of the HTTP endpoint shown above (with the required SOAP module) will be able to make use of it. GreatH also defines a new endpoint:</p><example id="example-fp-soap-over-shttp"> ! <head>A SOAP Binding Over a Secure HTTP Protocol</head> ! <eg xml:space="preserve"> ! <![CDATA[. . . ! <binding name="reservationSecureSOAPBinding" ! interface="tns:reservationInterface" ! ]]>type="&wsdl-soap-ns;"<![CDATA[ ! wsoap:protocol="http://bindings.example.com/SOAPBindings/secureHTTP"> ! . .. ! </binding> ! . . . ! <service name="reservationService"> ! . . . ! <endpoint name="secureReservationEndpoint" ! binding="tns:reservationSecureSOAPBinding" ! address="https://greath.example.com/2004/secureReservation"/> ! </service> ! . . .]]></eg> ! </example><p>The user will have a choice as to which of the endpoints, and therefore which binding, is to be used, but they both satisfy the abstract feature requirement specified in the interface.</p><p>Note that it is not necessary to declare the abstract feature in order to use/require the SOAP module, or in order to use/require the secure binding. Abstract feature declarations serve purely to indicate requirements which must be fulfilled by more concrete components such as modules or bindings. In other words, the abstract feature declaration allows components such as interfaces to be reused without caring exactly which SOAP modules or bindings satisfy the feature.</p></div3><div3 id="adv-fp-properties"><head>Properties</head><p>So far we've discussed how to indicate the availability or the "requiredness" of features and modules. Often it is not enough to indicate that a particular extension is available/required: you also need some way to control or parameterize aspects of its behavior. This i achieved by the use of WSDL 2.0 <emph>properties</emph>. Each feature, SOAP module, or SOAP binding may express a variety of <emph>properties</emph> in its specification. These properties are very much like variables in a programming language. If GreatH would like to indicate that the <code>securityLevel</code> property should be 5 for the "makeReservation" operation, it would look like this:</p><example id="example-fp-def-prop"> ! <head>Defining a Property</head> ! <eg xml:space="preserve"> ! <![CDATA[. . . ! <interface name="reservationInterface"> ! <operation name="makeReservation"> ! <property ! uri="http://features.example.com/2005/securityFeature/securityLevel"> ! <value>5</value> ! </property> ! . . . [rest of operation definition] . . . ! </operation> ! </interface> ! . . .]]></eg> ! </example><p>The <code>property</code> element specifies which property is to be set. By setting the <code>value</code> element, a toolkit processing this WSDL 2.0 document is informed that the securityLevel property must be set to 5. The particular meanings of any such values are up to the implementations of the modules/bindings that use them. The <code>property</code> element can be placed at many different levels in a WSDL 2.0 document (see "Property Composition Model" section in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/>). ! </p><p>It is also possible to provide a <emph>constraint</emph> on the value space for a given property. This allows the author of the WSDL 2.0 document to indicate that several valid values for the property are possible for a given scope, limiting the value space already described in the specification that defined the property. Let's extend our example to make this clearer.</p><p>The security feature specification defines securityLevel as an integer with values between 1 and 10, each of which indicates, according to the spec, a progressively higher level of security. The GreatH service authors, having read the relevant specifications, have decided that any security level between 3 and 7 will be supported by their infrastructure. Levels less than 3 are deemed unsafe for GreatH's purposes, and levels greater than 7 require too much in the way of resources to make it worthwhile. We can express this in WSDL 2.0 as follows:</p><example id="example-fp-def-prop-constraints"> ! <head>Defining Property Constraints</head> ! <eg xml:space="preserve"> ! <![CDATA[. . . ! <types> ! <schema> ! <simpleType name="securityLevelConstraint"> ! <restriction base="xs:int"> ! <minInclusive value="3"/> ! <maxInclusive value="7"/> ! </restriction> ! </simpleType> ! </schema> ! </types> ! . . . ! <property uri="http://features.example.com/2005/securityFeature/securityLevel"> ! <constraint type="tns:securityLevelConstraint"/> ! </property> ! . . . ! ]]></eg> ! </example><p>First we define, in the <code>types</code> section, an XML Schema restriction type over integers with minimum and maximum values, per our discussion above. Then instead of using the <code>value</code> element inside <code>property</code>, we use <code>constraint</code> and refer to the restriction type. This informs the implementation that the property must have the appropriate values. This information might be useful to a deployment user interface, for example, which might allow an administrator to set this value with a slider when deploying the service.</p></div3></div2> ! ! <div2 id="adv-MEP"> <head>Defining New MEPs</head> --- 2071,2111 ---- <div2 id="adv-extensibility"> <head>Extensibility</head> ! <p>WSDL 2.0 provides an open content model, which allows XML elements and attributes from other ! (non-WSDL 2.0) XML namespaces to be interspersed in a WSDL 2.0 document. The qualified name ! (complete with namespace URI) of the extension element or attribute acts as an unambiguous name ! for the semantics of that extension.</p> ! <p>The namespace URI of the extension element should be dereferenceable ! to a document that describes the semantics of that extension. As of this writing, there is ! no generally accepted standard for what kind of document that should be. However, the ! <loc href="http://www.w3.org/2001/tag/">W3C TAG</loc> has been discussing the issue (see ! TAG issue <loc href="http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">namespaceDocument-8</loc>) ! and is likely to provide guidance at some point.</p> + <div3 id="adv-optional-versus-required"><head>Optional Versus Required Extensions</head> + <p>Extensions can either be required or optional.</p> ! <p>An <emph>optional</emph> extension is one that the client may either engage or ignore, ! entirely at its discretion, and is signaled by <code>wsdl:required="false"</code> ! or the absence of the <code>wsdl:required</code> attribute (because it defaults to false). ! Thus, a WSDL 2.0 processor, acting on behalf of the client, that encounters an unknown ! optional extension can safely ignore it and continue to process the WSDL 2.0 document. ! However, it is important to stress that optional extensions are only optional to the ! <emph>client</emph> -- not the service. A service must support all optional and required ! extensions that it advertises in its WSDL 2.0 document. </p> ! ! <p>A <emph>required</emph> extension is one that must be supported and engaged by the ! client in order for the interaction to proceed properly, and is signaled by ! <code>wsdl:required="true"</code>. If a WSDL 2.0 processor, acting on behalf of the ! client, encounters a required extension that it does not recognize or does not support, ! then it cannot safely continue to process the WSDL 2.0 document. In most practical ! cases, this is likely to mean that the processor will require manual intervention to ! deal with the extension. For example, a client developer might manually provide an ! implementation for the required extension to the WSDL 2.0 processor. </p> ! </div3> ! </div2> ! ! <div2 id="adv-MEP"> <head>Defining New MEPs</head> *************** *** 2441,2562 **** - - <div2 id="adv-MTOM"><head>MTOM and Attachments Support</head> - - - <!-- =============== --> - <p>Unlike WSDL 1.1 which defines a MIME binding for attachments support, WSDL 2.0 supports MIME attachments via the SOAP Message Transmission Optimization Mechanism (MTOM) <bibref ref="SOAP-MTOM"/>. This section shows how MTOM may be engaged in the WSDL 2.0 SOAP binding extension.</p> - - <p>We will modify the <code>CheckAvailability</code> operation of the GreatH Hotel Reservation Service (<specref ref="example-initial"/>) to return not only the room rate, but images of the room and the floorplan. This will involve modifying the <code>checkAvailabilityResponse</code> data structure to include binary data representing these two images, indicated by the <code>xs:base64Binary</code> data type. Here is an example:</p> - - <example id="example-MTOM-schema"> - <head>XML Schema with 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 - <code>xmime:expectedContentType</code> - and - <code>xmime:contentType</code> - 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 - <bibref ref="DESCRIBEMEDIA"/>. Also note that, when using the WSDL HTTP Binding, an - implementation MAY use incoming HTTP Accept headers to choose - between alternative media types listed in - xmime:expectedContentType. - - </p> - - <p>A <code>checkAvailabilityResponse</code> message conforming to this schema might look like this:</p> - - <example id="example-MTOM-soap-message"> - <head>Non-optimized SOAP Message with Embedded Binary Data </head> - - <eg><![CDATA[ - - <soap:Envelope - xmlns:soap='http://www.w3.org/2003/05/soap-envelope' - xmlns:xmime='http://www.w3.org/2005/05/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 Mechanism (MTOM). The use of this feature by the WSDL 2.0 SOAP binding extension is indicated as follows:</p> - - - <example id="example-MTOM-soap-binding"> - <head>Specifying MTOM in a WSDL 2.0 Binding</head> - - <eg><![CDATA[ - - . . . - <binding name="reservationSOAPBinding" - interface="tns:reservationInterface" - ]]>type="&wsdl-soap-ns;"<![CDATA[ - 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="checkAvailabilityResponse"> - <feature - uri="http://www.w3.org/2004/08/soap/features/http-optimization" - required="true" /> - </output> - - </operation> - . . . - </binding> - . . .]]></eg></example> - - - <p>The HTTP Message Transmission Optimization (MTOM) feature is engaged using the <code>feature</code> element. Note that the attribute <code>required="true"</code> on the feature declaration indicates that the message must be encoded using the HTTP Optimization feature. If the attribute were <code>required="false"</code> (or this attribute were absent), it would indicate that the use of MTOM is optional for this service: the service accepts either MTOM-encoded messages, or the embedded base64Binary data directly in the SOAP 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 <code>required="false"</code>) 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 <code>required="false"</code>) MTOM support for all the operations in that interface. - </p> - - </div2> </div1> --- 2371,2374 ---- *************** *** 2612,2659 **** </p> ! <p> ! If any of the three cases above arise, then one of ! the following two alternatives can be used within ! the context of a single WSDL service by WSDL ! authors: ! </p> ! <ulist> ! <item> ! <p> ! <emph>Feature.</emph> ! The service or the interface element ! contains a Feature element declaration, ! having a required attribute with a value of ! true. The feature unambiguously identifies ! the mechanism that a message sender is ! required to support in order to enable the ! message recipient to unambiguously determine ! the message received. ! </p> ! </item> ! <item> ! <p> ! <emph>Extension.</emph> ! The interface element contains an extension ! element (i.e., an element that is not in the ! &wsdl-ns; namespace), ! having a wsdl:required attribute with a ! value of "true". The extension element ! unambiguously identifies the mechanism that ! a message sender is required to support in ! order to enable the message recipient to ! unambiguously determine the message ! received. ! </p> ! </item> ! </ulist> ! ! <p>In addition, WS-Addressing [WS-Addressing] specification already provides a ! disambiguation mechanism. It defines a required [action] property whose value is ! always present in a message delivery. The value of the action property can be used ! to disambiguate the message by the receiver and there is a well defined way to associate actions to messages in WS-Addressing specifications. Further, WS-Addressing also provides an appropriate default action value that identifies each message type ! uniquely. </p> <!-- old text for this section, replaced by contribution from Umit --- 2424,2443 ---- </p> ! <p>If any of the three cases above arise, disambiguation mechanisms may be ! provided by means of an extension element (i.e., an element that is not in the ! &wsdl-ns; namespace), having a wsdl:required attribute with a value of "true". ! The semantics of such an extension element would indicate the mechanism for ! unambiguously identifing the mechanism that a message sender is required to ! support in order to enable the message recipient to unambiguously determine ! the message received.</p> ! ! <p>For example, the WS-Addressing [WS-Addressing] specification provides such a ! disambiguation mechanism. It consists of an extension element which may be marked ! as required, and defines a required [action] property whose value is ! always present in a conformant message delivery. The value of the action property ! can be used to disambiguate the message by the receiver and there is a well defined way to associate actions to messages in WS-Addressing specifications. Further, WS-Addressing also provides an appropriate default action value that identifies each message type ! uniquely.</p> <!-- old text for this section, replaced by contribution from Umit Index: wsdl20-primer.html =================================================================== RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v retrieving revision 1.162 retrieving revision 1.163 diff -C 2 -d -r1.162 -r1.163 *** wsdl20-primer.html 26 Oct 2006 15:37:51 -0000 1.162 --- wsdl20-primer.html 30 Oct 2006 23:40:26 -0000 1.163 *************** *** 1,13 **** ! <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> ! <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> ! <head> ! <meta http-equiv="Content-Type" content= ! "text/html; charset=utf-8" /> ! <title>Web Services Description Language (WSDL) Version 2.0 Part 0: ! Primer</title> ! ! <style type="text/css" xml:space="preserve"> [...9315 lines suppressed...] ! (Lexmark), Jerry Thrasher ! (Lexmark), Prasad Yendluri ! (webMethods, Inc.), William Vambenepe ! (Hewlett-Packard Company), David Booth ! (W3C), Sanjiva Weerawarana ! (IBM), Charlton Barreto ! (webMethods, Inc.), Asir Vedamuthu ! (webMethods, Inc.), Igor Sedukhin ! (Computer Associates), Martin Gudgin ! (Microsoft Corporation), Rebecca Bergersen ! (IONA Technologies), Ugo Corda ! (SeeBeyond).</p> ! <p>The people who have contributed to <a href="http://lists.w3.org/Archives/Public/www-ws-desc/">discussions ! on www-ws-desc@w3.org</a> are also gratefully ! acknowledged.</p> </div> ! ! </div> ! </body></html> \ No newline at end of file
Received on Monday, 30 October 2006 23:40:47 UTC