- From: Tony Rogers via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 10 Jan 2007 11:26:35 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv15667
Modified Files:
ws-addr-wsdl.xml
Log Message:
Changed the namespace and namespace prefix for this document
Corrected introduction and conformance section
Index: ws-addr-wsdl.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-wsdl.xml,v
retrieving revision 1.107
retrieving revision 1.108
diff -C 2 -d -r1.107 -r1.108
*** ws-addr-wsdl.xml 5 Jan 2007 14:20:35 -0000 1.107
--- ws-addr-wsdl.xml 10 Jan 2007 11:26:32 -0000 1.108
***************
*** 50,54 ****
<p>Web Services Addressing provides transport-neutral mechanisms to address Web services
and messages. &wsa-wsdl.title; (this document) defines how the abstract
! properties defined in &wsa-core.title; are described using WSDL.</p>
<p>The classes of products for which this specification is designed to be relevant
include WSDL and WS-Addressing EPR consumers.</p>
--- 50,55 ----
<p>Web Services Addressing provides transport-neutral mechanisms to address Web services
and messages. &wsa-wsdl.title; (this document) defines how the abstract
! properties defined in &wsa-core.title; are described using WSDL, and how
! WS-Policy can be used to indicate the support of WS-Addressing by a Web service.</p>
<p>The classes of products for which this specification is designed to be relevant
include WSDL and WS-Addressing EPR consumers.</p>
***************
*** 114,118 ****
</tr>
<tr>
! <td>wsaw</td>
<td> &wsa-wsdl-nsuri; </td>
</tr>
--- 115,119 ----
</tr>
<tr>
! <td>wsam</td>
<td> &wsa-wsdl-nsuri; </td>
</tr>
***************
*** 142,145 ****
--- 143,150 ----
<td>http://schemas.xmlsoap.org/wsdl/soap/</td>
</tr>
+ <tr>
+ <td>wsp</td>
+ <td>http://www.w3.org/2006/07/ws-policy</td>
+ </tr>
</tbody>
</table>
***************
*** 173,177 ****
<glist>
<gitem>
! <label> wsaw:InterfaceName (0..1)</label>
<def>
<p>A QName identifying a description of the sequences of messages that a
--- 178,182 ----
<glist>
<gitem>
! <label> wsam:InterfaceName (0..1)</label>
<def>
<p>A QName identifying a description of the sequences of messages that a
***************
*** 183,187 ****
</gitem>
<gitem>
! <label> wsaw:ServiceName (0..1)</label>
<def>
<p>A QName that identifies the set of endpoints at which a particular
--- 188,192 ----
</gitem>
<gitem>
! <label> wsam:ServiceName (0..1)</label>
<def>
<p>A QName that identifies the set of endpoints at which a particular
***************
*** 192,196 ****
</gitem>
<gitem>
! <label> wsaw:ServiceName/@EndpointName (0..1)</label>
<def>
<p>An NCName that identifies one endpoint amongst the set identified by
--- 197,201 ----
</gitem>
<gitem>
! <label> wsam:ServiceName/@EndpointName (0..1)</label>
<def>
<p>An NCName that identifies one endpoint amongst the set identified by
***************
*** 217,221 ****
xmlns:wsdli="&wsdl20nsuri;-instance"
wsdli:wsdlLocation="http://greath.example.com/2004/wsdl/resSvc http://greath.example.com/2004/reservation.wsdl">
! <wsaw:InterfaceName>ghns:reservationInterface</wsaw:InterfaceName>
</wsa:Metadata>
</wsa:EndpointReference></eg>
--- 222,226 ----
xmlns:wsdli="&wsdl20nsuri;-instance"
wsdli:wsdlLocation="http://greath.example.com/2004/wsdl/resSvc http://greath.example.com/2004/reservation.wsdl">
! <wsam:InterfaceName>ghns:reservationInterface</wsam:InterfaceName>
</wsa:Metadata>
</wsa:EndpointReference></eg>
***************
*** 304,308 ****
<div2 id="uaee">
<head><el>UsingAddressing</el> Extension Element</head>
! <p> WS-Addressing defines an empty global element, wsaw:UsingAddressing, that can be
used to indicate that an endpoint conforms to the WS-Addressing specification.
The wsdl:required attribute MAY be used to indicate whether WS-Addressing
--- 309,313 ----
<div2 id="uaee">
<head><el>UsingAddressing</el> Extension Element</head>
! <p> WS-Addressing defines an empty global element, wsam:UsingAddressing, that can be
used to indicate that an endpoint conforms to the WS-Addressing specification.
The wsdl:required attribute MAY be used to indicate whether WS-Addressing
***************
*** 312,316 ****
how the use of addressing is indicated in the WSDL. </p>
<table border="1" id="mappresence">
! <caption>MAPs Present in output message when wsaw:UsingAddressing is present</caption>
<thead>
<tr>
--- 317,321 ----
how the use of addressing is indicated in the WSDL. </p>
<table border="1" id="mappresence">
! <caption>MAPs Present in output message when wsam:UsingAddressing is present</caption>
<thead>
<tr>
***************
*** 340,361 ****
&wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]), and this specification,
and MUST follow all applicable WS-Addressing normative requirements. </p>
! <p>The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding
! element. Alternatively, the wsaw:UsingAddressing element MAY instead be included
as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to
indicate compliance with WS-Addressing for a specific endpoint only.</p>
! <p>The inclusion of the wsaw:UsingAddressing element indicates that the applicable
WS-Addressing specifications are supported and allows use of anonymous or
non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP
! binding, the wsaw:UsingAddressing marker identifies the use of Web Services
Addressing 1.0 bound to SOAP as defined by &wsa-soap.title;[<bibref
ref="WSADDR-SOAP"/>].The presence of this element can extend the semantics
of the endpoint's WSDL binding. </p>
<example>
! <head>Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 2.0</head>
<eg xml:space="preserve"><binding name="reservationSOAPBinding"
interface="tns:reservationInterface"
type="&wsdl20nsuri;/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
! <wsaw:UsingAddressing wsdl:required="true" />
<operation ref="tns:opCheckAvailability"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
--- 345,366 ----
&wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]), and this specification,
and MUST follow all applicable WS-Addressing normative requirements. </p>
! <p>The wsam:UsingAddressing element SHOULD appear as a child of the wsdl:binding
! element. Alternatively, the wsam:UsingAddressing element MAY instead be included
as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to
indicate compliance with WS-Addressing for a specific endpoint only.</p>
! <p>The inclusion of the wsam:UsingAddressing element indicates that the applicable
WS-Addressing specifications are supported and allows use of anonymous or
non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP
! binding, the wsam:UsingAddressing marker identifies the use of Web Services
Addressing 1.0 bound to SOAP as defined by &wsa-soap.title;[<bibref
ref="WSADDR-SOAP"/>].The presence of this element can extend the semantics
of the endpoint's WSDL binding. </p>
<example>
! <head>Indicating use of WS-Addressing using wsam:UsingAddressing in WSDL 2.0</head>
<eg xml:space="preserve"><binding name="reservationSOAPBinding"
interface="tns:reservationInterface"
type="&wsdl20nsuri;/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
! <wsam:UsingAddressing wsdl:required="true" />
<operation ref="tns:opCheckAvailability"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
***************
*** 364,372 ****
</example>
<example>
! <head>Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 1.1</head>
<eg xml:space="preserve"><binding name="reservationSOAPBinding"
type="tns:reservationInterface">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
! <wsaw:UsingAddressing wsdl:required="true" />
<operation name="opCheckAvailability">
<soap:operation soapaction="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability" />
--- 369,377 ----
</example>
<example>
! <head>Indicating use of WS-Addressing using wsam:UsingAddressing in WSDL 1.1</head>
<eg xml:space="preserve"><binding name="reservationSOAPBinding"
type="tns:reservationInterface">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
! <wsam:UsingAddressing wsdl:required="true" />
<operation name="opCheckAvailability">
<soap:operation soapaction="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability" />
***************
*** 404,408 ****
<tr>
<td>{addressing}</td>
! <td> If a <el>wsaw:UsingAddresing</el> extension element is present: <ulist>
<item>
<p>if a <att>wsdl:required</att> &AII; is present
--- 409,413 ----
<tr>
<td>{addressing}</td>
! <td> If a <el>wsam:UsingAddresing</el> extension element is present: <ulist>
<item>
<p>if a <att>wsdl:required</att> &AII; is present
***************
*** 424,436 ****
<div2 id="wspolicyassertions">
<head>WS-Policy Assertions</head>
! <p>Another mechanism for indicating that a binding or endpoint <ednote>
<edtext>open issue on policy attachment options</edtext>
! </ednote> conforms to the WS-Addressing specification is through the use of the
Web Services Policy - Framework [<bibref ref="WSPolicy"/>] and Web Services
Policy - Attachment [<bibref ref="WSPolicyAttachment"/>] specifications. This
! specification defines the following three policy assertions.</p>
<div3 id="wspolicyaddressing">
<head>Addressing Assertion</head>
! <p>The wsaw:Addressing policy assertion is a nested policy container assertion.
The meaning of this assertion when present in a policy alternative is that
WS-Addressing is required to communicate with the subject. In order to
--- 429,445 ----
<div2 id="wspolicyassertions">
<head>WS-Policy Assertions</head>
! <ednote>
<edtext>open issue on policy attachment options</edtext>
! </ednote>
! <p>Another mechanism for indicating that a binding or endpoint conforms to the WS-Addressing specification is through the use of the
Web Services Policy - Framework [<bibref ref="WSPolicy"/>] and Web Services
Policy - Attachment [<bibref ref="WSPolicyAttachment"/>] specifications. This
! specification defines three policy assertions.</p>
! <p>For WSDL 1.1, these assertions may be attached to <code>wsdl11:port</code> or
! <code>wsdl11:binding</code>. For WSDL 2.0, they may be attached to
! <code>wsdl20:endpoint</code> or <code>wsdl20:binding</code>.</p>
<div3 id="wspolicyaddressing">
<head>Addressing Assertion</head>
! <p>The wsam:Addressing policy assertion is a nested policy container assertion.
The meaning of this assertion when present in a policy alternative is that
WS-Addressing is required to communicate with the subject. In order to
***************
*** 442,452 ****
<div3 id="wspolicyanonresponses">
<head>AnonymousResponses Assertion</head>
! <p>The wsaw:AnonymousResponses element MAY be used as a policy assertion nested
! within the wsaw:Addressing assertion in accordance with the rules laid down
by WS-Policy Framework 1.5 section 4.3.2. The appearance of this element
within a policy alternative indicates that the endpoint will accept request
messages with response endpoint EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of
! [address]. The absence of the wsaw:AnonymousResponses policy assertion
within a policy alternative does <b>not</b> indicate that the endpoint will
not accept request messages with response endpoint EPRs that contain the
--- 451,461 ----
<div3 id="wspolicyanonresponses">
<head>AnonymousResponses Assertion</head>
! <p>The wsam:AnonymousResponses element MAY be used as a policy assertion nested
! within the wsam:Addressing assertion in accordance with the rules laid down
by WS-Policy Framework 1.5 section 4.3.2. The appearance of this element
within a policy alternative indicates that the endpoint will accept request
messages with response endpoint EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of
! [address]. The absence of the wsam:AnonymousResponses policy assertion
within a policy alternative does <b>not</b> indicate that the endpoint will
not accept request messages with response endpoint EPRs that contain the
***************
*** 456,460 ****
<div3 id="wspolicynonanonresponses">
<head>NonAnonymousResponses Assertion</head>
! <p>The wsaw:NonAnonymousResponses element MAY be used as a policy assertion
nested within the Addressing assertion in accordance with the rules laid
down by WS-Policy Framework 1.5 section 4.3.2. The appearance of this
--- 465,469 ----
<div3 id="wspolicynonanonresponses">
<head>NonAnonymousResponses Assertion</head>
! <p>The wsam:NonAnonymousResponses element MAY be used as a policy assertion
nested within the Addressing assertion in accordance with the rules laid
down by WS-Policy Framework 1.5 section 4.3.2. The appearance of this
***************
*** 466,482 ****
like. A receiver can still reject a request that contains an address that it
doesn't understand or that requires a binding it doesn't support. As with
! the other assertions, the absence of the wsaw:NonAnonymousResponses policy
assertion within a policy alternative does <b>not</b> indicate that the
endpoint will not accept request messages with response endpoint EPRs that
contain something other than the anonymous URI address. </p>
!
! <p>NOTE: If both AnonymousResponses and NonAnonymousResponses are supported and the
! intention is to allow either to be used care should be taken to ensure there is
! an alternative which includes just AnonymousResponses as a nested assertion and
! an alternative with just NonAnonymousResponses as a nested assertion so that a
! subject which supports only one will have a compatible policy [<bibref
! ref="WSPolicyPrimer"/> section 3.4].</p>
! <p> Also, given that the lack of either of these assertions (AnonymousResponses and
! NonAnonymousResponses) does not indicate lack of support, it is suggested that a
subject that does not have a strict compatibility requirement that an
interacting subject understands or is concerned with these assertions provides
--- 475,494 ----
like. A receiver can still reject a request that contains an address that it
doesn't understand or that requires a binding it doesn't support. As with
! the other assertions, the absence of the wsam:NonAnonymousResponses policy
assertion within a policy alternative does <b>not</b> indicate that the
endpoint will not accept request messages with response endpoint EPRs that
contain something other than the anonymous URI address. </p>
! </div3>
! <div3>
! <head>Using both AnonymousResponses and NonAnonymousResponses</head>
! <p>If both AnonymousResponses and NonAnonymousResponses are supported, and the
! intention is to allow either to be used, care should be taken to ensure that
! there are alternatives such that a subject which supports only one will have
! a compatible policy [<bibref ref="WSPolicyPrimer"/> section 3.4]. There
! should be at least an alternative which includes just AnonymousResponses as
! a nested assertion and an alternative with just NonAnonymousResponses as a
! nested assertion.</p>
! <p>Note also that the lack of either of these assertions (AnonymousResponses and
! NonAnonymousResponses) does not indicate lack of support. So it is suggested that a
subject that does not have a strict compatibility requirement that an
interacting subject understands or is concerned with these assertions provides
***************
*** 488,494 ****
<head>Subject supports WS-Addressing, no statement on supported response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsaw:Addressing wsp:Optional="true">
! <wsp:Policy></wsp:Policy>
! </wsaw:Addressing>
</wsp:Policy></eg>
</example>
--- 500,506 ----
<head>Subject supports WS-Addressing, no statement on supported response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsam:Addressing wsp:Optional="true">
! <wsp:Policy/>
! </wsam:Addressing>
</wsp:Policy></eg>
</example>
***************
*** 496,502 ****
<head>Subject requires WS-Addressing, no statement on supported response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsaw:Addressing>
! <wsp:Policy></wsp:Policy>
! </wsaw:Addressing>
</wsp:Policy></eg>
</example>
--- 508,514 ----
<head>Subject requires WS-Addressing, no statement on supported response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsam:Addressing>
! <wsp:Policy/>
! </wsam:Addressing>
</wsp:Policy></eg>
</example>
***************
*** 504,513 ****
<head>Subject supports WS-Addressing, explicitly (and optionally) supports anonymous and non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsaw:Addressing wsp:Optional="true">
<wsp:Policy>
! <wsaw:AnonymousResponses wsp:Optional="true"/>
! <wsaw:NonAnonymousResponses wsp:Optional="true"/>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:Policy></eg>
</example>
--- 516,525 ----
<head>Subject supports WS-Addressing, explicitly (and optionally) supports anonymous and non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsam:Addressing wsp:Optional="true">
<wsp:Policy>
! <wsam:AnonymousResponses wsp:Optional="true"/>
! <wsam:NonAnonymousResponses wsp:Optional="true"/>
</wsp:Policy>
! </wsam:Addressing>
</wsp:Policy></eg>
</example>
***************
*** 515,526 ****
<head>Subject requires WS-Addressing, requires explicit support of anonymous or non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
! <wsaw:AnonymousResponses wsp:Optional="true"/>
! <wsaw:NonAnonymousResponses wsp:Optional="true"/>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:Policy></eg>
</example>
--- 527,538 ----
<head>Subject requires WS-Addressing, requires explicit support of anonymous or non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
! <wsam:AnonymousResponses wsp:Optional="true"/>
! <wsam:NonAnonymousResponses wsp:Optional="true"/>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:Policy></eg>
</example>
***************
*** 528,536 ****
<head>Subject requires WS-Addressing and use of non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsaw:Addressing>
<wsp:Policy>
! <wsaw:NonAnonymousResponses/>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:Policy></eg>
</example>
--- 540,548 ----
<head>Subject requires WS-Addressing and use of non-anonymous response EPRs</head>
<eg xml:space="preserve"><wsp:Policy>
! <wsam:Addressing>
<wsp:Policy>
! <wsam:NonAnonymousResponses/>
</wsp:Policy>
! </wsam:Addressing>
</wsp:Policy></eg>
</example>
***************
*** 544,548 ****
<wsp:All/>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
--- 556,560 ----
<wsp:All/>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
***************
*** 550,554 ****
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
</wsp:ExactlyOne>
--- 562,566 ----
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
***************
*** 560,564 ****
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
--- 572,576 ----
<wsp:ExactlyOne>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
***************
*** 566,570 ****
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
</wsp:ExactlyOne>
--- 578,582 ----
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
***************
*** 577,581 ****
<wsp:All/>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
--- 589,593 ----
<wsp:All/>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
***************
*** 583,621 ****
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:AnonymousResponses/>
! <wsaw:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
</wsp:ExactlyOne>
--- 595,633 ----
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:AnonymousResponses/>
! <wsam:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
***************
*** 627,650 ****
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
</wsp:ExactlyOne>
--- 639,662 ----
<wsp:ExactlyOne>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
***************
*** 656,668 ****
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsaw:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsaw:Addressing>
</wsp:All>
</wsp:ExactlyOne>
--- 668,680 ----
<wsp:ExactlyOne>
<wsp:All>
! <wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
! <wsam:NonAnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
! </wsam:Addressing>
</wsp:All>
</wsp:ExactlyOne>
***************
*** 692,696 ****
<operation ref="tns:opCheckAvailability"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response">
- <wsaw:Anonymous>required</wsaw:Anonymous>
</operation>
<fault ref="tns:invalidDataFault" wsoap:code="soap:Sender" />
--- 704,707 ----
***************
*** 767,795 ****
<div3 id="explicitaction">
<head>Explicit Association</head>
! <p>WS-Addressing defines a global attribute, wsaw:Action, that can be used to
explicitly define the value of the [action] property for messages in a WSDL
description. The type of the attribute is xs:anyURI and it is used as an
extension on the WSDL input, output and fault elements. A SOAP binding can
specify SOAPAction values for the input messages of operations. In the
! absence of a wsaw:Action attribute on a WSDL input element where a non-empty
SOAPAction value is specified, the value of the [action] property for the
! input message is the value of the SOAPAction specified. If the wsaw:Action
attribute is absent, and SOAPAction is not specified, or is empty, then the
default pattern is used. Note that the SOAPAction value is not required to
be an absolute IRI, but the [action] property is required to be an absolute
! IRI; if wsaw:UsingAddressing is present, wsaw:Action is not specified, and
the SOAPAction value is not empty or an absolute IRI, then the document MUST
be considered invalid. &wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]
specifies restrictions on the relationship between the values of [action]
and SOAPAction for SOAP 1.1 and SOAP 1.2.</p>
! <p>The inclusion of wsaw:Action without inclusion of wsaw:UsingAddressing has no
normative intent and is only informational. In other words, the inclusion of
! wsaw:Action attributes in WSDL alone does not imply a requirement on clients
to use Message Addressing Properties in messages it sends to the service. A
client, however, MAY include Message Addressing Properties in the messages
it sends, either on its own initiative or as described by other elements of
the service contract, regardless of the presence or absence of
! wsaw:UsingAddressing. Other specifications defining the value of [action]
! are under no constraint to be consistent with wsaw:Action.</p>
<p>For example consider the following WSDL excerpt:</p>
<example>
--- 778,806 ----
<div3 id="explicitaction">
<head>Explicit Association</head>
! <p>WS-Addressing defines a global attribute, wsam:Action, that can be used to
explicitly define the value of the [action] property for messages in a WSDL
description. The type of the attribute is xs:anyURI and it is used as an
extension on the WSDL input, output and fault elements. A SOAP binding can
specify SOAPAction values for the input messages of operations. In the
! absence of a wsam:Action attribute on a WSDL input element where a non-empty
SOAPAction value is specified, the value of the [action] property for the
! input message is the value of the SOAPAction specified. If the wsam:Action
attribute is absent, and SOAPAction is not specified, or is empty, then the
default pattern is used. Note that the SOAPAction value is not required to
be an absolute IRI, but the [action] property is required to be an absolute
! IRI; if wsam:UsingAddressing is present, wsam:Action is not specified, and
the SOAPAction value is not empty or an absolute IRI, then the document MUST
be considered invalid. &wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]
specifies restrictions on the relationship between the values of [action]
and SOAPAction for SOAP 1.1 and SOAP 1.2.</p>
! <p>The inclusion of wsam:Action without inclusion of wsam:UsingAddressing has no
normative intent and is only informational. In other words, the inclusion of
! wsam:Action attributes in WSDL alone does not imply a requirement on clients
to use Message Addressing Properties in messages it sends to the service. A
client, however, MAY include Message Addressing Properties in the messages
it sends, either on its own initiative or as described by other elements of
the service contract, regardless of the presence or absence of
! wsam:UsingAddressing. Other specifications defining the value of [action]
! are under no constraint to be consistent with wsam:Action.</p>
<p>For example consider the following WSDL excerpt:</p>
<example>
***************
*** 801,807 ****
<operation name="opCheckAvailability" pattern="&wsdl20nsuri;/in-out">
<input element="tns:checkAvailability" messageLabel="In"
! wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
<output element="tns:checkAvailabilityResponse" messageLabel="Out"
! wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>
</operation>
</interface>
--- 812,818 ----
<operation name="opCheckAvailability" pattern="&wsdl20nsuri;/in-out">
<input element="tns:checkAvailability" messageLabel="In"
! wsam:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
<output element="tns:checkAvailabilityResponse" messageLabel="Out"
! wsam:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>
</operation>
</interface>
***************
*** 822,828 ****
<operation name="opCheckAvailability">
<input message="tns:checkAvailability"
! wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
<output message="tns:checkAvailabilityResponse"
! wsaw:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>
</operation>
</portType>
--- 833,839 ----
<operation name="opCheckAvailability">
<input message="tns:checkAvailability"
! wsam:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailability"/>
<output message="tns:checkAvailabilityResponse"
! wsam:Action="http://greath.example.com/2004/wsdl/resSvc/opCheckAvailabilityResponse"/>
</operation>
</portType>
***************
*** 1636,1640 ****
obeys the structural constraints defined in that section.</p>
<p> A WSDL description conforms to this specification when it incorporates directly or
! indirectly one or more of the <specref ref="uaee"/> or the <specref
ref="wsdlsoapmodule"/> markers, and obeys the structural constraints defined in
section <specref ref="indicatinguse"/> appropriate to that marker, and those defined
--- 1647,1651 ----
obeys the structural constraints defined in that section.</p>
<p> A WSDL description conforms to this specification when it incorporates directly or
! indirectly one or more of the <specref ref="wspolicyassertions"/> or the <specref
ref="wsdlsoapmodule"/> markers, and obeys the structural constraints defined in
section <specref ref="indicatinguse"/> appropriate to that marker, and those defined
***************
*** 1706,1718 ****
href="http://www.w3.org/TR/ws-policy-attach">latest version of WS Policy
Attachment</loc> is available at http://www.w3.org/TR/ws-policy-attach </bibl>
- <bibl key="WS Policy 1.5 - Primer" id="WSPolicyPrimer"
- href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/">
- <titleref>Web Services Policy 1.5 - Attachment</titleref>, Asir S Vedamuthu,
- David Orchard, Maryann Hondo, Toufic Boubez, Prasad Yendluri, Editors. World
- Wide Web Consortium, 18 November 2006. This version of the WS-Policy Primer
- is http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018. The <loc
- href="http://www.w3.org/TR/ws-policy-primer">latest version of WS Policy
- Primer</loc> is available at http://www.w3.org/TR/ws-policy-primer
- </bibl>
<bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt"
id="RFC2119">
--- 1717,1720 ----
***************
*** 1786,1789 ****
--- 1788,1800 ----
<head>Informative</head>
<blist>
+ <bibl key="WS Policy 1.5 - Primer" id="WSPolicyPrimer"
+ href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/">
+ <titleref>Web Services Policy 1.5 - Primer</titleref>, Asir S Vedamuthu,
+ David Orchard, Maryann Hondo, Toufic Boubez, Prasad Yendluri, Editors. World
+ Wide Web Consortium, 18 November 2006. This version of the WS-Policy Primer
+ is http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018. The <loc
+ href="http://www.w3.org/TR/ws-policy-primer">latest version of WS Policy
+ Primer</loc> is available at http://www.w3.org/TR/ws-policy-primer
+ </bibl>
<bibl id="WS-Security" key="WS-Security"
href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"
***************
*** 1806,1810 ****
for 1.0 [action] and 2004-08 [action]. </p>
<p>However, when describing services in WSDL, the namespace of the Action attribute used
! to associate values with WSDL operations differs in the two versions (wsaw:Action
versus wsa200408:Action), and the default action pattern in WS-Addressing 1.0
differs in two respects from that in the 2004-08 version: the [delimiter] can be
--- 1817,1821 ----
for 1.0 [action] and 2004-08 [action]. </p>
<p>However, when describing services in WSDL, the namespace of the Action attribute used
! to associate values with WSDL operations differs in the two versions (wsam:Action
versus wsa200408:Action), and the default action pattern in WS-Addressing 1.0
differs in two respects from that in the 2004-08 version: the [delimiter] can be
***************
*** 1828,1832 ****
<olist>
<item>
! <p>specifying wsaw:Action explicitly when the message is a fault.</p>
</item>
</olist>
--- 1839,1843 ----
<olist>
<item>
! <p>specifying wsam:Action explicitly when the message is a fault.</p>
</item>
</olist>
Received on Wednesday, 10 January 2007 11:29:07 UTC