- From: <bugzilla@jessica.w3.org>
- Date: Sun, 09 Jan 2011 02:20:32 +0000
- To: public-ws-resource-access-notifications@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11703 --- Comment #1 from Doug Davis <dug@us.ibm.com> 2011-01-09 02:20:32 UTC --- Eventing and Enum deal with filters slightly differently. In particular, enum has this text under the definition of "Filter": ==== If the data source supports filtering and the requested dialect but cannot process the requested filter content, the request MUST fail, and the data source MUST generate a wsen:CannotProcessFilter fault. ==== In cases where the filter expression is bad (e.g. a syntax error) I believe that the above text in enum will case a wsen:CannotProcessFilter fault to be generated. However, I don't see a similar fault defined for eventing. This leads me to believe that we have an interop issue in the case where someone provides a bad filter to a Subscribe() because the fault returned is undefined. Proposal: add the above text and corresponding fault to eventing. Additionally, there's another issue here. The above fault can only be generated during subscribe time. However, not all event sources will evaluate the expression at that time - some may only do so afterwards (while processing new events). Its not clear to me what should happen in this case. I'm leaning towards us changing the spec so that when this happens the Subscription terminates (unexpectedly - e.g. generate an endSubscription msg) so that the sink knows why its not receiving any notifications. But I'd like to discuss this in the group. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug.
Received on Sunday, 9 January 2011 02:20:33 UTC