Re: HTML version of operation name proposal

Hi,

See below for a comment on the uniqueness of operation names.

I also had a question about section 2.5.3: does anything need to be said
about "inherited" operations?  In particular, the description of the mapping
of {target namespace} only applies to operations defined in the portType
itself, not "inherited" ones.

John Colgrave
IBM
----- Original Message -----
From: "Roberto Chinnici" <roberto.chinnici@sun.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>; <www-ws-desc@w3.org>
Sent: Friday, January 31, 2003 2:46 AM
Subject: 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.

The Note at the end of the operation name proposal says:

"Due to the above rules, if two port types that have the same value for
their {target namespace} property also have one or more operations that have
the same value for their {name} property then those two port types cannot
both form part of the derivation chain of a derived port type. Therefore is
is considered good practice to ensure that operation names within a
namespace are unique, thus allowing such derivation to occur without error."

so if you have more than one portType in a namespace then the "good
practice" is to ensure that operation names are unique in the namespace as a
whole, not just in the portType.

If Sanjiva's WSDL document 1 were:

namespace=nsuri-1;
portType pt1 {
    operation o1;
    operation o2;
}
portType pt2 {
    operation o2;
    operation o3;
}

then this is not following the "good practice" as o2 occurs in both
portTypes and a portType cannot derive from both pt1 and pt2.  To follow the
"good practice" we would have to rename one of the o2 operations to a name
that did not occur in any portType in the namespace nsuri-1.  The end result
is that operation names should be unique within a namespace, not just within
a portType.

As has been mentioned, one way to achieve this is to have only one portType
per namespace.  Another would be to encode the portType name into every
operation, so we would have pt1_o2 and pt2_o2 in this example.

> >>>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 Friday, 31 January 2003 04:42:05 UTC