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

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

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Mon, 14 Jul 2003 14:12:42 +0600
Message-ID: <03c201c349df$b60966f0$02c8a8c0@lankabook2>
To: <www-ws-desc@w3.org>

"Jonathan Marsh" <jmarsh@microsoft.com> writes:
> If the remaining concept we wish to express is grouping, the
> targetResource is not the most direct way to achieve this.  Instead of
> introducing the "resource" entity, we can introduce an entity
> representing the "group".  The relationship between endpoint(s) and the
> group is that of "member of", instead of the fuzzier "manipulates".
> There are several ways this could be manifested in the syntax:
> a) Add a "serviceGroup" attribute that takes a URI.  The URI is an
> arbitrary identifier for the "group" to which this service belongs.  The
> purpose of the group is defined by the creator of the URI.
> b) Add a <serviceGroup> element to group <service>s together into an
> anonymous group.
> c) Both of a) and b).
> d) Use external mechanisms such as RDF.
> e) Conflate grouping with an existing construct such as <description> or
> @targetNamespace.

So one way I can read this is that by doing
(in SED syntax for those not fortunate enough to have had the pleasure
of it) we're getting the concept passed. After all, the membership 
criteria for the group can be "all <service>s that manipulate the same
resource", right?

Several people have indicated that a <service> should be able to belong
to zero or more groups:
    <service [groups="list-of-qnames"]> .. </service>
I have to agree that a single group concept is rather artificial.

OGSi (the gridders) have a similar concept *shockingly* called service
group!! The idea is similar (or may even be precisely the same): its
a group of services which meet the required membership criteria. So
I suspect that Steve & Steve should like this approach as they can
model service groups directly at the WSDL level. 

While I continue to prefer the more rigid @targetResource concept (yes
I do believe its more rigid/focused than @groups), I can live with this
solution too. I think in most scenarios the grouping is very dynamic; so
I don't expect service/@groups to be widely used. That is, I don't believe
service authors will statically declare what groups they belong to 
simply because they won't know that statically. Furthermore, the groups
themselves are unlikely to be static. 

I'm a bit surprised that @groups isn't getting trashed like 
@targetResource was. To me @groups is even worse at supporting the
multiple interface scenario ..

Received on Monday, 14 July 2003 04:17:17 UTC

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