RE: Separate concepts for "service" and "targetResource?" (was RE : /service/@targetResource ?)

>So trying to understand the value proposition of targetResource and best 
>practice, it seems to me that it tries to solve a very specific problem: 
>how to define multiple <service> definitions that are independently 
>managed, yet all relate to the same service agent/provider/resource.

Yes, the problem seems to be very specific. I think I know how all this originated. Initially a WSDL service could include various entry points representing different interfaces. The latest draft redefined service to only represent a single interface. Hence the need some people felt to have a way to represent the type of service aggregation that was possible in the old draft.

I think that the idea of achieving such an aggregation via the concept of a resource is ill conceived. As already discussed, resource is too vague an idea for that. And the aggregation concept, as it was discussed during the F2F, belongs more in the application domain than the WSDL domain. (Different criteria for service aggregation can be devised given the same set of WSD services, depending on the application).

If I had to make a suggestion, I would say WSD should provide some (optional) syntax to specify the old type of aggregation, and leave it at that. That syntax would simply collect a bunch of "new" services together under the same XML element. No need to base that syntax on any concept of common URIs identifying resources or other things.

Ugo

Received on Wednesday, 21 May 2003 16:55:50 UTC