Re: features and requiredness

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 07:43:13 UTC