I don't think you can just pass the event filter to the aggregated server as is in any case - the namespace associated with the items in the filter may be wrong. I'm assumming that the Aggregating server has a merged type system and the filter that was constructed was based on this merged type system. So as a minimum the selectClause and whereFilter must be processed for namespace translations.

Part 4 already describes the correct behaviour for the operands in the content filter description - in that they return a false (see Table 111 - Complex filterOperand definition)

The selectclause also correctly describes that a NULL is returned for any field that do not exist in an event that passes the filter.

So the issue is 7.16.3 EventFilter definition, where it allows a server to return an error regarding the selectClause if the error is true for all possible Events. The same statement applies to whereClause - i.e. all possible Events.

I would think that aggregating server must process both the selectClause and whereClause in any case to verify namespace Ids - would it be that hard to omit select item that do not exist in the aggregated server? As to whereClause items, it may be difficult to update a filter, but I would think that this is what the aggregating server must do in any case. Any whereCluase item that is not available in the server is just replaced with a "false" where it is referenced I would think only OfType could have a problem, so it is relativly quick to parse the event filter and verify that the typeid in an OfType exist in the Aggregated server, if not then updated filter to have a false in that given row.

Converting from local to remote namespace indexes is trivial and does not require that the filter be analyzed. Missing namespace URIs can be converted to 65535 and the aggregating server can handle them easily returning no match.

The merged type system may exist - but each aggregated server only supports a subset and it is not easy to determine which subset is supported - this is the problem that needs solving.

A potential resolution is a two stage approach:

The aggregator tries twice: once with the mapped filter - if it is rejected the clauses which cause the error are 'zeroed out' and it tries again.

zeroed out means they are set to a valid field that is likely to always be null.

we should recommend and field in the specification.

Randy will work with Paul to propose a viable solution.

Need input from Paul and Randy - can be a topic for the next face to face meeting.

Added the following clarification to 7.16.3 EventFilter:
Some Servers, like aggregating Servers, may not know all possible EventTypes at the time the EventFilter is set. These Servers do not return errors for unknown EventTypes or BrowsePaths.

Resolved in document IEC 62541-4 - Services [Pre-CDV] 1.02.06.doc

Reviewed and agreed to clarified text.