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 04:20:44 UTC