Read *.ssv file in ExternData about externdata

[tbeu]

Parameterization by XML files already is supported (but not from tag attributes).

Not sure what the use-case is and your expectations are. Within ExternData, there is no magic planned, for extracting the SSP zip container and importing, connecting and parameterizing the extracted FMUs. This would be a purely tool-specific workflow,

[hyumo]

Yeah, parameter values are not from tag attributes, and this is actually a small problem.

I am not saying we should load ssp zip file in ExternData, which is not realistic. I am thinking just to use the format as a standard way of doing parameterization. Several use cases/benefits:

1. There's a *.ssv schema to define the format. For us, we are using ExternData to read parameters from xml files. Usually we let our users generate the parameter xml file themselves, however, we cannot give them a schema file. We usually just tell them to do a "find and replace" with the demo xml file we give them. And people need to write a custom generator for each every xml file.

2. Metadata. Units, data types, descriptions etc.

3. If something goes wrong in an FMU or a binary format due to parameter files, we can load the xml back into the model from the authoring tool to troubleshoot what went wrong. We do that very often with current ExternData, however, if we want to cut and paste a portion of the xml file, we need to make sure the nodes tags/hierarchy still remains the same in order to load into the model. In *.ssv files, the hierarchy is flat, variables could be indexed by the name attribute.

These are just my 2 cents, correct me if I am wrong.

[tbeu]

Regarding your first point, I checked the SSV description, the schema (version 20171219) and example and converted the parameter sets of test.xml to something like

<?xml version="1.0" encoding="UTF-8"?><!-- test.ssv -->
<ParameterSet version="Draft20171219" name="set1">
  <Parameters>
    <Parameter name="gain.k">
      <Real value="2"/>
    </Parameter>
    <Parameter name="clock.offset">
      <Real value="0.1"/>
    </Parameter>
  </Parameters>
</ParameterSet>

skipping all optional parts and the ssv namespace. Looks clean and easy to support. Is this close to your idea? Would you miss the array support, that I did not see in SSP so far?

Regarding your second point, I think that ExternData could check if the specified data type matches the expected data type.

Be aware, that the SSP standard is not finalised yet and still subject to change.

[hyumo]

Good point, I didn't notice that the array support is missing. I guess it is reflecting the current FMI standard which does not have array support? I wouldn't expect it to change anytime soon, but I hope I am wrong.

In terms of meta data, to be honest, I think it serves a better job at being just a "visual aid" to anyone who got a certain parameter file than applying actual changes to the original data. We got a lot of questions from users asking what a parameter does and what's its unit (we are in the US...) and available enum types etc.

I am completely aware that SSP is still in development. I'm just proposing this idea which will hopefully be an improvement in external data management (comparing to some commercial xml reader). This is not urgent at all, so please take your time and thanks a lot for your support.