｢‍｣ Lingenic

Format Comparison

HSV vs JSON, CSV, XML, and others

Overview

* Text mode never needs escaping. Binary mode uses DLE transparency (~0.4% overhead).

vs JSON

Simple Object

{"name": "Alice", "age": 30, "city": "NYC"}

name␟Alice␞age␟30␞city␟NYC

Special Characters

{"msg": "He said \"hello\""}

msg␟He said "hello"

{"path": "C:\\Users\\data"}

path␟C:\Users\data

Multiline Content

{"text": "line 1\nline 2\nline 3"}

text␟line 1
line 2
line 3

Streaming

{"name": "Alice"}
{"name": "Bob"}
{"name": "Carol"}

␂name␟Alice␜name␟Bob␜name␟Carol␃

Nested Objects

{"user": {"name": "Alice", "email": "a@b.com"}}

user␟␎name␟Alice␞email␟a@b.com␏

Legend: ␟ = key:value · ␞ = properties · ␝ = array · ␎/␏ = nested (SO/SI) · ␜ = records · ␂/␃ = start/end

Both JSON and HSV support unlimited nesting. HSV uses SO/SI (Shift Out/Shift In) characters for nesting depth.

vs CSV

The Quoting Problem

name,bio
Alice,"Software engineer, loves coding"
Bob,"Said ""hello"" yesterday"

␂name␟Alice␞bio␟Software engineer, loves coding␜name␟Bob␞bio␟Said "hello" yesterday␃

CSV requires quoting when data contains commas or quotes. HSV never needs quoting.

vs XML

<user>
  <name>Alice</name>
  <age>30</age>
</user>

name␟Alice␞age␟30

Entity Escaping

<msg>x &lt; y &amp; a &gt; b</msg>

msg␟x < y & a > b

Document Structures (HTML-like data)

HSV can represent document trees. Angle brackets are just visible nesting delimiters—SO/SI are invisible ones:

<div class="box">
  <p>Hello <b>world</b></p>
</div>

tag␟div␞class␟box␞children␟␎
  tag␟p␞children␟␎
    text␟Hello
    ␝tag␟b␞text␟world
  ␏
␏

Where HSV wins: No entity escaping. Literal <, &, " in text content.

Where HTML wins: Human authoring, view source, 30 years of browser tooling.

AST Serialization

Abstract syntax trees are nested structures with node types and properties—a natural fit for HSV:

{"type": "BinaryExpr",
 "op": "+",
 "left": {"type": "Num", "value": 1},
 "right": {"type": "Num", "value": 2}}

type␟BinaryExpr␞op␟+␞left␟␎type␟Num␞value␟1␏␞right␟␎type␟Num␞value␟2␏

Compiler toolchains, linters, and code formatters can exchange ASTs without escaping operators like \, ", or &&.

Templating Engines

Templates mix literal text with structure. HSV keeps them separate without escape sequences:

Hello {{name}},
Your balance is ${{amount}}.
Click <a href="{{url}}">here</a>.

text␟Hello ␝var␟name␝text␟,
Your balance is $␝var␟amount␝text␟.
Click ␝tag␟a␞href␟␎var␟url␏␞text␟here␝text␟.

Template compilation becomes tree manipulation, not string surgery.

vs Binary Formats

HSV fills the gap: More efficient than JSON/XML, more debuggable than binary, and can still embed raw bytes when needed.

Binary Data

HSV uses DLE (Data Link Escape) for binary transparency—the same technique BISYNC used in 1967:

{"image": "iVBORw0KGgo..."}

image␟␐␂<raw PNG bytes>␐␃

How it works:

• ␐␂ (DLE STX) = start binary section
• ␐␃ (DLE ETX) = end binary section
• ␐␐ (DLE DLE) = literal DLE byte

Inside binary mode, only DLE needs escaping. All 17 other control codes become literal data.

Streaming Comparison

Parallel Parsing

HSV is the only format here that supports parallel parsing at every data level.

Why other formats require sequential parsing:

HSV has no escape state. Every separator byte (FS, GS, RS, US) is always a separator. Split on any of them, parse chunks independently.

Parallel at Every Data Level

File level:     Scan for STX/ETX → split into blocks → parse blocks in parallel
Record level:   Scan for FS (␜) → split into records → parse records in parallel
Property level: Scan for RS (␞) → split into pairs → parse pairs in parallel
Array level:    Scan for GS (␝) → split into items → parse items in parallel

Every split is just "find byte, cut." No state machine. No lookahead. No backtracking.

When to Use What

Summary

HSV is ideal when:

• You need streaming with clean framing
• Data contains special characters (quotes, newlines, backslashes)
• Size matters but you want human-readable
• You want simple split-based parsing
• You need parallel parsing on multi-core systems
• You need bidirectional protocol support (ENQ/ACK/NAK)
• You need flow control (XON/XOFF)

Stick with JSON when:

• Tooling ecosystem matters more than efficiency
• Human editing of the format is primary use case
• Existing JSON infrastructure is already in place