Re: features and requiredness

OK with me.

JJ.

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 Wednesday, 17 March 2004 12:10:25 UTC