Re: Extending port types (AKA a scenario for UPnP)

Although the first approach looks somewhat easier, I think there is actually little difference in terms of processing between the two approaches, i.e. between:

A)  <portType name="BasicTuner">
    <portType name="AdvancedTuner">
    <port name="TunerPort" bindings="tns:BasicTuner tns:AdvancedTuner">

and:

B)  <portType name="BasicTuner">
    <portType name="AdvancedTuner" extends="BasicTuner">
    <port name="TunerPort" bindings="tns:AdvancedTuner">

A) gives you multiple inheritance limited to a depth of one ("one-level multiple inheritance"). B) gives you normal inheritance. For a client, the choice is beween using a recursive (B) or a non-recursive algorithm
(A). Otherwise, I think the algorithms are grossly equivalent.

I have a slight preference for the cleaner approach (B).

Jean-Jacques.

PS. Keith, sorry for the delay in responding to your email.

Keith Ballinger wrote:

> It seems to me that we could get the same functionality by allowing ports to implement more than one portType. This would satisfy Jeffrey's requirement (I'm pretty sure) without us having to deal with inheritance.
>
> Changing the attribute name to bindings (with an "s"), and making the value a list a list of qnames, this could look like this:
>
> <port name="TunerPort" bindings="tns:basicTuner tns:AdvancedTuner">
>
>         -----Original Message-----
>         From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
>         Sent: Monday, May 06, 2002 2:14 AM
>         To: Jeffrey Schlimmer
>         Cc: www-ws-desc@w3.org
>         Subject: Re: Extending port types (AKA a scenario for UPnP)
>
>         I don't know if this is being put forward as a formal proposal,
>         but I like the general direction this is going.
>
>         Jean-Jacques.
>
>         Jeffrey Schlimmer wrote:
>
>         > A possible solution to this would be to allow one port type to
>         > derive from another by extending the set of operations
>         > supported. The description of the “extended tuner” would not
>         > have to re-list the operations defined by the “basic tuner”,
>         > but more importantly, the dual-tuner device could list just two
>         > ports of type “extended tuner”, and down-level clients could
>         > look at the derivation of the port type to recognize the “basic
>         > tuner”.
>         >

Received on Tuesday, 21 May 2002 07:28:12 UTC