- From: Marc Hadley <mhadley@dev.w3.org>
- Date: Tue, 01 Feb 2005 19:51:05 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv16579
Modified Files:
ws-addr-core.html ws-addr-soap.html ws-addr-wsdl.html
Log Message:
Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.
Index: ws-addr-wsdl.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-wsdl.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** ws-addr-wsdl.html 25 Jan 2005 22:27:10 -0000 1.11
--- ws-addr-wsdl.html 1 Feb 2005 19:51:03 -0000 1.12
***************
*** 74,78 ****
<p>Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>] defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! identify Web service endpoints and to secure end-to-end identification of endpoints
in messages. Web Services Addressing 1.0 - WSDL Binding (this document) defines how the abstract
properties defined in Web Services Addressing 1.0 - Core are described using WSDL.</p>
--- 74,78 ----
<p>Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>] defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! reference Web service endpoints and to facilitate end-to-end addressing of endpoints
in messages. Web Services Addressing 1.0 - WSDL Binding (this document) defines how the abstract
properties defined in Web Services Addressing 1.0 - Core are described using WSDL.</p>
***************
*** 137,150 ****
<h2><a name="_Toc77464317"></a>2. Endpoint References</h2>
! <p> This specification introduces a new description element type, the endpoint
! reference, with the intent of supporting a set of dynamic usage patterns not
currently appropriately covered by WSDL 1.1 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>].</p>
<p>To support these scenarios, we define a lightweight and extensible mechanism to
! dynamically identify and describe service endpoints and instances. Endpoint
references logically extend the WSDL description model (e.g., portTypes, bindings,
etc.), but do not replace it. Endpoint references can be used in the following cases:</p>
<ul>
<li>
! <p> Specific instances of a stateful service need to be identified or its
instance-specific configuration details need to be transmitted.</p>
</li>
--- 137,150 ----
<h2><a name="_Toc77464317"></a>2. Endpoint References</h2>
! <p> Web Services Addressing introduces a new description element type, the endpoint
! reference, to support a set of dynamic usage patterns not
currently appropriately covered by WSDL 1.1 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>].</p>
<p>To support these scenarios, we define a lightweight and extensible mechanism to
! dynamically reference and describe service endpoints and instances. Endpoint
references logically extend the WSDL description model (e.g., portTypes, bindings,
etc.), but do not replace it. Endpoint references can be used in the following cases:</p>
<ul>
<li>
! <p> Specific instances of a stateful service need to be reference or its
instance-specific configuration details need to be transmitted.</p>
</li>
***************
*** 998,1002 ****
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-01-25 @ 22:23</td><td>mhadley</td><td>Added descriptive text for wsa:Action attribute. Fixed references to WSDL 1.1 to be more explicit version-wise.</td></tr><tr><td>2005-01-24 @ 10:12</td><td>mgudgin</td><td>Incorporated resolution of i034 and i035; default action URI for WSDL 2.0 and default action URI for faults. All edits in section 3</td></tr><tr><td>2005-01-18 @ 04:01</td><td>mgudgin</td><td>Modified text in Section 2 WRT closing issue i020</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show hanges between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
--- 998,1002 ----
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-25 @ 22:23</td><td>mhadley</td><td>Added descriptive text for wsa:Action attribute. Fixed references to WSDL 1.1 to be more explicit version-wise.</td></tr><tr><td>2005-01-24 @ 10:12</td><td>mgudgin</td><td>Incorporated resolution of i034 and i035; default action URI for WSDL 2.0 and default action URI for faults. All edits in section 3</td></tr><tr><td>2005-01-18 @ 04:01</td><td>mgudgin</td><td>Modified text in Section 2 WRT closing issue i020</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Swtched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
Index: ws-addr-core.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** ws-addr-core.html 25 Jan 2005 22:27:10 -0000 1.12
--- ws-addr-core.html 1 Feb 2005 19:51:03 -0000 1.13
***************
*** 60,66 ****
and messages. Web Services Addressing 1.0 - Core (this document) defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! identify Web service endpoints and to facilitate end-to-end identification of
! endpoints in messages. This specification enables messaging systems to support
! message transmission through networks that include processing nodes such as endpoint
managers, firewalls, and gateways in a transport-neutral manner.</p>
</div><div>
--- 60,66 ----
and messages. Web Services Addressing 1.0 - Core (this document) defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! reference Web services and to facilitate end-to-end addressing of endpoints in
! messages. This specification enables messaging systems to support message
! transmission through networks that include processing nodes such as endpoint
managers, firewalls, and gateways in a transport-neutral manner.</p>
</div><div>
***************
*** 79,92 ****
of any particular transport or messaging system.</p>
<p>A Web service endpoint is a (referenceable) entity, processor, or resource to which
! Web service messages can be targeted. Endpoint references convey the information
! needed to identify/reference a Web service endpoint.</p>
<p>This specification defines a family of message addressing properties that convey
! end-to-end message characteristics including addressing for source and destination
endpoints and message identity that allows uniform addressing of messages
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 http://example.com/fabrikam/Purchasing:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 1-1. </span>Use of message addressing properties in a SOAP 1.2 message.</i></p>
--- 79,94 ----
of any particular transport or messaging system.</p>
<p>A Web service endpoint is a (referenceable) entity, processor, or resource to which
! Web service messages can be addressed. Endpoint references convey the information
! needed to address a Web service endpoint.</p>
<p>This specification defines a family of message addressing properties that convey
! end-to-end message characteristics including references for source and destination
endpoints and message identity that allows uniform addressing of messages
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
! http://example.com/fabrikam/Purchasing:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 1-1. </span>Use of message addressing properties in a SOAP 1.2 message.</i></p>
***************
*** 127,131 ****
<p>When describing abstract data models, this specification uses the notational
convention used by the XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically,
! abstract property names always appear in square brackets (e.g., [some property]).</p>
<p>When describing concrete XML schemas [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>, <cite><a href="#XMLSchemaP2">XML Schema Datatypes</a></cite>], this specification uses the notational convention of
WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. Specifically, each member of an
--- 129,134 ----
<p>When describing abstract data models, this specification uses the notational
convention used by the XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>]. Specifically,
! abstract property names always appear in square brackets (e.g., [some
! property]).</p>
<p>When describing concrete XML schemas [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>, <cite><a href="#XMLSchemaP2">XML Schema Datatypes</a></cite>], this specification uses the notational convention of
WS-Security [<cite><a href="#WS-Security">WS-Security</a></cite>]. Specifically, each member of an
***************
*** 133,137 ****
notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates
the presence of an element wildcard (<xs:any/>). The use of @{any}
! indicates the presence of an attribute wildcard (<xs:anyAttribute/>).</p>
</div>
<div class="div2">
--- 136,141 ----
notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates
the presence of an element wildcard (<xs:any/>). The use of @{any}
! indicates the presence of an attribute wildcard
! (<xs:anyAttribute/>).</p>
</div>
<div class="div2">
***************
*** 140,144 ****
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <a href="#nsprefix">Table 1-1</a>. Note that the choice of any namespace
! prefix is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite> ]).</p>
<a name="nsprefix"></a><br><table summary="Namespace prefixes usage in this specification" border="1">
<caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
--- 144,149 ----
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <a href="#nsprefix">Table 1-1</a>. Note that the choice of any namespace
! prefix is arbitrary and not semantically significant (see [<cite><a href="#XMLNS">XML Namespaces</a></cite>
! ]).</p>
<a name="nsprefix"></a><br><table summary="Namespace prefixes usage in this specification" border="1">
<caption>Table 1-1. Prefixes and Namespaces used in this specification</caption>
***************
*** 191,196 ****
<ul>
<li>
! <p> Identification and description of specific service instances that are
! created as the result of stateful interactions.</p>
</li>
</ul>
--- 196,201 ----
<ul>
<li>
! <p> Referencing and description of specific service instances that are created
! as the result of stateful interactions.</p>
</li>
</ul>
***************
*** 199,203 ****
<p> Flexible and dynamic exchange of endpoint information in tightly coupled
environments where communicating parties share a set of common assumptions
! about specific policies or protocols that are used during the interaction.</p>
</li>
</ul>
--- 204,209 ----
<p> Flexible and dynamic exchange of endpoint information in tightly coupled
environments where communicating parties share a set of common assumptions
! about specific policies or protocols that are used during the
! interaction.</p>
</li>
</ul>
***************
*** 210,218 ****
<dt class="label"> [address] : URI (mandatory)</dt>
<dd>
! <p>An address URI that identifies the endpoint. This may be a network
! address or a logical address.</p>
</dd>
!
<dt class="label"> [reference parameters] : xs:any (0..unbounded).</dt>
--- 216,224 ----
<dt class="label"> [address] : URI (mandatory)</dt>
<dd>
! <p>An address URI for the endpoint. This may be a network address or a
! logical address.</p>
</dd>
!
<dt class="label"> [reference parameters] : xs:any (0..unbounded).</dt>
***************
*** 227,234 ****
protocol binding and data encoding used to interact with the
endpoint. Web Services Addressing 1.0 - SOAP Binding[<cite><a href="#WSADDR-SOAP">WS-Addressing-SOAP</a></cite>]
! describes the default binding for the SOAP protocol.
!
!
! </p>
</dd>
--- 233,239 ----
protocol binding and data encoding used to interact with the
endpoint. Web Services Addressing 1.0 - SOAP Binding[<cite><a href="#WSADDR-SOAP">WS-Addressing-SOAP</a></cite>]
! describes the default binding for the SOAP protocol.
!
! </p>
</dd>
***************
*** 246,250 ****
endpoints at which a particular Web service is deployed; the NCName
identifies one endpoint in particular. See
! Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] for more details.</p>
</dd>
--- 251,256 ----
endpoints at which a particular Web service is deployed; the NCName
identifies one endpoint in particular. See
! Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] for more
! details.</p>
</dd>
***************
*** 267,271 ****
<h3><a name="_Toc77464319"></a>2.2 Endpoint Reference XML Infoset Representation</h3>
<p>This section defines an XML Infoset-based representation for an endpoint
! reference as both an XML type (wsa:EndpointReferenceType) and as an XML element (<wsa:EndpointReference>).</p>
<p>The wsa:EndpointReferenceType type is used wherever a Web service endpoint is
referenced. The following describes the contents of this type:</p>
--- 273,278 ----
<h3><a name="_Toc77464319"></a>2.2 Endpoint Reference XML Infoset Representation</h3>
<p>This section defines an XML Infoset-based representation for an endpoint
! reference as both an XML type (wsa:EndpointReferenceType) and as an XML element
! (<wsa:EndpointReference>).</p>
<p>The wsa:EndpointReferenceType type is used wherever a Web service endpoint is
referenced. The following describes the contents of this type:</p>
***************
*** 284,288 ****
</pre></div>
</div>
! <p>The following describes the attributes and elements listed in the schema overview above:</p>
<dl>
--- 291,296 ----
</pre></div>
</div>
! <p>The following describes the attributes and elements listed in the schema overview
! above:</p>
<dl>
***************
*** 291,295 ****
<p>This represents some element of type wsa:EndpointReferenceType. This
example uses the predefined <wsa:EndpointReference>
! element, but any element of type wsa:EndpointReferenceType may be used.</p>
</dd>
--- 299,304 ----
<p>This represents some element of type wsa:EndpointReferenceType. This
example uses the predefined <wsa:EndpointReference>
! element, but any element of type wsa:EndpointReferenceType may be
! used.</p>
</dd>
***************
*** 299,306 ****
<p>This REQUIRED element (of type xs:anyURI) specifies the [address]
property of the endpoint reference. This address may be a logical
! address or identifier for the service endpoint.</p>
</dd>
!
<dt class="label"> /wsa:EndpointReference/wsa:ReferenceParameters/</dt>
--- 308,315 ----
<p>This REQUIRED element (of type xs:anyURI) specifies the [address]
property of the endpoint reference. This address may be a logical
! address for the service endpoint.</p>
</dd>
!
<dt class="label"> /wsa:EndpointReference/wsa:ReferenceParameters/</dt>
***************
*** 322,326 ****
<p>This OPTIONAL element (of type xs:Qname) specifies the value of the
[selected interface] property of the endpoint reference, see
! Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] for more details..</p>
</dd>
--- 331,336 ----
<p>This OPTIONAL element (of type xs:Qname) specifies the value of the
[selected interface] property of the endpoint reference, see
! Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] for more
! details..</p>
</dd>
***************
*** 355,359 ****
<dt class="label"> /wsa:EndpointReference/{any}</dt>
<dd>
! <p>This is an extensibility mechanism to allow additional elements to be specified.</p>
</dd>
--- 365,370 ----
<dt class="label"> /wsa:EndpointReference/{any}</dt>
<dd>
! <p>This is an extensibility mechanism to allow additional elements to be
! specified.</p>
</dd>
***************
*** 363,368 ****
<p>This is an extensibility mechanism to allow additional attributes to
be specified. Some examples in this specification show use of this
! extensibility point to include a wsdlLocation[<cite><a href="#WSDL20">WSDL 2.0</a></cite>] attribute to provide a hint for the location of a
! WSDL description of the [selected interface] and [service endpoint] properties.</p>
</dd>
--- 374,380 ----
<p>This is an extensibility mechanism to allow additional attributes to
be specified. Some examples in this specification show use of this
! extensibility point to include a wsdlLocation[<cite><a href="#WSDL20">WSDL 2.0</a></cite>] attribute to provide a hint for the location of a WSDL
! description of the [selected interface] and [service endpoint]
! properties.</p>
</dd>
***************
*** 392,425 ****
endpoint references describing the endpoints it needs to interact with.
Different copies of an endpoint reference may also be received over time.</p>
! <p>The following rule clarifies the relation between the behaviors of the endpoints represented by two endpoint references with the same [address];</p>
! <ul>
! <li>
! <p>The two endpoints accept the same sets of messages, and follow and require the same set of policies. That is, the XML Schema, WSDL, and policy and other metadata applicable to the two references are the same.</p>
! </li>
! </ul>
! <p>
! However, the metadata embedded in each of the EPRs MAY differ, as the
! metadata carried by an EPR is not necessarily a complete statement of the
! metadata pertaining to the endpoint. Moreover, while embedded metadata is
! necessarily valid at the time the EPR is initially created it may become
! stale at a later point in time.
! </p>
! <p>
! To deal with conflicts between the embedded metadata of two EPRs, or
! between embedded metadata and metadata obtained from a different source, or
! to ascertain the current validity of embedded metadata, mechanisms that are
! outside of the scope of this specification, such as EPR life cycle
! information [see <a href="#eprlifecycle"><b>2.4 Endpoint Reference Lifecycle</b></a>] or retrieval
! of metadata from an authoritative source, SHOULD be used.
! </p>
<p>The [address] properties of two endpoint references are compared according to
! Section 6 of [<cite><a href="#RFC2396">RFC 2396bis</a></cite>].
!
! </p>
!
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
definitions and policies apply to endpoint references whose addresses
!
! differ.</p>
</div>
<div class="div2">
--- 404,435 ----
endpoint references describing the endpoints it needs to interact with.
Different copies of an endpoint reference may also be received over time.</p>
! <p>The following rule clarifies the relation between the behaviors of the endpoints
! represented by two endpoint references with the same [address];</p>
! <ul>
! <li>
! <p>The two endpoints accept the same sets of messages, and follow and
! require the same set of policies. That is, the XML Schema, WSDL, and
! policy and other metadata applicable to the two references are the
! same.</p>
! </li>
! </ul>
! <p> However, the metadata embedded in each of the EPRs MAY differ, as the metadata
! carried by an EPR is not necessarily a complete statement of the metadata
! pertaining to the endpoint. Moreover, while embedded metadata is necessarily
! valid at the time the EPR is initially created it may become stale at a later
! point in time. </p>
! <p> To deal with conflicts between the embedded metadata of two EPRs, or between
! embedded metadata and metadata obtained from a different source, or to ascertain
! the current validity of embedded metadata, mechanisms that are outside of the
! scope of this specification, such as EPR life cycle information [see <a href="#eprlifecycle"><b>2.4 Endpoint Reference Lifecycle</b></a>] or retrieval of metadata from an authoritative source,
! SHOULD be used. </p>
<p>The [address] properties of two endpoint references are compared according to
! Section 6 of [<cite><a href="#RFC2396">RFC 2396bis</a></cite>].
!
! </p>
!
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
definitions and policies apply to endpoint references whose addresses
! differ.</p>
</div>
<div class="div2">
***************
*** 435,444 ****
<h2><a name="_Toc77464322"></a>3. Message Addressing Properties</h2>
! <p>This section defines the information model and syntax of message addressing properties.</p>
! <p>
! Message addressing properties enable the identification and location of the endpoints involved in an interaction. The use of these properties to support specific interaction is in general defined by both the semantics of the properties themselves and the implicit or explicit contract that governs the message exchange. If explicitly available, this contract can take different forms including but not being limited to WSDL MEPs and interfaces; business processes and e-commerce specifications, among others, can also be used to define explicit contracts between the parties. The basic interaction pattern from which all others are composed is "one way". In this pattern a source sends a message to a destination without any further definition of the interaction. "Request Reply" is a common interaction pattern that consists of an initial message sent by a source endpoint (the request) and a subsequent message sent from the destination of the request back to the source (the reply). A reply in this case can be eiter an application message, a fault, or any other message. Note, however, that reply messages may be sent as part of other message exchanges as well, and are not restricted to the usual single Request, single Reply pattern, or to a particular WSDL MEP. The contract between the interacting parties may specify that multiple or even a variable number or replies be delivered.
! </p>
<p>Message addressing properties collectively augment a message with the following
! abstract properties to support one way, request reply, and any other interaction pattern:</p>
<dl>
--- 445,471 ----
<h2><a name="_Toc77464322"></a>3. Message Addressing Properties</h2>
! <p>This section defines the information model and syntax of message addressing
! properties.</p>
! <p> Message addressing properties provide references for the
! endpoints involved in an interaction. The use of these properties to support
! specific interaction is in general defined by both the semantics of the properties
! themselves and the implicit or explicit contract that governs the message exchange.
! If explicitly available, this contract can take different forms including but not
! being limited to WSDL MEPs and interfaces; business processes and e-commerce
! specifications, among others, can also be used to define explicit contracts between
! the parties. The basic interaction pattern from which all others are composed is
! "one way". In this pattern a source sends a message to a destination without any
! further definition of the interaction. "Request Reply" is a common interaction
! pattern that consists of an initial message sent by a source endpoint (the request)
! and a subsequent message sent from the destination of the request back to the source
! (the reply). A reply in this case can be either an application message, a fault, or
! any other message. Note, however, that reply messages may be sent as part of other
! message exchanges as well, and are not restricted to the usual single Request,
! single Reply pattern, or to a particular WSDL MEP. The contract between the
! interacting parties may specify that multiple or even a variable number or replies
! be delivered. </p>
<p>Message addressing properties collectively augment a message with the following
! abstract properties to support one way, request reply, and any other interaction
! pattern:</p>
<dl>
***************
*** 457,461 ****
<dt class="label"> [reply endpoint] : endpoint reference (0..1)</dt>
<dd>
! <p>An endpoint reference that identifies the intended receiver for replies
to this message. If a reply is expected, a message MUST contain a [reply
endpoint]. The sender MUST use the contents of the [reply endpoint] to
--- 484,488 ----
<dt class="label"> [reply endpoint] : endpoint reference (0..1)</dt>
<dd>
! <p>An endpoint reference for the intended receiver for replies
to this message. If a reply is expected, a message MUST contain a [reply
endpoint]. The sender MUST use the contents of the [reply endpoint] to
***************
*** 467,471 ****
<dt class="label"> [fault endpoint] : endpoint reference (0..1)</dt>
<dd>
! <p>An endpoint reference that identifies the intended receiver for faults
related to this message. When formulating a fault message as defined in
<a href="#formreplymsg"><b>3.2 Formulating a Reply Message</b></a>, the sender MUST use the contents of
--- 494,498 ----
<dt class="label"> [fault endpoint] : endpoint reference (0..1)</dt>
<dd>
! <p>An endpoint reference for the intended receiver for faults
related to this message. When formulating a fault message as defined in
<a href="#formreplymsg"><b>3.2 Formulating a Reply Message</b></a>, the sender MUST use the contents of
***************
*** 483,491 ****
identifying an input, output, or fault message within a WSDL port type.
An action may be explicitly or implicitly associated with the
! corresponding WSDL definition. Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] describes the mechanisms of association. Finally,
! if in addition to the [action] property, a SOAP Action URI is encoded in
! a request, the URI of the SOAP Action MUST be the same as the one
! specified by the [action] property.</p>
!
</dd>
--- 510,518 ----
identifying an input, output, or fault message within a WSDL port type.
An action may be explicitly or implicitly associated with the
! corresponding WSDL definition. Web Services Addressing 1.0 - WSDL Binding[<cite><a href="#WSADDR-WSDL">WS-Addressing-WSDL</a></cite>] describes the mechanisms of association.
! Finally, if in addition to the [action] property, a SOAP Action URI is
! encoded in a request, the URI of the SOAP Action MUST be the same as the
! one specified by the [action] property.</p>
!
</dd>
***************
*** 531,546 ****
</table><br>
<p>A reply message MUST contain a [relationship] property consisting of the
! predefined reply URI and the message id property of the request message.</p>
</dd>
</dl>
<p>The dispatching of incoming messages is based on two message properties: the
! mandatory "destination" and "action" fields identify the target processing location
! and the verb or intent of the message.</p>
<p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
DHCP, firewalls), many deployments cannot assign a meaningful global URI to a given
endpoint. To allow these "anonymous" endpoints to initiate message exchange patterns
and receive replies, WS-Addressing defines the following well-known URI for use by
! endpoints that cannot have a stable, resolvable URI: <code>http://www.w3.org/@@@@/@@/addressing/role/anonymous</code>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
--- 558,575 ----
</table><br>
<p>A reply message MUST contain a [relationship] property consisting of the
! predefined reply URI and the message id property of the request
! message.</p>
</dd>
</dl>
<p>The dispatching of incoming messages is based on two message properties: the
! mandatory "destination" and "action" fields indicate the target processing location
! and the verb or intent of the message respectively.</p>
<p>Due to the range of network technologies currently in wide-spread use (e.g., NAT,
DHCP, firewalls), many deployments cannot assign a meaningful global URI to a given
endpoint. To allow these "anonymous" endpoints to initiate message exchange patterns
and receive replies, WS-Addressing defines the following well-known URI for use by
! endpoints that cannot have a stable, resolvable URI:
! <code>http://www.w3.org/@@@@/@@/addressing/role/anonymous</code>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
***************
*** 556,560 ****
that can be easily secured as a unit. These properties are immutable and not
intended to be modified along a message path. </p>
! <p>The following describes the XML Infoset representation of message addressing properties:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 3-1. </span>XML Infoset representation of message addressing properties.</i></p>
--- 585,590 ----
that can be easily secured as a unit. These properties are immutable and not
intended to be modified along a message path. </p>
! <p>The following describes the XML Infoset representation of message addressing
! properties:</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 3-1. </span>XML Infoset representation of message addressing properties.</i></p>
***************
*** 569,573 ****
</pre></div>
</div>
! <p>The following describes the attributes and elements listed in the schema overview above:</p>
<dl>
--- 599,604 ----
</pre></div>
</div>
! <p>The following describes the attributes and elements listed in the schema overview
! above:</p>
<dl>
***************
*** 597,601 ****
<dd>
<p>This OPTIONAL attribute (of type xs:anyURI) conveys the relationship
! type as a URI. When absent, the implied value of this attribute is <code>http://www.w3.org/@@@@/@@/addressing/reply</code>.</p>
</dd>
--- 628,633 ----
<dd>
<p>This OPTIONAL attribute (of type xs:anyURI) conveys the relationship
! type as a URI. When absent, the implied value of this attribute is
! <code>http://www.w3.org/@@@@/@@/addressing/reply</code>.</p>
</dd>
***************
*** 636,640 ****
<dd>
<p>This OPTIONAL element (of type xs:anyURI) provides the value for the
! [destination] property. If this element is NOT present then the value of the [destination] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the [children] of this element convey the value of this property.</p>
</dd>
--- 668,675 ----
<dd>
<p>This OPTIONAL element (of type xs:anyURI) provides the value for the
! [destination] property. If this element is NOT present then the
! value of the [destination] property is
! "http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the
! [children] of this element convey the value of this property.</p>
</dd>
***************
*** 645,649 ****
<dd>
<p>This REQUIRED element of type xs:anyURI conveys the [action]
! property. The [children] of this element convey the value of this property.</p>
</dd>
--- 680,685 ----
<dd>
<p>This REQUIRED element of type xs:anyURI conveys the [action]
! property. The [children] of this element convey the value of this
! property.</p>
</dd>
***************
*** 749,758 ****
Information Set Recommendation is
http://www.w3.org/TR/1999/REC-xml-names-19990114. The <a href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
! XML</a> is available at http://www.w3.org/TR/REC-xml-names. </dd>
<dt class="label"><a name="XMLInfoSet"></a>[XML Information Set] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, J. Cowan and R. Tobin, Editors. World
Wide Web Consortium, 24 October 2001. This version of the XML Information Set
Recommendation is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The <a href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
! Set</a> is available at http://www.w3.org/TR/xml-infoset. </dd>
<dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Structures] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>, H. Thompson, D. Beech, M.
--- 785,794 ----
Information Set Recommendation is
http://www.w3.org/TR/1999/REC-xml-names-19990114. The <a href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
! XML</a> is available at http://www.w3.org/TR/REC-xml-names. </dd>
<dt class="label"><a name="XMLInfoSet"></a>[XML Information Set] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">XML Information Set</a></cite>, J. Cowan and R. Tobin, Editors. World
Wide Web Consortium, 24 October 2001. This version of the XML Information Set
Recommendation is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The <a href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
! Set</a> is available at http://www.w3.org/TR/xml-infoset. </dd>
<dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Structures] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">XML Schema Part 1: Structures</a></cite>, H. Thompson, D. Beech, M.
***************
*** 775,782 ****
1.2 Part 1: Messaging Framework"</a> is available at
http://www.w3.org/TR/soap12-part1/. </dd>
! <dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>E. Christensen, et al,
! <cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</a></cite>, March 2001.</dd>
! <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd>
! OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>, March 2004.</dd>
</dl>
</div>
--- 811,818 ----
1.2 Part 1: Messaging Framework"</a> is available at
http://www.w3.org/TR/soap12-part1/. </dd>
! <dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>E. Christensen, et al, <cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL)
! 1.1</a></cite>, March 2001.</dd>
! <dt class="label"><a name="WS-Security"></a>[WS-Security] </dt><dd> OASIS, <cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security</a></cite>,
! March 2004.</dd>
</dl>
</div>
***************
*** 794,798 ****
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-01-23 @ 21:13</td><td>mgudgin</td><td>Incorporated resolution of issue i014; edits to Section 2.3</td></tr><tr><td>2005-01-23 @ 20:52</td><td>mgudgin</td><td>Incorporated resolution of issue i006; made wsa:To optional</td></tr><tr><td>2005-01-23 @ 19:32</td><td>mgudgin</td><td>Incorporated resolution of Issue i001 by removing Reference Properties</td></tr><tr><td>2005-01-17 @ 02:13</td><td>mgudgin</td><td>Incorporated Paco's proposal for resolving Issue 038</td></tr><tr><td>2005-01-16 @ 22:40</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-17 @ 16:08</td><td>mhadley</td><td>Improved readability of introduction</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley/td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
--- 830,834 ----
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-23 @ 21:13</td><td>mgudgin</td><td>Incorporated resolution of issue i014; edits to Section 2.3</td></tr><tr><td>2005-01-23 @ 20:52</td><td>mgudgin</td><td>Incorporated resolution of issue i006; made wsa:To optional</td></tr><tr><td>2005-01-23 @ 19:32</td><td>mgudgin</td><td>Incorporated resolution of Issue i001 by removing Reference Properties</td></tr><tr><td>2005-01-17 @ 02:13</td><td>mgudgin</td><td>Incorporated Paco's proposal for resolving Issue 038</td></tr><tr><td>2005-01-16 @ 22:40</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-17 @ 16:08</td><td>mhadley</td><td>Improved readability of introduction</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley/td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
Index: ws-addr-soap.html
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** ws-addr-soap.html 25 Jan 2005 22:27:10 -0000 1.11
--- ws-addr-soap.html 1 Feb 2005 19:51:03 -0000 1.12
***************
*** 74,78 ****
<p>Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>] defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! identify Web service endpoints and to secure end-to-end identification of endpoints
in messages. Web Services Addressing 1.0 - SOAP Binding (this document) defines the binding of the
abstract properties defined in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
--- 74,78 ----
<p>Web Services Addressing 1.0 - Core[<cite><a href="#WSADDR-CORE">WS-Addressing-Core</a></cite>] defines a set of abstract
properties and an XML Infoset [<cite><a href="#XMLInfoSet">XML Information Set</a></cite>] representation thereof to
! reference Web service endpoints and to facilitate end-to-end addressing of endpoints
in messages. Web Services Addressing 1.0 - SOAP Binding (this document) defines the binding of the
abstract properties defined in Web Services Addressing 1.0 - Core to SOAP Messages.</p>
***************
*** 551,555 ****
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-01-24 @ 20:22</td><td>mgudgin</td><td>Removed spurious reference to section 3.3.2 from Section 3</td></tr><tr><td>2005-01-23 @ 21:11</td><td>mgudgin</td><td>Incorporated resolution of issue i008; added wsa:Type attribute to reference parameters</td></tr><tr><td>2005-01-20 @ 13:10</td><td>mgudgin</td><td>Removed text from first paragraph of section 3 per resolution of issue i040</td></tr><tr><td>2005-01-16 @ 22:41</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 @ 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges fr logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
--- 551,555 ----
<h3>B.1 Changes Since First Working Draft</h3>
! <table border="1"><tr><th>Date</th><th>Editor</th><th>Description</th></tr><tr><td>2005-02-01 @ 19:49</td><td>mhadley</td><td>Removed several occurances of the word 'identify' when used with endpoint references. Replaced with 'reference' or 'address' as appropriate.</td></tr><tr><td>2005-01-24 @ 20:22</td><td>mgudgin</td><td>Removed spurious reference to section 3.3.2 from Section 3</td></tr><tr><td>2005-01-23 @ 21:11</td><td>mgudgin</td><td>Incorporated resolution of issue i008; added wsa:Type attribute to reference parameters</td></tr><tr><td>2005-01-20 @ 13:10</td><td>mgudgin</td><td>Removed text from first paragraph of section 3 per resolution of issue i040</td></tr><tr><td>2005-01-16 @ 22:41</td><td>mgudgin</td><td>s/PortType/InterfaceName in certain examples</td></tr><tr><td>2004-12-16 @ 18:20</td><td>mhadley</td><td>Added resolution to issue 19 - WSDL version neutrality</td></tr><tr><td>2004-12-16 @ 16:50</td><td>mhadley</td><td>Added issue 33 resolution</td></tr><tr><td>2004-12-14 20:10</td><td>mhadley</td><td>Switched back to edcopy formatting</td></tr><tr><td>2004-12-14 @ 20:02</td><td>mhadley</td><td>Enhanced auto-changelog generation to allow specification of data ranges for logs. Split change log to show changes between early draft and first working draft and changes since first working draft.</td></tr><tr><td>2004-12-14 @ 18:13</td><td>mhadley</td><td>Added resolutions for issues 12 (EPR lifecycle), 37 (relationship from QName to URI) and 39 (spec name versioning)</td></tr></table>
</div>
<div class="div2">
Received on Tuesday, 1 February 2005 19:51:07 UTC