RE: [wsn] Analysis of filtering

["Patil, Sanjay" <sanjay.patil@sap.com>]

Title: Message

 

+1

 

Requirement of commutativity (or any particular positioning) on the open content filters is too strict.

 

Since we allow open content for filters, I think we are expected to remain open about the composition of filters also.  At the same time, defining the nesting/composition rules for filters in BaseN would pull in a lot of additional complexity, and I don't know if we want to go there either.

 

Perhaps we could have the BaseN spec 

- Define the composition rules for the three filters defined by BaseN (commutative, etc.)

- Allow open content filters to also utilize the composition rules defined by BaseN (a compositionRule attribute on the top level filter element with BaseN specific default value)

- Insert language to allow implementations (or other specifications) to define and use new composition rules.

 

Hopefully this will provide support for interoperable filters out of the box (spec defined) for the majority of use cases and still allow extensibility for the complex ones (80-20).

 

Thanks,

Sanjay

-----Original Message-----
From: David Hull [mailto:dmh@tibco.com]
Sent: Tuesday, Nov 23, 2004 13:40 PM
To: Steve Graham
Cc: wsn@lists.oasis-open.org
Subject: Re: [wsn] Analysis of filtering

Steve Graham wrote:

> For example, suppose dmhFilter has a "suppress all but every Nth message" option.  
> This seems like a perfectly reasonable, if arbitrary, filter on its own.  But it
> won't commute with anything.
Then whoever specifies the dmhFilter MUST state that the dmhFilter MUST be placed
last in the list of expressions to be evaluated.

The point was that such a filter could legitimately be used either before or after some other filter, with differing but equally legitimate effects.  Restricting it to some particular position just de-legitimizes one of those effects, for no apparent reason.

As far as I can tell, the requirement of commutativity is too strict.