W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > June 2005

RE: Operation Name Mapping Requirement Bug

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 9 Jun 2005 14:29:40 -0700
Message-ID: <7DA77BF2392448449D094BCEF67569A507D84243@RED-MSG-30.redmond.corp.microsoft.com>
To: "Arthur Ryman" <ryman@ca.ibm.com>
Cc: <public-ws-desc-comments@w3.org>
Thank you for your comment, which we tracked as LC82 [1].  The WG agreed
to fix this by adopting the proposal at

If you find this resolution unacceptable please let us know within two


[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC82




From: public-ws-desc-comments-request@w3.org
[mailto:public-ws-desc-comments-request@w3.org] On Behalf Of Arthur
Sent: Thursday, November 11, 2004 2:44 PM
To: public-ws-desc-comments@w3.org
Subject: Operation Name Mapping Requirement Bug


The Operation Name Mapping Requirement [1] has a bug. 

Consider an interface that has two operations that both return the same
GED output message, e.g. a Car search service that has findByColour and
findByHorsepower operations which both return ListOfCars. Assume this
operation uses a request-response MEP so the response is always
corelated with the request. 

According to the ONMR, these operations are ambiguous because they have
the same GED for their output message. The Interface component must have
either a Feature or an Extension element component that describes how
the sender is enabling the recipient to distinguish the messages. 

This is a spec bug since in this case there is no ambiguity on the input
messages. The requirement text needs to be corrected to restrict the
case where the ONMR applies. Also, even those the output messages are
the same, there is no amibuity since the output is corelated with the


Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/
Received on Thursday, 9 June 2005 21:30:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:57 UTC