W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: part 2/sec 6

From: Christopher Ferris <chris.ferris@sun.com>
Date: Tue, 11 Dec 2001 07:18:52 -0500
Message-ID: <3C15F9AC.10604@sun.com>
To: David Fallside <fallside@us.ibm.com>
CC: xml-dist-app@w3.org
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
> 
> 
> 
Received on Tuesday, 11 December 2001 07:19:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC