First, appreciation is due for the quality of the work on the multiscales specification. The current structure is clear, consistent, and highly useful, including for scenarios such as WMTS exposure.
A point of concern remains regarding the restriction on relative paths:
Relative paths cannot start with / or refer to parent directories (..).
While this constraint simplifies validation and client implementation in some specific cases, it also limits flexibility in real-world production environments.
In particular, some workflows - such as those used at ESA for EOPF third-party missions - require adding overview levels without restructuring or duplicating existing datasets. In such cases, the ability to reference data located in current group (.), parent groups (../../previews) via relative paths would avoid costly data rewrites and enable more modular dataset evolution. In some other case, the overviews might be provided in a totally different directory (sibling).
Note that this topic was previously discussed in issue zarr-developers/geozarr-spec#83 and that support for more flexible relative paths had been initially adopted in an earlier draft (see https://github.com/EOPF-Explorer/data-model/pull/41/changes), which suggests that this capability had prior consensus before being restricted.
Given this, it may be beneficial to reconsider the strict prohibition of parent-relative paths (..) to support more flexible dataset layouts
This is not a blocker but rather a suggestion to improve inclusiveness and adaptability of the standard. Broader consideration of such use cases would strengthen adoption across diverse operational contexts.
Thank you again for the excellent work and continued efforts on this specification.
First, appreciation is due for the quality of the work on the multiscales specification. The current structure is clear, consistent, and highly useful, including for scenarios such as WMTS exposure.
A point of concern remains regarding the restriction on relative paths:
While this constraint simplifies validation and client implementation in some specific cases, it also limits flexibility in real-world production environments.
In particular, some workflows - such as those used at ESA for EOPF third-party missions - require adding overview levels without restructuring or duplicating existing datasets. In such cases, the ability to reference data located in current group (
.), parent groups (../../previews) via relative paths would avoid costly data rewrites and enable more modular dataset evolution. In some other case, the overviews might be provided in a totally different directory (sibling).Note that this topic was previously discussed in issue zarr-developers/geozarr-spec#83 and that support for more flexible relative paths had been initially adopted in an earlier draft (see https://github.com/EOPF-Explorer/data-model/pull/41/changes), which suggests that this capability had prior consensus before being restricted.
Given this, it may be beneficial to reconsider the strict prohibition of parent-relative paths (..) to support more flexible dataset layouts
This is not a blocker but rather a suggestion to improve inclusiveness and adaptability of the standard. Broader consideration of such use cases would strengthen adoption across diverse operational contexts.
Thank you again for the excellent work and continued efforts on this specification.