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

> IMO the whole reason for needing this comes from not allowing > 1 interface 
> per service (which our rep opposed, I believe).

Yes, from reading the WSD records it looks like you guys originated the whole thing ;-)

What puzzles me is that the old mechanism (i.e. the old definition of "service") was just an aggregation (multiple interfaces under the same "service" element), and I wonder why the WSD group decided to introduce the linking and the resource concepts, and to move away from the simple aggregation idea. Maybe they thought they would be killing two birds with one stone: fix the aggregation problem not supported anymore by the new "service" definition, and introduce the "deep" concept of targetResource (I am not sure they called it that way, but that is the substance of it). But in my view the attempt failed because targetResource is too slippery to deal with, and in any case there are service aggregations that are poorly represented by the concept of a targetResource.

If we really wanted to use a linking approach based on a URI, this URI should just be an abstract way to label a particular aggregation. So it would be a resource (by Web definition, anything identified by a URI is a resource) but it would be a very abstract type of resource (i.e. the concept of that particular aggregation) and have nothing to do, in the general case, with the concept of targetResource as discussed so far on this list. 

But I am afraid this abstract resource/URI might create more issues than the ones it fixes. So my feeling is that everybody would be better off at this time just sticking to the old WSDL concept of service aggregation, and the WSD group should just redefine it (taking into account the new definition of "service") as a serviceGroup element or something like that (which, by the way, exactly corresponds to proposal #2 from the WSD 5/12 F2F meeting - see minutes at [1]).

Ugo

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0042.html
 

> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com]
> Sent: Friday, May 23, 2003 10:22 AM
> To: Assaf Arkin
> Cc: Champion Mike; www-ws-arch@w3.org
> Subject: Re: Separate concepts for "service" and 
> "targetResource?" (was
> RE : /service/@targetResource ?)
> 
> 
> 
> Assaf Arkin wrote:
> > In the case would it be fair to say that this is nothing 
> than some common name that correlates multiple service 
> definitions together? Something like a service set. 
> 
> This is also my understanding, from the discussion so far. And if so, 
> the concept is interesting and, I think, possibly useful, but 
> "targetResource" is a bad name for it.
> 
> Also if you don't allow >1 target resource/service, I fail to see why 
> you just aren't using aggregration rather than a linking 
> concept .. IMO 
> the whole reason for needing this comes from not allowing > 1 
> interface 
> per service (which our rep opposed, I believe).
> 
> --Jon
> 
> 
>

Received on Friday, 23 May 2003 14:02:59 UTC