RE: Rationale to close the operation overloading issue

Jeff,

Whether types are different wrt overloading is an implementation language
issue. In the example, int and float are different in Java so you can have
a method for each. The issue is how do you represent overloaded methods in
the Web service. I am pointing out that you can define a Web service that
captures the semantics of overloading without allowing overloaded operation
names in the Web service.

When you create a Web service from a class that has an overloaded method,
you need to map each method signature to a different child <element> of the
<choice>.

Conversely, if you are generating a stub from WSDL that contains an
operation that has a <choice> message type, then you could generate
overloaded methods, one for each child of the <choice>. If the XML Schema
types of two or more children of the <choice> mapped to the same
programming language type (e.g. XML Schema has more numeric types than
programming languages typically have) then you would have to munge the
operation name, perhaps by appending the child element name.

Arthur Ryman


                                                                                                                                    
                    Jeff Mischkinsky                                                                                                
                    <jeff.mischkinsky@o       To:     Arthur Ryman/Toronto/IBM@IBMCA, Jochen.Ruetschlin@DaimlerChrysler.com         
                    racle.com>                cc:     jmarsh@microsoft.com, www-ws-desc@w3.org, www-ws-desc-request@w3.org          
                    Sent by:                  Subject:     RE: Rationale to close the operation overloading issue                   
                    www-ws-desc-request                                                                                             
                    @w3.org                                                                                                         
                                                                                                                                    
                                                                                                                                    
                    06/20/2002 12:19 PM                                                                                             
                    Please respond to                                                                                               
                    Jeff Mischkinsky                                                                                                
                                                                                                                                    
                                                                                                                                    




At 09:03 AM 6/20/02, ryman@ca.ibm.com wrote:

>Jochen remarked that overloading was needed to avoid operation name
>munging. However, you could avoid name munging by using a suitable message
>type. For example, suppose you have a class that has operations
>
>print(int) and
>print(float).
>
>These could be mapped to a single Web service operation named print that
>had an input message that allowed either int or float, e.g.

How does one know (i.e. what normative rules are applied) that "int" and
"float" are different types wrt overloading semantics.
I think this is just a roundabout way of asking what are the type
equivalence rules?

jeff


>     <complexType name="printType">
>         <choice>
>             <element name="int" type="int"/>
>             <element name="float" type="float"/>
>         </choice>
>     </complexType>
>
>Arthur Ryman
>
>
>
>
>                     Jochen.Ruetschlin@DaimlerCh
 >
>                     rysler.com                        To:
> <jmarsh@microsoft.com>
>                     Sent
> by:                          cc:     <www-ws-desc@w3.org>
 >
>                     www-ws-desc-request@w3.org        Subject:     RE:
> Rationale to close the operation overloading issue
>
>
>
>
>                     06/20/2002 10:59
> AM
>
>                     Please respond
> to
>
>                     Jochen.Ruetschlin
 >
>
>
>
>
>
>
>
>
> > Last time we visited this issue [1], nobody spoke in favor of retaining
>overloaded operations, so we did have consensus to remove them.
>
>Sorry, I could not attend this telcon (and I have not seen that this topic
>was
>scheduled for this day; cf. [1] -- and afterwards, I somehow missed
reading
>the
>minutes) -- But anyhow, this is  my problem :-)
>
> > The burden on proof is on Jochen to show that his arguments are new.
>
>IMO I have done so, because aspects of clearness and structuring are not
>discussed so far.
>
>Regards
>
>jr.
>
>[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0189.html
>
>Jochen Ruetschlin
>DaimlerChrysler · Research and Technology
>Data and Process Management (RIC/ED)
>P.O. Box 2360 · D-89013 Ulm (Donau) · Germany
>Visitor's address: Wilhelm-Runge-Straße 11
>Phone:   +49.731.505-2830
>Telefax: +49.731.505-4401
>Internet E-Mail: jochen.ruetschlin@DaimlerChrysler.com
>
>
>
>
>
>            jmarsh@microsoft.com
>            Gesendet von: www-ws-desc-request@w3.org
>            18.06.2002 00:22
>
>                       An: www-ws-desc@w3.org
>                       Kopie:
>                       Thema: RE: Rationale to close the operation
>overloading issue
>
>
>Last time we visited this issue [1], nobody spoke in favor of retaining
>overloaded operations, so we did have consensus to remove them.  Since we
>didn't create a long email thread on this issue, I asked that we at least
>get
>the rationale for our decision on the record, which Joyce has provided.
>So, I
>consider this issue closed unless new information is unearthed..  The
>burden on
>proof is on Jochen to show that his arguments are new.
>
>[1]
>http://lists.w3.org/Archives/Public/www-ws-desc/2002May/att-0223/01-minutes-irc-

>
>02-05-23.htm#item04
>
>
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> > Sent: Monday, June 17, 2002 4:42 AM
> > To: www-ws-desc@w3.org
> > Subject: Re: Rationale to close the operation overloading issue
> >
> >
> > Sorry, I wasn't implying you were wasting time .. just wondering
> > where we are.
> >
> > I agree with you its a useful feature to have, however, I am not
> > certain the ensuing complexity is justified. Basically, the question
> > is whether its in the 80 of 80-20 rule.
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: <Jochen.Ruetschlin@DaimlerChrysler.com>
> > To: <sanjiva@watson.ibm.com>
> > Cc: <www-ws-desc@w3.org>
> > Sent: Monday, June 17, 2002 2:20 PM
> > Subject: Re: Rationale to close the operation overloading issue
> >
> >
> > >
> > > Sorry Sanjiva, I was not aware that there already was a _consensus_
for
> > > removing operator overloading (I read several arguments; some pros
from
> > Russell
> > > and myself and some cons from different persons). If I'm really the
>only
> > > person, who thinks that operation overloading in WSDL is a useful and
> > > realizable must/should feature, I'm sorry for wasting time in this
list
> > by
> > > re-discussing the issue.
> > >
> > > Regards
> > >
> > > jr.
> > >
> > > Jochen Rütschlin
> > > DaimlerChrysler · Research and Technology
> > > Data and Process Management (RIC/ED)
> > > P.O. Box 2360 · D-89013 Ulm (Donau) · Germany
> > > Visitor's address: Wilhelm-Runge-Straße 11
> > > Phone:   +49.731.505-2830
> > > Telefax: +49.731.505-4401
> > > Internet E-Mail: jochen.ruetschlin@DaimlerChrysler.com
> > >
> > >
> > >
> > >
> > >
> > > sanjiva@watson.ibm.com
> > > Gesendet von: www-ws-desc-request@w3.org
> > > 17.06.2002 05:44
> > >
> > > An: moreau@crf.canon.fr, Jochen Ruetschlin/FT/DCAG/DCX@WK-EMEA2
> > > Kopie: www-ws-desc@w3.org, joyce.yang@oracle.com
> > > Thema: Re: Rationale to close the operation overloading issue
> > >
> > >
> > > If I recall correctly there was pretty good consensus to remove
> > > operator overloading and we were waiting for the rationale from
> > > Joyce (now I don't recall why). Are we re-discussing the issue?
> > >
> > > Jonathan: How do we close this issue (one way or the other)?
> > >
> > > Thanks,
> > >
> > > Sanjiva.
> > >
> > > ----- Original Message -----
> > > From: <Jochen.Ruetschlin@DaimlerChrysler.com>
> > > To: <moreau@crf.canon.fr>
> > > Cc: <joyce.yang@oracle.com>; <www-ws-desc@w3.org>
> > > Sent: Friday, June 14, 2002 7:43 PM
> > > Subject: Re: Rationale to close the operation overloading issue
> > >
> > >
> > > >
> > > > > I don't think the point is about the least common denominator,
but
> > about
> > > not
> > > > tying
> > > > > a particular Web Service to a given implementation. Allow
operation
> > > > overloading
> > > > > would, IMO, just do that.
> > > >
> > > > Seen from an implementational point of view, this is correct. But
if
> > you
> > > take
> > > > operation overloading as a kind of structuring mechanism for adding
> > more
> > > > semantical information to the description, I think this is
> > implementation
> > > > independent. For example: I have one (logical) operation
"getAddress"
> > > which
> > > > returns the address of a certain person. With an overload mechanism
I
> > can
> > > > express the fact, that the following operations are "instances"
(not
> > in
> > an
> > > > implementational way but in a logical) of an operation providing
one
> > > certain
> > > > functionality: returning an address of a person which is identified
>in
> > > > different ways.
> > > >
> > > > getAddress(socialNo)
> > > > getAddress(name, surname)
> > > > getAddress(login)
> > > > ...
> > > >
> > > > Having no overload mechanism results to a more or less unstructured
> > and
> > > maybe
> > > > missleading description (depending from the authors preferences),
>e..g.
> > > >
> > > > <operation name="getAddressFromSocialNo" ....
> > > > <operation name="getAddressWithNameSurname" ...
> > > > <operation name="getAddressFromLoginInfo" ...
> > > >
> > > > IMO it seems easier to map from WSDL to the PL then the other way
> > round
> > > (for
> > > > the last case see also the comment from Russel [1]).
> > > > Finally some mapping between the "ASCII-based" operation name and
the
> > real
> > > > method name of the implenentation has to be done in any way. So,
why
> > it
> > > should
> > > > not be possible to do so with additionally considering the message
> > format
> > > (i.e.
> > > > the input parameters)?
> > > >
> > > > WSDL with overloaded ops | PL without overload ops.
> > > >
>======================================================================
> > > > getAddress(socialNo) -> getAddressFromSocialNo(socialNo)
> > > > getAddress(name, surname) -> getAddressWithNameSurname(socialNo)
> > > > getAddress(login) -> getAddressFromLoginInfo(login)
> > > >
> > > > Now it could be stated, that this again results to unstructured
(and
> > maybe
> > > > missleading) method names as shown above in the oposite direction.
>But
> > (1)
> > > > there are no other possibilities in this PL (because we have no
> > overload
> > > > mechanism) and an implementation has to be done anyway in this way.
> > And
> > > (2) I
> > > > think we have to decide, if we want to have complicated identifiers
>in
> > the
> > > > description (i.e. the WSDL document), which is published, or in the
> > > > implementation, which is usually private.
> > > >
> > > > I'm not sure if additionally considering the input parameters for
>this
> > > mapping
> > > > is such a big deal, apart from the fact that --- as far is I
> > understand
> > > our
> > > > activities --- we are focusing on the description of interfaces and
> > not
> > > how to
> > > > implement the mapping in a efficient way (which are implementation
> > > details).
> > > >
> > > >
> > > >
> > > > So what I want to say is, that overloading of operations is not
>(only)
> > an
> > > > implementational aspect. It is a usefull feature and enhances the
> > > > expressiveness of an interface description like WSDL . Yes, it's
true
> > that
> > > > there are actually (not always trivial) implementation aspects
which
> > has
> > > to be
> > > > considered when implementing the mapping, but IMO these seems
>solvable
> > and
> > > are
> > > > out of the focus of our activity.
> > > >
> > > > JM2p
> > > >
> > > > jr.
> > > >
> > > > [1]
http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0172.html
> > > >
> > > >
> > > > Jochen Rütschlin
> > > > DaimlerChrysler · Research and Technology
> > > > Data and Process Management (RIC/ED)
> > > > P.O. Box 2360 · D-89013 Ulm (Donau) · Germany
> > > > Visitor's address: Wilhelm-Runge-Straße 11
> > > > Phone:   +49.731.505-2830
> > > > Telefax: +49.731.505-4401
> > > > Internet E-Mail: jochen.ruetschlin@DaimlerChrysler.com
> > > > Internet:
> > > > http://www.informatik.uni-
> > stuttgart.de/ipvr/as/personen/ruetschlin.html
> > > >
> > > >
> > > >
> > > >
> > > > moreau@crf.canon.fr
> > > > 14.06.2002 12:11
> > > > Bitte antworten an moreau
> > > >
> > > >
> > > >
> > > > An: Jochen Ruetschlin/FT/DCAG/DCX@WK-EMEA2
> > > > Kopie: www-ws-desc@w3.org, joyce.yang@oracle.com
> > > > Thema: Re: Rationale to close the operation overloading issue
> > > >
> > > > I don't think the point is about the least common denominator, but
> > about
> > > not
> > > > tying
> > > > a particular Web Service to a given implementation. Allow operation
> > > overloading
> > > > would, IMO, just do that.
> > > >
> > > > Jean-Jacques.
> > > >
> > > > Jochen.Ruetschlin@DaimlerChrysler.com wrote:
> > > >
> > > > > As stated in 2.1 of our charter
> > > > (http://www.w3.org/2002/01/ws-desc-charter#prog> ) the WSDL
framework
> > "is
> > > not
> > > > geared towards any programming language". The
> > > > > other way round this could mean, that we should not exclude
useful
> > > features
> > > > > only because some --- let me be more restrective and say:
"exotic"
> > in
> > > the
> > > > sense
> > > > > of not used in a broad way --- programming languages does not
allow
> > > function
> > > > > overloading.
> > > >
> > > >
> > >
> > >

--
Jeff Mischkinsky                    jeff.mischkinsky@oracle.com
Consulting Member Technical Staff   +1(650)506-1975 (voice)
Oracle Corporation                  +1(650)506-7225 (fax)
400 Oracle Parkway, M/S 4OP960
Redwood Shores, CA 94065 USA

Received on Thursday, 20 June 2002 14:32:04 UTC