JSON, YAML & CSS Conformance
The three data grammars follow the same conformance discipline as HTML and Markdown: industry-standard corpora ingested as ordinary tests, with any exception tracked per case with a written rationale — never as silent skips or aggregate pass-rate floors.
JSON — RFC 8259
Section titled “JSON — RFC 8259”The complete JSONTestSuite corpus runs in the package suite:
| Category | Cases | Result |
|---|---|---|
y_* must-accept | 95 | 95 accepted (root is Document) |
n_* must-reject | 183 | 183 rejected (root is Error, with failure byte offset) |
i_* implementation-defined | 33 | 33 parsed without throwing |
| Total | 311 | 311 / 311 |
JSON conformance is binary by design: a document either parses to a full tree or yields a single-node Error root pointing at the failing byte. Implementation-defined cases follow a written interop policy (e.g. a UTF-8 BOM is stripped and the remainder parsed). String validation is complete per RFC 8259 §§7–8: surrogate-pair pairing for \u escapes, and full UTF-8 well-formedness including overlong-encoding and out-of-range rejection — the checks most JSON parsers skip.
YAML — 1.2.2
Section titled “YAML — 1.2.2”The official yaml-test-suite runs with a per-case expectations file:
| Metric | Result |
|---|---|
| Valid cases passing | 267 / 268 |
| Expected failures (with rationale codes) | 1 — CT4Q |
| Silent skips | 0 |
| Never-throw across the whole corpus | ✓ |
The single expected failure, CT4Q (Spec Example 7.20), covers the explicit ? key indicator in flow context, currently consumed as a plain scalar. It is recorded in the expectations file under the rationale code EXPLICIT_KEY_FLOW; the harness fails if any other case regresses or if CT4Q silently starts passing without the expectation being updated.
Multiline flow scalars (block styles inside flow context, §7.3) are the one known feature gap; everything else — block structures, flow collections, anchors/aliases/tags (including decorator-prefixed implicit keys like [&a key: value]), directives, multi-document streams — is covered.
CSS — Syntax Module Level 3
Section titled “CSS — Syntax Module Level 3”All 125 inputs from the CourtBouillon css-parsing-tests corpus run in the suite:
| Check | Result |
|---|---|
| Never-throw across the corpus | 125 / 125 |
Error-detection agreement (fixture expects error ⇔ tree contains Error) | 125 / 125 |
| Root-kind correctness | 125 / 125 |
The CSS oracle is deliberately scoped: it verifies never-throw, error agreement, and root correctness — not yet structural comparison against the fixtures’ expected component-value trees. That upgrade (and WPT css/css-syntax/ coverage) is tracked future work; the current claim is exactly what the harness enforces.
Shared verification beneath the corpora
Section titled “Shared verification beneath the corpora”Every data grammar additionally carries:
- Never-throw entry-point registration — each public parse function runs against adversarial byte samples in
verify:no-throw. - Seeded fuzz loops on every run (hundreds of deterministic pseudo-random inputs per grammar) plus timed soak modes for CI, all asserting never-throw and valid tree roots.
- Structural hang immunity — iterative state machines with forward-progress guards, so no byte sequence can cause non-termination.
See Stability Guarantees for the framework-wide posture and fuzz totals, and the per-grammar guides for API details: JSON · YAML · CSS.