I think this may be another case where we should define the semantics
in terms of some naive evaluation algorithm, with the understanding
that the implementation doesn't have to be naive. The one that springs
to mind is just to evaluate each filter, in order. If order matters,
the user can control it directly. If it doesn't the NP can take that
into account in its optimizations.
For example, the built-in filters commute, so if the filter consists
only of built-in filters, the NP knows it can re-arrange them however
it likes for performance.
On the other hand, if dmhFilter doesn't commute (or the NP can't easily
figure out whether it does or not), then the NP will have to drop back
to a particular order.
Even then, it has some freedom. If the filter looks like
<filter>
<topic/>
<selector/>
<dmhFilter/>
<precondition/>
</filter>
it can still evaluate topic and selector in either order, even if it
knows nothing at all about dmhFilter.
It may well be that in the corner cases, where there is a non-standard
filter and an NP that doesn't know much about it, we lose performance.
(Even then, why is the NP accepting a filter it knows nothing about?)
But we needn't lose it in the usual case, even if we specify in-order
evaluation semantics. The NP can do whatever it wants as long as the
results are equivalent to the specified semantics (we might want to say
that specifically).
Patil, Sanjay wrote:
Message
Where do we draw the line? Defining nesting may
not be so hard for us, but the specification is not exactly aimed at
ourselves :-)
There are all sorts of possibilities for
composing filters ranging from defining simple commutative
filters (which is what we should include in the spec, IMHO), all the
way to someone deploying entire business rules in the form of
filters. One may possibly compose rules for detecting when a particular
IT event qualifies as a Sarbanes Oxley material event and put these
rules in the form of filters in the Subscription! What is the
complexity of such rules language - I don't know. Do we want to
explicitly prohibit such usage - I don't think so either.
So basically, if we bake in simple filters and
simple rules for their composition in the core spec, we will have
a simple and fairly useful spec for majority of the use cases and we
will still leave the door open for unlimited extensibility for those
advanced users out there.
Just my 2 cents.
Thanks,
Sanjay
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
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.
|