The legacy OIOUBL rule sets (OIOUBLLegacyValidation, versions 2.0.2 and 3.0.1) are registered under the same Group ID dk.oioubl and the same artefact IDs as the active rules (OIOUBLValidation, versions 1.12.3 / 1.13.0 / 1.13.2). Because DVR pseudo-versions (latest, latest-release) resolve to the numerically highest version within a Group+Artefact coordinate, dk.oioubl:invoice:latest (and the other document types) resolves to the legacy 3.0.1 artefacts — which were deprecated by the Danish government — instead of the current active 1.x rules. Anyone relying on pseudo-version resolution to always pick the current OIOUBL rules therefore silently gets the wrong, outdated rule set.
Moving the legacy artefacts to a separate Group ID (e.g. dk.oioubl.legacy) removes the overlap, so pseudo-version resolution on dk.oioubl only ranges over the active rules while the legacy sets stay addressable under their own coordinate.
The legacy OIOUBL rule sets (
OIOUBLLegacyValidation, versions 2.0.2 and 3.0.1) are registered under the same Group IDdk.oioubland the same artefact IDs as the active rules (OIOUBLValidation, versions 1.12.3 / 1.13.0 / 1.13.2). Because DVR pseudo-versions (latest,latest-release) resolve to the numerically highest version within a Group+Artefact coordinate,dk.oioubl:invoice:latest(and the other document types) resolves to the legacy 3.0.1 artefacts — which were deprecated by the Danish government — instead of the current active 1.x rules. Anyone relying on pseudo-version resolution to always pick the current OIOUBL rules therefore silently gets the wrong, outdated rule set.Moving the legacy artefacts to a separate Group ID (e.g.
dk.oioubl.legacy) removes the overlap, so pseudo-version resolution ondk.oioublonly ranges over the active rules while the legacy sets stay addressable under their own coordinate.