It seems to me that the schema does not actually enforce this requirement. I also believe this is different in SDMX-ML where the message "Footer" can co-exist with data. In SDMX-ML the footer may also contain "warnings" and "information" indicated by a severity attribute. For instance, an SDMX-ML to SDMX-JSON conversion tool might want to indicate a warning that time and time zone information has been imputed during the conversion process (#161). Or for that matter, it might want to note that warnings from the SDMX-ML message had to be removed during the conversion process as they have no representation in SDMX-JSON.
I think at the least the specifications should highlight this limitation and then enforce this requirement in the schemas.
162 would allow using $.meta.annotations to represent such additional information at least in an implementation-defined manner where implementations have the option to converge on a common representation, possibly following guidelines published separately.
(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)
In https://github.com/sdmx-twg/sdmx-json/tree/71fe5eaa9fcd29e3c15f2f0216a19b9b650b1dbd all the message formats say that »The members data and errors MUST NOT coexist in the same message.«
It seems to me that the schema does not actually enforce this requirement. I also believe this is different in SDMX-ML where the message "Footer" can co-exist with data. In SDMX-ML the footer may also contain "warnings" and "information" indicated by a
severityattribute. For instance, an SDMX-ML to SDMX-JSON conversion tool might want to indicate a warning that time and time zone information has been imputed during the conversion process (#161). Or for that matter, it might want to note that warnings from the SDMX-ML message had to be removed during the conversion process as they have no representation in SDMX-JSON.I think at the least the specifications should highlight this limitation and then enforce this requirement in the schemas.
162 would allow using
$.meta.annotationsto represent such additional information at least in an implementation-defined manner where implementations have the option to converge on a common representation, possibly following guidelines published separately.(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)