RE: [wsrf] Groups - DerivedFrom portType extension.doc uploaded

[Tim Banks <tim_banks@uk.ibm.com>]

Here's my twopence on issue 1:

William said:
> consumers ... want to know what they can do with this resource they just
discovered...
> ...
> So what consumer will be most looking for, is the list of "atomic"
portTypes that are
> available. This is what will tell them what they can do with this
resource.

Seems like a reasonable requirement to me, but different from looking in a
directory for WS Resources that support a particular portType or set of
ops.

Igor said:

>3) [WSDM states that the way you know that a resource is a manageable
resource is that it implements the muws:Identity portType.] And in that
>"portType" there is only one mandatory property <muws-xs:ResourceID>.
Would it not be simpler to merely look for that property instead of looking
>for the "atomic" portType and fetch all the portTypes along the way. Would
it not solve the problem that you're describing below, William?

+1 This works for resource properties because the 'muws:ResourceID'
identifies the namespace in which the property is defined and this is very
likely to be the namespace of the portType which uses the property, and
this relationship should be understood by the consumer. There is no rule
about this, but to define a portType using properties defined by someone
else (ie in a different namespace) would be crazy, I think. It's a bit
flaky, but pragmatically, this does the job and avoids the need for
'DerivedFrom'.

William responded:

> When I see an operation called "foo" that has input and
> output messages that happen to match those of the "foo" operation in
> portType William:MyPortType, I still don't know whether the service
> supports portType William:MyPortType. There could very well be a
> Igor:MyOtherPortType portType that has a "foo" operations with these
> exact same input and output messages and yet is a whole different
> operation. This is the very reason why we have issue #1. We need to have
> the Qname of the portType to know what operation this is.

Yes, operations are a more difficult issue.  We need to acknowledge
somewhere in the specs that a derived portType may need to use new
operation names to avoid collision between two extended portTypes as the
operations are copied/pasted.  However, this should be a rare accident: a
recommendation to add a documentation element to the new operation to
describe the association with the original name/portType might be
sufficient.

In WSDL 2.0, the 'extends' attribute leaves operations in their original
namespace, so provided operation names are unique in a namespace, the
relevant Interface should be clear to consumers who understand and want to
detect its existence.  Meantime, couldn't  WSDM consumers depend on the
existence of Resource Properties?  It's really WSDL that should be tackling
the 'operations' side of the problem.


Regards, Tim Banks