This wiki page documents  ticket 343

Telco notes

To support the material in Marie Pierre's powerpoint .

Decision on XML structure

• components consist of
  • A definition
  • 0..n components
  • 1..n parametergroups
• parametergroups consist of
  • 0..1 title
  • 0..n constraints.
  • 0..n parameters.
• parameters consist of
  • A definition subelement
  • A name attribute (text)
  • A choiceType attribute from ('OR','XOR','keyboard','couple')
  • If OR or XOR, value subelements
  • If keyboard, an optional unit subelement
• A constraint consists of
  • Some text enclosed and
  • 1... n parameters
• A definition element simply has text enclosed.

Some decisions

1. Constraints consist of two sorts (both of which are for questionnaire guidance, and don't survive to the CIM ...):
   1. "parsable" ones, that Rupert's validation code will use, and
   2. Free text ones.
2. No cross component validation is not currently supported but could be if required (but would need an extension to the mind-map syntax).
3. Rupert will put empty definitions in the XML (for components and parameters, but not yet for values), and
4. Bryan will produce popups. Maybe the absence of definitions will then be more obvious.
5. We will deprecate the [info] syntax: Rupert will flag them as errors.

Some issues:

1. BL: Shouldn't we keep the constraints in the CIM documents somehow, they guide how the material was made ...
   • RF: My view on sticking constraint info into the CIM is that we shouldn't. It is the same issue with the component hierarchy. Should we record what is valid there too and what might have been included but was not?. My preference would be to mark the CIM documents as being CMIP5 compliant. We can then refer back to the many different constraints that were used to create and validate CMIP5 CIM instances.
   • BL: Not so sure, but am happy to park it for the long term. It's certainly not a must have any time soon.
2. For Bryan: need to make sure that we have one form for all the parameters on display, so the class structure needs to reflect that. Might need mapping between the outside classes and internal classes.
3. RF: Shouldn't we have a definition for the parametergroups? They may only be labels in the questionnaire but they are a logical grouping of some science and will become complex properties in the CIM.
4. RF: I think we will have one nameless parametergroup for every component. This is where we will place parameters that are not part of a hierarchy and any new parameters that are added. I propose that a parameter group that has no name will be ignored when creating the CIM as it is purely used as a container for the questionnaire.
5. MPM: component identity: We (in fact I) have to be careful with migrating what was formerly components into parameter groups (think about attributes/functionality lost in the operation and consequences: code modifications, references, component type, inputs/coupling). In particular be careful with parameter groups that do not deal with numerical aspects (scientific/physical).