part 2/sec 6

In keeping with my comments about the tone/style of the proposed part
2/section 6 in the ed copy [1], here is the text of an editorial rewrite
for that section.

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#soapfeatspec

===============================
6 A Convention for Describing Features and Bindings

In this section, we describe a convention involving properties and property
values for describing Features (including MEPs)

and Bindings. This convention is sufficient to describe the distributed
states of Feature and Binding specifications as

mandated by the Binding Framework [ref sec 5.3], and indeed we use the
convention to describe a Single-Request-Response MEP

[ref] and an HTTP Binding [ref] elsewhere in this document. Along with the
convention itself, we present an informal model

that describes how properties propagate through a SOAP system. Note that
this model is intended to be illustrative only, and

is not meant to imply any constraints on the structure or layering of any
particular SOAP implementation.

6.1 Model and Properties

In general, a SOAP message is the information that one SOAP Node wishes to
exchange with another SOAP Node according to a

particular set of features, including a MEP. In addition, there may be
information essential to exchanging a message that is

not part of the message itself. Such information is sometimes called
message meta-data. In the model, the message, any

message meta-data, and the various information items that enable features
are represented as abstractions called properties.

6.1.1 Properties

Under the convention, properties are represented as follows:

- Properties are named with XML qualified names (QNames). For example,
"myNS:RetryCount" where "RetryCount" is the name of

the property, and "myNS" is a prefix mapped to a namespace.

- Property values are typed, and the type of a property-value is defined by
an XML Schema simple datatype in the

specification which introduces the property. For example, the type of
RetryCount is "xsi:int".

6.1.2 Property Scope

>>>Insert Figure @@ about here<<<
>>>Figure caption "Model describing properties shared between SOAP and
Binding"<<<

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. In Figure @@, we
make the distinction between  per

message-exchange and more widely scoped properties by showing them in
different containers called Message Exchange Context

and Environment respectively. All properties, regardless of their scope,
are shared by SOAP and a particular Binding.

However, the values of properties in Environment may depend upon local
circumstances (as depicted by the external arrow from

Environment in Figure @@). More specifically, the properties in our 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.

6.1.3 Properties and Features

Features may be enabled through multiple properties, and a single property
may enable more than one feature.  For example,

the properties called User ID, Password may be used to enable a feature
called Authentication. And for example, a single

property called Message ID may be used to enable one feature called
Transaction and a second feature called Message

Correlation.
===============================

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

Received on Friday, 7 December 2001 13:34:12 UTC