This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6595 - Eventing: WS-Eventing needs to specify behavior for empty filters
Summary: Eventing: WS-Eventing needs to specify behavior for empty filters
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: FPWD
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on:
Blocks:
 
Reported: 2009-02-19 06:45 UTC by Gilbert Pilz
Modified: 2009-04-21 21:32 UTC (History)
2 users (show)

See Also:


Attachments

Description Gilbert Pilz 2009-02-19 06:45:48 UTC
WS-Eventing needs to cover the following case: a Subscribe message is sent to an Event Source that supports filtering. The Subscribe message contains a wse:Filter element. The value of the @Dialect attribute of this element is understood and supported by the Event Source. However, due to various properties of the filter and/or the Event Source, the Event Source can determine that no Notifications will ever match this filter.

1.) We should define a fault for this condition, perhaps "EmptyFilterSpecified".

2.) In general it is not possible for an Event Source to determine, at Subscribe time, whether there will ever be any Notifications that match the filter. However, some Subscribers may want to know if any checking was done to determine if the filter was empty. There are a range of things we can do from offering some pious advice to Event Sources to make "best efforts" to defining policy assertions that describe, on a per-Dialect basis, the amount of checking that is performed.

Strawman proposal: define new fault and offer some pious advice on making "best efforts" to determine if the filter is empty.
Comment 3 Robert Freund 2009-03-11 17:45:22 UTC
Action-41 on Gil
Comment 5 Robert Freund 2009-03-24 19:49:51 UTC
2009-03-24 resolved with proposal contained in comment 4