The forgotten hierarchy in every computer
When the American Standards Association published ASCII (ANSI X3.4-1963), they included four separator characters specifically designed for hierarchical data:
| Code | Hex | Name | Intended Use |
|---|---|---|---|
| 28 | 0x1C | File Separator (FS) | Separate files or major sections |
| 29 | 0x1D | Group Separator (GS) | Separate groups within a file |
| 30 | 0x1E | Record Separator (RS) | Separate records within a group |
| 31 | 0x1F | Unit Separator (US) | Separate fields within a record |
The codepoints were deliberately ordered: as the number decreases, the scope increases.
The ASCII committee envisioned hierarchical data storage decades before JSON, XML, or even CSV became widespread:
"These four can be used to subdivide data into structured groupings... The specific meaning of each separator is left to the application."
— Paraphrased from early ASCII documentation
ASCII also defined transmission control characters for framing data:
| Code | Hex | Name | Purpose |
|---|---|---|---|
| 1 | 0x01 | SOH | Start of Header |
| 2 | 0x02 | STX | Start of Text |
| 3 | 0x03 | ETX | End of Text |
| 4 | 0x04 | EOT | End of Transmission |
| 16 | 0x10 | DLE | Data Link Escape |
These were used in serial communication to frame messages. A typical transmission:
IBM's Binary Synchronous Communications protocol faced a problem: what if the data contains control characters?
Their solution: DLE (Data Link Escape). When you need to send arbitrary binary:
Inside a DLE-transparent section, only DLE itself needs escaping. All other bytes—including STX, ETX, and the separators—are literal data.
This elegant solution has been available since 1967. HSV uses it unchanged.
These characters were designed for hierarchical data. But the computing industry forgot them:
Every format reinvented hierarchy using printable characters—requiring escaping, quoting, and complex parsers.
Using printable characters as delimiters means they can appear in data:
The ASCII separators (0x1C–0x1F) never appear in normal text. They don't need escaping. They were designed for exactly this purpose.
HSV uses ASCII control characters as they were intended—all 18 of them:
| ASCII | HSV Purpose |
|---|---|
| Framing | |
| SOH (0x01) | Start header metadata |
| STX (0x02) | Start data block |
| ETX (0x03) | End data block |
| EOT (0x04) | End of stream |
| Protocol | |
| ENQ (0x05) | Enquiry (request acknowledgment) |
| ACK (0x06) | Acknowledge (success) |
| NAK (0x15) | Negative acknowledge (error) |
| CAN (0x18) | Cancel operation |
| Flow Control | |
| XON (0x11) | Resume transmission |
| XOFF (0x13) | Pause transmission |
| SYN (0x16) | Sync/keepalive |
| Nesting & Binary | |
| SO (0x0E) | Start nested structure |
| SI (0x0F) | End nested structure |
| DLE (0x10) | Binary transparency (escape to raw bytes) |
| Structure | |
| FS (0x1C) | Separate records |
| GS (0x1D) | Separate array elements |
| RS (0x1E) | Separate properties |
| US (0x1F) | Separate key from value |
This isn't a new invention. It's a return to what the ASCII committee designed 60 years ago—including BISYNC's DLE transparency for binary data, and full protocol support for bidirectional communication.
Non-printable: Control codes never appear in normal text, user input, or file content. No escaping needed.
Universal: Every computer system supports ASCII. These bytes work everywhere.
Invisible: The structure doesn't pollute the data. You see content, not syntax.
Hierarchical: Unlimited nesting via SO/SI, plus four structure levels and framing. Covers all data structures.
Every computer already has these characters. Every programming language can use them. They've been in every text file specification since 1963.
We just forgot to use them.