Section 6.3.4/5/6
Those variables should not be in the supertype (6.3.4) since LabelCollection (for ex.) doesnt need them. Better move those values to only the subtypes that need them.
In practice, OPENSCSSNCollectionDataType and OPENSCSLableCollectionDataType should be the same type (something like a OPENSCS<EVENTS>CollectionDataType ) and no variables; whereas there will be a type (with those variables) for the serial management side.

ALSO, the OPENSCSSNLabelPropertyDataType is in reality a key/value pair and it should be an optional property of the new OPENSCS<EVENTS>CollectionDataType.

I disagree with the assertion that the Label Collection does not need to information contained in the Collection Type.
I also disagree with the statement that the Label, SID, and Aggregation events are not "pool" events. Given the fact that this standard will be used for internal serial number management as well an industry or county wide serial number management, I can envision a scenario where you need to know the pool and state in order to determine what to do about the event. For example, I may need to handle Aggregation Events for Walmart pallets different form Costco pallets, and they use Walmart and Costco provided serial number rules and pools.

We need to discuss

The problem is the scope of the usage of these data types. The event method data types are semantically different to the sn pool method data types. As such mixing these results unclear fields of responsibilities and usages.
Also, the OPENSCSCollectionDataType contains data which is redundant to the SID event methods or just plain confusing (the 'State' especially)... Adding the 'Pool' information to the SID is fine but keep in mind that this information is not always available for 'Event'-Method invoker

Agreed to change 6.3.1.9 Input arg to OPENSCSSNCollectionDataType instead of OPENSCSLabelCollectionDataType.
Also LabelCollectsionType is no longer a subtype of SCSCollectionType.