At the moment the code generators generate an ExtensionObject for a StructureField if the DataType is an abstract structure data type.

The problem is that the knowledge about the isAbsract is only on the DataType node but not on the DataTypeDefinition. Therefore it is only known inside the nodeset/address space but not in DataTypeSchemaHeader.

In addition this works only if the data type is abstract but not if you want to use a concrete type but allow subtypes.

We can not change the StructureField structure. We can only do a hack with the maxStringLength in StructureField since this one is not needed if the field is a strcuture.

At the June WG meeting we agreed on the following solution.

The StructureDefinition DataType will be enhanced to extend the structureType with 3 new enumeration values and the StructureField DataType will be enhanced to overload the isOptional Boolean for these 3 new enumerations. The 3 new types will be extensions of the current 3 by adding allowSubTypes flag in addition to the existing isOptional flag by redefining it as a byte. This will ensure no change to the encoding of this type.

Extended 8.48 StructureDefinition and 8.50 StructureField to support subtyping of DataTypes

I suggest to add following constraining condition when any of the "new" structureTypes is used (3, 4, 5):

If the allowSubTypes bit is 0, the dataType shall be a concrete type.

Or, formulated the other way round:

If dataType is abstract type, the allowSubTypes bit shall be 1.

Agreed with suggested addition.
Now it states
"If the structureType is Union_2 this field shall be ignored.
If the structureType is StructureEx_3, StructureWithOptionalFieldsEx_4 or UnionEx_2 this field is used as an emumeration with 2 bits defined as:
Bit 0 when TRUE indicates the data type field in a Structure is optional.
Bit 1 when TRUE indicates the data type field in a Structure allows subtyping. If the data type field is an abstract type this bit shall be set to TRUE."

Waiting for Mathias to review to close.

rethinking the proposed approach.

During Working Group review the proposal. Issues related to the encoding with non-binary encoders was raised. While recasting the boolean bit as a byte will work for binary encoding and not change the on the wire format it will break other encodings and possibly SDKs as they expect a boolean.

New proposal:

• Stay with isOptional as a boolean.
• Add 2 new enum types not the 3rd proposed StructureWithOptionalFieldsEx_4
• When using the 2 new enums the isOptional is actually a isAllowSubTypes indication.

Need an Errata for 1.04

Updated the descriptions of StructureDefiniton and StructureFieldDefinition to describe the compromised solution agreed to today.
Also broke out the StructureType into a proper definition table for the enum.

Agreed and accepted the updated next in Part 5 version 1.05.
Can't close until we decide what the Errata for 1.04 should say.

The final changes applied to 1.05 included changes to the StructureDefinition's structureType description and the StructureField's dataType and isOptional descriptions.
The attached document includes a diff of th 1.04 vs. the 105 versions of the changed sections.

Added Errata to 1.04.10 describing the changes.

Agreed to 1.04.10 Errata.