Review Inputs Measured Against Revision 33

Seven review documents, all prepared against Revision 32, arrived after Revision 33 was executed. This document does two things: it measures each input against what Revision 33 actually contains — separating asks the revision already answers from asks that remain open — and it assembles the open remainder into a recommended scope and sequence for Revision 34. Nothing here modifies Revision 33 or the inputs themselves; the inputs remain in review, and this document quotes their conclusions as candidates, not commitments.

The headline: Revision 33 already answers the single item every mapping report called blocking — recursion semantics — along with the disjointness model the sum-type work leans on, the regex conformance gate, and a surprising number of facets the reports listed as “planned additions” that in fact already exist in the artifacts. What remains open clusters into one breaking clause (value spaces), one atom (null), one kernel token (discriminator), a vocabulary batch, two record/map extensions, and one new spec part (evolution) — plus the product-side work the reports sequence around them.

1. The inputs, briefly

schema-mappings-synthesis.md consolidates five schema-language mapping reports (JSON Schema/OpenAPI, Protocol Buffers, ASN.1 X.680–X.683, Apache Avro, GraphQL SDL). Its headline: five languages, four decades, and the kernel survived untouched — every construct landed on existing machinery, an already-planned addition, or a principled decline. It carries the cross-source scoreboard (§3), the four-cell sum-type taxonomy (§2), a shared five-stage converter architecture (§5), a prioritized worklist (§6), and an encoding-leakage audit (§8) whose deliverable is the one breaking candidate in the whole set.

