Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

0012: Exact numbers and JSON input policies

Esdieff distinguishes JSON decoding, framework syntax, information-level numeric meaning, and implementation capability. RFC 9880 Appendix C.1 makes integrality a value property, including fractional or exponential notation with integral values. RFC 8259 Sections 6 and 9 admit decimal tokens while permitting explicit implementation limits. RFC 8610 Appendix E explains the JSON mapping of CDDL numerical types; successful exact decoding establishes a number but does not prove every uint requirement in the normative SDF grammar.

Numeric input retains its original JSON token and is represented as a bounded signed decimal coefficient with a base-10 exponent. Mathematical comparison and integrality preserve exact values without binary floating-point conversion or exponent-sized expansion. Affected numeric work that exceeds capability or a finite work budget remains incomplete with its source value available, following ADR 0009: Bounded processing and reporting. Independent conclusions remain available. Unchanged generated numbers preserve an accepted raw lexeme, including at lexical exponent boundaries; normalization is an internal representation rather than a mandatory output syntax. Future computed-number output must meet the same-default acceptance/capability contract or identify an explicit limitation. This preserves usable JSON numbers with unchanged mathematical values, following ADR 0007: Generated SDF and sample JSON.

The initial assessment’s numeric contract covers JSON number shape, exact sign and positivity of multipleOf, nonnegative integral count/length values, and guarded mathematical proofs enumerated by its inventory. FullBaseline separately checks the normative CDDL number and uint domains under ADR 0032: Formal model admission: number admits every JSON number, while uint is the integral interval 0 through 2^64-1. Exact decoding of a count such as 18446744073709551616 does not establish uint admission; an available exact predicate establishes its exclusion when the grammar requires uint. Framework extension alternatives remain distinct from definite grammar errors. Initial, expanded and selected-sample behavior stays unchanged. Neither decoding capability nor a machine-type failure silently widens normative syntax or establishes a definite violation.

JSON input is one UTF-8 text. Decoding accepts JSON whitespace and rejects comments, trailing commas, concatenated texts, and quoted-number coercion. A leading BOM is not accepted. Syntactically admitted non-scalar escaped strings or keys are unsupported decoding capabilities, rather than a blanket acceptance restriction or JSON syntax violation. Preserve raw source and scope incomplete work to the affected conclusions. An unsupported key can prevent usable map construction; an unsupported value leaf does not erase independent numeric conclusions. Paired surrogate escapes decode normally.

Acceptance restriction A002 refuses duplicate decoded names in any JSON object, including nested and opaque content. Repeated identical values also fail. Names compare exactly after escape decoding, without case folding or Unicode normalization. No first/last precedence is established. The input-policy result identifies the repeated member and preserves supplied source. Independent documents remain usable. RFC 8259 Section 4 gives the interoperability basis; duplicate names are not rejected as JSON syntax errors.

Finite configurable defaults are 4 MiB per document, 32 MiB per catalogue, 256 documents, 64 nested containers, 100,000 JSON value nodes per document, 1,024 bytes per number token, 512 normalized coefficient digits, explicit exponent magnitude 1,000,000, and 2,000,000 numeric work units per request. Input and numeric caps are implementation capability, not standards limits. Configuration must remain finite and satisfy internal checked-arithmetic and stack bounds. Numeric work charges token characters and compared digits before operations; future arithmetic debits a documented finite work model before large allocation. Operational limits never erase retained aggregate findings.

Input, depth, and node caps do not alone control location/report amplification. Production storage uses shared or compact ancestry and source spans, with finite path/report materialization and work budgets checked before allocation. Full ancestor-pointer strings repeated per node or finding are not an adopted architecture. Public workflow and source-document implementation must settle and test these budgets before relying on the numerical/input contract. Report byte truncation preserves aggregate errors and is distinct from unfinished semantic work, following ADR 0009. A path or semantic-work limit leaves affected requested conclusions incomplete; presentation truncation alone does not imply semantic incompleteness.

Source inspection retains supplied content and number tokens. Generated output preserves known numeric and JSON value semantics; exact whitespace, escape spelling, and key ordering are separate presentation capabilities. Opaque content remains structurally available, without proving fidelity when its semantic context changes.

Considered Options

Fixed-width integer/float representations and fixed-scale decimal types can round, overflow, or underflow values before the model is assessed. Unbounded arbitrary-precision arithmetic and exponent expansion can spend disproportionate work on short tokens. Bounded arbitrary precision may support later operations, but exact parse/order/integrality do not require a large-integer dependency. Mandatory normalized output can cross the accepted lexical exponent budget, so unchanged values preserve accepted lexemes. A stock JSON map decoder can discard duplicate evidence and choose undocumented precedence. Externally converting numbers to strings changes JSON types. Full ancestor pointers repeated at every node can amplify small inputs despite ordinary input caps. Treating every numerical or decoding limitation as an RFC violation, or adding a blanket non-scalar-string restriction, confuses toolkit capability, input policy, and standards meaning.