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

Jonathan:

> > 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.
> 
> Unique message element QNames is a reasonable way to ensure 
> that a service can dispatch a message to the right operation. 
>  But as I understand it, such a mechanism would not satisfy 
> the OperationName feature, which would require extra (and 
> unnecessary in this case) goo to be squirted into the message.

Hm, I think you are missing something here.  Making the operationName
feature an ABSTRACT feature was precisely so that we can allow multiple
different ways of satisfying it.  One of these ways is using the RPC
style, for instance - that does not require any "extra goo" in the
message at all.  It simply says "when using this style, the feature is
satisfied because the QNames are unique".  We could also imagine another
feature or style whose spec said essentially the same thing without the
other RPC rules about schema structure.  But you still want SOMETHING in
the WSDL to describe what's going on - a hint to the processor that says
"hey I'm asserting that all my QNames are unique, so you can feel free
to fault if you discover duplicates".  

> I agree that a service needs to be able to know what to do 
> with any particular message.  That's built into my assumption 
> about how to build any Web service.  But constraining the 
> solution to this problem to the particular strategy of 
> inserting the Operation Name into the message doesn't seem right.

Agreed, and the feature doesn't say that you must insert it into the
message explicitly in any way.  It just says that the information MUST
somehow be transmitted from the sender to the receiver.

> In any case, if functionality is always "required", there 
> doesn't seem to be much point in giving it a feature URI that 
> can appear in the markup and will appear in the component 
> model, instead of just using text in the spec.

Two reasons.  First, for consistency, since it is a real feature.
Second, because giving it a URI allows other specifications to be
written (i.e. the operationName SOAP module, or another binding which
might include operation names in some transport-specific way) to
unambiguously refer to the semantic we're talking about.   That's the
whole point of naming it.  As a side benefit, you can also make RDF
assertions about the feature once it has been given a URI.

--Glen

Received on Monday, 23 February 2004 15:18:54 UTC