W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > March 2009

Re: [Bug 6692] New: Remove Mode from the specification

From: Chou, Wu (Wu) <wuchou@avaya.com>
Date: Tue, 31 Mar 2009 17:01:40 -0400
Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112AAFD@300813ANEX2.global.avaya.com>
To: <public-ws-resource-access@w3.org>
Cc: "Gilbert Pilz" <gilbert.pilz@oracle.com>
Ops, that kitten slipped my fingers. It should be for another debate
that I was on, while typing my response to this one. 
Don't worry. No kitten is killed, just semantics are changed. 
Need to save sheeps from unintended collaterals. 
- WC
I'm sorry, but the hyperbole is getting a bit deep around here.
"Fundamentally change the semantics of event delivery in WS-E"? How?!?
It's an extension point (and a redundant one at that)! Extension points,
by their definition, are not allowed to "fundamentally change the
semantics" of anything!

If we're just going to trade wildly exaggerated, unsubstantiated claims,
I claim that, every time "Mode" is used, one of these kittens
<http://www.hoitytoitypersians.co.uk/>  is killed. Clearly we need
remove "Mode" before any more such innocent creatures are harmed!

- gp

Chou, Wu (Wu) wrote: 

	wse:Mode attribute in WS-E is just an extension point to allow a
subscriber to specify the required type of the push mode event delivery.
The importance of having Mode attribute in Delivery of WS-E is that the
event source have to fully understand/support the extension in the Mode
attribute; otherwise it must fault the event subscription with a
standard wse:DeliveryModeRequestedUnavailable fault. These are semantics
defined in WS-E specs, not from EPR.
	I am not convinced that EPR solves everything, including
Internet routing, etc. Removing Mode attribute is going to fundamentally
change the semantics of event delivery in WS-E. This is a protocol
change that can impact many applications and implementations. This is
not a case of removing redundancy in the specs.
	- Wu Chou
Received on Tuesday, 31 March 2009 21:05:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:34:35 UTC