The variabletype has to have a modeling rule - they are not subtyped where they are used (i.e. in the typedefinition as an instance declaration - each use of them has a seperate string - so they must have a modeling rule.

They should be updated to indicate that the ietms shall not be subscribed for.

the text can also explain that if instance are created of the conditionType that these item should be singleton item (i.e. they point from all of the instance back to the type

UPdated text and provided a figure to illlustrate expected behavior

Needs 1.03 & 1.04 Errata to close.

Agreed to 1.03 & 1.04 Errata in Virtual F2F.

The changes in Part 9 are fine for me but this issue must be cloned to the nodeset to remove the Optional modeling rule on the instance declaration nodes of the AlarmTypes.

Paul is right with the modeling rule on the TwoStateVariableType

But my statement from the issue report is also true
"The bug is actually in the Nodeset. The TrueState and FalseState properties have an Optional modeling rule on the instance declaration nodes on the condition types. There should be no modeling rule to make it clear that these properties only exist on the instance declaration nodes."

Removing the optional modeling rule on the instance declaration would exactly to what the new figure describes.

The spec states "Servers shall not allow these Properties to be selected in the Event filter for a MonitoredItem".
But clients would see the event field in the type tree.
The client needs a way to detect that the property is not available as event field. The only option to provide this information is to check the modeling rule.
Maybe we should add also a statement for clients like "Clients should only subscribe to event fields that have a modeling rule"

Paul needs to add addtional tables to override the modeling rules on types that contain TwoStateVariableTypes from Optional to None. The nodeset will also need to be updated with the overrides.

Reviewed in UA WG meeting. 1.04,11 and 1.03.9 Errata updated.