Re: features and requiredness

DONE all (including David's suggestions).

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 09:15:36 UTC