How reset works in the typed data externalizer

The typed data externalizer differs from other externalizers because it does not maintain the list of tags stored during the initialization process. Therefore, it does not use tag instances to create the type instances when required. Instead, it keeps a list of type instances (which it creates from the tags read during initialization) and uses the list to instantiate the typed data element from a type. For this reason, the reset process for the type externalizer differs slightly from the other externalizers.

When an application requests a change to a type definition in the type externalizer, the type externalizer goes to the type instance and modifies it according to the new definition. Once the externalizer has modified the definition, whenever the externalizer instantiates a typed data element from that type, it uses the new type definition. Note that type instances created before reset process are not aware of the changes.

The reset process modifies a type definition instead of replacing it. The reset process does this so that it can automatically update other types with property descriptors pointing to the modified type provided the descriptors do not override anything in the referred type. The toolkit allows this because these descriptors maintain the same type instance. If the property descriptors do have any extra definition to override, the reset process does not automatically update the default descriptor for that type with the new type definition.

If the modifications to a type includes adding references to other types, the reset process recursively resolves these references. If these references point to new type definitions, they must also be in the file or the reset process throws an exception.

Removing a type definition removes all the information that the instance contained but it does not remove the type instance itself. This has the following impact: