Re: HTML version of operation name proposal

Sanjiva Weerawarana wrote:

>Hi Roberto,
>
>  
>
>>You were asking Gudge, but I hope you don't mind if I try
>>to answer your questions.
>>    
>>
>
>Yes of course!
>
>  
>
>>>Now, what are the operations available in {nsuri-2}pt2? Can you
>>>please indicate both the name and targetnamespace properties of
>>>each of the operations?
>>>
>>>      
>>>
>>There's three of them:
>>  operation {nsuri-1}o1;
>>  operation {nsuri-1}o2;
>>  operation {nsuri-2}o3;
>>    
>>
>
>OK.
>
>  
>
>>Yes, it is legal. In short, the qualified name of an operation must be
>>unique.
>>It's just like before, but instead of saying "the name must be unique"
>>we now
>>say "the qualified name must be unique".
>>    
>>
>
>If the qualified name of an operation must be unique, then we have
>created an arbitrary restriction by saying operations cannot
>be referred to be QNames. Furthermore, the entire portType concept
>is really meaningless now because its just a wrapper and the name
>of the portType is simply irrelevant.
>
>In effect, if we accept this proposal we would have made operations
>top level components!
>
Not at all. Operation names must be unique only within a portType, not 
globally, so
this proposal is very different from making operations top-level 
components. The only
similarity is that operation names would be QNames in both cases.

>>>If legal, what are the values of the TNS and name properties of
>>>all the operations available via pt3?
>>>
>>>      
>>>
>>operation {nsuri-1}o1;
>>operation {nsuri-1}o2;
>>operation {nsuri-3}o1;
>>    
>>
>
>So this really doesn't address the requirement from the grid
>folks that started this thread - that of wanting to re-use an
>operation name during subtyping. This proposal in effect makes
>operation names be more complicated, but leaves them global.
>
No, the names are not global, they are just qualified. You cannot refer 
to operations
by QName anywhere in WSDL, it's only within a portType that an operation
can be uniquely identified by its QName.

At the F2F Steve Graham thought the grid needs were addressed, and from his
explanation of what those needs were, I agree with him. If you want to leave
the option to derive from your portType completely open, all you need to do
is to place it in its own namespace, and that's going to be documented 
as a best
practice. For everybody else, life goes on just as before, they don't 
need to
learn any new concepts.

>IMO the only way to meet the requirement that the grid folks
>brought up is to re-introduce operation overloading. Otherwise
>any way you cut it the operation names become global. All this
>new proposal does is define a way to make them global by bringing
>in the target namespace to the operation name.
>
It does NOT make them global. It just makes their names more unique.

>We removed operation overloading before we introduced inheritance.
>I think we need to revisit that decision and bring it back.
>
I hope you realize what a can of worms operation overloading is. The 
programming
language binding issues raised by the current proposal pale in 
comparison to what
overloading would do.

>Finally, how does all this look when bound to a language (like
>Java)? I'd like to understand how the targetnamespace properties
>of an operation name will be represented in the language binding.
>Yes, I know we don't do language binding, but someone does.
>
>  
>
>>Hmmm, wonder who that someone might be!  ;-)
>>    
>>
>
>I had named you in my email first, but then I thought I'll
>remove it ;-).
>
Right, no need to mention my name, I fell for it head first!  ;-)

>>I guess you'll have to come up with identifiers that reflect the
>>combination of
>>namespace name and local part.
>>    
>>
>
>This is the answer I expected. This is nothing short of disgusting!
>
>Spse nsuri-1 was http://www.sun.com/services/s1 and nsuri-2 was
>http://www.microsoft.com/services/s2 (now imagine that- MSFT
>extending a Sun defined service!). I forget the name mangling
>rules u defined in JAX-RPC, but you'd end up with something like
>the following for {nsuri-2}pt2:
>
>====
>package com.sun.www.services.s1;
>
>public interface pt1 {
>  public typeX1 www_sun_com_services_s1_o1 (...);
>  public typeX2 www_sun_com_services_s1_o2 (...);
>}
>====
>
>====
>package com.microsoft.com.services.s2;
>import com.sun.www.services.s1.pt1;
>
>public interface pt2 extends pt1 {
>  public typeX3 www_microsoft_com_services_s2_o3 (...);
>}
>====
>
>How can that be considered user-friendly and acceptable? The user
>of this interface in effect must know exactly which super portType
>defined every single operation in order to figure out the name
>of the operation.
>
It doesn't have to be that bad. In most cases, no mangling will occur.
Sometimes, you'll have mangling, but the user will be able to override it
and pick the names he wants. See my remark about the already existing
naming conflicts.

>>In most cases, everything will be fine,
>>in some
>>cases tools will come up with bad defaults and humans will override them.
>>    
>>
>
>No, humans cannot override the JAX-RPC defined mapping; otherwise
>that mapping is no longer a contract I can rely on. That is, if I
>do dynamic lookup of a proxy, then that better not have changed
>the names or all hell will break loose. Do you not agree??
>
In J2EE 1.4, the mapping can be overriden using a jaxrpc-mapping-info 
file and
I expect development tools to make it usable in practice (read: don't 
force you to
write a mapping file by hand).

>>Notice also that the problem exists today, even without overloading: if
>>    
>>
>you
>  
>
>>have an operation called "foo-bar" and the dash ('-') is not valid in
>>identifiers,
>>you'll have to map it to something else (fooBar, foobar, foox2DBar,
>>foo45Bar,
>>foo$2D$Bar), but no matter how clever you are you might get a conflict
>>with another operation (called, e.g. "fooBar", or "foobar", or...).
>>    
>>
>
>Yes of course this problem exists today. However, I hope that
>you'd agree that that is an entirely different level of the
>problem than the one we are considering creating.
>
Just because URIs are longer than the typical NCNames?

>Finally, given that this proposal does not solve the original
>problem (that of wanting a subtype to define an operation with
>the same name), what problem does this solve?
>
>  
>
It does solve the problem quite nicely at the WSDL level.

Language bindings will have to deal with some potential naming 
conflicts, but
they should already be equipped to deal with them. Overloading, on the other
hand, would have the same problems and on top of that it would add typing
conflicts *and* force wsdl bindings to become more complex.

Roberto

Received on Thursday, 30 January 2003 21:47:23 UTC