RE: 2004-02-12 Action Item: Clarification to the OperationName feature

Hi Jonathan: 

> > right switches set - grrrrrrrrrrrrr!!!  If you have a clue how to do
> this,
> > let me know!)
> 
> [This is probably not an optimal solution, but you can open 
> the message, select Edit/Edit Message then Format/Plain Text. 
>  Then Reply All and you'll get a plain text message with the 
> line prefix.  (Sad in this day and age that plain text is 
> still the lowest common demoninator...)]

I disagree, rather liking the simplicity and cleanliness of plain text,
and rather disliking the horrible things (both aesthetically and
functionally) one can do with HTML mail - but to each their own.
Incidentally, a) your solution works for Outlook, but not OE.  And b) I
found the fabulous "OE-QuoteFix" [1] program, which works like a champ!

> > Having the operation name available somehow, no matter how, on the 
> > receiving end is precisely what we are trying to define with this 
> > feature.
> 
> I don't see a lot of difference in practice between "not 
> expressed in the WSDL" and "expressed through an extension 
> unknown to the processor."
> I don't see how you can meaningfully constrain the presence 
> of the feature without also prescribing the sets of 
> mechanisms for implementing it.  Otherwise there are 
> loopholes you can drive a medium-sized asteroid through, 
> which is where my examples are leading.

WSDL is about hints.  Just because WSDL says that a particular request
message will generate a particular response message does not mean that
in practice some implementer hasn't screwed things up or done something
"clever" to void the contract the WSDL specifies.  So the requirement
that there must be SOME understood mechanism in the WSDL explaining how
the operation name gets resolved for each operation is also just a hint.
The idea of required features, whether "built in" or explicit, is that
you now know some semantic requirement which better well be satisfied if
you are to use this description correctly.  If you don't grok the URI,
forget it immediately.  If you DO grok the URI, you should also be aware
of what the possible implementations are which satisfy it in your world.
The point of abstracting it, and not prescribing up front the exact set
of available implementations, is precisely so that later on people can
build different ways of doing the same thing and plug those in without
breaking anything.

Can you screw up?  Of course, but no more so than with any of the rest
of the language we're proposing.

> > I don't think that you can "widen" a required feature to 
> optional, so 
> > having the required="false" as you suggest below wouldn't have any 
> > effect.
> 
> Does the spec say that somewhere?

I don't believe so - it probably should.

> > If you specify your "stick-operation-name-in-a-header" 
> module without 
> > noting that it implements the operationName feature, then 
> you haven't
> satisfied
> > the
> > operationName feature.
> 
> So, my WSDL is non-conformant because the spec writer didn't 
> write his spec according to your guidelines?  Even in this 
> case where the messages conform to the spirit of the feature?

Here's the point.  If I'm a service implementer and I wish to use my
tool to build a conforming server-side instance of your
industry-standard WSDL, I need some way to distinguish which operation
is which.  Sure, I can generate a DIFFERENT WSDL which specifies, for
instance, my own SOAP action values or something, but if I want to use
YOUR binding so that clients built to understand that binding will work
with my service without changes (except for the endpoint address), I
need to make sure that I'll be able to actually dispatch correctly.

So you need to have SOMETHING in there which I understand is "the way"
to do this.  If you're using RPC style, that's enough - I can use the
body QName.  If you're using the operation name SOAP module, that's fine
if I understand that module.  If you're using SOAP action, that's fine
as long as I have the capability to dispatch based on SOAP action.  If
you're using some secret other feature, I NEED TO UNDERSTAND IT in order
to be able to successfully build my service, otherwise I won't be able
to tell the difference between operation A and operation B when they
both use the same input message.

So if your messages "conform to the spirit of the feature", what we're
saying is that you should note, in the WSDL, exactly how they do that.
For instance, I could easily imagine a feature which says simply "all
message element QNames are unique".  That's fine, but you need to
express that.

This relates a little to the other conversation in this same thread, as
to whether operations are really important.  If it isn't important to
know which operation you're using, then we may as well just all go home
because we can simply use schema for our descriptions and leave
everything up to "higher level choreography languages".  If we are going
to continue calling operations out as first-class citizens, however, the
claim is that we MUST enable WSDL processors to understand how the
author intended the operations to be distinguished from each other.

> <my:put-no-operation-name-in-the-message-even-though-the-Opera
tionName-f
> eature-says-you-have-to wsdl:required="true"/>
> 
> This feature conflicts with the OperationName feature, and 
> its spec probably says that it takes precedence over the 
> OperationName feature.
> Is that an allowable composition with a "built-in" feature?  
> These are the kinds of questions we have to answer if we 
> introduce built-in features as a new concept.

I don't think you would put that extension in as you're imagining it.
If it's saying "there is NO WAY to distinguish operations when using
this extension" then I would claim, according to the conversation we had
in Palo Alto, that this is in fact an invalid WSDL - no one would want
such a thing, any more than they would want a WSDL which says "you don't
need a binding or an endpoint; hey, have fun figuring out where these
messages go!".

What is more likely is:

<my:use-some-funky-technique-for-figuring-the-operation
wsdl:required="true"/>

That is totally reasonable, and if I understand the extension, I also
understand that this satisfies the OperationName feature requirement.

I don't think there are going to be a lot of "built-in" features - this
may well be the only one, but it's something that people feel is
important and something that we want to allow implementors to accomplish
in different ways.  Actually, the MEPs we have are like "built-in"
features as well - you need to have a way of making them work
(request/response MEP over a one-way binding, for instance), otherwise
your WSDL is invalid.

--Glen

[1] http://home.in.tum.de/~jain/software/oe-quotefix/

Received on Monday, 23 February 2004 13:21:38 UTC