json-schema-to-tson-mapping.md (rev 2) is the founding report: the construct tables, the object-triage rule, the discriminator design (two jobs: inheritance → composition; dispatch → choice + token), the tiered additions list (#1–#10), and the declined-by-design set (not, if/then/else, $dynamicRef, constraint-intersection allOf). The OpenAPI addendum adds format-registry integers, readOnly/writeOnly as derived request/response views, and 3.0 nullable normalization.

protobuf-to-tson-mapping.md finds the best-aligned source yet: messages ≅ closed records, oneof ≅ OPTIONAL field group, typed map keys map directly, and all three presence disciplines land on existing field states with matching injection semantics. Protovalidate maps onto refinements nearly term-for-term; the strictness pitch inverts (TSON supplies the constraint layer protobuf never had).

asn1-to-tson-mapping.md finds the deepest architectural kin (abstract/transfer syntax separation ≅ the Part 1/2/3 structure): subtype constraints ≅ refinements, CHOICE ≅ REQUIRED field group, X.683 parameterized types ≅ templates (the first source exercising them), and the X.681/X.682 information object system decomposing exactly onto the envelope pattern + discriminator token, with closed object sets as sealed’s most concrete consumer.

avro-to-tson-mapping.md completes the sum taxonomy (wrapper-key unions ≅ the labelled sum on the wire), makes the strongest functional case for the null atom (the ["null", T] idiom separates present-null from absent), and carries the report set’s genuinely new item: Avro’s schema-resolution algebra as the model for a TSON evolution/compatibility part — take the concepts (compat relation, rename bridge, deterministic default injection), refuse the sharp edges (first-match coercion, silent numeric promotion).

graphql-to-tson-mapping.md scopes SDL as a capability schema, converts the input universe fully and the output graph as model, and identifies the per-query compiler — (SDL, query) → response-contract TSON schema — as the novel product. It is the fifth and loudest null-atom corroboration (nullable-by-default is the language’s default case), the first source mandating float finiteness, and the source of the recursion admissibility hint (cycles legal where a participating position admits absence).

implementation-feedback.md is spec feedback from building a Java implementation (io.ltr8.tson) against Part 1 Revision 32 — see §2, because its status against Revision 33 is fully settled.

2. implementation-feedback.md: fully subsumed by Revision 33

This file was compared mechanically against the 59-entry feedback document adjudicated for Revision 33 (SPEC-FEEDBACK.md). Result: it is an earlier edition of that document’s entries 1–24 — same 24 entry titles verbatim, same problems, same suggested resolutions in substance. The differences are confined to the “interpretation chosen” narratives, where the adjudicated edition reflects a later state of the same implementation (refactored class names; evolved policies — e.g. entry 5’s interpretation advanced from “withhold !email” to “implement it and ask the spec to scope the RFC 5322 pin”). Nowhere does this file raise a problem the adjudicated edition lacks; where the editions differ, the adjudicated edition is the richer one.

Every entry therefore already has a recorded disposition in REV33-CHANGELOG, and the executed text covers even the later edition’s added nuances — for example, Part 1 §5.5’s !email row now scopes the RFC 5322 pin to the dot-atom "@" dot-atom core with an explicit rationale, which is precisely the “naming the RFC without scoping it leaves every implementation to pick its own subset” complaint. Entries 4 and 7’s request for reader-policy guidance (fail on unrecognized type-refs by default, passthrough as opt-in) was dispositioned as a guide candidate and remains on the guide’s pending list (with #13) — carried below as a Revision 34 documentation item, not a spec item.

No action for Revision 34 arises from this file beyond the already-carried guide candidates. If the implementation produces a fresh feedback batch against Revision 33, that is a new input.

3. What Revision 33 already answers

The five mapping reports and the synthesis were written against Revision 32 and a set of “planned additions.” Measured against Revision 33 as executed, the following asks are answered — the largest single result of this assessment.

3.1 Recursion (synthesis scoreboard #3) — the universal blocker, resolved

All five reports called recursion semantics the single blocking spec item (“three converters queued behind it,” then four, then five). Revision 33 landed the answer in Part 2 §5.10.1:

• Productivity is a MUST. A type must admit at least one finite value; a definition with no finite member is a resolver error at schema load. A recursive reference is guarded when every cycle passes at least one position that can terminate: an OPTIONAL field or tuple position, an array/map position whose floor admits emptiness or whose elements admit absence, or a choice with a non-recursive variant; a REQUIRED group terminates when one member is non-recursive. This is exactly the GraphQL circular-input admissibility hint the synthesis said to steal — generalized beyond nullability to every absence-admitting position, which is the right generalization for a language whose optionality is positional.
• Regular recursion. Recursive template applications must pass each parameter through unchanged — the standard regularity restriction, checked statically. This settles the synthesis’s “templates × cycles” residue.
• Choice-cycle disjointness terminates by construction. Revision 33 replaced value-set disjointness derivation with discrimination classes (§5.4): a total, two-valued fact derived per type after following its reference chain. Class derivation does not recurse into bodies, so cyclic types pose no termination question — the synthesis’s third residue.

Consequence for the worklist: the converters are unblocked on recursion today. Synthesis §6’s Part 2 item 2 is done; its converter sequencing no longer waits on spec work for this item. (Recursive discriminated types remain on the worked-examples list — see §5.4.)

3.2 The disjointness substrate for the sum-type work

The reports’ sum machinery was designed atop Revision 32’s “MAY-prove, tag-free never guaranteed” disjointness. Revision 33’s discrimination-class model (§5.4) is strictly better ground: disjointness is total and two-valued (classes: boolean / number / string / brace / bracket), resolvers MUST record it exactly, and @disjoint is verified-or-error. The discriminator token (#9) is not in Revision 33 (see §4.3), but two of its design points are partially pre-paid: variant discrimination is already deterministic where classes differ, and the token’s job narrows cleanly to same-class variant sets (which is exactly the OpenAPI/ GraphQL record-vs-record case). Also aligned: Revision 33 bans void as a choice variant (§5.4), matching the GraphQL report’s careful note that bare T is (T | null) REQUIRED, never T? — optionality is positional, and the type system now enforces the distinction the report relied on.

3.3 The regex policy’s spec half

The reports’ regex ledger (translate when semantics-preserving; classify; fail loudly or annotate-unenforced; I-Regexp stays normative) assumed a spec-side guarantee that didn’t yet exist. Revision 33 added it: the I-Regexp pin is a strict subset gate, and an implementation MUST document any divergence from RFC 9485. The converter-side classifier (ECMA-262 riskiest → RE2 friendly → XSD-flavored friendliest) is product work with its spec dependency now met.

3.4 “Planned additions” that already exist in the artifacts

Several Tier 1–2 items the JSON Schema report proposed, and later reports repeated as pending, are already present in the meta/kernel vocabularies (some since Revision 32; the reports appear to have worked from an earlier artifact snapshot):

These should be struck from the Revision 34 additions list and, when the reports are next revised, corrected in their tables.

3.5 Vocabulary and hardening the reports lean on

• !email and !text are now Part 1 §5.5 rows (with the RFC 5322 subset scoped), and the full sixteen-member integer family is in §5.6 — the format/protovalidate upward mappings (email/uri/uuid/ipv4/ipv6 → validated types) now match the schemaless vocabulary they cite.
• Injection and field states. The reports’ presence mappings (proto IMPLICIT → ~ zero; ASN.1 DEFAULT → ~ v; Avro defaults; GraphQL input defaults; JSON Schema default → non-injecting annotation) rest on REQUIRED_DEFAULT’s decode-injection semantics — vindicated as designed, per the synthesis. Revision 33 tightened the machinery around them: the five-states clarification (OPTIONAL_FIXED never injected), parametric = fixation at materialisation, and _ at REQUIRED-family positions as a validation error.
• Deterministic verdicts. The warn-tier sweep (every warn-level rule resolved to an error or a deletion) plus Part 1’s duplicate-field/map-key MUST-reject (three-layer key identity) and the encoding-error rule (invalid bytes are lexer errors, no U+FFFD) give the converters’ canonical-strict profiles a spec floor with no implementation-defined wobble underneath — directly serving the protojson duplicate/unknown-member and lexical-cluster items in synthesis §4.
• Templates, ready for X.683. The ASN.1 report is the first to exercise templates, and Revision 33’s structure-templates overhaul is what it will actually target: labelled-only constructor parameters, level discipline, every-application-materialises with structural identity, instance-form templates (vector => <T, N> !array { … } is now the worked example in §5.10), and synthetic/instantiation entries that merge under transitive import. Monomorphization-by-materialisation is now fully specified, including the recursion rules above.
• Transitive imports (§2.2.3) serve the reports’ companion-module recommendation (proto.tn beside core.tn): a converter-emitted schema chain composes without manual re-export lists.
• Annotations have teeth — and a consequence. Revision 33 made annotation conformance normative and an unresolved annotation a resolver error. This is good news for the provenance vocabulary’s reliability and a forcing function for its packaging: the reports’ annotation families (@field_number, @tag, @wire, @reserved, @branch_order, @version_bracket, @proto_name, @graphql_id, @enum_number, @package, @precision, @spelling, …) can no longer ride as ad-hoc names — they need a declared home the emitted schemas chain to. See §4.4.

3.6 A re-baselining caution

The reports’ TSON spellings are Revision 32’s. Under Revision 33: the size templates (array_min/array_max/array_ranged) are gone — [T; N..M] is constructor sugar desugaring to an !array binding record; vector is a user-template example, not a core type; every sugar form lifts to a synthetic entry; and resolved output for any converted schema will carry @synthetic-marked internal entries. None of this changes the mappings’ substance, but their TSON-side example spellings and §A construct lists should be re-baselined against Revision 33 before any of their text is quoted into normative drafting. (The reports are in review and are not modified by this document.)

4. What remains open — the Revision 34 candidate set

Ordered per the synthesis worklist, adjusted for §3.

4.1 The value-space clause, the bytes collapse, and token re-grounding (synthesis §8)

The encoding-leakage audit is the one breaking candidate and the reports’ own item 1. The deliverable is a short normative clause — types denote value spaces; encodings define lexical spaces and one canonical form per type; equality, ordering, refinement, disjointness, and content addressing are defined over value spaces only — plus its consequences:

• Collapse base64/base32/hex/base64url into one bytes atom (they are four spellings of one octet-string value space); per-encoding lexical/canonical forms; non-default spellings become a non-semantic @spelling annotation. Payoff: content addressing becomes encoding-independent — the property hash-pinning should have and currently doesn’t if base64 ≠ hex. This also fixes the JSON Schema report’s identified live bug (contentEncoding: base64 conflating “bytes spelled as base64” with “text containing base64”).
• Re-ground token as pattern-refined text — unquoted-spelling privilege becomes a lexical rule of the text encoding, not a type.
• Define time types and uuid as value spaces with RFC 3339 / canonical-hex as lexical forms — which is also where the zone-less and calendar-duration decisions (§4.4) belong, as legitimate value-space distinctions.
• One sentence on sized integers: int8…uint256 are range-refinement aliases, not storage widths. (Their Revision 33 §5.6 definitions are already range-stated; core should say the principle.)

Interactions with Revision 33’s carried-open items: this is the revisit that carrying #11 (the binary name and bucketing, left unchanged in Revision 33 “expected to be revisited later”) anticipated — the collapse answers it. It also strengthens the case in carried #26 (hash-pin placement): once hashing is defined over canonical value spaces, the pin-spelling question (?sha256= query vs fragment vs structured directive) should be settled against that definition in the same revision. Facet-kind hygiene: the audit’s per-type canonical-form machinery should be classified under §5.7’s facet-kind taxonomy (an encoding’s canonical form is not a facet; @spelling is annotation, resolver-invisible — say so explicitly).

Do this first: it is cheapest before anything else lands, and the time/float/oid items below depend on its vocabulary. Draft-stage cost is one breaking rename plus definition rewording.

4.2 The null atom (#4) and §7.3 tightening

Five corroborations, unanimous, with Avro’s two-spelling optionality idiom and GraphQL’s default case as the functional forcing arguments. Scope for Revision 34:

• A first-class null atom distinct from void/absence, completing the present / absent / null triad (email: (null | text) ~ null must be spellable and mean what Avro’s idiom means).
• Tighten Part 2 §7.3’s null-at-void concession in the same revision — the reports are explicit that the concession’s safety argument (void has one inhabitant) changes once null is a real value elsewhere.
• Sequencing: land before literal-valued enums (§4.4), since real-world heterogeneous enums include null.
• Design attention: base type resolution (Part 1 §4.1) already resolves the bare token null; the atom must compose with that without forking schemaless and schema-governed readings. The GraphQL nullability tables (all four list-wrapper combinations) and Avro §B’s strict-document vs resolution-aware pair are the acceptance tests.

4.3 The discriminator token (#9)

The one kernel addition, “fully designed” per the JSON Schema report §E9 and unchanged by subsequent reports: a Record/choice attribute naming a single dispatch field; the mapping table is derived from per-variant REQUIRED_FIXED pins (pairwise-distinct, resolution error otherwise); materialization (the pinned field loses omission privilege — present in every encoding); the !variant tag demoted to assertion (must agree; mismatch is a validation error); REQUIRED_FIXED only, no defaulted discriminators; declarable on the choice or a composed-from parent. Revision 34 work is the normative text, now written against the discrimination-class model (§3.2): state precisely how a declared discriminator composes with class-based dispatch (classes decide where they can; the token governs same-class sets and open-set positions), and work the deferred examples — recursive discriminated types, choices over choices. ASN.1’s UNIQUE and the Apollo/Relay injection convergence are the corroboration to cite in rationale (guide material).

4.4 The vocabulary batch (Tier 1–2, minus what §3.4 struck)

What genuinely remains:

• Literal-valued enums beyond token (integers, mixed scalars, null) — after §4.2. Feeds discrimination: state their class treatment explicitly.
• contains / minContains / maxContains — a genuinely new facet class (existential quantification over elements). Extend §5.7’s facet-kind taxonomy with the class and its refinement direction (tightening = raising the floor / lowering the ceiling); this is the one Tier-2 item with resolver-semantics wording to write.
• Decimal precision/scale facets on decimal_type — Avro decimal now, SQL inevitable. Classify per §5.7 (ordered facets).
• oid core type — dotted-integer value space with canonical text form (per §4.1’s framing); earns its place as uuid did; doubles as the natural discriminator value type for ASN.1 envelopes.
• Time decisions, decided once, as value spaces: zone-less/local timestamps (Avro local-timestamp-*, ASN.1 GeneralizedTime local forms) and calendar duration (Avro’s months/days/millis triple vs core duration’s model — verify what core’s model admits and say so). Both are new-or-clarified value spaces, not spellings — legitimate under §4.1.
• Float specials, the remaining half: the facets exist (§3.4); decide the named- convenience question (a core finite_float64-style refinement, or leave it to authors) and, when encodings return to scope, the per-encoding spelling policy ("NaN" strings etc.) — the latter is part-3 material, note it now.
• Byte-counted string length facet — optional; admit only on corpus evidence (protovalidate min_bytes/max_bytes), else keep drop-with-report.
• The annotation vocabulary, with a home. Two sub-decisions forced by Revision 33’s unresolved-annotation rule (§3.5): (a) where these names live — recommend a conversion companion schema (e.g. conv.tn, or per-source modules proto.tn, asn1.tn) rather than core, keeping provenance out of the interchange core; (b) the rename bridge’s name — Avro’s aliases is the right shape but @alias is taken (Revision 33 uses it for reference flattening in resolver output, a different animal, as the Avro report itself notes). Pick a distinct name (e.g. @renamed_from) in the evolution part’s vocabulary (§4.6) and reserve it now so converter report wording can stabilize. JSON-Schema annotation carriers (@title, @examples, @read_only, @write_only, @content_media_type) and @spelling (§4.1) round out the batch.

4.5 Rest field (#7) and requiredKeys (#8)

Tier 3, unchanged in design by the later reports (and pointedly not asked for by protobuf, ASN.1, Avro, or GraphQL — openness remains a JSON-Schema-ism, which the synthesis reads as confirmation the design is contained correctly). The rest field keeps records closed in the model (an ordinary declared map<text, X> field; openness is purely a JSON-encoding flatten/collect transform); its dispatch rule depends on the discriminator existing, so sequence after §4.3. requiredKeys is the map-side dual (presence obligations on a homogeneous map, deliberately without per-key types). Revision 34 items to settle in the text: rest fields under composition chains (at most one per chain), encode-side collision errors, and the tag-free-dispatch exclusion (rest-field records dispatch only via a declared discriminator). Note a Revision 33 interaction to state: the catch-all field’s map type lifts to a synthetic entry like any other form — no special carriage needed.

4.6 The evolution/compatibility part

The largest genuinely new item (Avro §E; retroactively unifies the proto open-enum flags, the ASN.1 extensibility flags, and gap #6’s re-conversion diffing). Not a kernel change — a new specification layer over resolved schemas:

• A compatibility relation between two resolved schemas (“every document valid under writer W is valid under reader R after a defined transformation”), checkable with existing machinery: field-state comparison (adding OPTIONAL or REQUIRED_DEFAULT is backward-compatible; adding REQUIRED is not), enum-set widening/narrowing, refinement loosening/tightening. Revision 33 helps here: resolved output is now fully canonical (synthetic entries, structural identity, R8’s resolved-output conformance tier), so the relation is defined over stable, comparable artifacts.
• A rename bridge as declared metadata on the new schema (name pending — §4.4).
• Explicit-never-silent: compatibility checking may report “int matches long by promotion”; validation never silently promotes.

Recommendation unchanged from the reports and worth honoring: spec the vocabulary early even if the part ships late — three converters’ report-flag wording depends on it, and retrofitting phrasing after divergent shipping is the expensive path. A Revision 34 deliverable of “terms and relation definitions” (even without full conformance text) would suffice.

4.7 sealed (#10) — keep deferred, commission the census

Both new evidence sources are now concrete (ASN.1 closed vs extensible object sets; GraphQL unions sealed vs interfaces open — one language with both cases as constructs). The deferral logic still holds (additive later; retracting a kernel guarantee is worse). Revision 34 action: no spec text; commission the Stage-5 corpus census (object sets + union usage) so Revision 35 can decide with data, and settle the two recorded open questions (instantiability of a sealed parent; enforcement scope across schema chains) as census questions.

4.8 The namespacing decision

One dotted-name policy serving proto packages, ASN.1 modules, Avro namespaces, and GraphQL — “decide once” per the synthesis, still undecided. Dots are already legal in unquoted type names, so this is convention plus (possibly) a reserved-annotation for the source namespace (@package family). Small, but it blocks converter output stability; decide in Revision 34 even if the answer is “convention only, no spec text.”

4.9 Product-side items with spec touchpoints

Not Revision 34 spec scope, but sequenced around it and worth tracking in the changelog:

• The machine-readable conversion-report schema — itself a TSON schema, the Stage-1 deliverable; its flag vocabulary should wait for §4.6’s terms.
• Canonical-strict profiles per encoding (protojson, Avro JSON, JER, GraphQL’s 2×2) — part-3-era documents; the §4.1 clause is written to give them their vocabulary.
• The GraphQL per-query compiler — the identified novel product; reuses records, choices, the token, and the null atom; zero kernel asks.
• Converter order (synthesis §6): JSON Schema → protobuf+protovalidate → Avro+Registry → GraphQL input-universe then per-query → ASN.1/X.509 pilot. With recursion answered (§3.1), the stated gating shifts to the null atom and, for the JSON Schema converter’s discriminated cases, the token.

5. Interactions with Revision 33’s carried-open items

Revision 33 deliberately carried four questions; the inputs bear on three:

• #11 (binary bucketing/name) — answered in direction by §4.1’s bytes collapse; fold the carried item into that work.
• #26 (hash-pin placement) — the synthesis’s content-addressing-over-value-spaces argument raises the stakes and should be resolved alongside §4.1; the external-review options (fragment; structured directive) remain the candidates.
• #54 (type-argument literal identity) — touched by literal-valued enums (§4.4): when enum members extend beyond token, the “bare token vs typed value” identity question recurs in argument lists; resolve together.
• #12 (PnW) and #34 (UTS #39 restructure) — no new input; carry forward on their own merits.

Guide candidates #4, #7, #13 (reader policy for unrecognized type-refs; annotation-recovery guidance; diagnostics conventions) remain pending for a guide pass; the reports add guide- grade material of the same kind (the SET OF multiset note, envelope-vs-flattened trade-offs, the discriminator convergence story) — batch them.

6. Recommended Revision 34 sequence

1. Value-space clause + bytes collapse + token re-grounding (§4.1), folding in carried #11 and settling carried #26 in its light. The one breaking change; do it first and alone in its own commit-equivalent so the diff reads clean.
2. Null atom + §7.3 tightening (§4.2), with Part 1 base-resolution composition stated.
3. Discriminator token normative text (§4.3) on the discrimination-class substrate, including the deferred worked examples.
4. Vocabulary batch (§4.4): literal enums (after 2; resolve carried #54 with it), contains facet class (+ §5.7 taxonomy extension), decimal precision/scale, oid, time value-space decisions, float-specials conveniences, annotation home + rename-bridge name reservation.
5. Rest field + requiredKeys (§4.5), after 3.
6. Evolution part: vocabulary and relation definitions (§4.6) — terms now, full part when ready.
7. Decisions without text: namespacing convention (§4.8); sealed census commissioned (§4.7).
8. Editorial: re-baseline the five mapping reports and the synthesis against Revision 33 (§3.4’s corrections, §3.6’s spellings) before any of their text informs normative drafting; batch the guide candidates.

Items 1–3 are the load-bearing sequence; 4–5 are parallelizable behind them; 6–8 can proceed independently.

Caveats

• The seven inputs are in review and unmodified; this document reflects their current text and may need revision if they change.
• Section references into the inputs use their own numbering; references into TSON use Revision 33’s. Where an input’s claim about the Revision 32 artifacts proved stale (§3.4), this document reports the Revision 33 state and flags the correction rather than adjudicating how the discrepancy arose.
• “Answered by Revision 33” means the spec text exists; it does not assert the reports’ authors would accept the answer — re-review of the recursion, disjointness, and regex clauses by the mapping-report track is the natural next check.
• The recommendations are the editor-input synthesis of the documents’ own worklists, adjusted for the Revision 33 baseline; they are candidates for Revision 34 planning, not adjudicated dispositions.