Re: features and requiredness

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

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 17 March 2004 12:30:09 UTC