- From: Marc Hadley <mhadley@dev.w3.org>
- Date: Tue, 01 Feb 2005 19:49:19 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv16460
Modified Files:
ws-addr-core.xml ws-addr-soap.xml ws-addr-wsdl.xml
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.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-wsdl.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** ws-addr-wsdl.xml 25 Jan 2005 22:23:53 -0000 1.20
--- ws-addr-wsdl.xml 1 Feb 2005 19:49:17 -0000 1.21
***************
*** 57,61 ****
<p>&wsa-core.title;[<bibref ref="WSADDR-CORE"/>] defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] representation thereof to
! identify Web service endpoints and to secure end-to-end identification of endpoints
in messages. &wsa-wsdl.title; (this document) defines how the abstract
properties defined in &wsa-core.title; are described using WSDL.</p>
--- 57,61 ----
<p>&wsa-core.title;[<bibref ref="WSADDR-CORE"/>] defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] representation thereof to
! reference Web service endpoints and to facilitate end-to-end addressing of endpoints
in messages. &wsa-wsdl.title; (this document) defines how the abstract
properties defined in &wsa-core.title; are described using WSDL.</p>
***************
*** 121,134 ****
<div1 id="_Toc77464317">
<head> Endpoint References</head>
! <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 [<bibref ref="WSDL11"/>].</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>
<ulist>
<item>
! <p> Specific instances of a stateful service need to be identified or its
instance-specific configuration details need to be transmitted.</p>
</item>
--- 121,134 ----
<div1 id="_Toc77464317">
<head> Endpoint References</head>
! <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 [<bibref ref="WSDL11"/>].</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>
<ulist>
<item>
! <p> Specific instances of a stateful service need to be reference or its
instance-specific configuration details need to be transmitted.</p>
</item>
Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** ws-addr-soap.xml 24 Jan 2005 20:22:46 -0000 1.20
--- ws-addr-soap.xml 1 Feb 2005 19:49:17 -0000 1.21
***************
*** 56,60 ****
<p>&wsa-core.title;[<bibref ref="WSADDR-CORE"/>] defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] representation thereof to
! identify Web service endpoints and to secure end-to-end identification of endpoints
in messages. &wsa-soap.title; (this document) defines the binding of the
abstract properties defined in &wsa-core.title; to SOAP Messages.</p>
--- 56,60 ----
<p>&wsa-core.title;[<bibref ref="WSADDR-CORE"/>] defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] representation thereof to
! reference Web service endpoints and to facilitate end-to-end addressing of endpoints
in messages. &wsa-soap.title; (this document) defines the binding of the
abstract properties defined in &wsa-core.title; to SOAP Messages.</p>
Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -C2 -d -r1.25 -r1.26
*** ws-addr-core.xml 23 Jan 2005 21:13:26 -0000 1.25
--- ws-addr-core.xml 1 Feb 2005 19:49:17 -0000 1.26
***************
*** 44,50 ****
and messages. &wsa-core.title; (this document) defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] 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>
</abstract> &status; <langusage>
--- 44,50 ----
and messages. &wsa-core.title; (this document) defines a set of abstract
properties and an XML Infoset [<bibref ref="XMLInfoSet"/>] 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>
</abstract> &status; <langusage>
***************
*** 63,76 ****
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>
<example>
<head>Use of message addressing properties in a SOAP 1.2 message.</head>
--- 63,78 ----
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>
<example>
<head>Use of message addressing properties in a SOAP 1.2 message.</head>
***************
*** 110,121 ****
<p>When describing abstract data models, this specification uses the notational
convention used by the XML Infoset [<bibref ref="XMLInfoSet"/>]. Specifically,
! abstract property names always appear in square brackets (e.g., [some property]).</p>
<p>When describing concrete XML schemas [<bibref ref="XMLSchemaP1"/>, <bibref
! ref="XMLSchemaP2"/>], this specification uses the notational convention of
WS-Security [<bibref ref="WS-Security"/>]. Specifically, each member of an
element's [children] or [attributes] property is described using an XPath-like
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>
</div2>
<div2 id="_Toc77464316">
--- 112,125 ----
<p>When describing abstract data models, this specification uses the notational
convention used by the XML Infoset [<bibref ref="XMLInfoSet"/>]. Specifically,
! abstract property names always appear in square brackets (e.g., [some
! property]).</p>
<p>When describing concrete XML schemas [<bibref ref="XMLSchemaP1"/>, <bibref
! ref="XMLSchemaP2"/>], this specification uses the notational convention of
WS-Security [<bibref ref="WS-Security"/>]. Specifically, each member of an
element's [children] or [attributes] property is described using an XPath-like
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>
</div2>
<div2 id="_Toc77464316">
***************
*** 123,128 ****
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <specref ref="nsprefix"/>. Note that the choice of any namespace
! prefix is arbitrary and not semantically significant (see [<bibref ref="XMLNS"/> ]).</p>
! <table summary="Namespace prefixes usage in this specification" id="nsprefix" border="1">
<caption>Prefixes and Namespaces used in this specification</caption>
<tbody>
--- 127,134 ----
<p> This specification uses a number of namespace prefixes throughout; they are
listed in <specref ref="nsprefix"/>. Note that the choice of any namespace
! prefix is arbitrary and not semantically significant (see [<bibref ref="XMLNS"/>
! ]).</p>
! <table summary="Namespace prefixes usage in this specification" id="nsprefix"
! border="1">
<caption>Prefixes and Namespaces used in this specification</caption>
<tbody>
***************
*** 173,178 ****
<ulist>
<item>
! <p> Identification and description of specific service instances that are
! created as the result of stateful interactions.</p>
</item>
</ulist>
--- 179,184 ----
<ulist>
<item>
! <p> Referencing and description of specific service instances that are created
! as the result of stateful interactions.</p>
</item>
</ulist>
***************
*** 181,185 ****
<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>
</item>
</ulist>
--- 187,192 ----
<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>
</item>
</ulist>
***************
*** 191,199 ****
<label> [address] : URI (mandatory)</label>
<def>
! <p>An address URI that identifies the endpoint. This may be a network
! address or a logical address.</p>
</def>
</gitem>
! <!-- Resolving issue i001
<gitem>
<label> [reference properties] : xs:any (0..unbounded).</label>
--- 198,206 ----
<label> [address] : URI (mandatory)</label>
<def>
! <p>An address URI for the endpoint. This may be a network address or a
! logical address.</p>
</def>
</gitem>
! <!-- Resolving issue i001
<gitem>
<label> [reference properties] : xs:any (0..unbounded).</label>
***************
*** 233,244 ****
protocol binding and data encoding used to interact with the
endpoint. &wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]
! describes the default binding for the SOAP protocol.
!
! <!-- Resolving i001
Unlike [reference properties], the [reference parameters] of two endpoint
references may differ without an implication that different XML
Schema, WSDL or policies apply to the endpoints.
-->
! </p>
</def>
</gitem>
--- 240,250 ----
protocol binding and data encoding used to interact with the
endpoint. &wsa-soap.title;[<bibref ref="WSADDR-SOAP"/>]
! describes the default binding for the SOAP protocol.
! <!-- Resolving i001
Unlike [reference properties], the [reference parameters] of two endpoint
references may differ without an implication that different XML
Schema, WSDL or policies apply to the endpoints.
-->
! </p>
</def>
</gitem>
***************
*** 248,252 ****
<p>A QName identifying a description of the sequences of messages that a
service sends and/or receives, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details.</p>
</def>
</gitem>
--- 254,258 ----
<p>A QName identifying a description of the sequences of messages that a
service sends and/or receives, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details.</p>
</def>
</gitem>
***************
*** 257,261 ****
endpoints at which a particular Web service is deployed; the NCName
identifies one endpoint in particular. See
! &wsa-wsdl.title;[<bibref ref="WSADDR-WSDL"/>] for more details.</p>
</def>
</gitem>
--- 263,268 ----
endpoints at which a particular Web service is deployed; the NCName
identifies one endpoint in particular. See
! &wsa-wsdl.title;[<bibref ref="WSADDR-WSDL"/>] for more
! details.</p>
</def>
</gitem>
***************
*** 277,286 ****
<head> Endpoint Reference XML Infoset Representation</head>
<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>
<example>
<head>Structure of the wsa:EndpointReference element.</head>
! <eg xml:space="preserve">
<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
--- 284,295 ----
<head> Endpoint Reference XML Infoset Representation</head>
<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>
<example>
<head>Structure of the wsa:EndpointReference element.</head>
! <eg xml:space="preserve"
! >
<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
***************
*** 296,300 ****
</eg>
</example>
! <p>The following describes the attributes and elements listed in the schema overview above:</p>
<glist>
<gitem>
--- 305,310 ----
</eg>
</example>
! <p>The following describes the attributes and elements listed in the schema overview
! above:</p>
<glist>
<gitem>
***************
*** 303,307 ****
<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>
</def>
</gitem>
--- 313,318 ----
<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>
</def>
</gitem>
***************
*** 311,318 ****
<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>
</def>
</gitem>
! <!-- Resolving issue i001
<gitem>
<label> /wsa:EndpointReference/wsa:ReferenceProperties/</label>
--- 322,329 ----
<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>
</def>
</gitem>
! <!-- Resolving issue i001
<gitem>
<label> /wsa:EndpointReference/wsa:ReferenceProperties/</label>
***************
*** 349,353 ****
<p>This OPTIONAL element (of type xs:Qname) specifies the value of the
[selected interface] property of the endpoint reference, see
! &wsa-wsdl.title;[<bibref ref="WSADDR-WSDL"/>] for more details..</p>
</def>
</gitem>
--- 360,365 ----
<p>This OPTIONAL element (of type xs:Qname) specifies the value of the
[selected interface] property of the endpoint reference, see
! &wsa-wsdl.title;[<bibref ref="WSADDR-WSDL"/>] for more
! details..</p>
</def>
</gitem>
***************
*** 357,361 ****
<p>This OPTIONAL element (of type xs:QName) specifies the value of the
[service endpoint] property, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details..</p>
</def>
</gitem>
--- 369,373 ----
<p>This OPTIONAL element (of type xs:QName) specifies the value of the
[service endpoint] property, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details..</p>
</def>
</gitem>
***************
*** 365,369 ****
<p>This OPTIONAL attribute (of type xs:NCName) specifies the name of a
particular endpoint, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details.</p>
</def>
</gitem>
--- 377,381 ----
<p>This OPTIONAL attribute (of type xs:NCName) specifies the name of a
particular endpoint, see &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] for more details.</p>
</def>
</gitem>
***************
*** 384,388 ****
<label> /wsa:EndpointReference/{any}</label>
<def>
! <p>This is an extensibility mechanism to allow additional elements to be specified.</p>
</def>
</gitem>
--- 396,401 ----
<label> /wsa:EndpointReference/{any}</label>
<def>
! <p>This is an extensibility mechanism to allow additional elements to be
! specified.</p>
</def>
</gitem>
***************
*** 392,398 ****
<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[<bibref
! ref="WSDL20"/>] attribute to provide a hint for the location of a
! WSDL description of the [selected interface] and [service endpoint] properties.</p>
</def>
</gitem>
--- 405,412 ----
<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[<bibref ref="WSDL20"
! />] attribute to provide a hint for the location of a WSDL
! description of the [selected interface] and [service endpoint]
! properties.</p>
</def>
</gitem>
***************
*** 401,408 ****
[selected interface] "fabrikam:Inventory" at the endpoint URI
"http://example.com/www.fabrikam/acct". Note the use of the WSDL[<bibref
! ref="WSDL20"/>] wsdlLocation attribute.</p>
<example>
<head>Example endpoint reference.</head>
! <eg xml:space="preserve">
<wsa:EndpointReference
xmlns:wsa="&nsuri;"
--- 415,423 ----
[selected interface] "fabrikam:Inventory" at the endpoint URI
"http://example.com/www.fabrikam/acct". Note the use of the WSDL[<bibref
! ref="WSDL20"/>] wsdlLocation attribute.</p>
<example>
<head>Example endpoint reference.</head>
! <eg xml:space="preserve"
! >
<wsa:EndpointReference
xmlns:wsa="&nsuri;"
***************
*** 422,454 ****
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>
! <ulist>
! <item>
! <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>
! </item>
! </ulist>
! <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 <specref ref="eprlifecycle"/>] 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 [<bibref ref="RFC2396"/>].
! <!-- Resolving i001
The [reference properties] of two
endpoint references are equal if:
-->
! </p>
! <!-- Resolving i001
<ulist>
<item>
--- 437,469 ----
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>
! <ulist>
! <item>
! <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>
! </item>
! </ulist>
! <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 <specref
! ref="eprlifecycle"/>] 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 [<bibref ref="RFC2396"/>].
! <!-- Resolving i001
The [reference properties] of two
endpoint references are equal if:
-->
! </p>
! <!-- Resolving i001
<ulist>
<item>
***************
*** 465,474 ****
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
definitions and policies apply to endpoint references whose addresses
! <!-- Resolving i001
or reference properties
! -->
! differ.</p>
</div2>
! <div2 id='eprlifecycle'>
<head>Endpoint Reference Lifecycle</head>
<p>This specification does not define a lifecycle model for endpoint references and
--- 480,488 ----
<p>Therefore, a consuming application should assume that different XML Schemas, WSDL
definitions and policies apply to endpoint references whose addresses
! <!-- Resolving i001
or reference properties
! --> differ.</p>
</div2>
! <div2 id="eprlifecycle">
<head>Endpoint Reference Lifecycle</head>
<p>This specification does not define a lifecycle model for endpoint references and
***************
*** 480,489 ****
<div1 id="_Toc77464322">
<head> Message Addressing Properties</head>
! <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>
<glist>
<gitem>
--- 494,520 ----
<div1 id="_Toc77464322">
<head> Message Addressing Properties</head>
! <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>
<glist>
<gitem>
***************
*** 502,506 ****
<label> [reply endpoint] : endpoint reference (0..1)</label>
<def>
! <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
--- 533,537 ----
<label> [reply endpoint] : endpoint reference (0..1)</label>
<def>
! <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
***************
*** 512,516 ****
<label> [fault endpoint] : endpoint reference (0..1)</label>
<def>
! <p>An endpoint reference that identifies the intended receiver for faults
related to this message. When formulating a fault message as defined in
<specref ref="formreplymsg"/>, the sender MUST use the contents of
--- 543,547 ----
<label> [fault endpoint] : endpoint reference (0..1)</label>
<def>
! <p>An endpoint reference for the intended receiver for faults
related to this message. When formulating a fault message as defined in
<specref ref="formreplymsg"/>, the sender MUST use the contents of
***************
*** 529,537 ****
An action may be explicitly or implicitly associated with the
corresponding WSDL definition. &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] 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>
! <!-- Possible resolution to i025
<p>Protocol designers building on this specification are encouraged to take care when designing those protocols that they do not violate the requirement that there be exactly one [action] property.</p>
-->
--- 560,568 ----
An action may be explicitly or implicitly associated with the
corresponding WSDL definition. &wsa-wsdl.title;[<bibref
! ref="WSADDR-WSDL"/>] 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>
! <!-- Possible resolution to i025
<p>Protocol designers building on this specification are encouraged to take care when designing those protocols that they do not violate the requirement that there be exactly one [action] property.</p>
-->
***************
*** 562,566 ****
<p>This specification has one predefined relationship type as shown in
<specref ref="predefrels"/>.</p>
! <table id="predefrels" border="1" summary="Predefined [relationship] type values">
<caption>Predefined [relationship] values</caption>
<tbody>
--- 593,598 ----
<p>This specification has one predefined relationship type as shown in
<specref ref="predefrels"/>.</p>
! <table id="predefrels" border="1"
! summary="Predefined [relationship] type values">
<caption>Predefined [relationship] values</caption>
<tbody>
***************
*** 579,594 ****
</table>
<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>
</def>
</gitem>
</glist>
<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>&nsuri;/role/anonymous</code>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
--- 611,628 ----
</table>
<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>
</def>
</gitem>
</glist>
<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>&nsuri;/role/anonymous</code>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
***************
*** 603,610 ****
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>
<example>
<head>XML Infoset representation of message addressing properties.</head>
! <eg xml:space="preserve">
<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
--- 637,646 ----
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>
<example>
<head>XML Infoset representation of message addressing properties.</head>
! <eg xml:space="preserve"
! >
<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
***************
*** 616,620 ****
</eg>
</example>
! <p>The following describes the attributes and elements listed in the schema overview above:</p>
<glist>
<gitem>
--- 652,657 ----
</eg>
</example>
! <p>The following describes the attributes and elements listed in the schema overview
! above:</p>
<glist>
<gitem>
***************
*** 644,648 ****
<def>
<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>&nsuri;/reply</code>.</p>
</def>
</gitem>
--- 681,686 ----
<def>
<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>&nsuri;/reply</code>.</p>
</def>
</gitem>
***************
*** 683,687 ****
<def>
<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 <attval>&nsuri;/role/anonymous</attval>. Otherwise the [children] of this element convey the value of this property.</p>
</def>
</gitem>
--- 721,728 ----
<def>
<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
! <attval>&nsuri;/role/anonymous</attval>. Otherwise the
! [children] of this element convey the value of this property.</p>
</def>
</gitem>
***************
*** 692,696 ****
<def>
<p>This REQUIRED element of type xs:anyURI conveys the [action]
! property. The [children] of this element convey the value of this property.</p>
</def>
</gitem>
--- 733,738 ----
<def>
<p>This REQUIRED element of type xs:anyURI conveys the [action]
! property. The [children] of this element convey the value of this
! property.</p>
</def>
</gitem>
***************
*** 705,709 ****
<example>
<head>Example request message.</head>
! <eg xml:space="preserve">
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
--- 747,752 ----
<example>
<head>Example request message.</head>
! <eg xml:space="preserve"
! >
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
***************
*** 734,738 ****
<example>
<head>Example response message.</head>
! <eg xml:space="preserve">
<S:Envelope
xmlns:S="http://www.w3.org/2003/05/soap-envelope"
--- 777,782 ----
<example>
<head>Example response message.</head>
! <eg xml:space="preserve"
! >
<S:Envelope
xmlns:S="http://www.w3.org/2003/05/soap-envelope"
***************
*** 766,772 ****
<head> References</head>
<blist>
! <bibl key="WS-Addressing-SOAP" id="WSADDR-SOAP" href="&w3c-designation-wsa-soap;">
<titleref>&wsa-soap.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL" href="&w3c-designation-wsa-wsdl;">
<titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
<bibl key="WSDL 2.0" id="WSDL20" href="">
--- 810,818 ----
<head> References</head>
<blist>
! <bibl key="WS-Addressing-SOAP" id="WSADDR-SOAP"
! href="&w3c-designation-wsa-soap;">
<titleref>&wsa-soap.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
! <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
! href="&w3c-designation-wsa-wsdl;">
<titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
<bibl key="WSDL 2.0" id="WSDL20" href="">
***************
*** 792,796 ****
href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</loc> is
available at http://www.w3.org/TR/REC-xml. </bibl>
! <bibl id="XMLNS" key="XML Namespaces" href="http://www.w3.org/TR/1999/REC-xml-names-19990114">
<titleref>Namespaces in XML</titleref>, T. Bray, D. Hollander, and A. Layman,
Editors. World Wide Web Consortium, 14 January 1999. This version of the XML
--- 838,843 ----
href="http://www.w3.org/TR/REC-xml">latest version of XML 1.0</loc> is
available at http://www.w3.org/TR/REC-xml. </bibl>
! <bibl id="XMLNS" key="XML Namespaces"
! href="http://www.w3.org/TR/1999/REC-xml-names-19990114">
<titleref>Namespaces in XML</titleref>, T. Bray, D. Hollander, and A. Layman,
Editors. World Wide Web Consortium, 14 January 1999. This version of the XML
***************
*** 798,809 ****
http://www.w3.org/TR/1999/REC-xml-names-19990114. The <loc
href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
! XML</loc> is available at http://www.w3.org/TR/REC-xml-names. </bibl>
! <bibl id="XMLInfoSet" key="XML Information Set" href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">
<titleref>XML Information Set</titleref>, 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 <loc
href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
! Set</loc> is available at http://www.w3.org/TR/xml-infoset. </bibl>
! <bibl id="XMLSchemaP1" key="XML Schema Structures" href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">
<titleref>XML Schema Part 1: Structures</titleref>, H. Thompson, D. Beech, M.
Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001. This
--- 845,858 ----
http://www.w3.org/TR/1999/REC-xml-names-19990114. The <loc
href="http://www.w3.org/TR/REC-xml-names">latest version of Namespaces in
! XML</loc> is available at http://www.w3.org/TR/REC-xml-names. </bibl>
! <bibl id="XMLInfoSet" key="XML Information Set"
! href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024">
<titleref>XML Information Set</titleref>, 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 <loc
href="http://www.w3.org/TR/xml-infoset">latest version of XML Information
! Set</loc> is available at http://www.w3.org/TR/xml-infoset. </bibl>
! <bibl id="XMLSchemaP1" key="XML Schema Structures"
! href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">
<titleref>XML Schema Part 1: Structures</titleref>, H. Thompson, D. Beech, M.
Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001. This
***************
*** 812,816 ****
href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</loc> is available at http://www.w3.org/TR/xmlschema-1. </bibl>
! <bibl key="XML Schema Datatypes" id="XMLSchemaP2" href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">
<titleref>XML Schema Part 2: Datatypes</titleref>, P. Byron and A. Malhotra,
Editors. World Wide Web Consortium, 2 May 2001. This version of the XML Schema
--- 861,866 ----
href="http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema Part
1</loc> is available at http://www.w3.org/TR/xmlschema-1. </bibl>
! <bibl key="XML Schema Datatypes" id="XMLSchemaP2"
! href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/">
<titleref>XML Schema Part 2: Datatypes</titleref>, P. Byron and A. Malhotra,
Editors. World Wide Web Consortium, 2 May 2001. This version of the XML Schema
***************
*** 818,822 ****
<loc href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
Part 2</loc> is available at http://www.w3.org/TR/xmlschema-2. </bibl>
! <bibl id="SOAP12-PART1" key="SOAP 1.2 Part 1: Messaging Framework" href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">
<titleref>SOAP Version 1.2 Part 1: Messaging Framework</titleref>, M. Gudgin, M.
Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web
--- 868,873 ----
<loc href="http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
Part 2</loc> is available at http://www.w3.org/TR/xmlschema-2. </bibl>
! <bibl id="SOAP12-PART1" key="SOAP 1.2 Part 1: Messaging Framework"
! href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">
<titleref>SOAP Version 1.2 Part 1: Messaging Framework</titleref>, M. Gudgin, M.
Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web
***************
*** 827,836 ****
1.2 Part 1: Messaging Framework"</loc> is available at
http://www.w3.org/TR/soap12-part1/. </bibl>
! <bibl id="WSDL11" key="WSDL 1.1"
! href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">E. Christensen, et al,
! <titleref>Web Services Description Language (WSDL) 1.1</titleref>, March 2001.</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">
! OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>, March 2004.</bibl>
</blist>
</div1>
--- 878,888 ----
1.2 Part 1: Messaging Framework"</loc> is available at
http://www.w3.org/TR/soap12-part1/. </bibl>
! <bibl id="WSDL11" key="WSDL 1.1" href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315"
! >E. Christensen, et al, <titleref>Web Services Description Language (WSDL)
! 1.1</titleref>, March 2001.</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"
! > OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>,
! March 2004.</bibl>
</blist>
</div1>
***************
*** 845,853 ****
<div2>
<head>Changes Since First Working Draft</head>
! <p role="ws-addr-core.xml:20041206:20060101">Placeholder for auto change log generation.</p>
</div2>
<div2>
<head>Changes Since Submission</head>
! <p role="ws-addr-core.xml:20041001:20041205">Placeholder for auto change log generation.</p>
</div2>
</inform-div1>
--- 897,907 ----
<div2>
<head>Changes Since First Working Draft</head>
! <p role="ws-addr-core.xml:20041206:20060101">Placeholder for auto change log
! generation.</p>
</div2>
<div2>
<head>Changes Since Submission</head>
! <p role="ws-addr-core.xml:20041001:20041205">Placeholder for auto change log
! generation.</p>
</div2>
</inform-div1>
Received on Tuesday, 1 February 2005 19:49:21 UTC