- From: Arthur Ryman via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 13 Jun 2005 19:22:54 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv20326/wsdl20
Modified Files:
wsdl20-primer.xml
Log Message:
Fixed some typos and grammar errors.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.92
retrieving revision 1.93
diff -C2 -d -r1.92 -r1.93
*** wsdl20-primer.xml 13 Jun 2005 18:27:59 -0000 1.92
--- wsdl20-primer.xml 13 Jun 2005 19:22:52 -0000 1.93
***************
*** 744,748 ****
<p>The optional <att>extends</att> attribute allows an interface to extend or inherit from one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines directly. Two things about extending interfaces deserve some attention. </p><p>First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given interface extends must NOT themselves extend that interface either directly or indirectly. </p><p>Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="&w3c-designation-part1;#compequiv">Equivalence of Components</xspecref>") then they are considered to be the same peration, i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendents.) In the second case, if two operations have the same name in the same WSDL target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely. </p><p>Finally, since faults, features and properties can also be defined as children of the <code>interface</code> element (as described in the following sections), the same name-collision rules apply to those constructs. </p>
! <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service, the content of of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p>
<example id="example-faults">
--- 744,749 ----
<p>The optional <att>extends</att> attribute allows an interface to extend or inherit from one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines directly. Two things about extending interfaces deserve some attention. </p><p>First, an inheritance loop (or infinite recursion) is prohibited: the interfaces that a given interface extends must NOT themselves extend that interface either directly or indirectly. </p><p>Second, we must explain what happens when operations from two different interfaces have the same target namespace and operation name. There are two cases: either the component models of the operations are the same, or they are different. If the component models are the same (per the component comparison algorithm defined in WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/> "<xspecref href="&w3c-designation-part1;#compequiv">Equivalence of Components</xspecref>") then they are considered to be the same peration, i.e., they are collapsed into a single operation, and the fact that they were included more than once is not considered an error. (For operations, component equivalence basically means that the two operations have the same set of attributes and descendents.) In the second case, if two operations have the same name in the same WSDL target namespace but are not equivalent, then it is an error. For the above reason, it is considered good practice to ensure that all operations within the same target namespace are named uniquely. </p><p>Finally, since faults, features and properties can also be defined as children of the <code>interface</code> element (as described in the following sections), the same name-collision rules apply to those constructs. </p>
! <p>Let's say the GreatH hotel wants to maintain a a standard message log operation for all received messages. It wants this operation to be reusable across the whole reservation system, so each service will send out, for potential use of a logging service,
! the content of each message it receives together with a timestamp and the originator of the message. One way to meet such requirement is to define the log operation in an interface which can be inherited by other interfaces. Assuming a <code>messageLog</code> element is already defined in the ghns namespace with the required content, the inheritance use case is illustrated in the following example. As a result of the inheritance, the <code>reservationInterface</code> now contains two operations: <code>opCheckAvailability</code> and <code>opLogMessage</code></p>
<example id="example-faults">
***************
*** 826,830 ****
<item><p>RPC Style.The RPC style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/rpc. It places restrictions for Remote Procedure Call-types of interactions. </p></item>
<item><p>URI Style. The URI style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/uri. It places restrictions on message definitions so they may be serialized into something like HTTP URL encoded.</p></item>
! <item><p>The Multipart style. The Multipart style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/multipart. In http binding, for Xform clients, an message must be defined following the Multipart style and serialized as "Multipart/form-data". </p> </item>
</ulist>
--- 827,831 ----
<item><p>RPC Style.The RPC style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/rpc. It places restrictions for Remote Procedure Call-types of interactions. </p></item>
<item><p>URI Style. The URI style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/uri. It places restrictions on message definitions so they may be serialized into something like HTTP URL encoded.</p></item>
! <item><p>The Multipart style. The Multipart style is selected when the <att>style</att> is assigned the value http://www.w3.org/2005/05/wsdl/style/multipart. In the HTTP binding, for XForm clients, a message must be defined following the Multipart style and serialized as "Multipart/form-data". </p> </item>
</ulist>
***************
*** 837,841 ****
</item>
</ulist></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>
! <div4><head>The messageLabel Attribute</head><p>The <att>messageLabel</att> attribute of the <code>input</code> and <code>output</code> elements is optional. It is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> and it has only one message with a given direction. </p></div4><div4><head>The element Attribute</head><p>The <att>element</att> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (a/k/a payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: <glist><gitem><label><code>#any</code></label><def><p>The message content is any single element.</p></def></gitem><gitem><label><code>#none</code></label><def><p>There is no mesage content, i.e., the message payload is empty.</p></def></gitem></glist>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <ednote><edtext>ToDo: Say what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </edtext></ednote></p></div4><div4><head>Multiple infault or outfault Elements</head><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div4></div3>
<!-- ************************MEPs*************************** -->
--- 838,842 ----
</item>
</ulist></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>
! <div4><head>The messageLabel Attribute</head><p>The <att>messageLabel</att> attribute of the <code>input</code> and <code>output</code> elements is optional. It is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> and it has only one message with a given direction. </p></div4><div4><head>The element Attribute</head><p>The <att>element</att> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (aka payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: <glist><gitem><label><code>#any</code></label><def><p>The message content is any single element.</p></def></gitem><gitem><label><code>#none</code></label><def><p>There is no messge content, i.e., the message payload is empty.</p></def></gitem></glist>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <ednote><edtext>ToDo: Say what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </edtext></ednote></p></div4><div4><head>Multiple infault or outfault Elements</head><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div4></div3>
<!-- ************************MEPs*************************** -->
***************
*** 906,910 ****
<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 an 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
--- 907,911 ----
<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
***************
*** 949,955 ****
<div2 id="bindingOperations">
<head id="more-bindings-operations">Binding Operations</head>
! <p>A binding <code>operation</code> describes a concrete binding of a particular
! operation of an interface to a particular concrete message format. A particular
! operation of an interface is uniquely identified by the WSDL target namespace of the
interface and the name of the operation within that interface, via the required <att>ref</att> attribute of binding <code>operation</code>. As with faults, for each <code>operation</code> within a <code>binding</code>, the value of the <att>ref</att> attribute must be unique.</p>
--- 950,956 ----
<div2 id="bindingOperations">
<head id="more-bindings-operations">Binding Operations</head>
! <p>A binding <code>operation</code> describes a concrete binding of an interface
! operation to a concrete message format. An interface
! operation is uniquely identified by the WSDL target namespace of the
interface and the name of the operation within that interface, via the required <att>ref</att> attribute of binding <code>operation</code>. As with faults, for each <code>operation</code> within a <code>binding</code>, the value of the <att>ref</att> attribute must be unique.</p>
Received on Monday, 13 June 2005 19:22:58 UTC