Re: [wsn] Analysis of filtering

[David Hull <dmh@tibco.com>]

I'm not convinced that nested structure is any more complex than coming up with implicit rules for evaluation.  Evaluating nested expressions only becomes difficult when you start to deal with variable parameters and recursive evaluation, neither of which I'm proposing.  I'm talking about expressions equivalent in form to

1 +  2 + (3 * 4)

not

a + b + (b*c where b = 4) where a = 1, b = 2, c = 3

or

f(3) where f(0) = 1 and f(n+1) = (n+1)*f(n).

We're XML experts, right?  Does nesting really scare us? :-)

I'm not going to go to the mat on this, but I think it's worth considering.  IMHO much harm has been done by trying to invent specialized evaluation rules in order to make syntax "nicer".

Patil, Sanjay wrote:

 

+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.