The Nodes in question are metadata that only show up on the type Node so the missing ModellingRule is intentional.

This is a problem with Part 9.
Moving the issue,

The UANodeSet is right, the spec has the wrong modeling rules.

See also related issue for Programs (Part 10) 0003521

Document 1.04.05 contains the updates (made changes as requested)

The change does not make sense for state machines that contain optional states and transitions. the instance version of it will reflect which of the states and transition are supported by the particular instance.

This issue needs to be reassigned back to the nodeset file in my opinion - we can discuss it in the next UA call.

Paul needs to clone this to Part 5 also.

Fix statemachines that are always the same to be none, left ones that are to be instance specific to have modeling rules of mandatory or Optional

Need more discussion on this mantis issue

PackML information model has state machines. by there definition a state machine has fixed names (they don't have nodeids). all instance of the type they defined pick which of the predefined states and predefined transition they will support. The instance expose the states that are part of that instance (as well as transitions). The current list of modeling rules do not allow us to model this state machine. We have nodeid to identify the state and transitions - all instance need to have the same nodeid for states and for transition, but each instance needs to be able to expose only the states that apply for that instance.

I would propose the following fix:
we need a pair of new modeling rules OptionalFix and MandatoryFixed. These rules would behave like none, in that no new nodes would be created as part of the instance, but unlike none, the reference used to define the nodes in the type would exist in the instance, they would just point to the node in the type.
mandatoryFix would mean the node would always have the reference, optionalFix would mean some instance would include other would not.

We already have a precedent with TwoStateVariableType. This type we have two non-hierarchical references defined to point to an instance of StateType.

We should follow the same pattern for optional states.

The two reference in question point to the related states (HasTrueSubState and HasFalseSubState) Allowing the TwoStateVariableType to indicate what statemachine it is a substate of, which is different then indicating what states on a state machine are actually available. The HasSubStateMacihine reference is a non-hierarchical reference and these additional reference server the same purpose but allow a link to something that is not a full statemachine.

Would we define additional reference for which states & transitions are supported? So each instance would have a lot of non-hierarchical reference. what would the expect behavior of a client be if no reference are found, what is just one is found?

We created the TWOStateVariableType to create a simplification of a statemachine - one in which only two states are available and no transition or effects are listed. It eliminated a lot of nodes from an alarm instance, which makes sense for most alarms, but this issue is wider that just alarms - StateMachines in Programs or companion specifications are not worried about node counts, and they would like to see the available states and transitions

Updated All StateMachine to set States and Transitions to have no Modeling rule. Added text to StateMachines that might have instances where some states and/or transition are not exposed, to expose ValidateStates and ValidTransitions optional properties allowing clients to determine what states are valid for the given instance

Agreed to changes edited in 1.04.07.