Ordering of DSD dimensions in structure messages using the "position" attribute

[sdmx3mdt]

From Abdulla Gozalov UNSD Received via email 16 July 2021

Summary The SDMX-ML and SDMX-JSON structure message Data Structure Definition "position" attribute is currently optional and for information only, the ordering and position of dimensions being determined solely by their position in the message's DimensionList. As DSDs can be generated using various tools and undergo several transformations it may be difficult to preserve the physical ordering of dimensions with serious implications for the REST API which relies on them being in a fixed and defined sequence.

Solution Options

1. If dimension "position" attributes exist in the structure message, the ordering they define takes precedence over the physical ordering in the DimensionList.
2. Remove the "position" attribute from the specification to avoid apparent contradiction should the stated position of a dimension differ from its physical position within the structure message.

Email Discussion Trail UNSD dimension position attribute issue.pdf

[sdmx3mdt]

Action with TF3 to make a proposal for TWG consideration.

[brainwasher]

Isn't the component list in XML an ordered list? Thus, if a tools changes the order of the nodes, it is a bug in the tool? We had a similar discussion in the sorting of code items within a code list .There the default order is the one given by the designer uploading the code list artefact to a registry. Not only within SDMX, but also within XML, no tool should modify that order. For code lists, we have defined an annotation in the controlled vocabulary to override the default order within a specific context. Consequently, and to be consistent, the same approach can be used for dimension order. The position attribute can be removed and in case for some visualisation purposes the positions of dimensions is relevant, the controlled annotation @SDMX.ORDER may be used

[dosse]

@brainwasher To complement your comment: The "annotation in the controlled vocabulary to override the default order within a specific context" for codelists does not replace the fixed order of codes in the codelist. This annotation is for representational purposes only and allows for a language-specific display order in a localised context. The same annotation could indeed be used to allow for a localised display order of components.

[sdmx3mdt]

The following agreed solution has been implemented:

• 'position' attribute retained within the messages
• Schema documentation updated to state that the ordering of dimensions in the DSD is defined by the sequence of elements / array items in the structure message, the 'position' attribute remains optional but if specified must be consistent with the actual position of the dimension otherwise tools must report an error
• The 'position' attribute has been removed from the special TimeDimension, and the position of the TimeDimension enforced as the last dimension in the list by the schemas