Re: Semantics of WSDL vs. semantics of service

On Mar 17, 2006, at 2:35 PM, Josh@oklieb wrote:

> Bijan,
>
> I appreciate your comments and provide some further clarifications 
> below:
>
> On Mar 17, 2006, at 1:34 PM, Bijan Parsia wrote:
>
>> 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?
>
> For example, one XML form of an invocation message (e.g. SOAP, 
> standalone WSDL)

Sorry, this confuses me. A WSDL document isn't (typically) an 
invocation message, or the form of one. It *describes* them.

>  versus another when much the same information needs to be carried 
> anyway. Sometimes this seems to involve equating SOAP with a simple 
> form of SOAP RPC, which is unfortunate for a more generally useful 
> technology.

I'm afraid I don't see what this has to do with "XML Schema arguments",

[snip]
>>> the idea that the useful information abstractions of WSDL should 
>>> command  slavish devotion to its syntax (as well as claim to 
>>> completeness).

To reiterate, I don't see anyone claiming that one must slavishly (?!) 
be devoted to the WSDL syntax. OTOH, I don't think you should 
gratuitously depart from it. Interop. Reuse. These are facilitated by 
reusing syntax, conceputal models, etc.

>> 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.
>
> WSDL has it's place, certainly,

I guess I don't understand what you think its place is.

>  but it is neither as flexible nor as automatic as some vendors of 
> development systems would have it believed.

Well, I've been on the WSDL working group for a while. I've not noticed 
too much overestimation. I certainly don't.

> Handling of optional parameters is poor, for example, and dynamic 
> binding is quite limited in practice.

I believe this, I guess.

>  The service descriptions used for OGC services contain much of the 
> same information as in WSDL, plus much other information. Some 
> attempts to stuff that information into the WSDL syntax have produced 
> WSDL documents which are as non-standard as they are disfunctional.

Well, is it inherently dysfunctional? I mean, we could always 
*standardize* it. What makes it dysfunctional? I.e., what are the 
specific problems with the syntax? Have you raised these with the WSDL 
group?

[snip]
>>> 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.
>
> All OGC services support a "GetCapabilities" operation (and soon a 
> "GetWSDL" operation). Practically, any other arrangement ends up in 
> some form of disconnection between the service instance and its 
> description, various in-progress cataloguing projects aside.

Ah. I don't generally call that "self describing", but ok.

[snip]
> There is a theory, I suppose, that everything needed to call an 
> operation can be defined in the interface,

Well, that's strong. If I have to have invoked A before I can 
successfully invoke B, that's not typically in the interface. But I can 
invoke B. I'll just fault.

>  but I would assert that is only achievable in the most simple of 
> cases concerning the domains of and correlations between the (input 
> and output) parameters. It is not so valuable to develop software 
> which can only invoke a single operation on a single interface with a 
> single set of parameter options returning a single type of content 
> (e.g. street features from the City of Cambridge) and cannot adapt on 
> the basis of service information to another service (e.g. with street 
> features from the City of Brookline).

I was with you up to the end there (about content). Then I got lost. 
It's true that fully or mostly independent operations are limited, but 
you can do a lot with them. There is augmentation to be done even of 
them. Cases where there are more complex interaction patterns are 
interesting, of course, as well (see WS-CDL), but I'm happy with small 
steps, myself. (Unless there is a clear market/community with clear 
requirements. Point me at 'em!)

> Even so, development of that software would require knowledge about 
> the service which is generally beyond the (necessary but not 
> sufficient) descriptive capabilities of WSDL.

I lost the thread. My point was that WSDL allows you to automatically 
invoke. And even to anticipate the types of return or the possible 
faults. This is fully automated. I can even figured out how to invoke 
the "same" action though my transport protocol is entirely different 
and my message looks entirely different. These are small, and yet, not 
so small.

Now, there are TONS of conditions and issues and so on that this 
doesn't help a whit with. It doesn't tell me much of any number of 
required conditions for *successful* invokation. It doesn't tell me 
that two operations described in different interface actually do (at a 
certain level) the "same" thing. Things like that are what we wish to 
add.

> There is certainly no such thing as the perfectly soft client and will 
> alway be some limited domain of service capabilities that any one 
> piece of software can be developed for, but both OGC standard service 
> types and OWL-S VM's (to a limited extent as yet) have provided some 
> demonstration of a software client being able to "use" any of a 
> collection of services using extra-WSDL metadata.

Suuure. But that's what we want to add as an extension to WSDL. So I'm 
confused. WSDL (2.0) is extensible. It makes sense to extend it to 
handle descriptions it can't handle now. Where's the disconnect?

> The verb "use" is probably a term we are not at all agreed on. I take 
> it to mean something more than "invoke in a syntactically correct 
> manner" and something less than "understand fully the purpose of the 
> invocation and response".

There is a *wide* range (along several dimensions) in between. It would 
be great to start defining some useful points in between.

> Perhaps we should simply (!) work towards service descriptions to 
> enable development of client software which allows users 
> (orchestrators?) to get as many different tasks done as possible using 
> as many different services as possible, in other words keep enlarging 
> the circle of friends...
[snip]

Well, ideally, yes. But it would be pragmatic to identify useful steps 
that help build mindshare and allow for reasonable milestones of a 
working group. And I think things should tend toward the more specific.

For example, with a precondition-effect mechanism, I could encode 
various invocation sequencing (i.e., "you must *register with the 
printer* before *printing a paper*"). But that could, well, suck. In a 
lot of cases.

Anyway, to move forward, I'd love to see something you want to 
represent that's missing from WSDL. If we can package it up as a WSDL 
extension, let's do it. If we can't, I'd like to understand why.

Cheers,
Bijan.

Received on Friday, 17 March 2006 20:20:22 UTC