standard: require canonical ASCII digit and case forms in citation-system profiles

[maehr]

Affected spec section

/standard/system-profiles/ (locator validation contract) and /standard/identifier-syntax/ § Deterministic identity (which currently leaves canonical form unspecified at the profile level).

Motivation

The deterministic UUID seed uses the exact normalized locator bytes. If a citation-system profile permits multiple regex-valid spellings of the same passage, each spelling mints a distinct permanent identity — a hard identity split for the same conceptual reference, with no way to merge after publication.

Examples that today's profiles silently allow:

• Bekker: 514a1 vs 514a01 (line leading zero), 0514a1 (page leading zero) — same line of Aristotle, three permanent IDs.
• Bible (current bible-book-chapter-verse): John.3.16, john.3.16, JOHN.3.16 — three permanent IDs for John 3:16.

The current editorial rule says references must represent attested reference points, but that rule is not machine-checkable and does not prevent two contributors from minting different spellings of the same point.

Proposed change

Require every citation-system profile to declare and enforce canonical forms along two axes:

1. ASCII digit sequences. Profiles MUST state whether leading zeros are permitted in numeric components. Default: forbidden unless the citation tradition uses them.
2. ASCII letter case. Profiles MUST state the canonical case for letter components. Default: case-sensitive match against the profile's declared casing.

Enforcement MUST be by locator_regex rejection, not by silent folding/normalization at minting time. Rejection at the validation boundary avoids normalization_version churn — folding would force a profile version bump on every refinement, and would invalidate already-minted IDs.

Scope is intentionally narrow:

• ASCII digits only — does not touch decimal separators, thousands separators, or non-ASCII digits.
• ASCII case only — does not propose Unicode case folding, NFC/NFKC normalization choices, or whitespace handling.

The two concrete bugs that motivated this (textrefs/registry#2 Bekker leading-zero forms, textrefs/registry#3 Bible case variants) become single-line constraints in the per-profile regex once this is normative.

Alternatives considered

• Fold at minting time. Compiler lower-cases letters and strips leading zeros before seeding the UUID. Pros: forgiving. Cons: requires normalization_version bumps for any refinement, and means the bytes hashed don't match the locator authored — surprising for anyone recomputing IDs from the published record.
• Document the convention; do not enforce. Status quo, plus a note. Cons: relies entirely on reviewer vigilance and does nothing for contributor-introduced regex laxity.
• Wait for the locator-validation meta-discussion (standard: revisit locator validation mechanism (regex + examples vs. alternatives) #9). This proposal partially overlaps with option 1 there. It can land independently of standard: revisit locator validation mechanism (regex + examples vs. alternatives) #9's outcome, but should be revisited if standard: revisit locator validation mechanism (regex + examples vs. alternatives) #9 picks option 2/3/4.

Compatibility impact

breaking — major version bump required

(Profiles change shape and become stricter. Existing minted references must be re-checked against the new constraints; the review found no live data that would break, but this needs a CI sweep before the bump.)

Target spec version

v0.2.0-draft

Related

• standard: revisit locator validation mechanism (regex + examples vs. alternatives) #9 — broader locator-validation mechanism discussion (this proposal is the explicit content of option 1 there).
• data: Bekker locator regex rejects valid pages 1–99 registry#2 and data: Bible book-chapter-verse regex rejects numbered books; vocabulary unpinned registry#3 — the two concrete cases this prevents recurring.