Serialization
Compatibility
The conformance rules ensuring that independent implementations exchange, parse, normalize, and reproduce normative Survey representations without ambiguity while preserving one canonical spatial meaning.
Serialization Compatibility establishes how a conforming implementation proves that its machine-readable Survey expressions are compatible with the normative serialization and interchange rules defined by the Specification.
The integrated Specification now makes the current machine-interchange profile concrete: FSF-CJSON-1.0 is the candidate canonical serialization for the solved Point / Segment / SCPE core, with exact structured CRPC values, deterministic normalization-before-serialization, deterministic key ordering, duplicate-key rejection, governed unknown-field handling, NFC string normalization, and canonical UTF-8 byte output.
Implementations may use any internal representation they choose. Where canonical interchange is claimed, they shall reproduce the governed FSF-CJSON-1.0 meaning and bytes exactly. Future alternate normative encodings remain a separate Specification-level question and shall not be invented by Conformance.
Day #126 lineage reconciliation further distinguishes mathematical identity, representation identity, format identity, and Specification identity. FSF-CJSON-1.0 is a governed canonical representation of supported mathematical objects; it is not itself the spatial identity of those objects.
Conformance Principle Implement however you like. Exchange one spatial truth.
The Current Canonical Interchange Profile Is Now Testable
Specification 06 now defines FSF-CJSON-1.0 as the current candidate canonical machine representation for the solved core.
Conformance may therefore test exact parsing, validation, normalization, serialization, byte identity, round-trip behavior, and cross-implementation exchange for that profile.
Authoritative Exchange Uses FSF-CJSON-1.0 for the Current Core
Every implementation claiming serialization compatibility with the current Mandatory Core shall support FSF-CJSON-1.0 for the canonical Point / Segment / SCPE profile.
Internal representations may differ, but authoritative exchange shall satisfy the applicable canonical format rules and preserve one exact Survey meaning.
Canonical Bytes Follow Valid Canonical Meaning
Canonical serialization shall operate on valid supported FSF objects.
The governing processing discipline is: validate → normalize → serialize.
Invalid input shall not become canonical merely because it can be encoded as syntactically valid JSON.
Exact Values Are Structural, Not Floating
Canonical exact coordinate values shall use the structured CRPC representation defined by FSF-CJSON-1.0.
JSON numeric literals shall not substitute for canonical exact coordinate components where the format requires exact integer-string fields.
Equivalent rational values shall first normalize mathematically before canonical serialization.
Point · Segment · SCPE Must Serialize Canonically
Supported Point, Segment, and SCPE objects shall serialize according to the exact type structures and normalized geometry rules defined by the Specification.
Segment endpoint order and SCPE traversal/start-vertex form shall therefore be normalized before byte comparison.
Canonical Object Structure Has One Key Order
Canonical FSF-CJSON-1.0 object members shall appear in the deterministic order required by the Specification.
Implementations shall not emit semantically equivalent but differently ordered canonical objects where one exact canonical key order is required.
Array Order Is Preserved Where Meaning Requires It
Arrays shall preserve the semantic order defined by the serialized object.
Conformance shall not arbitrarily reorder vertices, sequence elements, or other ordered content unless normalization explicitly defines the canonical order before serialization.
Canonical Parsing Must Reject Ambiguous Object Structure
Duplicate object keys shall be invalid in canonical FSF-CJSON-1.0 input.
Unknown or prohibited fields shall be rejected according to the governing format rules rather than ignored, guessed, or treated as harmless extensions.
Canonical Text Must Be Deterministic
Canonical serialization shall use UTF-8, omit a byte-order mark, apply required Unicode normalization, and follow the shortest required JSON escaping behavior defined by the Specification.
Locale, platform defaults, pretty-print settings, or implementation-specific escaping preferences shall not alter canonical output.
Canonical Serialization Is Compact
Canonical FSF-CJSON-1.0 shall contain no insignificant presentation whitespace.
Pretty-printed, indented, annotated, or UI-oriented JSON may exist as noncanonical presentation, but shall not be confused with canonical machine interchange.
The Same Canonical Bytes Must Produce the Same Meaning
Independent conforming implementations shall parse the same valid FSF-CJSON-1.0 canonical bytes to the same authoritative FSF object and spatial meaning.
Parsing shall not depend on undocumented defaults, locale, implementation-specific field interpretation, hidden registries, database state, or other mutable context.
Same Normalized Object, Same Canonical Bytes
For every supported normalized object in the current profile, conforming implementations shall produce identical FSF-CJSON-1.0 canonical UTF-8 bytes.
Semantic equivalence does not excuse a byte mismatch where the current canonical format defines one exact serialization.
Parse and Serialize Without Semantic Drift
A canonical FSF-CJSON-1.0 object serialized by one conforming implementation and parsed by another shall preserve identical canonical meaning.
Re-serialization of the normalized parsed object shall reproduce the required canonical bytes exactly.
Convenience Input Does Not Acquire Canonical Authority
If a future or implementation-facing parser accepts valid noncanonical input forms, those forms shall remain distinguishable from canonical FSF-CJSON-1.0 and shall normalize deterministically before any canonical serialization claim is made.
Conformance shall not treat arbitrary JSON that can be interpreted as equivalent as canonical bytes.
Serialization Must Not Silently Lose Exact Meaning
Canonical interchange shall preserve the complete exact CRPC and geometry meaning required by the serialized object.
Truncation, rounding, floating conversion, lossy compression, reduced numeric precision, or approximate geometry substitution shall not be represented as canonical interchange.
Interchange Must Not Require Shared Internals
Canonical FSF-CJSON-1.0 data shall be independently exchangeable across conforming implementations without proprietary internal structures, private schema extensions, hidden registries, inaccessible services, or shared implementation libraries.
Compatibility shall arise from the published Specification and Conformance rules.
The Encoding Identity Must Be Explicit
A current serialization conformance claim shall identify FSF-CJSON-1.0 wherever the format is being tested.
Final top-level FSF Specification identifier syntax and future compatibility-declaration syntax remain open and shall not be invented by Conformance.
Format identity identifies the governing representation. It does not become part of the spatial identity of the place or geometry described.
Where compatibility is claimed across governed formats or Specification versions, the representations must correspond losslessly and deterministically to the same normalized mathematical object.
Unsupported Serialization Must Fail Clearly
A conforming implementation shall not silently reinterpret an unknown, unsupported, malformed, or incompatible encoding as valid canonical Survey input.
Unsupported forms shall be rejected or classified according to the governing validation and profile/version rules.
One Current Canonical Format Does Not Pre-Adopt Future Encodings
FSF-CJSON-1.0 is the current candidate canonical machine representation for the solved core.
A future Specification may adopt another normative representation only through an explicit governed decision defining its relationship to existing canonical meaning and compatibility obligations.
Conformance 06 shall not presume that future alternate encodings are already canonical or normatively equivalent.
Representations may evolve. Canonical place may not drift. A future encoding may differ in syntax or bytes only where the governing Specification explicitly defines its status, precedence, and exact compatibility relationship to existing canonical meaning.
Serialization Compatibility Must Be Proven With Exact Fixtures
Reference Vectors or equivalent executable fixtures shall test parse success, parse failure, normalization-before-serialization, canonical structured CRPC encoding, deterministic object ordering, canonical geometry encoding, canonical byte equality, and round-trip reproduction.
The current solved core is sufficiently deterministic for those fixtures to be authored now.
Interchange Disagreement Is a Conformance Issue
Failure to parse valid canonical bytes, acceptance of invalid canonical serialization, disagreement about canonical meaning, noncanonical key order, incorrect normalization, precision loss, or canonical-byte mismatch shall constitute a Conformance failure where the applicable rule is mandatory.
Proprietary convention or implementation preference shall not resolve disagreement in normative interchange or canonical spatial meaning.
Current Serialization Profile Now Executable
FSF-CJSON-1.0; structured CRPC values; validate → normalize → serialize; Point / Segment / SCPE encoding; deterministic key order; semantic arrays; duplicate-key rejection; governed unknown fields; UTF-8 canonical text; compact bytes; deterministic parsing; exact byte equality; round-trip proof.
Still Open in Conformance
Final top-level FSF Specification identifier; formal Specification version-succession rules; full cross-version compatibility syntax; future normative encoding precedence; incompatible-transition / migration governance if ever required; machine-readable serialization error identifiers; final formal interchange test-suite identifiers; and conformance rules for any future additional normative encoding.
Serialization Has Moved From Abstract Interchange to One Testable Canonical Format
The original section correctly preserved the possibility of one canonical serialization or multiple governed normative encodings because the Specification had not yet selected a format.
The integrated Specification has now selected FSF-CJSON-1.0 for the current solved core. Conformance 06 therefore tests that format directly while preserving future-format governance as a later Specification decision.
Conformance May Detect Encoding Incompatibility; It Does Not Authorize Succession
If a future representation cannot preserve lossless deterministic correspondence to the same normalized mathematical object, Conformance shall classify that relationship according to the governing incompatibility rules rather than treating it as compatible serialization evolution.
Any intentionally incompatible successor would require separate institutional Specification succession / migration governance. Conformance may prove the difference; it does not grant authority to adopt it.
Primary Referenced Findings
This Conformance section is derived especially from Requirements Findings #30, #57–#60, #63–#64, #66, #72–#75, and #78–#83.
Architectural Boundary Formats may differ internally and, where governed by the Specification, normatively. They may not disagree about canonical spatial meaning or create competing authoritative truths.