Extending port types (AKA a scenario for UPnP)

Vertical standards organizations like the UPnP Forum [1] are defining
device-specific standards, ranging from home appliances, to
entertainment, to small office appliances. The UPnP Forum and others
would like to use WSDL as their machine-readable description language.

 

A working committee within UPnP may wish to define a core set of
behaviors to be implemented by all devices of a particular type as well
as an extended set of behaviors to be implemented by advanced devices.
For example, imagine that an audio-visual working committee is defining
analog TV tuner functionality; to support standardized behavior in
inexpensive as well as expensive TV sets, they define two sets of
operations: a minimal set (like channel up / down) and an extended set
(like minimal plus jump to previous channel). Within WSDL, a natural way
for such a working committee to define these behaviors is to use port
types: a "basic tuner" port type with the core operations and an
"extended tuner" port type that has the superset.

 

This has the mildly awkward disadvantage that the definition of the
"extended tuner" must re-list each of the operations previously defined
in "basic tuner". 

 

When building a UPnP TV device, a vendor may wish to include two analog
TV tuners to support a feature like picture-in-picture. Within WSDL, a
natural way to expose this is as two ports of the correct type. This
works as expected if the device includes two analog tuners with only
basic functionality: there are two ports, each of type "basic tuner".
Clients that wish to control the device can parse the WSDL for the
device and correctly recognize that the device supports two tuners with
the basic functionality.

 

However, consider the case where the vendor wishes to include two analog
tuners with extended functionality. At a minimum, within the WSDL for
that device, they need to include two ports of type "extended tuner". In
order to support down-level clients (say written only to use "basic
tuner"), a vendor would be inclined to also include two ports of type
"basic tuner". However, such WSDL would likely be very confusing to a
client: how many tuners does the device actually contain? 

 

For the sake of completeness, note working committees in the UPnP Forum
also define standards for how many of each port type are in a type of
device. Thus, the vendor's dilemma is also encountered within the
standard WSDL descriptions a working committee would produce.

 

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". 

 

 [1] www.upnp.org <http://www.upnp.org/>