Table view - Indented children for hierarchies in rows
As a .Stat Data Explorer and Data Viewer user,
In the table view,
A hierarchical dimension, when displayed as last row dimension, gets its children gradually indented according to their respective current (data message dependent) level in the hierarchy.
The dimension hierarchy is to be logically derived from the parent-child relationship specified for the dimension values in the structure part of the SDMX-JSON data message.
- The parent-child relationship is returned in the data message in the parent id:
{ "id": "REF_AREA", "name": { "en": "Reference Area" }, "keyPosition": 2, "roles": [ "REF_AREA" ], "values": [ { "id": "ITF", "name": { "en": "Sud" }, "parent": "IT" },{ "id": "ITF1", "name": { "en": "Abruzzo" }, "parent": "ITF" } ] }
Reference of the SDMX-JSON data message format: https://github.com/sdmx-twg/sdmx-json/blob/master/data-message/docs/1-sdmx-json-field-guide.md
Important note: Because only dimension values are returned in the data message for which data are also returned, there might be many cases where the value of a parent is not included itself in the data message, as the "IT" parent in the above example. All dimension values for which the parent is not included itself in the message and all dimension values that do not have a parent are to be displayed in the table at the root level. The label of the child dimension values should then use the "alternative label" (see #7), if available. All their below levels must be indented relative to this level.
Example:
Incomplete hierarchy (with unavailable parent values marked by [...]) from data message:
[...] Asia China [...] France Germany
Indented table row values:
Asia China France Germany
Additional note: The order (see #28 (closed)) between root dimension values (without parent) should be respected. The order between child dimension values of the same parent should be respected even if the parent is missing and is not displayed. The order between child dimension values of different missing parents is undefined in the data message. In case there is an easy to implement technical mean to obtain all original orders from the underlying complete codelist (structure message), it would be ideal to use that (including in the Data Viewer). If not, then the new root elements should first show the child elements without parent (if having the same parent then in the given order (see #28 (closed)); if having different parents then as retrieved in the data message) and then the proper root elements in the given order (see #28 (closed)).
Acceptance Criteria
- In the row/vertical axis of the table view, if the last row dimension has a hierarchy, then all children labels are indented according to their respective level in the hierarchy.
- If there is only one dimension in the row axis, and this dimension has a hierarchical codelist, then the indented rule is applied.
- If there is more than one dimension in the row axis, then indentation is not applied to dimensions that are not the last in the row/vertical axis (not at the most right position), even if they have a hierarchy.
- When a hierarchy is to be displayed, then each level of hierarchy has its level of indentation represented by 15 pixels. The font format is identical to each level of the hierarchy (no bold to apply)
- The hierarchy is reconstructed dynamically based on the dimension content retrieved in the data message. Note that some codes from the original codelist might not be included in the data message. All codes with a parent ID, for which the parent is not included in the data message, are displayed at the root level (see above) and get alternative labels applied (see #7), if available.
Mockups
Display hierarchical codelist with indent of 15 pixels and not bold for the first level
Wireframe
NOTE: In the above wireframe, the "Unit" column is not representing a row dimension, but a fake dimension that will later be generated out of Unit, Powercode and Base Period attributes. "Transaction" is thus the last row dimension.