fix(validator): FHIR string/markdown/code regex rejects non-breaking spaces (Unicode vs XSD \S)

[mauripunzueta]

Fixes #425.

Problem

FHIR primitive pattern facets are XSD regexes, and XSD defines the shorthand whitespace class as ASCII only — \s == [#x20#x9#xD#xA]. Rust's regex crate makes \s/\S Unicode-aware by default, so U+00A0 (non-breaking space) — Unicode whitespace but not XSD whitespace — matches neither the literal [ \r\n\t] branch nor \S in the R4/R4B string/markdown pattern [ \r\n\t\S]+. The anchored match fails and a valid FHIR string is reported invalid.

	R4	R4B	R5	R6
string/markdown	[ \r\n\t\S]+ (bug)	[ \r\n\t\S]+ (bug)	[\s\S]+ (ok)	[\s\S]+ (ok)
code ([^\s]+…)	affected	affected	affected	affected

Root cause & fix

The single compile site is crates/fhir-validator/src/engine/primitives.rs::compiled(), which compiled ^(?:{pattern})$ on the Unicode-aware regex::Regex. The fix compiles with unicode(false) so the shorthand classes carry XSD/ASCII semantics.

The obvious spelling — (?-u:…) (which the issue suggested) or RegexBuilder…unicode(false) on the &str engine — does not compile: the &str engine refuses any program that could match invalid UTF-8, and (?-u:\S) / (?-u:[^\s]) can. The fix therefore compiles on the regex::bytes engine and matches the value's UTF-8 bytes. The validator's input is always a valid UTF-8 &str (Value::as_str()), so the only observable effect is that \s/\S/\d/\w become ASCII.

Why byte matching is safe/equivalent here: across every primitive pattern in all four versions, \s and \S are the only shorthand classes that appear (in string/markdown, code, uri/url/canonical \S*, and R4/R4B base64Binary). No primitive pattern uses ., \d, or \w, and every bounded quantifier (id {1,64}, base64 {4}, dates, uuid) operates on explicit ASCII classes where 1 byte = 1 char. So byte matching is exactly XSD-equivalent — verified empirically and by a 5-persona design review.

Scope

Fixing at the compile site inherently corrects both the issue's headline case (string/markdown, R4/R4B) and the code U+00A0 residual (all versions) — same one-line root cause, no extra diff. uri/base64/R5-R6 are already correct under the new engine and are covered by regression tests.

Tests

Added unit tests in primitives.rs (exercised through compiled(), so they cover real anchoring + engine + flags):

• string/markdown R4/R4B accepts U+00A0 (the exact issue case) and lone U+00A0; still accepts spaces/tabs; still rejects empty.
• R5/R6 [\s\S]+ proven unchanged.
• code treats U+00A0 as content (single token) but still rejects leading/trailing real spaces.
• uri \S* rejects a real space, accepts U+00A0, accepts empty.
• Negative guards: date and id still reject a stray U+00A0 (the fix does not blanket-accept non-ASCII); base64Binary {4} grouping unaffected.

Full validator suite is green on R4,R4B,R5,fhirpath; cargo fmt --check clean.

Notes

• No DB / storage / persistence is touched. This is a runtime regex-engine change; the committed schema packs are unchanged and remain spec-literal (a deliberate invariant of the converter).
• Cross-dependency with test(validator): run the pack tests in CI, sweep the official FHIR example corpus #423 (open): the official-example corpus sweep and its known-failures-*.json baselines live only on the test(validator): run the pack tests in CI, sweep the official FHIR example corpus #423 branch, not on main. When test(validator): run the pack tests in CI, sweep the official FHIR example corpus #423 lands, its R4/R4B baselines must be regenerated — the U+00A0 entries currently recorded as failures become correct passes; that drop is the intended effect of this fix, not a regression. The unit tests here are the guardrail on main.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!