The summary is a bit misleading, abstract DataTypes as a concept can basically never be allowed for Structure fields, as it is impossible to determine encodings for serializers otherwise (i.e. if it would be a "structure" type instead vs. ExtensionObject, no encoder could put more info there as the abstract type, as there is no identifier for a nested structrure field; which is why it must be an ExtensionObject). I would argue that ExtensionObject specifically is not an "abstract type" per se, but instead a "container type", which holds some Structure value. The idea itself is reasonable with the Description box, just wanted to make the distinction clear.

Do note that currently the system in theory technically could allow subtypes of the "allowed types". Additionally these might not be known thus not reference-able from within the NodeSet. So basically the only use would be within the Standard Model for e.g. PubSub configuration objects.

And as a extra clarification as this is really important and cannot be broken: For example,

<UADataType NodeId="i=376" BrowseName="AddNodesItem">
<DisplayName>AddNodesItem</DisplayName>
<References>
<Reference ReferenceType="HasSubtype" IsForward="false">i=22</Reference>
</References>
<Definition Name="AddNodesItem">
<Field Name="ParentNodeId" DataType="i=18" />
<Field Name="ReferenceTypeId" DataType="i=17" />
<Field Name="RequestedNewNodeId" DataType="i=18" />
<Field Name="BrowseName" DataType="i=20" />
<Field Name="NodeClass" DataType="i=257" />
<Field Name="NodeAttributes" DataType="i=22" />
<Field Name="TypeDefinition" DataType="i=18" />
</Definition>
</UADataType>

The NodeAttributes Field is defined as i=22 ("Structure" DataType node id). No abstract Structure types can ever be a Field of a Structure, as they are impossible to decode (there is no type info due to how Part 6 defines the rules for the binary encoding for Structure fields, they are just put in order there and the top-lvl Structure id is only used for the ExtensionObject that is put to the Variant and the fact that the field is of a Structure is determined from the top-lvl Structure's fields). Therefore given that the binary form must always hold, it means theoretically only the fields defined by the "i=22" could be fetched here (so none as it defines none; and typically abstract Structures are defined as abstract concepts within programming languages, so nothing that could be instantiated to represent that either). However given that this has always been defined as like this, stacks and SDKs basically have to treat the i=22 as ExtensionObject for decoding purposes. Which then allows having any Structure inside it. So it is really important that the i=22 stays there, but it is OK to have an additional XML Attribute that maybe could define the all known sub-types (which was the suggestion to my understanding).

Added an optional field AbstractDataType which means modellers can capture the true type information in the NodeSet.

If a field allows any subtype of an abstract DataType to be used then the DataType is set to ExtensionObject because it ensures type information is serialized with the field value. However, this results in auto-generated code that is not type-safe. Code generators can use this field to create code that has the types defined by the model.

We cannot resolve this issue without having a corresponding solution for the DataTypeDefinition attribute defined in OPC UA Part 3.

It is also not clear if the new Element is optional or not. I assume it has to be optional.

During June face to face we discussed a solution which would include:

• Added 3 additional enum values to StructureDefinition's StructureType field. This would also include clarifying the existing 3.
  0 - A structure without optional fields and no subtypes allowed
  1 - A Structure with optional fields and no subtypes allowed
  2 - A Union DataType and no subtypes allowed
  3 - A structure without optional fields and subtypes allowed
  4 - A Structure with optional fields and subtypes allowed
  5 - A Union DataType and subtypes allowed

Should the isOptional of the StructureField be redefined for the 3 new StructureTypes?
It could be defined as a byte without breaking the encoding which would allow both the existing isOptional and a new subTypesAllowed flag. The name of the field would be misleading (i.e. isOptional).
Do we really need to change isOptional? What if the StructureType was the only change? This would mean for types 3, 4 and 5 subtyping would be assumed for all fields of the structure.

More WG discussion is needed.

Added AllowSubTypes attribute to DataTypeField.

After we have decided to add the allowSubType bit to StructrueField, shouldn't there be something in Part 6 that describes its actual influence on the encoding? Without it, it would be just a new text in Part 3 that has no real consequences on the data encoding.

Added to new AllowSubTypes flag:

This means any encoded value is represented with an ExtensionObject (see 5.1.6).

Agreed to changes in Draft 1.05.19 in Virtual F3F.

Added reference to 0006478 which makes the same change in the 1.04.10 errata.
As a general rule each deliverable gets a difference mantis issue even for the same bug.

Agreed to changes in telecon.