- From: Jean-Jacques Moreau via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 01 Jun 2005 05:59:32 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv23378
Modified Files:
wsdl20.xml
Log Message:
LC82: removed ONMR section (transfer to primer).
LC71: added default value for pattern attribute (".../inout").
Index: wsdl20.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20.xml,v
retrieving revision 1.272
retrieving revision 1.273
diff -C2 -d -r1.272 -r1.273
*** wsdl20.xml 26 May 2005 13:52:54 -0000 1.272
--- wsdl20.xml 1 Jun 2005 05:59:29 -0000 1.273
***************
*** 3466,3470 ****
<tr>
<td>{message exchange pattern}</td>
! <td>The actual value of the <att>pattern</att> &AII;.</td>
</tr>
<tr>
--- 3466,3471 ----
<tr>
<td>{message exchange pattern}</td>
! <td>The actual value of the <att>pattern</att> &AII;;
! otherwise '&wsdl-mep-in-out;'.</td>
</tr>
<tr>
***************
*** 7606,7686 ****
</z:notation>
-
- <div4 id="Service_OperationName">
- <head>Operation Name Mapping (non-normative)</head>
- <note>
- <p>This section is best-practice and hence non-normative.</p>
- </note>
-
- <p>It is generally desirable that, when a message recipient receives a message,
- it knows how to handle the message. In WSDL 2.0 terms, this means being
- able to map back the message to a single Interface Operation. However,
- this is NOT always possible. There are cases when multiple Interface Operations
- could correspond to the same received message. This happens either when:
- </p>
-
- <ulist>
- <item><p>the {message content model} property of any of these
- Interface Message Reference components (see below) has a value of “#any”; or
- </p></item>
-
- <item><p>more than one of these Interface Message Reference components (see below)
- has a value of “#none”; or
- </p></item>
-
- <item><p>the qualified names of the global element declarations specified
- by the values of the {element declaration} properties of these Interface Message Reference
- components (see below) are NOT unique when considered together.
- </p></item>
- </ulist>
-
- <p>The Interface Message Reference components above are defined as follows.
- First, consider the Interface component specified in the {interface}
- property of a Service component. Second, consider all Interface Operation
- components specified in the {interface operations} property of that Interface
- component and the Interface component it directly or indirectly extends.
- Third, consider all Interface Message Reference components specified
- in the {interface message references} properties of said Interface Operation
- components. Fourth, consider the Interface Message Reference components that
- have the same value for their {direction} property (i.e., either the token
- <emph>in</emph> or the token <emph>out</emph>). These are the Interface Message Reference
- components considered above.</p>
-
- <p>If any of the three cases above arise, then one of the following two
- alternatives can be used. Note these alternatives are in no way mandated by
- this specification and are considered best practice only.</p>
-
- <ulist>
- <item><p><b>Feature</b>.
- The {features} property of the Service or Interface components
- contains a Feature component, having a {required} property with
- a value of <emph>true</emph>. 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 name of the
- Interface Operation component that is intended to be associated
- with the received message.
- </p>
- </item>
- <item><p><b>Extension</b>.
- The &EII; for the Interface component
- contains an extension element (i.e., an element that is not
- in the &wsdl-ns; namespace), having a wsdl:required &AII; with
- a value of <attval>true</attval>. 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 name of the Interface Operation component that is intended
- to be associated with the received message.
- </p>
- </item>
- </ulist>
-
- <p>The WS-Addressing <bibref ref="ws-addr-core"/> specification allready
- provides a disambiguation mechanism.
- It defines an [action] property whose value is embedded in each message,
- and that can be used to associate the message with a particular operation.
- </p>
-
- </div4>
</div3>
--- 7607,7611 ----
***************
*** 11091,11094 ****
--- 11016,11033 ----
<tr>
+ <td>20050531</td>
+ <td>JJM</td>
+ <td><loc href="http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC82">LC82</loc>:
+ removed ONMR section (transfer to primer).</td>
+ </tr>
+
+ <tr>
+ <td>20050531</td>
+ <td>JJM</td>
+ <td><loc href="http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC71">LC71</loc>:
+ added default value for pattern attribute (".../inout").</td>
+ </tr>
+
+ <tr>
<td>20050526</td>
<td>AGR</td>
Received on Wednesday, 1 June 2005 05:59:34 UTC