Validate every GS1 Digital Link URI and AI element string we emit against GS1's own published syntax tooling in CI, not only against our parser.
Why
We wrote our own GS1 Digital Link implementation. It is tested, and every one of those tests was written by the same people who wrote the parser — so a shared misreading of the spec passes both. An external oracle is the only thing that catches that class of error.
Step 0 — before anything is wired
Confirm and record:
- which GS1 artefact is the right oracle — the Syntax Engine, the Syntax Dictionary, or both, and their versions
- its licence, and whether vendoring or CI-fetching is permitted
- how to call it from CI — native library plus bindings, a CLI, or a published package
- whether it validates what we need: Digital Link URI grammar, AI element strings, and check digits, or only a subset
Do not proceed on assumption. If the tooling is unsuitable or unusably licensed, that is a finding worth writing down, and the fallback is GS1's published test vectors rather than a homegrown second parser.
Design
CI-only dev dependency. Never a runtime dependency of dpp-core. The zero-infrastructure property is a load-bearing claim in the README — it builds with cargo build, no Docker, no native toolchain. A C library in the runtime graph would quietly retire that. The oracle runs in a CI job, on generated artefacts, out of process.
Two suites:
- Corpus — every Digital Link form we emit across every product group and both granularities:
/01/{gtin}, /01/{gtin}/21/{serial}, /8003/{grai}. Built from existing fixtures so new product groups are covered automatically.
- Differential — generate identifiers property-wise and assert our parser and the oracle agree on accept/reject. Disagreement either way is a failure; a link we reject and GS1 accepts is the direction that quietly loses interoperability.
Merge gate
- Every Digital Link the corpus generates passes the GS1 oracle
- A deliberately corrupted check digit fails the oracle and our parser, asserted separately
- The differential test finds no accept/reject disagreement
cargo build still requires no native toolchain, asserted by the existing minimal-build job
Scope boundary
Syntax is not semantics. This proves our links are well-formed GS1 — not that the GTINs are allocated to us, nor that a resolver finds anything. Nothing here supports the phrase "GS1-certified"; state the engine version and the date read.
Validate every GS1 Digital Link URI and AI element string we emit against GS1's own published syntax tooling in CI, not only against our parser.
Why
We wrote our own GS1 Digital Link implementation. It is tested, and every one of those tests was written by the same people who wrote the parser — so a shared misreading of the spec passes both. An external oracle is the only thing that catches that class of error.
Step 0 — before anything is wired
Confirm and record:
Do not proceed on assumption. If the tooling is unsuitable or unusably licensed, that is a finding worth writing down, and the fallback is GS1's published test vectors rather than a homegrown second parser.
Design
CI-only dev dependency. Never a runtime dependency of
dpp-core. The zero-infrastructure property is a load-bearing claim in the README — it builds withcargo build, no Docker, no native toolchain. A C library in the runtime graph would quietly retire that. The oracle runs in a CI job, on generated artefacts, out of process.Two suites:
/01/{gtin},/01/{gtin}/21/{serial},/8003/{grai}. Built from existing fixtures so new product groups are covered automatically.Merge gate
cargo buildstill requires no native toolchain, asserted by the existing minimal-build jobScope boundary
Syntax is not semantics. This proves our links are well-formed GS1 — not that the GTINs are allocated to us, nor that a resolver finds anything. Nothing here supports the phrase "GS1-certified"; state the engine version and the date read.