2002/ws/desc/wsdl20 wsdl20.xml,1.251,1.252

Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv31779

Modified Files:
	wsdl20.xml 
Log Message:
Rewrote the "Operation Name Mapping Requirement" section to make it best practice.

Index: wsdl20.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20.xml,v
retrieving revision 1.251
retrieving revision 1.252
diff -C2 -d -r1.251 -r1.252
*** wsdl20.xml	4 May 2005 09:58:03 -0000	1.251
--- wsdl20.xml	4 May 2005 10:45:36 -0000	1.252
***************
*** 6341,6353 ****
        description container, the {name} property MUST be unique. </p>
  
- 	<p>Additionally, the Interface component that is the value of
-         the {interface} property of a Service component MUST satisfy the Operation
-         Name Mapping requirement, as defined below. This requirement is intended
- 	to ensure that a received message can be uniquely mapped to a
- 	corresponding wsdl:operation. 
- 	</p>
- 
          <div4 id="Service_OperationName">
!           <head>Operation Name Mapping Requirement (non-normative)</head>
  
            <note>
--- 6341,6346 ----
        description container, the {name} property MUST be unique. </p>
  
          <div4 id="Service_OperationName">
!           <head>Operation Name Mapping (non-normative)</head>
  
            <note>
***************
*** 6355,6389 ****
            </note>
            
!           <p>Consider the Interface component specified in the {interface}
!           property of a Service component. Further, consider all Interface Operation
            components specified in the {interface operations} property of that Interface
            component and the Interface component it directly or indirectly extends.  
!           Further, consider all Interface Message Reference components specified
            in the {interface message references} properties of said Interface Operation
!           components.  Further, consider all said 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>).  If the {message content
!           model} property of any of these Interface Message Reference components has a value
! 	  of &ldquo;#any&rdquo;, or if more than one of these Interface Message Reference
!           components has a value of &ldquo;#none&rdquo;, or if the qualified names of
!           the global element declarations specified by the values of the {element declaration}
! 	  properties of these Interface Message Reference components are not unique
! 	  when considered together, and the Operation Name Mapping Requirement needs to be engaged,
! 	  then either one of the following two conditions applies: 
! 	  </p>
! 	  <olist>
! 	    <item><p>the {features} property of the Service or Interface components
                contains a Feature component, having a {required} property with
! 	      a value of <emph>true</emph>, that 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; or
  	      </p>
  	    </item>
! 	    <item><p>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>, that unambiguously identifies
  	    the mechanism that a message sender is required to support in
  	    order to enable the message recipient to unambiguously determine
--- 6348,6405 ----
            </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 &ldquo;#any&rdquo;; or
!           </p></item>
!           
!           <item><p>more than one of these Interface Message Reference components (see below)
!           has a value of &ldquo;#none&rdquo;; 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
***************
*** 6392,6401 ****
  	      </p>
  	    </item>
! 	  </olist>
  	  
! 	  <p>WS-Addressing <bibref ref="ws-addr-core"/> provides a mechanism for
!           implementing the Operation Name Mapping Requirment.
! 	  The WS-Addressing [action] property embeds a value in each message that
! 	  can be used to associate the message with a particular operation.
  	  </p>
  
--- 6408,6417 ----
  	      </p>
  	    </item>
! 	  </ulist>
  	  
! 	  <p>The WS-Addressing <bibref ref="ws-addr-core"/> speficiation 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>
  
***************
*** 9408,9412 ****
        		This can be achieved by using one of the following alternatives:
        	</p>
!       	<olist>
        		<item><p>
        		<b>Single document</b>.
--- 9424,9428 ----
        		This can be achieved by using one of the following alternatives:
        	</p>
!       	<ulist>
        		<item><p>
        		<b>Single document</b>.
***************
*** 9434,9438 ****
        		The definition of such an extension is outside the scope of this specification.
        		</p></item>
!       	</olist>
        </div2>
  
--- 9450,9454 ----
        		The definition of such an extension is outside the scope of this specification.
        		</p></item>
!       	</ulist>
        </div2>
  
***************
*** 9660,9663 ****
--- 9676,9686 ----
      	<td>20050504</td>
      	<td>JJM</td>
+     	<td>Rewrote the "Operation Name Mapping Requirement" section to make
+     	it best practice.</td>
+     </tr>
+     
+     <tr>
+     	<td>20050504</td>
+     	<td>JJM</td>
      	<td>Rewrote the "Single Interface" section, as per editorial AI dated 2005-01-19.</td>
      </tr>

Received on Wednesday, 4 May 2005 10:45:43 UTC