As mentioned in https://github.com/lifs-tools/rmzTab-m/issues/32 an SML table may not always make sense to report, if no identification has been performed yet. The use case here is that XCMS wants to output mzTab-M feature table information and metadata, but at this point in the workflow, has no identification, adduct, charge or other detailed information available.
Thus, we need to relax the specification at this point. This will lead to validation passing for files that would previously not pass validation with an error. After the change, validation would produce an info level message indicating a possible improvement by including an SML table.
@sneumann @philouail @jorainer
As mentioned in https://github.com/lifs-tools/rmzTab-m/issues/32 an SML table may not always make sense to report, if no identification has been performed yet. The use case here is that XCMS wants to output mzTab-M feature table information and metadata, but at this point in the workflow, has no identification, adduct, charge or other detailed information available.
Thus, we need to relax the specification at this point. This will lead to validation passing for files that would previously not pass validation with an error. After the change, validation would produce an info level message indicating a possible improvement by including an SML table.
A development build of the jmztab-m validator is online here: https://apps.lifs-tools.org/mztabvalidator-dev/