Missing DataTypeId in StructureFieldDefinition makes ListOf-types ambiguous and unreliable to resolve

[VasilBK]

Currently, the StructureFieldDefinition does not explicitly include the DataTypeId of the field. This creates ambiguity when dealing with structured fields whose types follow the ListOf naming convention.

For example, if a field has the type ListOfCustomDataType, the only possible workaround is to remove the ListOf prefix, resolve CustomDataType, and then read its NodeId. However, this approach relies entirely on naming conventions and not on actual structural references.

There is no guarantee that a corresponding scalar type (CustomDataType in this case) exists or is even intended to exist. A custom DataType could be defined as ListOfCustomDataType without defining a scalar CustomDataType counterpart, or with entirely different semantics.

In such cases, stripping the prefix and attempting to resolve the type would lead to incorrect or undefined behavior.

Without explicitly providing the DataTypeId in the StructureFieldDefinition or as a NodeId Attribute of the ListOf-AttributeType, it is impossible to reliably and deterministically resolve the field’s DataType.