W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Composition model

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 26 Jul 2004 12:39:25 -0400
Message-ID: <80A43FC052CE3949A327527DCD5D6B275D8A5B@MAIL01.bedford.progress.com>
To: <www-ws-desc@w3.org>


In fulfillment of my AI, I have reviewed the feature/property
composition models, and I think they are both correct with respect to
our status quo.

Unfortunately, I still think that allowing the "widening" of potential
values (i.e. feature requiredness and property values/constraints) is a
dangerous place to go.  Imagine this situation: I define a standard
interface which I expect to be used in a variety of circumstances, and
specify a property constraint for that interface:

<interface name="MissileLauncher">
  <feature name="http://security-feature" required="true"/>
  <property name="http://security-feature/encryptionLevel">
    <constraint>myNS:greaterThanFour</constraint>
  </property>
</interface>

In this example I posit a schema type has been defined which restricts
the normal int value of the encryptionLevel property to be > 4, since I
don't want anyone using the MissileLauncher interface anywhere without
proper safety considerations.

With the current model, it is possible to do this:

<binding name="LooseyGoosey" interface="ns:MissileLauncher">
  <property name="http://security-feature/encryptionLevel">
    <value>0</value>
  </property>
</binding>

In fact it's even possible to shut off the requiredness of the security
feature entirely in the binding, or for a particular operation.

It is my belief that this seriously compromises the intent of specifying
constraints and requirements at the higher levels of the model.  I
understand that there are certain situations when adopting a more
rigorous model might cause the WSDL authoring tool to write multiple
copies of the same feature or property declaration (when you want to be
able to turn off requiredness, or specify incompatible values, at a
lower scope), but this seems a small price to pay for what seems to be
to be a much clearer model that allows the specification of
requiredness/values at the higher levels to actually MEAN something.

In other words, this seems to me a bit like the case of bindings - once
you specify that a given endpoint uses a particular binding, you can't
override that and say that a particular operation uses a different
binding (unless you write a custom binding which explicitly describes
how to do exactly that).

--Glen
Received on Monday, 26 July 2004 14:09:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT