Some Documentation of Issues associated with ticket:868
Consider two feed entries in pseudo CIM xml:
<docset> <sim> <uri>SA</uri> <codemods/> </sim> <model> <uri>MA</uri> <version>1</version> <bindings>stuff a </bindings> <...> </model> etc: <platform/> <files/> <experiment/> </docset>
<model> <uri>MA</uri> <version>x</version> <...> <bindings> default - but see note below </bindings> </model>
This situation could exist at any time: Model MA,x could exist after model MA,1 was exported via the export of simulation SB. It might be that the increment of the version of MA existed because either, there was a fix in the model description, or a fix in the default bindings. (Even though, actually, the bindings don't currently appear in the feed itself because they're currently an artifact of the way the questionnaire tries to save folks reentering material over and over again).
- Either way, the exported feed to ESG needs to be updated so ESG that know there might have been an important change to the model description. We need to do this because we bundle everything up for ESG to harvest.
- There is an edge case: we probably need to ensure that users don't increment a model version when what they really want to do is change the model itself - that is they've changed the model description so it can be used a different way in a different simulation. That's the current risk with Karl's proposals that the model name has to be same whether or not the ocean is turned on or off. We need to solve that with appropriate code mods (ticket:810).
- Now consider what happens to the metafor portal. We're harvesting both the model feed and the simulation feed. We're going to have distinguish between the two versions of the model in this portal ... so logically we're certainly handling something that feels like
<model> <bindings> stuff a </bindings> <codemods> from the simulation description </codemods> <unconfiguredModel> <uri MA> </unconfiguredModel> </model>and
<model> <bindings>default</bindings> <unconfiguredModel> <uri MA> </unconfiguredModel> </model>
The latter might be used in a different simulation. In which case you want to be able to difference those two distinct "configured" models as used in potentially different simulations. At the same time, you do want to handle the use and description of the "unconfigured" model (use case: centre A is using a differently configured version of model MA than centre B, but centre B owns and describes the unconfigured model MA.) In any case, how does the metafor portal handle these multiple versions of models with the same URI?
Interim Solutions (for ESG, it's not obvious this helps the Metafor Portal):
- Create a simulation feed independent of the docset feed (coz we don't want to update simulations when other parts of the docset are updated), and it can have a new feed in it's own right.
- Make docset itself a class, with a version and foreign keys to it's components, and use the old feed.
- Modify the CIMdoc class so that a save on it forces an increment on any docsets which reference it *(NB: the issue of putting a break in for ESG could be solved here too, by putting the qcvalid attribute on this thing.)
Longer Term Solutions: