Configurations are both complete snapshots and templates. A complete snapshot of a Plot comprises the kind of plot (its class), the set of datasets (which themselves refer explicitly to particular datasources), the time domain, line colors, line styles, and so on. When applying a configuration to an existing Plot, or creating a new Plot from the configuration, the configuration may need to be masked. For example, apply a configuration but don't change the current time domain of the plot. Or apply a configuration but resolve the datasets to a different datasource. This is like a mask on the configuration, but the mask is specific to the component. For example, a dataset can mask its datasource, as in apply this dataset and allow the datasource to be changed. A plot window can mask its geometry. So the component being reconfigured needs both the new configuration, a mask, and a context from which to replace the masked elements.
Is a mask really like inheritance? If one configuration can inherit from another, but specifically override parts of the ancestor, then that achieves the same as a mask, and it allows master templates for things like sizes and colors or whatever. By default a configuration starts out without a parent, and all of its elements have a 'blank' state. If the configuration gets reparented, then those blanks can be inherited. So configuration elements have one of three states: 'blank', 'default', or a value. The 'blank' state inherits the value from the parent. The 'default' forces the default value, whatever it is, even if there is a value in the parent which could be inherited. Otherwise, the configuration element contains the actual value to be used.
Dynamic inheritance would require that derived configurations be listening for changes to their parents, so that their child configurations and realized instances can be informed of the reconfiguration.
One possibility is that basic kinds of masks can be pre-defined, and the user can assign those masks to a configuration through the configuration library. Or the act of applying a configuration would first popup a window querying the user for the parts of the configuration which should be masked. However, how does a user choose with what the masked elements should be filled when realizing the configuration?
The best option I've thought of so far is to keep a context in the configuration library. The context indicates how a configuration selected from the library will be applied. The context contains the current DataSource, maybe even a current DataDomain, and a selection of options for determining how the context is applied. The user can select that the context not be applied at all, so a configuration will be used exactly as it was saved. Or the user can choose that all DataSet templates will be resolved to the selected DataSource. There can be choices for applying time, such as 'Use as is', 'Use the latest available', or 'Do not overwrite the time', and there might be a list of recently-used times from which to choose. The point to the context is to allow the user to recall one or several configurations and apply them to existing or new plots in the current session without stepping through a popup each time. I think this also matches more closely what the typical usage pattern would be. Given a library of configurations, the user opens a new DataSource (ie, a new netcdf file), selects that DataSource in the library context, then restores several plots from the configuration library. Each restored plot would be resolved to the DataSource selected in the library context. Essentially the context is the current mask with which configurations will be modified before being applied.