Software Setting should be handled as a String List

[nilshoffmann]

https://github.com/HUPO-PSI/mzTab-M/blob/main/specification_documents/mzTab_format_specification_2_1-M.adoc#6211-software1-n-setting1-n

Multiple instances can exist, the parser will add multiple occurrences. This could be similar to regular to other lists:

Current:

MTD software[1]-setting Fragment tolerance = 0.1 Da
MTD software[1]-setting Parent tolerance = 0.5 Da

Should be:

MTD software[1]-setting[1] Fragment tolerance = 0.1 Da
MTD software[1]-setting[2] Parent tolerance = 0.5 Da

[philouail]

I know this is an old issue, but please go through the different steps of the template below, to make it easy for us to understand what to do next with this:

Is your feature request related to a problem? Please describe.
A clear and concise description of why the new element or modification of an existing element is necessary. Which use cases or needs does it address?

Describe the solution you'd like
A clear and concise description of what you want to add or modify. Please try to also add examples (snippets for the tab-separated format, see https://github.com/HUPO-PSI/mzTab-M/blob/main/specification_documents/mzTab_format_specification_2_1-M.adoc#625-sample_processing1-n for reference)

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here. If your request involves the use of other standards or external resources, please provide links to those.

Submitter Tasks

• Provide a pull request (Please add the link)
• Schema: Update mzTab_m_openapi.yml (View File)
• Specification: Update mzTab_format_specification_2_1-M.adoc with an example (View File)
• Example files: if possible, modify an existing or add a new example file (Existing example files)

Maintainer & WG Tasks

• Triage: Assign labels and Milestones to this issue.
• Discuss and review and approve PR.

Next Steps, once we reach an agreement on the changes above:

• Create a downstream issue in the jmzTab-m repo (https://github.com/lifs-tools/jmzTab-m/issues)
• Implement and test changes in jmzTab-M
• Implement changes in R & Python implementations

[nilshoffmann]

We should consider soft-deprecating this and rather introduce something like

software[1]-settings_uri where we point to a machine readable settings file.

[nilshoffmann]

Maybe add a cvparam for the settings format, e.g. JSON, ...

[jorainer]

or maybe as an alternative:

software[1]-setting[1]-name peakwidth
software[1]-setting[1]-value 3, 20
software[1]-setting[1]-method CentWaveParam

that would make it easier to parse the setting values properly and would also allow to tell for what method/algorithm in the software this parameters are good for?

[philouail]

We discussed that with Nils a bit but it's a bit random the values expected here, and we are running the risk of having MANY field. maybe fully replacing with a link to a script with parameter used would make things easier and clearer no ?

[jorainer]

for human readability I guess yes - for machine readability that might be even more complicated, because the format is not clear. but also, I would not overcomplicate things... so, am also fine with an external link.