A little history is needed regarding complex event filters. They use to include InView, TypeOf and RelatedTo.

The following clause was added to Part 4
"Any basic FilterOperator in Table 110 may be used in the whereClause, however, only the OfType FilterOperator from Table 111 is permitted." eliminating two of the options from this conformance unit.

I still feel this is in error; it was done since most systems would not be able to implement the RelatedTo operand easily on an event stream. The major reason I believe this is in error in that this same structure is used for Historical event filters and in many case implementing the "RelatedTo" Operand is very easy in a historical even retrieval. It is also one of the most often request event filter for historical data.

The reason OfType was left in a complex event filter is again do to implementation, (which I’m not sure is a good reason for it), not all system will be able to quickly in an event stream determine the OfType Operand –in particular – it may be fairly easy to get the type of the given event, but the OfType includes the idea of subtypes, the event would have to quickly be resolved into its type and to have a list of all parent types up to BaseEventType for it so that the filter can check if the OfType filter listed on of these Parent types.

I would propose the following fix
– Leave TypeOf in its own filter, but name it a different name, since it is the most common filter being used.
– Restore the RelatedTo and Inview filter operands to ComplexFilters.
– Remove the clause from Part 4 since this is something that really should just be defined in part 7 not in Part 4. That statement is two broad, in that even a future filter element would be excluded by it.

All of these conformance units should stay a optional, since they are being added to a release profile (but an argument could be made to change some to required, since currently no conformance test exist for this conformance unit, thus the change could not affect anyone’s current certification status – I would also support this)

As to the second part of this issue - currently no conformance units exist related to the number of items a filter can contain. I believe that new conformance units need to be added to reflect some limits on the size of a filter (how many statements it may have).

Note: Mantis Issue 2343 should be related to this one

Agreed to change the name of the CU after version 1.02 is published.

Adding RelatedTo and InView will need another Mantis issue as a "Feature Request".

this is proposed for v1.03

proposed to add this to v1.03