- From: Kevin Liu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 23 Jun 2005 21:59:26 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv7128/ws/desc/wsdl20
Modified Files:
wsdl20-primer.html wsdl20-primer.xml
Log Message:
more minor editings for typos + minor reorg of schema and component model sections
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.105
retrieving revision 1.106
diff -C2 -d -r1.105 -r1.106
*** wsdl20-primer.xml 23 Jun 2005 17:34:57 -0000 1.105
--- wsdl20-primer.xml 23 Jun 2005 21:59:24 -0000 1.106
***************
*** 9,12 ****
--- 9,13 ----
<!ENTITY prevloc "http://www.w3.org/TR/2004/WD-wsdl20-primer-20041221">
]>
+
<spec w3c-doctype="wd" role="&document.role;">
<header>
***************
*** 99,105 ****
<p>Section 2 presents a hypothetical use case involving a hotel reservation service. It then proceeds step-by-step through the development of a simple example WSDL 2.0 document that describes this service:<ulist><item><p>The <code>types</code> element describes the kinds of messages that the service will send and receive. </p></item><item><p>The <code>interface</code> element describes <emph>what</emph> abstract functionality the Web service provides. </p></item><item><p>The <code>binding</code> element describes <emph>how</emph> to access the service. </p></item><item><p>The <code>service</code> element describes <emph>where</emph> to access the service.</p></item></ulist></p>
! <p>Section 3 gives more information on defining message types.</p><p>Section 4 gives more information on interfaces.</p><p>Section 5 gives more information on bindings.</p><p>Section 6 gives more information on defining services.</p>
! <p>Section 5 covers various advanced topics, including features and properties, flexible authoring styles, service and endpoint references, use of URIs, etc. </p>
</div2><div2 id="notation">
--- 100,107 ----
<p>Section 2 presents a hypothetical use case involving a hotel reservation service. It then proceeds step-by-step through the development of a simple example WSDL 2.0 document that describes this service:<ulist><item><p>The <code>types</code> element describes the kinds of messages that the service will send and receive. </p></item><item><p>The <code>interface</code> element describes <emph>what</emph> abstract functionality the Web service provides. </p></item><item><p>The <code>binding</code> element describes <emph>how</emph> to access the service. </p></item><item><p>The <code>service</code> element describes <emph>where</emph> to access the service.</p></item></ulist></p>
! <p>Section 3 introduces the WSDL2.0 infoset, schema and component model.</p>
! <p>Section 4 gives more information on defining message types.</p><p>Section 5 gives more information on interfaces.</p><p>Section 6 gives more information on bindings and services.</p>
! <p>Section 7 covers various advanced topics.</p>
</div2><div2 id="notation">
***************
*** 109,113 ****
context-dependent URIs <bibref ref="RFC2396"/>.Note also that the choice of
any namespace prefix is arbitrary and not semantically significant
! (see <bibref ref="XMLInfoSet"/>).</p>
</div2>
--- 111,124 ----
context-dependent URIs <bibref ref="RFC2396"/>.Note also that the choice of
any namespace prefix is arbitrary and not semantically significant
! (see <bibref ref="XMLInfoSet"/>). </p>
!
! <p>Following the convention for XML syntax sumary in <bibref ref="WSDL-PART1"/>, this primer uses an informal syntax to describe the XML grammar of a WSDL 2.0 document:
! <ulist>
! <item><p>The syntax appears as an XML instance, but the values indicate the data types instead of values.</p></item>
! <item><p>Characters are appended to elements and attributes as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more).</p></item>
! <item><p>Elements names ending in "…" indicate that elements/attributes irrelevant to the context are being omitted.</p> </item>
! </ulist>
!
! </p>
</div2>
***************
*** 222,232 ****
<def>
<p>
! This is the XML namespace for WSDL 2.0 itself.
! Because we have not defined a prefix for it, any
! unprefixed elements are expected
! to be WSDL 2.0 elements (such as
! the
! <code>description</code>
! element).
</p>
</def>
--- 233,237 ----
<def>
<p>
! This is the XML namespace for WSDL 2.0 itself. We assign it as the default namespace for this example by not defining a prefix for it. In other words, any unprefixed elements in this example are expected to be WSDL 2.0 elements (such as the <code>description</code> element).
</p>
</def>
***************
*** 476,480 ****
</example>
! <div3 id="example-initial-documentation-explanation"><head>Explanation of Example</head><glist><gitem><label><code><documentation></code></label><def><p> This element is optional, but a good idea to include. It can contain arbitrary mixed content. </p></def></gitem><gitem><label><code>at http://greath.example.com/2004/reservation-documentation.html</code></label><def><p>The most important thing to include is a pointer to any additional documentation that a client developer would need in order to use the service. </p></def></gitem></glist><p>This completes our presentation of the GreatH example. </p></div3></div2>
</div1>
--- 481,486 ----
</example>
! <div3 id="example-initial-documentation-explanation"><head>Explanation of Example</head><glist><gitem><label><code><documentation></code></label><def><p> This element is optional, but a good idea to include. It can contain arbitrary mixed content. </p></def></gitem><gitem><label><code>at http://greath.example.com/2004/reservation-documentation.html</code></label><def><p>The most important thing to include is a pointer to any additional documentation that a client developer would need in order to use the service. </p></def></gitem></glist>
! <p>This completes our presentation of the GreatH example. In the following sections, we will move on to look into more details of various aspects of WSDL2.0 specification. </p></div3></div2>
</div1>
***************
*** 493,507 ****
</p>
-
-
-
</div2>
-
-
<div2 id="wsdl-schema">
! <head>WSDL 2.0 Schema and Element Ordering</head>
! <p>The WSDL 2.0 specification supplies a <xspecref href="http://www.w3.org/2005/05/wsdl">normative WSDL 2.0 schema</xspecref>, defined in XML Schema <bibref ref="XMLSchemaP1"/> <bibref ref="XMLSchemaP2"/>, which can be used as an aid in validating WSDL 2.0 documents.
<ednote>
<name>KevinL</name>
--- 499,508 ----
</p>
</div2>
<div2 id="wsdl-schema">
! <head>WSDL 2.0 Schema</head>
! <p>The WSDL 2.0 specification supplies a <xspecref href="http://www.w3.org/2005/05/wsdl">normative WSDL 2.0 schema</xspecref>, defined in <bibref ref="XMLSchemaP1">XML Schema </bibref>, which can be used as an aid in validating WSDL 2.0 documents. We say "as an aid" here because WSDL 2.0 specification <bibref ref="WSDL-PART1"/> often provides further constraints to the WSDL2.0 schema. In addition to being valid with the normative schema, a WSDL 2.0 document must also follow all the constraints defined by the WSDL2.0 specification.
<ednote>
<name>KevinL</name>
***************
*** 511,516 ****
</edtext>
</ednote>
! Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="&w3c-designation-part1;#Description_XMLRep">XML Representation of Description Component</xspecref>") clearly states a set of constraints about how the children elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, in spite of what the WSDL 2.0 schema says. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<eg xml:space="preserve">
--- 512,520 ----
</edtext>
</ednote>
+ </p>
+ <div3 id="element-order"><head>WSDL2.0 Element Ordering</head>
+ <p>This section gives an example of how WSDL 2.0 specification constrains the WSDL 2.0 schema about the ordering of top WSDL2.0 elements.</p>
! <p>Although the WSDL 2.0 schema does not indicate the required ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> section "<xspecref href="&w3c-designation-part1;#Description_XMLRep">XML Representation of Description Component</xspecref>") clearly states a set of constraints about how the children elements of the <code>description</code> element should be ordered. Thus, the order of the WSDL 2.0 elements matters, in spite of what the WSDL 2.0 schema says. </p><p>The following is a pseudo-content model of <code>description</code>.</p>
<eg xml:space="preserve">
***************
*** 595,616 ****
<p>Note the term "extension" is used above as a convenient way to refer to namespace-qualified extension elements. The namespace name of such extension elements must not be<attval>&wsdl-ns;</attval>.
</p>
</div2>
! <div2 id="component-model"><head>WSDL 2.0 Component Model</head><p>The WSDL 2.0 Infoset model above illustrates the required structure of a WSDL 2.0 document, using the XML Infoset. However, the WSDL 2.0 language also imposes many semantic constraints over and above structural conformance to this XML Infoset. In order to precisely describe these constraints, and as an aid in precisely defining the meaning of each WSDL 2.0 document, the WSDL 2.0 specification defines a <emph>component model</emph> as an additional layer of abstraction above the XML Infoset. Constraints and meaning are defined in terms of this component model, and the definition of each component includes a mapping that specifies how values in the component model are derived from corresponding items in the XML Infoset. The following diagram gives an overview of the WSDL 2.0 components and their containment hierarchy.
<graphic source="images/WSDL20Components.png" alt="WSDL 2.0 Components Containment hierarchy"/></p>
! <p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Service</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p><p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component orresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!).
! </p>
<p>
The WSDL 2.0 component model is particularly helpful in defining
! the meaning of
! <el>import</el>
! and
! <el>include</el>
! elements. The
<el>include</el>
element allows you to assemble the contents of a given WSDL 2.0
--- 599,620 ----
<p>Note the term "extension" is used above as a convenient way to refer to namespace-qualified extension elements. The namespace name of such extension elements must not be<attval>&wsdl-ns;</attval>.
</p>
+ </div3>
</div2>
! <div2 id="component-model"><head>WSDL 2.0 Component Model</head>
! <p>The WSDL 2.0 Infoset model above illustrates the required structure of a WSDL 2.0 document, using the XML Infoset. However, the WSDL 2.0 language also imposes many semantic constraints over and above structural conformance to this XML Infoset. In order to precisely describe these constraints, and as an aid in precisely defining the meaning of each WSDL 2.0 document, the WSDL 2.0 specification defines a <emph>component model</emph> as an additional layer of abstraction above the XML Infoset. Constraints and meaning are defined in terms of this component model, and the definition of each component includes a mapping that specifies how values in the component model are derived from corresponding items in the XML Infoset. The following diagram gives an overview of the WSDL 2.0 components and their containment hierarchy.
<graphic source="images/WSDL20Components.png" alt="WSDL 2.0 Components Containment hierarchy"/></p>
! <p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Service</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p>
! <p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!).
+ </p>
+ <div3 id="import-component"><head>WSDL 2.0 Import and Include</head>
<p>
The WSDL 2.0 component model is particularly helpful in defining
! the meaning of <el>import</el> and <el>include</el> elements. The
<el>include</el>
element allows you to assemble the contents of a given WSDL 2.0
***************
*** 662,665 ****
--- 666,671 ----
same or a different namespace.
</p>
+ <p>We will cover a lot more about how to use WSDL 2.0 import and include in <specref ref="adv-import-and-authoring"/></p>
+ </div3>
</div2></div1>
***************
*** 813,817 ****
</tbody>
</table>
! <p>More advanced topics on importing schemas are discussed in <specref ref="adv-multiple-inline-schemas"/></p>
</div2>
--- 819,823 ----
</tbody>
</table>
! <p>More advanced topics on importing WSDLs and schemas are discussed in <specref ref="adv-import-and-authoring"/> and <specref ref="adv-multiple-inline-schemas"/></p>
</div2>
***************
*** 1013,1017 ****
! <div3 id="more-interfaces-op-attr"><head>Operation Attributes</head><p>An <code>operation</code> has two required and an optional attributes:</p>
<ulist>
<item>
--- 1019,1023 ----
! <div3 id="more-interfaces-op-attr"><head>Operation Attributes</head><p>An <code>operation</code> has two required attributes and one optional attribute:</p>
<ulist>
<item>
***************
*** 1037,1041 ****
</ulist>
! <p>Note that <bibref ref="WSDL-PART2"/> provides a predefined extension for indicating operation safety. The <att>wsdlx:safe</att> global attribute whose value is a boolean can be used with an operation to indicate whether the operation is asserted to be "safe" (as defined in Section 3.5 of the Web Architecture <bibref ref="webarch"/>) for clients to invoke. In essence, a safe operation is any operation that does not give the client any new obligations. For example, an operation that permits the client to check prices on products typically would not obligate the client to buy those products, and thus would be safe, whereas an operation for purchasing products would obligate the client to pay for the products that were ordered, and thus would not be safe. </p><p>An operation should be marked safe (by using the <att>wsdlx:safe</att> and by setting its value to "true") if it meets the criteria for a safe interaction defined in Section 3.5 of the Web Architecture <bibref ref="webarch"/>, because tis permits the infrastructure to perform efficiency optimizations, such as pre-fetch, re-fetch and caching. </p><p>The default value of this attribute is false. If it is false or is not set, then no assertion is made about the safety of the operation; thus the operation may or may NOT be safe.</p>
</div3><div3><head>Operation Message References</head><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 <specref ref="basics-interface"/>, this section will merely comment on additional capabilities that were not previously explained.</p>
--- 1043,1047 ----
</ulist>
! <p>Note that <bibref ref="WSDL-PART2"/> provides a predefined extension for indicating operation safety. The <att>wsdlx:safe</att> global attribute whose value is a boolean can be used with an operation to indicate whether the operation is asserted to be "safe" (as defined in Section 3.5 of the Web Architecture <bibref ref="webarch"/>) for clients to invoke. In essence, a safe operation is any operation that does not give the client any new obligations. For example, an operation that permits the client to check prices on products typically would not obligate the client to buy those products, and thus would be safe, whereas an operation for purchasing products would obligate the client to pay for the products that were ordered, and thus would not be safe. </p><p>An operation should be marked safe (by using the <att>wsdlx:safe</att> and by setting its value to "true") if it meets the criteria for a safe interaction defined in Section 3.5 of the Web Architecture <bibref ref="webarch"/>, because tis permits the infrastructure to perform efficiency optimizations, such as pre-fetch, re-fetch and caching. </p><p>The default value of this attribute is false. If it is false or is not set, then no assertion is made about the safety of the operation; thus the operation may or may not be safe.</p>
</div3><div3><head>Operation Message References</head><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 <specref ref="basics-interface"/>, this section will merely comment on additional capabilities that were not previously explained.</p>
***************
*** 1166,1173 ****
<head>More on Bindings</head>
! <p>Bindings are used to supply protocol and encoding details that specify <emph>how</emph> messages are to be sent or received. Each <code>binding</code> element uses a particular <emph>binding extension</emph> to specify such information. WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> defines several binding extensions that are typically used. However, binding extensions that are not defined in WSDL 2.0 Part 2 can also be used, provided that client and service toolkits support them.</p><p>Binding information must be supplied for every operation in the interface that is used in an endpoint. However, if the desired binding extension provides suitable defaulting rules, then the information will only need to be explicitly supplied at the interface level, and the defaulting rules will implicitly propagate the information to the operations of the interface. For example, see the SOAP binding extension in WSDL 2.0 Part 2
! <bibref ref="WSDL-PART2"/>
! section 4.3
! <xspecref href="&w3c-designation-part2;#soap-defaults">Default Binding Rules</xspecref>.</p>
<div2 id="more-bindings-wsdl">
--- 1172,1177 ----
<head>More on Bindings</head>
! <p>Bindings are used to supply protocol and encoding details that specify <emph>how</emph> messages are to be sent or received. Each <code>binding</code> element uses a particular <emph>binding extension</emph> to specify such information. WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> defines several binding extensions that are typically used. However, binding extensions that are not defined in WSDL 2.0 Part 2 can also be used, provided that client and service toolkits support them.</p><p>Binding information must be supplied for every operation in the interface that is used in an endpoint. However, if the desired binding extension provides suitable defaulting rules, then the information will only need to be explicitly supplied at the interface level, and the defaulting rules will implicitly propagate the information to the operations of the interface. For example, see the <xspecref href="&w3c-designation-part2;#soap-defaults">Default Binding Rules</xspecref> of SOAP binding extension in WSDL 2.0 Prt 2
! <bibref ref="WSDL-PART2"/>.</p>
<div2 id="more-bindings-wsdl">
***************
*** 1235,1241 ****
<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"
--- 1239,1245 ----
<description
xmlns="http://www.w3.org/2005/05/wsdl"
! targetNamespace="http://greath.example.com/@@@@/wsdl/resSvc"
! xmlns:tns="http://greath.example.com/@@@@/wsdl/resSvc"
! xmlns:ghns="http://greath.example.com/@@@@/schemas/resSvc"
xmlns:wsoap="http://www.w3.org/2005/05/wsdl/soap"
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
***************
*** 1294,1298 ****
! <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>
--- 1298,1306 ----
! <div3 id="more-bindings-soap-example-explanation"><head>Explanation of Example</head><p>Most lines in 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 for SOAP 1.1 binding.<glist><gitem><label><code><description ... 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><binding...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><operation ref="tns:opCheckAvailability"/></code></label><def><p>Note that <code>wsoap:mep</code> is not appliable to SOAP 1.1 binding. </p></def></gitem>
! <gitem><label><code><fault...wsoap:code="soap11:Client"/></code></label><def><p>This line specifies the SOAP 1.1 fault code that will be used in transmitting invalidDataFault.</p></def></gitem>
! </glist></p>
</div3></div2>
***************
*** 1334,1345 ****
! <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: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>type="http://www.w3.org/2005/05/wsdl/http"</code></label>
<def>
<p>
--- 1342,1353 ----
! <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 for HTTP binding extension.
<glist>
<gitem>
! <label><code><description...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><binding...type="http://www.w3.org/2005/05/wsdl/http"</code></label>
<def>
<p>
***************
*** 1350,1357 ****
<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>
! <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><example id="example-bindings-http-path-subsset">
<head>Serializing a Subset of Types in the Path</head>
<eg xml:space="preserve">
--- 1358,1365 ----
<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 would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></def></gitem></glist></p>
! <p>Here is an alternate example that appends "/" to the type name in order to serialize the remaining instance data into the message body:</p><example id="example-bindings-http-path-subsset">
<head>Serializing a Subset of Types in the Path</head>
<eg xml:space="preserve">
***************
*** 1495,1499 ****
</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 2.8.1.1 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>
--- 1503,1507 ----
</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>
***************
*** 1703,1707 ****
<div2 id="adv-import-and-authoring">
! <head>Import mechanism and authoring style</head>
--- 1711,1715 ----
<div2 id="adv-import-and-authoring">
! <head>Importing WSDL</head>
***************
*** 1709,1713 ****
<p>
! In some circumstances you may want to split up a Web service description into two or more documents.
For example, if a description is getting long or is being developed by several authors, then it
is convenient to divide it into several parts.
--- 1717,1721 ----
<p>
! In some circumstances WSDL authors may want to split up a Web service description into two or more documents.
For example, if a description is getting long or is being developed by several authors, then it
is convenient to divide it into several parts.
***************
*** 1720,1728 ****
</p><p>To solve these problems,
WSDL 2.0 provides two mechanisms for modularizing Web service description documents: <code>import</code> and <code>include</code>.
! This section discusses the import mechanism and describes some typical cases where it is be used.
</p>
<p>
! The <code>import</code> mechanism lets you refer to the definitions of Web service components that belong to other namespaces.
To illustrate this, consider the GreatH hotel reservation service. Suppose that the reservation service uses a
standard credit card validation service that is provided by a financial services company. Furthermore, suppose that
--- 1728,1736 ----
</p><p>To solve these problems,
WSDL 2.0 provides two mechanisms for modularizing Web service description documents: <code>import</code> and <code>include</code>.
! This section discusses the import mechanism and describes some typical cases where it may be used.
</p>
<p>
! The <code>import</code> mechanism lets one refer to the definitions of Web service components that belong to other namespaces.
To illustrate this, consider the GreatH hotel reservation service. Suppose that the reservation service uses a
standard credit card validation service that is provided by a financial services company. Furthermore, suppose that
***************
*** 2154,2158 ****
<!-- =============== -->
! <p>This section shows how theSOAP Message Transmission Optimization Mechanism (MTOM) <bibref ref="SOAP-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>
--- 2162,2166 ----
<!-- =============== -->
! <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>
***************
*** 2246,2250 ****
<output name="checkAvailabilityResponse">
<feature
! uri="http://www.w3.org/2003/06/soap/features/http-optimization"
required="true" />
</output>
--- 2254,2258 ----
<output name="checkAvailabilityResponse">
<feature
! uri="http://www.w3.org/2004/08/soap/features/http-optimization"
required="true" />
</output>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.77
retrieving revision 1.78
diff -C2 -d -r1.77 -r1.78
*** wsdl20-primer.html 23 Jun 2005 17:34:57 -0000 1.77
--- wsdl20-primer.html 23 Jun 2005 21:59:23 -0000 1.78
***************
*** 1,15 ****
! <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
! "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
! <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
! <head>
! <meta name="generator" content=
! "HTML Tidy for Mac OS X (vers 12 April 2005), see www.w3.org" />
! <meta http-equiv="Content-Type" content=
! "text/html; charset=utf-8" />
! <title>Web Services Description Language (WSDL) Version 2.0 Part 0:
! Primer</title>
[...8866 lines suppressed...]
! (Electronic Data Systems), Yaron Goland
! (BEA Systems, Inc.), Ümit Yalçınalp
! (Oracle Corporation), Peter Madziak
! (Agfa-Gevaert N. V.), Jeffrey Schlimmer
! (Microsoft Corporation), Hao He
! (The Thomson Corporation), Erik Ackerman
! (Lexmark), Jerry Thrasher
! (Lexmark), Prasad Yendluri
! (webMethods, Inc.), William Vambenepe
! (Hewlett-Packard Company), David Booth
! (W3C), Sanjiva Weerawarana
! (IBM).</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 Thursday, 23 June 2005 21:59:33 UTC