After a Node has been published, modifying certain attributes constitutes a breaking change, while others may be changed without affecting backward compatibility. Some constraints are already implied—for example, the DataType of a Variable shall not be changed (see 3.2.12). In general, changes to attributes should be avoided unless there is a compelling justification.

Table 1 lists all Node attributes and specifies whether they may be modified without introducing breaking changes (column “Rule to avoid breaking changes”).

The table also indicates whether an attribute may still be changed by a Server implementation when a companion specification is implemented in the Server (column “Change in Server allowed?”). For example, the Description attribute, when provided by the companion specification, may be left out in the Server. This reduces memory consumption and may be helpful servers running in small, embedded environments. Or the text may be provided in other locales.

Note that the information if an attribute may be changed in the Server is not related to backward compatibility.

Table 1 – Rules for backward compatibly of attributes

NodeClass

Attribute

Rule to avoid breaking changes

Change in Server allowed?

Base

NodeId

Shall not change

No

NodeClass

Shall not change

No

BrowseName

Shall not change

No

DisplayName

May change; the meaning shall not change

Yes

Description

May change; the meaning shall not change

Yes

WriteMask

Typically, not defined; may be changed

Yes

UserWriteMask

Implementation-specific; is not defined

Yes (Calculated in server)

RolePermissions

Typically, not defined; may be changed

Yes

UserRolePermissions

Implementation-specific; is not defined

Yes (Calculated in server)

AccessRestrictions

Typically, not defined; may be changed

Yes

ReferenceType

IsAbstract

May be changed from true to false, but not vice versa

No

Symmetric

Shall not change

No

InverseName

May change; the meaning shall not change

Yes

View

ContainsNoLoops

Typically, not defined; may be changed

Yes

EventNotifier

Typically, not defined; may be changed

Yes

Object

EventNotifier

Typically, not defined; may be changed

Yes

ObjectType

IsAbstract

May be changed from true to false, but not vice versa

No

Variable

Value

Typically, not defined; may be changed

Yes

DataType

Shall not change

No, for InstanceDeclarations

Yes, for instances, if it becomes more restrictive (subtype)

ValueRank

Shall not change

No, for InstanceDeclarations

Yes, for instances, if it becomes more restrictive (as in subtype rules)

ArrayDimensions

Typically, not defined; shall not change

Yes, if not defined (per dimension)

AccessLevel

May be changed

Yes

UserAccessLevel

Implementation-specific; is not defined

Yes (Calculated in server)

MinimumSamplingInterval

Typically, not defined; may be changed

Yes

Historizing

Typically, not defined; may be changed

Yes

AccessLevelEx

May be changed

Yes

VariableType

Value

Typically, not defined; may be changed

Yes

DataType

Shall not change

No

ValueRank

Shall not change

No

ArrayDimensions

Typically, not defined; shall not change

Yes, if not defined(per dimension)

IsAbstract

May be changed from true to false, but not vice versa

No

Method

Executable

Implementation-specific; should not be defined

Yes

UserExecutable

Implementation-specific; is not defined

Yes (Calculated in server)

DataType

IsAbstract

May be changed from true to false, not vice versa

No

DataTypeDefinition

Shall not change

No

Remark: A special case is the SymbolicName, which is not an OPC UA attribute but can be defined in a UANodeSet. Changing a SymbolicName is not considered a breaking change; however, it should be avoided because it may affect code generation. Implementers may change the SymbolicName before using a standardized UANodeSet without violating the specification.