- From: Amelia Lewis <alewis@dev.w3.org>
- Date: Tue, 13 Jul 2004 18:04:08 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv24734
Modified Files:
wsdl20-patterns.xml
Log Message:
Issues 231, 232, 234, 112, 230, 233
Index: wsdl20-patterns.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-patterns.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** wsdl20-patterns.xml 10 Jun 2004 15:41:18 -0000 1.10
--- wsdl20-patterns.xml 13 Jul 2004 18:04:06 -0000 1.11
***************
*** 13,17 ****
<header>
<title>Web Services Description Language (WSDL) Version 2.0 Part 2:
! Message Exchange Patterns</title>
<w3c-designation>&w3c-designation-part2;</w3c-designation>
<w3c-doctype>&document.status;</w3c-doctype>
--- 13,17 ----
<header>
<title>Web Services Description Language (WSDL) Version 2.0 Part 2:
! Predefined Extensions</title>
<w3c-designation>&w3c-designation-part2;</w3c-designation>
<w3c-doctype>&document.status;</w3c-doctype>
***************
*** 68,87 ****
<body>
<div1 id="intro">
<head>Introduction</head>
<p>
! Web Services Description Language (WSDL) message exchange patterns define the
! sequence and cardinality of abstract messages listed in an operation.
! Message exchange patterns also define which other nodes send messages to, and
! receive messages from, the service implementing the operation.
</p>
! <p>The message exchange patterns defined in this document are similar to, but
! not identical to, the message exchange patterns defined in the SOAP 1.2
! specification. In particular, the message exchange patterns defined here
! are more abstract, and are defined independently of particular bindings.
</p>
<p>
By design, WSDL message exchange patterns abstract out specific message types.
--- 68,111 ----
<body>
+ <!-- Editor cheat sheet
+ <p diff="add" >
+ This is marked @diff='add'
+ </p>
+ <p diff="chg" >
+ This is marked @diff='chg'
+ </p>
+ <p diff="del" >
+ This is marked @diff='del'
+ </p>
+ -->
+
<div1 id="intro">
<head>Introduction</head>
<p>
! Web Services Description Language provides a number of opportunities to
! extend the syntax and component model, as mandated by the needs of an
! application. This document defines and describes a number of these
! extensions, particularly message exchange patterns and features.
</p>
! </div1>
!
! <div1 id="meps">
! <head>Predefined Message Exchange Patterns</head>
!
! <p>
! Web Services Description Language (WSDL) message exchange patterns (hereafter simply
! 'patterns') define the sequence and cardinality of abstract messages listed in
! an operation. Message exchange patterns also define which other nodes send
! messages to, and receive messages from, the service implementing the operation.
! WSDL message exchange patterns describe the interaction at the abstract
! (interface) level, which may be distinct from the pattern used by the
! underlying protocol binding (e.g. SOAP Message Exchange Patterns).
</p>
+ <div2 id="mep-intro">
+ <head>Introduction</head>
+
<p>
By design, WSDL message exchange patterns abstract out specific message types.
***************
*** 114,134 ****
</p>
- <!-- Editor cheat sheet
- <p diff="add" >
- This is marked @diff='add'
- </p>
- <p diff="chg" >
- This is marked @diff='chg'
- </p>
- <p diff="del" >
- This is marked @diff='del'
- </p>
- -->
-
<p>This specification defines several message exchange patterns for
use with <emph>WSDL Version 2.0 Part 1: Core Language</emph> <bibref
ref='WSDL-PART1' />.</p>
! <div2 id="notation">
<head>Notational Conventions</head>
--- 138,146 ----
</p>
<p>This specification defines several message exchange patterns for
use with <emph>WSDL Version 2.0 Part 1: Core Language</emph> <bibref
ref='WSDL-PART1' />.</p>
! <div3 id="notation">
<head>Notational Conventions</head>
***************
*** 137,150 ****
this document are to be interpreted as described in RFC 2119
<bibref ref="RFC2119"/>.</p>
! </div2>
! </div1>
! <div1 id="fault-rules">
! <head>Fault Generation Rules</head>
! <p>WSDL patterns specify their fault generation model using standard
! rulesets to indicate where faults may occur. The two most common patterns
! for fault generation are defined here, and referenced by patterns later in
the document.</p>
--- 149,162 ----
this document are to be interpreted as described in RFC 2119
<bibref ref="RFC2119"/>.</p>
! </div3>
! </div2>
! <div2 id="fault-rules">
! <head>Fault Propagation Rules</head>
! <p>WSDL patterns specify their fault propagation model using standard
! rulesets to indicate where faults may occur. The most common patterns
! for fault propagation are defined here, and referenced by patterns later in
the document.</p>
***************
*** 152,156 ****
exchange.</p>
! <div2 id="fault-replacement">
<head>Fault Replaces Message</head>
--- 164,168 ----
exchange.</p>
! <div3 id="fault-replacement">
<head>Fault Replaces Message</head>
***************
*** 158,202 ****
message, which MUST have identical cardinality and direction. The fault
message MUST be delivered to the same target node as the message it
! replaces.</p>
! </div2>
! <div2 id="fault-trigger">
<head>Message Triggers Fault</head>
<p>Any message, including the first, MAY trigger a fault message in
! response. Each recipient MAY generate a fault message, and MUST generate no
! more than one fault for each triggering message. Each fault message has direction the reverse of its triggering
! message. The fault message MUST be delivered to the originator of the
! message which triggered it. If there is no path to this node, the fault
! MUST be discarded.</p>
! </div2>
! <div2 id="no-fault">
<head>No Faults</head>
! <p>No faults may be generated.</p>
! <ednote id="no-fault-ruleset">
! <name>Introduction of No Faults ruleset</name>
! <date>12 June 2003</date>
! <edtext>The No Faults ruleset has been introduced primarily to clarify the
! confusion otherwise introduced by applying the Fault Replaces Message
! ruleset to single-message patterns (which implicitly disallows faults).
! Some concern has been expressed that a no-fault ruleset could easily be
! abused.</edtext>
! </ednote>
</div2>
! </div1>
!
! <div1 id="patterns">
<head>Message Exchange Patterns</head>
<p>WSDL patterns are described in terms of the WSDL component model,
! specifically the Label and Fault Reference components. </p>
! <div2 id="in-only">
<head>In-Only</head>
<p>
--- 170,206 ----
message, which MUST have identical cardinality and direction. The fault
message MUST be delivered to the same target node as the message it
! replaces. If there is no path to this node, the fault MUST be discarded.
! </p>
! </div3>
! <div3 id="fault-trigger">
<head>Message Triggers Fault</head>
<p>Any message, including the first, MAY trigger a fault message in
! response. Each recipient MAY propagate a fault message, and MUST propagate no
! more than one fault for each triggering message. Each fault message has
! direction the reverse of its triggering message. The fault message MUST
! be delivered to the originator of the message which triggered it. If there
! is no path to this node, the fault MUST be discarded.
! </p>
! </div3>
! <div3 id="no-fault">
<head>No Faults</head>
! <p>No faults may be propagated.</p>
! </div3>
</div2>
! <div2 id="patterns">
<head>Message Exchange Patterns</head>
<p>WSDL patterns are described in terms of the WSDL component model,
! specifically the Message Label and Fault Reference components. </p>
! <div3 id="in-only">
<head>In-Only</head>
<p>
***************
*** 211,215 ****
<item>
<p>
! indicated by a Label component whose {label} is 'In' and
{direction} is 'in'
</p>
--- 215,219 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'In' and
{direction} is 'in'
</p>
***************
*** 229,242 ****
the value '&wsdl-ns;/in-only'.
</p>
! </div2>
! <div2 id="robust-in-only">
<head>Robust In-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
<olist>
! <item><p>message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'In' and {direction} is 'in'</p></item>
<item><p>received from some node N</p></item>
</ulist>
--- 233,246 ----
the value '&wsdl-ns;/in-only'.
</p>
! </div3>
! <div3 id="robust-in-only">
<head>Robust In-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
<olist>
! <item><p>A message:</p>
<ulist>
! <item><p>indicated by a Message Label component whose
! {message label} is 'In' and {direction} is 'in'</p></item>
<item><p>received from some node N</p></item>
</ulist>
***************
*** 246,252 ****
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/robust-in-only'.</p>
! </div2>
! <div2 id="in-out">
<head>In-Out</head>
<p>This pattern consists of exactly two messages, in order, as follows:</p>
--- 250,256 ----
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/robust-in-only'.</p>
! </div3>
! <div3 id="in-out">
<head>In-Out</head>
<p>This pattern consists of exactly two messages, in order, as follows:</p>
***************
*** 259,263 ****
<item>
<p>
! indicated by a Label component whose {label} is 'In' and {direction}
is 'in'
</p>
--- 263,267 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'In' and {direction}
is 'in'
</p>
***************
*** 277,281 ****
<item>
<p>
! indicated by a Label component whose {label} is 'Out' and {direction}
is 'out'
</p>
--- 281,285 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'Out' and {direction}
is 'out'
</p>
***************
*** 294,300 ****
the value '&wsdl-ns;/in-out'.
</p>
! </div2>
! <div2 id="in-opt-out">
<head>In-Optional-Out</head>
<p>This pattern consists of one or two messages, in order, as
--- 298,304 ----
the value '&wsdl-ns;/in-out'.
</p>
! </div3>
! <div3 id="in-opt-out">
<head>In-Optional-Out</head>
<p>This pattern consists of one or two messages, in order, as
***************
*** 303,308 ****
<item><p>A message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'In' and {direction} is 'in'</p></item>
<item><p>received from some node N</p></item>
</ulist>
--- 307,312 ----
<item><p>A message:</p>
<ulist>
! <item><p>indicated by a Message Label component whose
! {message label} is 'In' and {direction} is 'in'</p></item>
<item><p>received from some node N</p></item>
</ulist>
***************
*** 310,315 ****
<item><p>An optional message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to node N</p></item>
</ulist>
--- 314,319 ----
<item><p>An optional message:</p>
<ulist>
! <item><p>indicated by a Message Label component whose
! {message label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to node N</p></item>
</ulist>
***************
*** 319,325 ****
<p>An operation using this message exchange pattern has a {pattern} property
with the value '&wsdl-ns;/in-opt-out'.</p>
! </div2>
! <div2 id="out-only">
<head>Out-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
--- 323,329 ----
<p>An operation using this message exchange pattern has a {pattern} property
with the value '&wsdl-ns;/in-opt-out'.</p>
! </div3>
! <div3 id="out-only">
<head>Out-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
***************
*** 332,336 ****
<item>
<p>
! indicated by a Label component whose {label} is 'Out' and {direction}
is 'out'
</p>
--- 336,340 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'Out' and {direction}
is 'out'
</p>
***************
*** 349,355 ****
the value '&wsdl-ns;/out-only'.
</p>
! </div2>
! <div2 id="robust-out-only">
<head>Robust Out-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
--- 353,359 ----
the value '&wsdl-ns;/out-only'.
</p>
! </div3>
! <div3 id="robust-out-only">
<head>Robust Out-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
***************
*** 357,362 ****
<item><p>message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to some node N</p></item>
</ulist>
--- 361,366 ----
<item><p>message:</p>
<ulist>
! <item><p>indicated by a Message Label component whose
! {message label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to some node N</p></item>
</ulist>
***************
*** 366,372 ****
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/robust-out-only'.</p>
! </div2>
! <div2 id="out-in">
<head>Out-In</head>
<p>This pattern consists of exactly two messages, in order, as follows:</p>
--- 370,376 ----
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/robust-out-only'.</p>
! </div3>
! <div3 id="out-in">
<head>Out-In</head>
<p>This pattern consists of exactly two messages, in order, as follows:</p>
***************
*** 379,384 ****
<item>
<p>
! indicated by a Label component whose {label} is 'Out' and {direction}
! is 'out'
</p>
</item>
--- 383,388 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'Out' and {direction}
! is 'out'
</p>
</item>
***************
*** 397,401 ****
<item>
<p>
! indicated by a Label component whose {label} is 'In' and {direction}
is 'in'
</p>
--- 401,405 ----
<item>
<p>
! indicated by a Message Label component whose {message label} is 'In' and {direction}
is 'in'
</p>
***************
*** 414,420 ****
the value '&wsdl-ns;/out-in'.
</p>
! </div2>
! <div2 id="out-opt-in">
<head>Out-Optional-In</head>
<p>This pattern consists of one or two messages, in order, as
--- 418,424 ----
the value '&wsdl-ns;/out-in'.
</p>
! </div3>
! <div3 id="out-opt-in">
<head>Out-Optional-In</head>
<p>This pattern consists of one or two messages, in order, as
***************
*** 423,428 ****
<item><p>A message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to some node N</p></item>
</ulist>
--- 427,432 ----
<item><p>A message:</p>
<ulist>
! <item><p>indicated by a Message Label component whose
! {message label} is 'Out' and {direction} is 'out'</p></item>
<item><p>sent to some node N</p></item>
</ulist>
***************
*** 430,435 ****
<item><p>An optional message:</p>
<ulist>
! <item><p>indicated by a Label component whose
! {label} is 'In' and {direction} is 'in'</p></item>
<item><p>sent from node N</p></item>
</ulist>
--- 434,439 ----
<item><p>An optional message:</p>
<ulist>
! <item><p>indicated by a MessageLabel component whose
! {message label} is 'In' and {direction} is 'in'</p></item>
<item><p>sent from node N</p></item>
</ulist>
***************
*** 439,445 ****
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/out-opt-in'.</p>
</div2>
! </div1>
<div1 id='References'>
--- 443,641 ----
<p>An operation using this message exchange pattern has a {pattern} property with
the value '&wsdl-ns;/out-opt-in'.</p>
+ </div3>
+
+ </div2><!-- message exchange patterns -->
+
+ </div1><!-- section on meps -->
+
+ <div1 id="features">
+ <head>Predefined Features</head>
+
+ <p>
+ Web Services Description Language (WSDL) features (hereafter
+ 'features') define properties or behaviors in the scope of a particular
+ message exchange. Scoping rules are outlined in [REFERENCE]. A property
+ exposed by a feature is visible to all participants in an exchange. Bindings
+ may have particular preferences for how this information is communicated:
+ WSDL features correspond closely with (but are not identical to) SOAP 1.2
+ features, as implemented in modules.
+ </p>
+
+ <p>
+ Features may change the behavior described for other components. In particular,
+ note that a feature (or any other extension) may change the semantics of a message
+ exchange pattern in some fashion, such as nominating an address for the delivery
+ of faults, etc.
+ </p>
+
+ <p>
+ The Web Services Description Working Group provides the following descriptions
+ as models of feature descriptions for WSDL, and encourages implementors to support
+ these features.
+ </p>
+
+ <div2 id="app-data">
+ <head>Application Data Feature</head>
+
+ <div3 id="adf-name">
+ <head>Name</head>
+
+ <p>
+ This feature is identified with the URI
+ http://www.w3.org/@@@@/@@/features/AD
+ </p>
+
+ </div3>
+
+ <div3 id="adf-operation">
+ <head>Operation</head>
+
+ <p>
+ This feature exists in order to enable the description of
+ application-defined additional data declarations outside of the normal
+ data channel (e.g. the SOAP body). The senders takes the value of the
+ property http://www.w3.org/@@@@/@@/features/AD/data, which is defined
+ below, and passes it to the receiver in a manner to be defined by the
+ particular bindings/modules implementing this specification.
+ </p>
+
+ </div3>
+
+ <div3 id="adf-data-prop">
+ <head>AD/data Property</head>
+
+ <p>
+ This property is identified with the URI
+ http://www.w3.org/@@@@/@@/features/AD/data.
+ </p>
+
+ <div4 id="adf-dp-desc">
+ <head>Description</head>
+
+ <p>
+ The data property consists of a sequence of elements, each of which
+ represents an individual piece of application data. Implementations of
+ this feature must ensure that the runtime value of this property is
+ correctly transferred from the sender to the receiver.
+ </p>
+
+ <p>
+ Here is an example of using the data property in a WSDL:
+ </p>
+
+ <eg xml:space="preserve">
+ <![CDATA[
+ <types>
+ <schema targetNamespace="http://foo"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ xmlns="http://www.w3.org/2001/XMLSchema">
+ <import namespace="http://www.w3.org/2003/05/soap-envelope"/>
+ <!-- Define the data type we'll use later -->
+ <complexType name="myDataType">
+ <sequence>
+
+ <!-- These elements are our data -->
+ <element name="isGoldClubMember">
+ <complexType>
+ <simpleContent>
+ <extension base="xs:boolean"/>
+ <attribute xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
+ ref="soap:mustUnderstand"
+ fixed="true"/>
+ </simpleContent>
+ </complexType>
+ </element>
+
+ <element name="promotionalCode"
+ type="xs:string"
+ minOccurs="0"/>
+
+ </sequence>
+ </complexType>
+ </schema>
+ </types>
+ <interface name="customerService">
+ <operation name="reserveCar">
+ <input element="myNS:reserveCarRequest">
+ <property uri="http://www.w3.org/@@@@/@@/features/AD/data">
+ <constraint xmlns:foo="http://foo">
+ foo:myDataType
+ </constraint>
+ </property>
+ </input>
+ </operation>
+ </interface>
+ ]]>
+ </eg>
+
+ <p>
+ This example defines two pieces of application data, and associates them
+ with the input message of the "reserveCar" operation. Notice that the
+ "promotionalCode" element is optional (minOccurs="0"), and that the
+ "isGoldClubMember" element has fixed the value of the SOAP 1.2
+ "mustUnderstand" element to "true".
+ </p>
+
+ </div4>
+ </div3>
+
+ <div3 id="adf-module">
+ <head>Application Data Module</head>
+
+ <p>
+ This module is identified with the URI
+ http://www.w3.org/@@@@/@@/modules/AD
+ </p>
+
+ <div4 id="adf-mod-impl">
+ <head>Features Implemented</head>
+
+ <p>
+ This module implements the feature
+ http://www.w3.org/@@@@/@@/features/AD.
+ </p>
+
+ </div4>
+
+ <div4 id="adf-mod-op">
+ <head>Operation</head>
+
+ <p>
+ This module specifies how to transmit "out of band" application data, as
+ defined in the Application Data feature, as SOAP headers.
+ </p>
+
+ <p>
+ As a SOAP sender, if the property
+ http://www.w3.org/@@@@/@@/features/AD/data has a value then each of the
+ top-level child element information items in the value SHOULD [ed:
+ MUST?] be turned into a SOAP header. The elements are serialized
+ according to their schemas, which might include the SOAP
+ "mustUnderstand" or "role" attributes, which will have the usual meaning
+ in the resultant headers. SOAP senders SHOULD also add an additional
+ header, with namespace "http://www.w3.org/@@@@/@@/modules/AD" and local
+ name "dataHeaders" - this header contains a list of element QNames, one
+ for each application data header created in the first step.
+ </p>
+
+ <p>
+ It is the responsibility of the receiving node to determine which, if
+ any, SOAP headers will populate the
+ http://www.w3.org/@@@@/@@/features/AD/data property. Typically this
+ will be accomplished via using some metadata, such as an understanding
+ of a constraint specified in WSDL, or out-of-band agreements. If the
+ "dataHeaders" SOAP header (described above) is present, the QNames
+ inside that header indicate which other headers are application data.
+ The contents of each SOAP header identified as application data will be
+ placed in a child element of the data property [ed: should we define a
+ particular "wrapper" element here as the top level one?].
+ </p>
+
+ </div4>
+ </div3>
+
</div2>
! </div1> <!-- features -->
<div1 id='References'>
***************
*** 523,526 ****
--- 719,755 ----
</tr>
<tr>
+ <td>20040713</td>
+ <td>aal</td>
+ <td>address issues 233 & 112 all at once, by increasing level
+ of all divs, adding new intro
+ div, adding new div to contain features, renaming spec. Lotsa
+ changes, what fun.</td>
+ </tr>
+ <tr>
+ <td>20040713</td>
+ <td>aal</td>
+ <td>s/Label/Message Label/g and s/{label}/{message label}/g.
+ issue 230.</td>
+ </tr>
+ <tr>
+ <td>20040713</td>
+ <td>aal</td>
+ <td>replace "fault generation" with "fault propagation" (in almost
+ all cases; one case of "generate" remains to indicate that it ends
+ an exchange). issue 234.</td>
+ </tr>
+ <tr>
+ <td>20040713</td>
+ <td>aal</td>
+ <td>add language to introduction describing relationship between
+ these MEPs and the MEPs defined by SOAP 1.2 (issue 232). This
+ replaces the language found two items down (issue 191).</td>
+ </tr>
+ <tr>
+ <td>20040713</td>
+ <td>aal</td>
+ <td>add (hereafter, simply 'patterns') to intro (issue 231).</td>
+ </tr>
+ <tr>
<td>20040610</td>
<td>aal</td>
Received on Tuesday, 13 July 2004 14:04:09 UTC