Re: Semantics of WSDL vs. semantics of service

On Mar 17, 2006, at 12:27 PM, Josh@oklieb wrote:

> This discussion is also giving me an inclination towards preemptive 
> deletion of sws-id emails, which is unfortunate.

That is unfortunate. Though, overall, there's not too much traffic, and 
really only one determined disrupter.

> Between the confusion of terms (as pointed out, using composition for 
> binding)

Again, single source.

> and "descent" to XML Schema arguments,

Hmm. What's this? Pointer?

> it can't be said to advance the cause.
>
> It is rather amazing (heartening or disheartening, I'm not sure) to 
> see arguments rehashed which have been going on in the OGC (Open 
> Geospatial Consortium) for years. For example, the use of private XML 
> message schemas versus SOAP formulations, whether URLencoded service 
> invocations using HTTP GET are still important, equating SOAP/WSDL 
> with RPC and in turn with the full spectrum of Web service 
> possibilities, the idea that the useful information abstractions of 
> WSDL should command  slavish devotion to its syntax (as well as claim 
> to completeness). 

Er...where was this last?

Personally, I don't see any point in departing from WSDL unless 
necessary. Certainly not at the W3C. The mindshare is compelling.

> In truth, and disjoint vocabulary aside, we are all fairly well agreed 
> on the general information which is needed to productively discover, 
> bind, and consume a remote service over the Web.

I'm not so sanguine. And, of course, there are details and there are 
details.

> We should focus on  the substantive general questions that remain. For 
> instance, is it advisable to abstract away all knowledge that an 
> operation is being invoked on a remote service over the Web (probably 
> not)? Should services be self-describing (probably so)?

What does this mean, concretely? It seems like everything points to 
their *not* being *self* describing (hence, all the descriptions :)). 
Since we don't have *access* to the "self" of the service, it seems 
like they can't be.

>  Is coupled content an important part of service semantics (yes and 
> yes)? Does WSDL impart all the information needed (for a machine) to 
> use a remote service outside of a small circle of friends (no).

Hmm. This is a bit brief. There's a version of the notion of "all the 
information" wherein the answer is yes. E.g., can a WSDL, using the 
default vocabulary, be sufficient to using (i.e., invoking) the 
service? Obviously yes, even outside a small circle of friends. Does 
pure standard wsdl have any way for me to indicate the *purpose* of so 
invoking it? Not in any way that doesn't require a person to read some 
text. (It's not *friendliness* but *out of band knowledge, that 
circumscribes the set of machines that can sensible use the service.)

Actually, that's not quite true. In principle, if I support the same 
interface (even though I'm a different service) you can use me in the 
same way. So once a program "knows" it wants to invoke an operation of 
a certain interface, it can (in principle) do so regardless of the 
endpoint, binding (assuming it supports a binding), or Service. This 
isn't nothing, but it's not a whole lot. One thing we might like is, 
given that we're want to invoke operation A in interface B, that we 
would be equally ok with invoking operation C in interface D. (And 
eventually, instead of A, invoke some composition of E, F, G, H, I...)

> Is it important to represent in service information how a service 
> processes inputs to generate outputs (yes, different geocoding 
> services for example have their own idiosyncratic heuristics 
> irrespective of the syntax)? Where are syntax standards useful for 
> interoperability? Should we get all wound up about whether this 
> additional service information is contained in a WSDL <definitions> 
> element, referenced from within a WSDL <definitions>, outside of a 
> WSDL <definitions>  (not really that important a question)?

In a sense not all that important. In a sense it has a strong default 
answer (in). The main point is to do so in whatever way is politically 
most acceptable (in the sense of not alienating vendors or users).

Cheers,
Bijan.

Received on Friday, 17 March 2006 18:34:27 UTC