Per the Eventing spec:
When the Delivery Format feature is engaged the formatting of the going events occurs after any filtering. This ensures that regardless of what type of formatting might occur, the same Filter dialect/expression can be used to subset the event stream. 

Key point: formatting is done _after_ filtering.

However, the default filter dialect (xpath), has this:
Context Node: the SOAP Envelope containing the notification.

We have a catch-22 situation here.  We can't filter until we have an envelope, but we can't generate an envelope (based on the format) until after we filter.

Filtering over the soap envelope is probably a pretty bad idea to begin with.
Doing the filtering that late in the processing is going to be very costly.
Most pub/sub processors would probably prefer to filter out the list of
events long before the serialization into a soap envelope occurs.

And, the spec is silent on when the envelope is run thru the filter.
Its possible that due to formatting or security, by the time the message hits
the filtering processor, the event data isn't anything like the original
event XML - which means the xpath may not be able to work properly.

So my proposal is to change the xpath filter so that it operates over the
raw event XML:

Context Node: the root of the event XML.