- From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 18 May 2005 17:58:06 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv32177
Modified Files:
ws-addr-core.xml ws-addr-soap.xml
Log Message:
Added lc64 resolution - numerous editorial fixes
Index: ws-addr-core.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-core.xml,v
retrieving revision 1.72
retrieving revision 1.73
diff -C2 -d -r1.72 -r1.73
*** ws-addr-core.xml 16 May 2005 20:28:27 -0000 1.72
--- ws-addr-core.xml 18 May 2005 17:58:04 -0000 1.73
***************
*** 77,94 ****
<head>Use of message addressing properties in a SOAP 1.2 message.</head>
<eg xml:space="preserve">
! (001) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
! (002) <S:Header>
! (003) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (004) <wsa:ReplyTo>
! (005) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (006) </wsa:ReplyTo>
! (007) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (008) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (009) </S:Header>
! (010) <S:Body>
! (011) ...
! (012) </S:Body>
! (013) </S:Envelope>
</eg>
<p>Lines (002) to (009) represent the header of the SOAP message where the
--- 77,94 ----
<head>Use of message addressing properties in a SOAP 1.2 message.</head>
<eg xml:space="preserve">
! (01) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
! (02) <S:Header>
! (03) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (04) <wsa:ReplyTo>
! (05) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (06) </wsa:ReplyTo>
! (07) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (08) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (09) </S:Header>
! (10) <S:Body>
! (11) ...
! (12) </S:Body>
! (13) </S:Envelope>
</eg>
<p>Lines (002) to (009) represent the header of the SOAP message where the
***************
*** 124,129 ****
<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">
--- 124,129 ----
<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">
***************
*** 218,229 ****
generated.</p>
<p>The metadata embedded in 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 <specref ref="eprlifecycle"/> or
retrieval of metadata from an authoritative source, SHOULD be
used.</p>
--- 218,230 ----
generated.</p>
<p>The metadata embedded in 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
! that have the same [address], 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>
***************
*** 236,240 ****
<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>
--- 237,244 ----
<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>). For brevity simple XML terms are used, e.g.
! 'element' instead of 'element information item' - this is not intended to
! constrain use of the constructs defined in this section to textual XML
! representations.</p>
<p>The wsa:EndpointReferenceType type is used wherever a Web service endpoint is
referenced. The following describes the contents of this type:</p>
***************
*** 332,336 ****
</glist>
<p>The following shows an example endpoint reference. This element references the
! the endpoint at the URI "http://example.com/www.fabrikam/acct".</p>
<example>
<head>Example endpoint reference.</head>
--- 336,340 ----
</glist>
<p>The following shows an example endpoint reference. This element references the
! the endpoint at the URI "http://example.com/fabrikam/acct".</p>
<example>
<head>Example endpoint reference.</head>
***************
*** 404,408 ****
<p> 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
--- 408,412 ----
<p> 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
***************
*** 461,465 ****
message.</p>
<p>It is RECOMMENDED that the value of the [action] property is an IRI
! 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. &wsa-wsdl.title;[<bibref
--- 465,469 ----
message.</p>
<p>It is RECOMMENDED that the value of the [action] property is an IRI
! identifying an input, output, or fault message within a WSDL interface.
An action may be explicitly or implicitly associated with the
corresponding WSDL definition. &wsa-wsdl.title;[<bibref
***************
*** 472,476 ****
<p>An absolute IRI that uniquely identifies this message in time and space.
No two messages with a distinct application intent may share a [message
! id] property. A message MAY be retransmitted for any purpose including
communications failure and MAY use the same [message id] property. The
value of this property is an opaque IRI whose interpretation beyond
--- 476,480 ----
<p>An absolute IRI that uniquely identifies this message in time and space.
No two messages with a distinct application intent may share a [message
! id] property. A message MAY be retransmitted for any reason including
communications failure and MAY use the same [message id] property. The
value of this property is an opaque IRI whose interpretation beyond
***************
*** 529,533 ****
endpoint. To allow these "anonymous" endpoints to send and receive messages,
WS-Addressing defines the following well-known URI for use by endpoints that cannot
! have a stable, resolvable IRI: <attval>&nsuri;/role/anonymous</attval>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
--- 533,537 ----
endpoint. To allow these "anonymous" endpoints to send and receive messages,
WS-Addressing defines the following well-known URI for use by endpoints that cannot
! have a stable, resolvable IRI: <attval>&nsuri;/address/anonymous</attval>
</p>
<p>Requests whose [reply endpoint], [source endpoint] and/or [fault endpoint] use this
***************
*** 622,626 ****
[destination] property. If this element is NOT present then the
value of the [destination] property is
! <attval>&nsuri;/role/anonymous</attval>.</p>
</def>
</gitem>
--- 626,630 ----
[destination] property. If this element is NOT present then the
value of the [destination] property is
! <attval>&nsuri;/address/anonymous</attval>.</p>
</def>
</gitem>
***************
*** 656,660 ****
<p>Comparison of [destination] property values is out of scope, other than using
simple string comparison to detect whether the value is anonymous, that is,
! where [destination] has the value "&nsuri;/role/anonymous".</p>
</div3>
</div2>
--- 660,664 ----
<p>Comparison of [destination] property values is out of scope, other than using
simple string comparison to detect whether the value is anonymous, that is,
! where [destination] has the value "&nsuri;/address/anonymous".</p>
</div3>
</div2>
Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.59
retrieving revision 1.60
diff -C2 -d -r1.59 -r1.60
*** ws-addr-soap.xml 16 May 2005 20:20:36 -0000 1.59
--- ws-addr-soap.xml 18 May 2005 17:58:04 -0000 1.60
***************
*** 70,87 ****
message.</head>
<eg xml:space="preserve">
! (001) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
! (002) <S:Header>
! (003) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (004) <wsa:ReplyTo>
! (005) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (006) </wsa:ReplyTo>
! (007) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (008) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (009) </S:Header>
! (010) <S:Body>
! (011) ...
! (012) </S:Body>
! (013) </S:Envelope>
</eg>
<p>Lines (002) to (009) represent the header of the SOAP message
--- 70,87 ----
message.</head>
<eg xml:space="preserve">
! (01) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="&nsuri;">
! (02) <S:Header>
! (03) <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
! (04) <wsa:ReplyTo>
! (05) <wsa:Address>http://example.com/business/client1</wsa:Address>
! (06) </wsa:ReplyTo>
! (07) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
! (08) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
! (09) </S:Header>
! (10) <S:Body>
! (11) ...
! (12) </S:Body>
! (13) </S:Envelope>
</eg>
<p>Lines (002) to (009) represent the header of the SOAP message
***************
*** 124,128 ****
throughout; they are listed in <specref ref="nsrefs"/>. Note
that the choice of any namespace prefix is arbitrary and not
! semantically significant (see [<bibref ref="XMLNS"/> ]).</p>
<table id="nsrefs" border="1"
summary="Namespace prefixes usage in this specification">
--- 124,128 ----
throughout; they are listed in <specref ref="nsrefs"/>. Note
that the choice of any namespace prefix is arbitrary and not
! semantically significant (see [<bibref ref="XMLNS"/>]).</p>
<table id="nsrefs" border="1"
summary="Namespace prefixes usage in this specification">
***************
*** 305,309 ****
in the message. Note that the message addressing properties
gathered by an intermediary when receiving a SOAP message do
! not necessarily get replayed as MAPs when resending the
message along the message path. A message MUST NOT contain
more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action,
--- 305,309 ----
in the message. Note that the message addressing properties
gathered by an intermediary when receiving a SOAP message do
! not necessarily get replayed as message addressing properties when resending the
message along the message path. A message MUST NOT contain
more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action,
***************
*** 525,529 ****
</eg>
</example>
! <p>The SOAP 1.1 fault is less expressive and map only [Subcode]
and [Reason]. These the properties bind to a SOAP 1.1 fault as
follows:</p>
--- 525,529 ----
</eg>
</example>
! <p>The SOAP 1.1 fault is less expressive and maps only [Subcode]
and [Reason]. These the properties bind to a SOAP 1.1 fault as
follows:</p>
***************
*** 594,598 ****
either due to some transient issue or a permanent failure. </p>
<p>The endpoint may optionally include a RetryAfter parameter in
! the detail. The source should not retransmit the message until
this duration has passed.</p>
<p> [Code] S:Receiver</p>
--- 594,598 ----
either due to some transient issue or a permanent failure. </p>
<p>The endpoint may optionally include a RetryAfter parameter in
! the detail. The source SHOULD NOT retransmit the message until
this duration has passed.</p>
<p> [Code] S:Receiver</p>
***************
*** 642,646 ****
<p>When receiving a SOAP message, certain SOAP headers may be
resulting from the serialization of an EPR's [reference
! parameters] property. The SOAP message receiver MAY perform
additional security and sanity checks to prevent unintended
actions.</p>
--- 642,646 ----
<p>When receiving a SOAP message, certain SOAP headers may be
resulting from the serialization of an EPR's [reference
! parameters] property. The SOAP message receiver can perform
additional security and sanity checks to prevent unintended
actions.</p>
Received on Wednesday, 18 May 2005 18:03:25 UTC