This comment proposes revising the SDMX-JSON specification to make the sender metadata fields within the message header optional.
Currently it is required and needs only an id field which can be any string. I have seen various examples »in the wild« with those fields containing placeholder values.
Rationale:
Improved Interoperability: Currently, software may omit these fields due to misconfiguration, a desire for anonymity, or simply lack of this information (like a service that transcodes legacy data formats to SDMX-JSON). Enforcing this field can lead to inconsistencies and potentially non-compliant messages, even if the data itself is valid. Omitting the field would promote smoother interoperability between applications with varying levels of information about the exchange.
Simplified Message Descriptions: Hand-crafting message descriptions for test or internal purposes is often necessary. Removing the requirement for the sender field would streamline this process (»no boilerplate«).
Data Stream Efficiency: Including placeholder values like "unknown" or "anonymous" adds unnecessary information to the data stream. Eliminating this requirement can contribute to a more efficient and environmentally conscious data exchange in the planetary public data space.
Proposed Change:
Update the SDMX-JSON specification to mark the sender field within the message header as optional.
For compatibility with other serialization formats, SDMX-JSON could specify that if the field is omitted, some pre-defined standard value can be assumed for the id field.
I believe this revision would strengthen the SDMX-JSON format by promoting broader adoption, streamlining development processes, and optimizing data exchange.
(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)
This comment proposes revising the SDMX-JSON specification to make the
sendermetadata fields within the message header optional.Currently it is required and needs only an
idfield which can be any string. I have seen various examples »in the wild« with those fields containing placeholder values.Rationale:
senderfield would streamline this process (»no boilerplate«).Proposed Change:
Update the SDMX-JSON specification to mark the
senderfield within the message header as optional.For compatibility with other serialization formats, SDMX-JSON could specify that if the field is omitted, some pre-defined standard value can be assumed for the
idfield.I believe this revision would strengthen the SDMX-JSON format by promoting broader adoption, streamlining development processes, and optimizing data exchange.
(In doubt, please handle this as a public review comment on SDMX 3.1 once the comment period begins.)