RE: HTML version of operation name proposal

> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
> Sent: 31 January 2003 09:42
> To: Roberto Chinnici; Sanjiva Weerawarana
> Cc: Martin Gudgin; www-ws-desc@w3.org
> Subject: 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.

In section 2.4.3[1] the mapping rule for the {operations} property of a
port type is as follows:

	The set of port type operation definitions corresponding to the 
	operation element information items in [children], if any, plus 
	the set of port type operation definitions in the {operations} 
	property of the port type definitions in {extended port types},
if any.

Note that this definition is recursive, so it walks all the way back up
the inheritance hierarchy until you hit the top(s). So that's how
inherited operations get into the derived port type. 

Due to the the way the mapping for {target namespace} is defined in
2.5.3[2] the value of that property is ALWAYS the same as target
namespace property of port type which actually defines the operation.

Hope this helps,

Gudge

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=
1.18.2.1&content-type=text/html#PortType_Mapping
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=
1.18.2.1&content-type=text/html#PortTypeOperation_Mapping

> 
> 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 12:03:29 UTC