My opinion:
The client should expect that each change in value will also always update the source timestamp. A trigger set to STATUS_VALUE_TIMESTAMP shall report a notification for every change in value.

The specification states that "the deadband filter can be used in addition ...". This should be changed into "the deadband filter shall be ignored".

I would think that filter are additive, i.e. it has to pass all filters. If the filter is an aggregate filter and the VQT is also selected, the aggregate processing should be performed and then if the value, quality or timestamp changes as a result of the aggregate processing then the value shall be reported.

In the future I think other filters may also be developed, and ignoring some while reporting other will make it very complicated and difficult to understand. I think any additional filters (besides VQT) are pre-filters and the VQT processing only occurs if the value is passed on by the pre-processing.

Thank you Paul/Karl. You both offer compelling arguments. I can see pros/cons for both.

My opinion: I think that the deadbandAbsolute must be obeyed even if the filter is VQT. Since the deadband was requested, it must be honored. Whenever the value changes it must pass the deadband filter to constitute a value change. If only the sourceTimestamp changes then technically the client asked for a notification, so that should be honored too. In this case, if a sourceTimestamp was the only thing to change, then the previous value that was sent to the client (previously screened by deadband) would be sent again.

This is a tough one...

Added clarification that Deadband can only be used with trigger STATUS_VALUE_1.
Changed in document "OPC UA Part 4 - Services RC 1.02.18 Specification.doc"

Reviewed and agreed to changes with some edits during the call.