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

issue 7970: new proposal

From: Doug Davis <dug@us.ibm.com>
Date: Tue, 3 Nov 2009 17:04:32 -0500
To: public-ws-resource-access@w3.org
Message-ID: <OF513C87BC.9B42A3B9-ON85257663.0078FA0C-85257663.0079457E@us.ibm.com>
After some talks with Ram about this one, we came up with a new proposal 
that should allow the usecase I'm concerned about to work while still 
allowing for the event source to be the one to send out notifications:
- - - - - -
Event Source 
A Web service that accepts requests to create subscriptions. 

A one-way message sent to indicate that an event, or events, have 
occurred. Notifications MAY be sent by any endpoint including the event 
- - - - - - - 

Also, as I was reviewing ws-eventing I noticed some other places where we 
talk about the event source being the one to send notifications - we 
should change those too: 

During that time, notifications are delivered by the event source to the 
requested event sink... 
-- s/by the event source// 

the event source sends only notifications that match the requested filter 
-- change to: only notifications that match the requested filter are sent 
-- actually, we should change "notifications" to "events" too since we 
don't filter notifications, we filter events 

The event source sends notifications until ... 
-- change to: Notifications are sent until... 

This specification defines a method for transmitting notifications from 
the event source to the event sink through the use of the wse:NotifyTo 
-- s/from the event source// 

I don't think these changes any have normative impact on the spec or 
coding changes.  It just avoid any confusion that they might cause. 

STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Received on Tuesday, 3 November 2009 22:05:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:53 UTC