- From: Arthur Ryman via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 15 Jun 2005 22:03:09 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv19103/wsdl20
Modified Files:
wsdl20-primer.xml
Log Message:
Fixed validation errors.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.94
retrieving revision 1.95
diff -C2 -d -r1.94 -r1.95
*** wsdl20-primer.xml 14 Jun 2005 22:39:19 -0000 1.94
--- wsdl20-primer.xml 15 Jun 2005 22:03:06 -0000 1.95
***************
*** 848,852 ****
from a service to one other node, a service defined by that MEP may multicast that message to
other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
! <p>A total of eight MEPs are defined in <bibref ref="WSDL-PART2"/>. These MEPs should cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <specref ref="more-interfaces-defining-meps"/> )</p>
<p>For the eight MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/2005/05/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault can be generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/2005/05/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and must be delivered to the originator of the message. If there is no path to this node, the fault must be discarded. For details about the common fault generation models used by the eight WSDL 2.0 MEPs, see <bibref ref="WSDL-PART2"/>. </p>
--- 848,852 ----
from a service to one other node, a service defined by that MEP may multicast that message to
other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
! <p>A total of eight MEPs are defined in <bibref ref="WSDL-PART2"/>. These MEPs should cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <specref ref="more-interfaces-meps"/> )</p>
<p>For the eight MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/2005/05/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault can be generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/2005/05/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and must be delivered to the originator of the message. If there is no path to this node, the fault must be discarded. For details about the common fault generation models used by the eight WSDL 2.0 MEPs, see <bibref ref="WSDL-PART2"/>. </p>
***************
*** 1326,1330 ****
<p>An operation using this message exchange pattern has a pattern property with
the value <attval>http://www.example.com/webservices/meps/confirmed-challenge</attval>.</p>
- </div3>
<p>Once the MEP had been defined (and the email binding specification
--- 1326,1329 ----
***************
*** 1371,1374 ****
--- 1370,1374 ----
sequence is not significant. Note, however, that for this pattern, the
messageLabel attribute is required on every input and output element.</p>
+ </div3>
</div2><!-- adv-MEP -->
Received on Wednesday, 15 June 2005 22:03:12 UTC