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

Bijan,

+1 to your summary.

Regarding your points 1 and 2, back in May I expressed similar views within the WS Architecture group (including your point 3 question of whether WSDL is the right place for this - see for example the attachment below).

Regarding your point 3, I recently made exactly the same point on this list (see [1]).

Ugo

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

 <<Combined services and URIs>> 
----- Original Message -----

Date: Fri, 11 Jul 2003 23:56:02 -0400
Cc: www-ws-desc@w3.org
To: Umit Yalcinalp <umit.yalcinalp@oracle.com>
From: Bijan Parsia <bparsia@isr.umd.edu>
Message-Id: <C168D640-B41C-11D7-A324-0003936A0B26@isr.umd.edu>
Subject: Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace    ?


[...]

---Summary

1) "targetResource", et al, is at best suggestive of some relationship, 
and that suggestion is not uniform across members of the WG. It 
explicitly is left undefined with the possible relationships (as 
mentioned in the text) ranging from "representing", to "operating", to 
"managing". I contend that it's not well or clearly defined in the 
spec, and it's very unclear to me, personally, what relationships are 
intended.

2) serviceGroup defines a set membership relationship only and leaves 
the rationale for that grouping for out-of-wsld-spec-band 
determination, say, by some RDF. It is not illdefined or undefined and 
it clearly communicates that if you want a group with some particular 
semantics you should check the out of band info. It also provides a 
hook by providing a uri that can be the subject of RDF assertions 
detailing the purpose of the grouping and what further information can 
be infered from that grouping

3) Having only one serviceGroup is wrongheaded. If having more than one 
is cumbersome, then that suggests we should leave grouping to things 
other than WSDL.

4) If there is a grouping/grouping purpose that is either supremely 
common, highly related to other bits of WSDL, etc. then that *may* be 
an argument for privileging it. But I would hold that a) the barrier to 
such an asymmetric treatment should be high and b) that the semantics 
of the distinguished rationale should be well defined in the spec. See 
1 for why targetResource currently fails.

Cheers,
Bijan Parsia.

Forwarded message 1

  • From: Ugo Corda <UCorda@SeeBeyond.com>
  • Date: Thu, 22 May 2003 14:19:27 -0700
  • Subject: Combined services and URIs
  • To: "Francis McCabe" <fgm@fla.fujitsu.com>, <w3c-ws-arch@w3.org>
  • Message-ID: <EDDE2977F3D216428E903370E3EBDDC90811CA@MAIL01.stc.com> 
Frank,

Near the end of today's call you brought up the issue of using a URI to indicate an aggregation of services. I think I have no problem with that idea as long as it is made clear that such a URI (which by definition indicates a resource) does not necessarily correspond to a targetResource of the type we have been discussing in the last couple of days (e.g a printer, an agent, etc.).

In the general case such a URI could indicate some semantic abstract concept (e.g. the collection of the 3 loan services that had the highest hit rate during last month).

At that point, though, I wonder if WSD is the right place to indicate such a concept. I guess it could be one of the possible places. It seems that a UDDI registry would be an alternative possibility.

Ugo

Received on Saturday, 12 July 2003 16:13:02 UTC