Re: part 2/sec 6

David,

Thanks for doing this. One minor point. The use of
"we use" or "we present" throughout this (and the previous
draft) is inconsistent with the remainder of the spec.
I would suggest changing the following:

s/In this section, we describe a/This section describes a/
s/, and indeed we use the convention/. This convention is used/
s/we present an informal model/an informal model is defined/
s/properties in our example/ properties in the example/

Cheers,

Chris



David Fallside wrote:

> 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
> 
> 
>