W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sat, 26 Jul 2003 05:01:13 -0400
Cc: www-ws-desc@w3.org
To: fred.carter@amberpoint.com
Message-Id: <B5065D38-BF47-11D7-A7DD-0003939E0B44@isr.umd.edu>

On Thursday, July 24, 2003, at 07:34  PM, Fred Carter wrote:
[snip partial debate twixt Umit and myself]

I want to point out that this debate is a *tad* moot at the moment, as 
we've decided to remove targetResource and not include serviceGroup.

> I agree completely.  While the serviceGroup is "more general," it 
> misses completely in providing the ability to express that some 
> collection of endpoints "manipulates" (works with, shares state with, 
> etc.) some underlying thing.

No, it defers that to 1) as yet defined further parts of WSDL, or 2) 
out of WSDL proper, including extentions.

Second, targetResource, as was then defined in the spec, was *totally 
unspecified*. Thus, it provided no *more* semantics than "grouping". It 
was less clear on this because 1) the name suggests further semantics, 
2) people keep asserting that there *are* further semantics.

Third, the proposed definition that includes the term "manipulates" 
(but only in scare quotes, and often with a disclaimer that the 
relationship designated by this term is *completely* application 
dependant, i.e., *unspecified*) doesn't acutally nail down the 
semantics any further, it just let's people *say* that it is.

And it's fuzzy. I gave examples where it's very unclear whether two 
services that intuitively affect the same printer, "manipulate the same 

A metapoint I'll make for the second time: more abstract just does not 
mean more fuzzy. Fuzziness is whether it's *unclear* whether something 
falls into a certain concept or not. E.g., baldness is fuzzy (there are 
a range of cases where one might legitimately go either way), pregnancy 
is not.

serviceGroup isn't fuzzy. targetResource is. It's *not* fuzzy whether 
two WSDL described services have the same targetResource (well, 
assuming we don't care about distinct URI which name the same 
resource): if they have the same value of their targetResource 
attribute, they have the same targetResource. What's *very* fuzzy is 
whether two services have the same targetResource, that is, whether I, 
as the WSDL author, *should make my WSDL* have a certain 
targetResource. It's also completely unclear what I can *do* with the 
fact of identical targetResources. With serviceGroup, I *know* I have 
to look for more information. WIth targetResoruce, y'all keep saying 
that I *can* infer something more than group membership. How?

> Having the ability to find an interface but be unable to figure out 
> which one to use seems to me to considerably lessen the power of the 
> standard.

And that's what we have with targetResource, only we pretend, 
sometimes, otherwise. In fact, that's exactly what we have in WSDL 1.1.

Would it be nice to have extra information...well, of course! But we 
need to actually either supply the extra information, or just provide 
hooks. Supplying something that seems to provide more information than 
it actually does is rather less helpful, IMHO.

 From our teleconic discussion, my sense, and certainly my position, was 
that  concrete, specific proposals that answered the ambiguity issues 
would be received with interest.

> Amongst the points of Web services is to create interoperable systems 
> which can be assembled regardless of implementation technology.

And, perhpas, of implementation.

>   Such assembly requires the ability to determine interfaces, points 
> of access, *and* an ability to determine which of the alternatives 
> with which to work.  The ability to indicate this as part of a 
> service's definition seems critical.

Why? I mean, why as part of a service *description* (and more 
important, as part of the specific sort of service description WSDL is 
meant to support)?

AFAICT, the only nailed down descriptions of "alternatives with which 
to work" are multiple bindings, which are supposed to have the same 
semantics (up to, I'd gather, significant effects). That is, once you 
know what operation you want, which binding you use is largely a matter 
of convenience and arbitrary choice. Ok, that's cool. But what can I 
infer about mulitiple operations in a service? Not a lot. Not that they 
are alternatives, or interdependent, or manipulate the same "thingy", 
at least, afaict. They'll share an endpoint, but specific invocations 
(I take it) needn't.

> The general notion, separately, of serviceGroups is also powerful.  
> *If* there were a means (perhaps an extensible collection of @purpose 
> attributes, at least one of which is something like /underlying 
> entity/), then that mechansim would work as well.
> But losing the means to link endpoints (or collections thereof) to 
> some named underlying thing seems like a loss to me.

"underlying", eh. That sounds metaphorical to me, again.

It's interesting that in one example I gave (the specific to one 
printer Info service, and the paremeterized "generic" printer info 
service) the problem I had in using targetResource to connect the two 
services which *clearly* gave me information about the same printer was 
to posit a mythical printer *database*, which, in fact, I had 
specifically excluded in my conception of the two service.

This is worse that making the range of targetResource just "the logical 
set of resource the service happens to manipulate, oh, and including 
any that other services with same targetResource also happen to 
manipulate". While somewhat vacuous, it at least doesn't posit 
something *false*.

In my test ontology, I had another example, of a mailing reading and 
posting service. The implementation kept changing (first i was 
scripting Eudora, then using Eudora for reading but my SMTP server 
directly for sending, etc.). Now perhaps the *real* targetResource was 
my email account, but that's not obvious to me! I'm very unclear on how 
to figure out the what "real" underlying thing is. My guess is that 
it's application dependent in a strong way.

Bijan Parsia.
Received on Saturday, 26 July 2003 04:59:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:32 UTC