Re: Properties text today?

Here's a draft of the text for property scoping.  Sorry for the delay -
comments appreciated.

NOTE : in this text, I specify the scope list as including the <service> and
the messages themselves.  I think it is important to allow property settings
in these scopes.  Although I haven't gone back and read the archives, it was
certainly the original intent to allow this stuff, so I bring it up here.  I
do think the spec needs to be clearer even now about where these things are
allowed, and with the scoping rules as laid out in this message and the one
about features, I think we're OK to put them all the places listed below.

<suggestedText>

NOTE : In the text which follows, "property constraint" is used to mean
EITHER a <constraint> inside a property component OR a <value>, since
<value> may be considered a special case of <constraint>.

At runtime, the behaviour of features, SOAP modules, and bindings may be
affected by the values of in-scope properties.  Properties combine into a
virtual "execution context" which maps property names (URIs) to
constraints - each property URI may therefore be associated with at most one
property constraint for a given interaction.  To determine the particular
set of constraints for a given interaction, combine all declared constraints
in the following scopes - the list is in order of increasing specificity,
and if a given property URI is constrained in a later scope, it overrides
the earlier constraint.

* The interface
* The binding
* The service
* The specific interface operation
* The specific binding operation
* The specific input/output message

</suggestedText>

We also need an example (which can perhaps just combine with the feature
example), which I'll write up in a bit but I want to get this out before (2
min before, but still before :)) the concall.

--Glen

---- Original Message ----
From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
To: "Glen Daniels" <gdaniels@sonicsoftware.com>
Cc: "David Booth" <dbooth@w3.org>; "Sanjiva Weerawarana"
<sanjiva@watson.ibm.com>; <www-ws-desc@w3.org> Sent: Thursday, March
18, 2004 10:05 AM Subject: Properties text today?

> Glen, any chance we could have the properties text today? This would
> allow us to complete the outstanding edtodo's for Part1.
>
> Cheers,
>
> JJ.
>
> David Booth wrote:
>
>> This looks good to me, with one minor editorial nit: I think the
>> phrase "or available" should be deleted, as I think it adds more
>> confusion than clarification.
>>
>> Glen's text nicely complements the changes I proposed earlier in:
>> http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0044.html and
>> http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0045.html
>>
>> If others are agreeable, I think Glen's and my two suggestions
>> should be incorporated.
>>
>>
>> At 07:43 AM 3/17/2004 -0500, Glen Daniels wrote:
>>
>>> How about something like this to describe the composition model for
>>> features:
>>>
>>> <suggestedText>
>>>
>>> The set of features which are required or available for a given
>>> interaction
>>> consists of the combined set of all feature declarations which are
>>> "in scope" for that interaction.  "In scope" is defined as follows
>>> : for a given
>>> operation at a given endpoint, the features that must be considered
>>> are those declared in the 1) service, 2) binding/operation, 3)
>>> binding, 4) interface/operation, and 5) interface.  An example:
>>>
>>> <definitions targetNamespace="http://example.com/bank"
>>>      xmlns:ns1="http://example.com/bank">
>>>   <interface name="ns1:Bank">
>>>     <!-- All uses of this interface must be secure -->
>>>     <feature uri="http://example.com/secure-channel"
>>>              required="true"/>
>>>     <operation name="withdrawFunds">
>>>       <!-- This operation must have ACID properties -->
>>>       <feature uri="http://example.com/transaction"
>>>                required="true"/>
>>>       ...
>>>     </operation>
>>>     <operation name="depositFunds">
>>>       <!-- This operation requires notarization -->
>>>       <feature uri="http://example.com/notarization"
>>>                required="true"/>
>>>       ...
>>>     </operation>
>>>   </interface>
>>>   <binding name="ns1:BankSOAPBinding">
>>>   </binding>
>>>   <service name="ns1:BankService"
>>>            interface="tns:Bank">
>>>    <!-- This particular service requires ISO9001
>>>         compliance to be verifiable -->
>>>    <feature uri="http://example.com/ISO9001"
>>>             required="true"/>
>>>    <!-- This service also requires notarization -->
>>>    <feature uri="http://example.com/notarization"
>>>             required="true"/>
>>>    <endpoint>
>>>      ...
>>>    </endpoint>
>>>   </service>
>>> </definitions>
>>>
>>> When using the "depositFunds" operation on the BankService, the
>>> ISO9001, notarization, and secure-channel features are all
>>> required, as they
>>> are all
>>> in scope.  Note that the notarization feature is declared both in
>>> the operation and in the service - multiple declarations have no
>>> effect on the
>>> combined set of active features, since features are either in use
>>> or not, with no multiplicity.  If multiple declarations of the same
>>> feature
>>> are in
>>> scope for a given interaction, the feature is required if ANY of
>>> the in scope declarations have the "required" attribute set to
>>> "true".
>>>
>>> </suggestedText>
>>>
>>> Properties are a little more complicated, since you have to actually
>>> combine
>>> the values, not just a boolean presence/required.  I'm working on
>>> text for
>>> that.
>>>
>>> --Glen
>>>
>>> ----- Original Message -----
>>> From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
>>> To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
>>> Cc: "Glen Daniels" <gdaniels@sonicsoftware.com>;
>>> <www-ws-desc@w3.org> Sent: Wednesday, March 17, 2004 3:51 AM
>>> Subject: Re: features and requiredness
>>>
>>>
>>>> Down to your specifics: one option would be to do as for
>>>> namespaces, the lower layer value overrides the higher level
>>>> value. However, this looks quite complicated and unnecessary.
>>>>
>>>> What about simply raising an error? This would be simple, and quite
>>>> consistent with our inheritance model (everything allowed, but
>>>> error upon conflic).
>>>>
>>>> What do you think?
>>>>
>>>> JJ.
>>>>
>>>> Sanjiva Weerawarana wrote:
>>>>
>>>>>> <interface name="iSvc">
>>>>>> <feature uri="foo:feature1" required="true"/>
>>>>>> </interface>
>>>>>> <binding interface="iSvc">
>>>>>> <feature uri="foo:feature1" required="false"/>
>>>>>> </binding>
>>>>>
>>>>>
>>>>> Where in the spec say how these things are spsed to be combined?
>>>>> Without that its hard to say what to do if what's being combined
>>>>> has different @required values. If you look at the features
>>>>> property of binding for example it doesn't say anything about
>>>>> having to compose the properties. What should it say?

Received on Thursday, 18 March 2004 10:58:12 UTC