- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Fri, 31 Jan 2003 07:27:48 +0600
- To: "Roberto Chinnici" <roberto.chinnici@sun.com>
- Cc: "Martin Gudgin" <mgudgin@microsoft.com>, <www-ws-desc@w3.org>
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!
> >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.
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.
We removed operation overloading before we introduced inheritance.
I think we need to revisit that decision and bring it back.
> >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 ;-).
> 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.
> 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??
> 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.
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?
Sanjiva.
Received on Thursday, 30 January 2003 20:30:36 UTC