Re: Issue 294 Proposed resolution - mark II

Posting on behalf of Jacek. Based on today's XMLP WG meeting, and addition
to Marc's proposal.


======================================
7.4 Supported Features

An implementation of the SOAP HTTP Binding MUST support the following
feature:

 * "http://www.w3.org/2002/06/soap/features/web-method/" (see 6.4 Web
Method Specification Feature)

<addition>
The possible values of webmeth:Method property are restricted in this HTTP
binding according to the MEP in use (as present in
context:ExchangePatternName):

         context:ExchangePatternName                   | webmeth:Method
-------------------------------------------------------+-----------------
"http://www.w3.org/2002/06/soap/mep/request-response/" |     "POST"
"http://www.w3.org/2002/06/soap/mep/soap-response/"    |     "GET"

Note: other SOAP Version 1.2 bindings to HTTP may permit other combinations
of context:ExchangePatternName and webmeth:Method.
</addition>
======================================



............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com



|---------+---------------------------->
|         |           Marc Hadley      |
|         |           <marc.hadley@sun.|
|         |           com>             |
|         |           Sent by:         |
|         |           xml-dist-app-requ|
|         |           est@w3.org       |
|         |                            |
|         |                            |
|         |           10/28/2002 06:26 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >-----------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                             |
  |       To:       xml-dist-app@w3.org                                                                                         |
  |       cc:                                                                                                                   |
  |       Subject:  Issue 294 Proposed resolution - mark II                                                                     |
  |                                                                                                                             |
  |                                                                                                                             |
  >-----------------------------------------------------------------------------------------------------------------------------|




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 Tuesday, 29 October 2002 17:36:12 UTC