Split from #1083.
Question
Where sh:order is present, is an implementation required to respect it? Where it is absent, what does the specification say about the resulting order?
Use cases
Options
Three were presented in the task force meeting of 11 August.
Option 1. sh:order MUST be respected, plus a defined fallback algorithm when it is absent. Shapes without sh:order then render in the same order across conforming implementations. Innovation such as ordering by usage frequency or pinned fields remains possible, with an empty context used when testing conformance.
Option 2. sh:order MUST be respected, fallback behaviour left open. Guarantees hold to the extent that sh:order values are given. A global setting such as sh:orderFallback could express intent, defaulting to positive infinity as some DASH implementations do today.
Option 3. sh:order optional or informative, to allow fully custom dynamic sorting.
Arguments
For a defined fallback: profiles that carry no ordering render unpredictably without it, which is the case that matters most for the application profile use case above.
Against: usage-based or context-dependent ordering depends on runtime data that is not in the shapes graph, so it cannot be made interoperable by specification text in any case.
Proposed resolution
I would propose something between options 1 and 2, close to what @robert-david suggested in #1083: sh:order MUST be respected where it is given, and the specification describes an algorithm implementations SHOULD follow where it is absent, rather than leaving the absent case undefined.
Concretely, I propose the text currently in the specification following #1104, with one change:
shui:defaultOrder in the global configuration, where present, MUST be respected. Unchanged from the current text.- Members with no effective order. The current text says these MUST be placed after all members that have one. I propose changing that MUST to a SHOULD, so an implementation can apply a smarter default ordering of its own where it has reason to, while the described behaviour remains the one an author can expect by default. This is the change that accommodates the concerns raised against a fully defined fallback.
- Tie-breaking. Keep the current text as it stands: renderers MUST apply a deterministic tie-breaking algorithm, SHOULD apply the one described, and MAY use an alternative provided it yields deterministic results within that implementation.
The effect is that ordering is defined wherever the shapes say something, the fallback is described rather than silent, and an implementation that wants to order differently can, without an author having to discover that by rendering a shape and comparing.
One addition I would like, though I am not sure it can be stated normatively: where an implementation departs from the described fallback, it documents what it does instead, so the behaviour is discoverable.
Split from #1083.
Question
Where
sh:orderis present, is an implementation required to respect it? Where it is absent, what does the specification say about the resulting order?Use cases
sh:orderat all, so the absent case is the common case, not the edge caseOptions
Three were presented in the task force meeting of 11 August.
Option 1.
sh:orderMUST be respected, plus a defined fallback algorithm when it is absent. Shapes withoutsh:orderthen render in the same order across conforming implementations. Innovation such as ordering by usage frequency or pinned fields remains possible, with an empty context used when testing conformance.Option 2.
sh:orderMUST be respected, fallback behaviour left open. Guarantees hold to the extent thatsh:ordervalues are given. A global setting such assh:orderFallbackcould express intent, defaulting to positive infinity as some DASH implementations do today.Option 3.
sh:orderoptional or informative, to allow fully custom dynamic sorting.Arguments
For a defined fallback: profiles that carry no ordering render unpredictably without it, which is the case that matters most for the application profile use case above.
Against: usage-based or context-dependent ordering depends on runtime data that is not in the shapes graph, so it cannot be made interoperable by specification text in any case.
Proposed resolution
I would propose something between options 1 and 2, close to what @robert-david suggested in #1083:
sh:orderMUST be respected where it is given, and the specification describes an algorithm implementations SHOULD follow where it is absent, rather than leaving the absent case undefined.Concretely, I propose the text currently in the specification following #1104, with one change:
shui:defaultOrderin the global configuration, where present, MUST be respected. Unchanged from the current text.The effect is that ordering is defined wherever the shapes say something, the fallback is described rather than silent, and an implementation that wants to order differently can, without an author having to discover that by rendering a shape and comparing.
One addition I would like, though I am not sure it can be stated normatively: where an implementation departs from the described fallback, it documents what it does instead, so the behaviour is discoverable.