W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2002

Issue 294 Proposed resolution - mark II

From: Marc Hadley <marc.hadley@sun.com>
Date: Mon, 28 Oct 2002 21:26:05 -0500
To: xml-dist-app@w3.org
Message-Id: <C6CAE3BD-EAE5-11D6-BBD0-0003937568DC@sun.com>

On last weeks telcon I took an action to flesh out my proposed 
resolution for issue 294[1] to show the text to be added to the spec. 
Here it is.

<current>
5.1.2 Property Scope

Properties within a SOAP node can differ in terms of their scope and 
the origins of their values. Some properties are scoped per 
message-exchange, while others have a wider significance. For example, 
the scope of a SOAP message property is per message-exchange, but the 
scope of a User Identity property may extend beyond the exchange of a 
single message. The values of some properties arise directly from the 
operations of the SOAP node and message exchanges, while others arise 
in implementation specific ways due to the local environment. As shown 
in the figure below, we make the distinction between per 
message-exchange and more widely scoped properties by assigning them to 
different containers called Message Exchange Context and Environment 
respectively. All properties, regardless of their scope, are shared by 
SOAP and a particular Binding.

<Graphic caption="Model describing properties shared between SOAP and 
Binding"/>

The values of properties in Environment may depend upon local 
circumstances (as depicted by the external arrow from Environment in 
the figure above). More specifically, the properties in the example 
could be influenced by an Operating System User ID on whose behalf a 
message exchange is being executed. The mapping of information in a 
particular implementation to such properties is outside the scope of 
the binding framework although the abstract representation of such 
information as properties is not.
</current>

<proposed>
5.1.2 Property Scope

Properties within a SOAP node differ in terms of their scope and the 
origins of their values. As shown in the figure below, we make the 
distinction between per message-exchange and more widely scoped 
properties by assigning them to different containers called Message 
Exchange Context and Environment Context respectively. All properties, 
regardless of their scope, are shared by a SOAP node and a particular 
Binding.

<Graphic caption="Model describing properties shared between SOAP and 
Binding"/>

5.1.2.1 Message Exchange Context

A message exchange context is a collection of properties whose scope is 
limited to an instance of a given message exchange pattern. An example 
of a message exchange context property is the identifier of the message 
exchange pattern in use.

5.1.2.2 Environment Context

The environment context is a collection of properties whose scope 
extends beyond an instance of a given message exchange pattern. 
Examples of environment context properties are the IP address of the 
SOAP node or the current date and time.

The values of properties in Environment may depend upon local 
circumstances (as depicted by the external arrow from Environment in 
the figure above). More specifically, the properties in the example 
could be influenced by an operating system user ID on whose behalf a 
message exchange is being executed. The mapping of information in a 
particular implementation to such properties is outside the scope of 
the binding framework although the abstract representation of such 
information as properties is not.
</proposed>

<current>
7.5 MEP Operation

For binding instances conforming to this specification:

  A SOAP node instantiated at an HTTP client may assume the role (i.e. 
the property context:Role ) of "RequestingSOAPNode".

  A SOAP node instantiated at an HTTP server may assume the role (i.e. 
the property context:Role ) of "RespondingSOAPNode".

The remainder of this section describes the MEP state machine and its 
relation to the HTTP protocol. In the state tables below, the states 
are defined as values of the property context:State (see 6.2 SOAP 
Request-Response Message Exchange Pattern), and are of type xs:anyURI . 
For brevity, relative URIs are used, the base URI being the value of 
context:Role .
</current>

<proposed>
7.5 MEP Operation

For binding instances conforming to this specification:

  A SOAP node instantiated at an HTTP client may assume the role (i.e. 
the property context:Role ) of "RequestingSOAPNode".

  A SOAP node instantiated at an HTTP server may assume the role (i.e. 
the property context:Role ) of "RespondingSOAPNode".

The remainder of this section describes the MEP state machine and its 
relation to the HTTP protocol. In the state tables below, the states 
are defined as values of the property context:State (see 6.2 SOAP 
Request-Response Message Exchange Pattern and 6.3 SOAP Response Message 
Exchange Pattern), and are of type xs:anyURI. For brevity, relative 
URIs are used, the base URI being the value of context:Role.

The message exchange pattern in use is indicated by the HTTP method 
used in the request. HTTP GET corresponds to the SOAP-Response MEP, 
HTTP POST corresponds to the SOAP Request-Response MEP.
</proposed>

Thoughts, comments ?
Marc.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0118.html
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.
Received on Monday, 28 October 2002 21:26:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT