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.
> > >
> > >
> >
> >

Received on Monday, 17 June 2002 18:18:45 UTC