2004/ws/addressing ws-addr-core.xml,1.91,1.92

Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv20933

Modified Files:
	ws-addr-core.xml 
Log Message:
Added explanation of cardinality notation

Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.91
retrieving revision 1.92
diff -C2 -d -r1.91 -r1.92
*** ws-addr-core.xml	25 May 2005 21:40:40 -0000	1.91
--- ws-addr-core.xml	2 Jun 2005 18:07:42 -0000	1.92
***************
*** 69,74 ****
                  independent of the underlying transport.</p>
              <p>Both of these constructs are designed to be extensible and re-usable so that other
!                 specifications can build on and leverage endpoint references and message information
!                 headers.</p>
              <p>The following example illustrates the use of these mechanisms in a SOAP 1.2 message
                  being sent from http://example.com/business/client1 to
--- 69,74 ----
                  independent of the underlying transport.</p>
              <p>Both of these constructs are designed to be extensible and re-usable so that other
!                 specifications can build on and leverage endpoint references and message addressing
!                 properties.</p>
              <p>The following example illustrates the use of these mechanisms in a SOAP 1.2 message
                  being sent from http://example.com/business/client1 to
***************
*** 96,100 ****
                      mechanisms defined in the specification are used. The body is represented by
                      lines (10) to (12).</p>
!                 <p>Lines (03) to (08) contain the message information header blocks. Specifically,
                      line (02) specifies the identifier for this message and lines (04) to (06)
                      specify the endpoint to which replies to this message should be sent as an
--- 96,100 ----
                      mechanisms defined in the specification are used. The body is represented by
                      lines (10) to (12).</p>
!                 <p>Lines (03) to (08) contain the message addressing header blocks. Specifically,
                      line (02) specifies the identifier for this message and lines (04) to (06)
                      specify the endpoint to which replies to this message should be sent as an
***************
*** 120,123 ****
--- 120,130 ----
                      indicates the presence of an attribute wildcard
                      (&lt;xs:anyAttribute/&gt;).</p>
+                 <p>When defining the cardinality of endpoint reference properties and 
+                     message addressing properties, this
+                     specification uses the following notation: (<i>n</i>..<i>m</i>), where <i>n</i>
+                     is the minimum allowed number of ocurrances of the property and <i>m</i> is the maximum
+                     allowed number of occurances. When <i>n</i> has the same value as <i>m</i> then exactly
+                     that number of ocurrances of the property must be present in the associated
+                     endpoint reference or message.</p>
              </div2>
              <div2 id="namespaces">
***************
*** 393,398 ****
              <note>
                  <p> The Working Group requests feedback regarding the mechanism for and description
!                     of Message Addressing Property extensibility /beyond the MEPs currently
!                     described in the WSDL specifications/, along with use cases that illustrate how
                      referencing specifications and other users of Addressing intend to extend them.
                      Although the Working Group has resolved upon a <loc
--- 400,405 ----
              <note>
                  <p> The Working Group requests feedback regarding the mechanism for and description
!                     of Message Addressing Property extensibility beyond the MEPs currently
!                     described in the WSDL specifications, along with use cases that illustrate how
                      referencing specifications and other users of Addressing intend to extend them.
                      Although the Working Group has resolved upon a <loc
***************
*** 539,548 ****
                  DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
                  endpoint. To allow these "anonymous" endpoints to send and receive messages,
!                 WS-Addressing defines the following well-known URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: <attval>&nsuri;/address/anonymous</attval>
!             </p>
!             <p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
                  address MUST provide some out-of-band mechanism for delivering replies or faults
                  (e.g. returning the reply on the same transport connection).</p>
              </div2>
              
--- 546,557 ----
                  DHCP, firewalls), many deployments cannot assign a meaningful global IRI to a given
                  endpoint. To allow these "anonymous" endpoints to send and receive messages,
!                 WS-Addressing defines the following standard URI for use by endpoints that cannot
!                 have a stable, resolvable IRI: <attval>&nsuri;/address/anonymous</attval>. Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
                  address MUST provide some out-of-band mechanism for delivering replies or faults
                  (e.g. returning the reply on the same transport connection).</p>
+                 <p>A binding of WS_Addressing message addressing properties MUST reflect the
+                     property cardinality shown above. &wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]
+                     defines such a binding for the SOAP 
+                     [<bibref ref="SOAP12-PART1"/>, <bibref ref="SOAP11"/>] protocol.</p>
              </div2>
              

Received on Thursday, 2 June 2005 18:07:48 UTC