Jacek Kopecky wrote:
On Thu, 2003-06-26 at 20:18, Michael Rowley wrote:
The use-case is very straight forward.  Suppose you would like to 
separate the service provided from the mechanism used to communicate 
with the service (which I believe is a goal of WSDL).  Client software 
then needs to be able to refer to something that is specific to a single 
service instance, has a single interface, but does not specify the binding.

Without the single interface restriction, it is not possible to specify 
such a thing with a single URI.  You can specify the service by 
something like:
And you can specify the interface with:
but you cannot, with a single URI, refer to something that specifies 
"any endpoint that presents the bar interface to service foo".

Why exactly do you want a single URI to be able to point to that? There
will always be things which are only identifiable indirectly...

Doesn't it make sense to allow service clients, at compile time or deployment time, to be able to refer to services without having to specify a binding, and then have the binding be negotiated with the service provider at runtime?  If every time someone had to do this they had to specify both a service URI and an interface URI it would be unwieldy.  I'm talking about using this kind of reference pervasively.  Can you imagine how much more awkward it would be to write HTML pages if every time you wanted to specify an href you had to specify two closely related URI's instead of one? 

One of the requirements for WSDL1.2 is that every semantically meaningful thing in WSDL should be referenceable by URI.  Well, in my opinion, the _most_ important thing to be able to reference with a URI is this, since these are the URI's that I expect would be used all over an application.  Requiring an application developer (or deployer or administrator) specify endpoint URI's that imply a binding is wrong.  It too closely ties together the identity of the service with the mechanism used to communicate with it.  I thought WSDL was trying to solve that.