RE: Rationale to close the operation overloading issue

While I agree with most arguments in favor of disallowing
operation overloading, I still find it highly unsatisfactory
not beeing able to describe service interfaces which *have*
overloaded operations. This is especially unsatisfactory
as there is no such restriction in SOAP nor WSDL 1.1.

Thus, I do not consider this discussion a waste of time.
In contrary, it appears to me that more discussion is required
to come up eventually with real solution instead of just
disallowing a common implementation technique (or enforcing
additional mappings).

Regards, Dietmar.

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Monday, June 17, 2002 1:42 PM
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 08:42:33 UTC