W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: Explaining visibility, take 54

From: Geoff Arnold <Geoff.Arnold@Sun.COM>
Date: Sun, 11 May 2003 09:35:42 -0400
To: Mark Baker <distobj@acm.org>
Cc: www-ws@w3.org
Message-id: <7623888F-83B5-11D7-9E35-000393C53568@sun.com>

On Sunday, May 11, 2003, at 07:47  AM, Mark Baker wrote:
> On Fri, May 09, 2003 at 12:11:22PM -0400, Anne Thomas Manes wrote:
>> Although it's conceivable that people might want to build an 
>> intermediary
>> dedicated to processing a specific type of SOAP message, it's not the 
>> normal
>> practice.
> The purpose of my initial message in this thread was to highlight that
> *IF* an intermediary were programmed to understand a specific type of
> SOAP interface, necessarily), *THEN* it would have vastly superior
> visibility to one that didn't.
> For example, a stock quote analysis intermediary would have better
> visibility when placed between a stock quote client and a stock quote
> server, than it would between a cake baking client and a cake baking
> server.
> Do you not agree?

I think one must "agree" in the same sense that one must agree that the 
efficient form of psychotherapy is the Vulcan mind-meld. It's not a 
useful use-case....

More seriously, it would be undesirable of someone (though surely not 
Mark!) were to try to argue from your example to the general principle 
improving visibility involves the inclusion of deep domain- or 
semantics to the intermediaries. As Anne and others have emphasized, the
primary business requirement here is to be able to get the maximum 
in the generic case. Visibility is not an end in itself: it is required 
to support
objectives such as traffic analysis, delegation, conformance, 
and a bunch of other stuff (even Homeland Security, I guess).

Let's leave deep semantics to the Vulcans.... If we feel the need to 
put more work
into visibility at this stage, I suggest that we begin with some use 
cases. There
are plenty of candidates.
Received on Sunday, 11 May 2003 09:35:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:08 UTC