A JSON format for spreadsheet data

1.What is xlli?

xlli is a JSON format for spreadsheet data. One file extension (.xlli), one MIME type (application/vnd.xlli+json), one canonical form readable in any language with a JSON parser.

The first public dictionary is MicroTable — a simple grid kind for the cases where a spreadsheet would be overkill but a CSV is too plain. Headers, styled cells, sparklines and badges as cell types, sparse overrides for hand-edited content. About thirty lines of JSON for a real table.

xlli is designed to round-trip cleanly with Excel via .NET (EPPlus), and to be implementable in a weekend by a competent engineer in any language. The reference engines are C# and Rust. The Rust engine compiles to WASM for the browser and Node, and exposes a native binding for Python via PyO3. Two engines in lockstep, multiple language runtimes, one canonical JSON.

2.Why xlli?

Four things motivate the format. Take any one of them and a thoughtful engineer would build something like xlli. We hit all four in actual use, which is why we're building it now.

{ "value": "1234567890.123456789",
  "type": "decimal" }

3.The shared WIT interface

WIT (WASM Interface Type) is the IDL we use to describe what every xlli engine must implement. The two engines and every binding speak through these types, so the parity story isn't aspirational — it's a contract that fails CI when broken.

// xlli.wit — the shared interface (excerpt)

package xlli:core@0.1.0;

interface engine {
  /// Parse canonical xlli JSON into a typed model.
  parse: func(json: string) -> result<document, parse-error>;

  /// Serialise a model back to canonical xlli JSON,
  /// byte-identical across implementations.
  serialise: func(doc: document) -> string;

  /// Canonicalise input that may be valid but non-canonical
  /// (whitespace, key order). Returns canonical bytes.
  canonicalise: func(json: string) -> result<string, parse-error>;

  /// Validate a document against the v0.1 schema.
  validate: func(doc: document) -> result<_, list<validation-error>>;
}

interface document {
  resource document {
    constructor();
    xlli-version: func() -> string;
    document-kind: func() -> string;
    microtables: func() -> list<microtable>;
    add-microtable: func(id: string, table: microtable);
  }
}

world xlli-engine {
  export engine;
  export document;
}

The Rust engine implements this directly. The C# engine implements an equivalent interface generated from the same WIT source, so the surface area in both languages is provably the same. The JavaScript and Python bindings are thin generated wrappers — when WIT changes, the bindings regenerate.

WIT also makes adding a fourth or fifth language a mechanical exercise. Java via JNI, Go via cgo, Swift via WIT-direct bindings — same contract, mechanical port, no redesign.

4.What MicroTable looks like

A real example. Three products, Q1 revenue, a sparkline:

{
  "xlliVersion": "0.1.0",
  "documentKind": "container",
  "meta": {
    "id": "01HXM3V4F8Q2WK9C6YNBZPRS71",
    "title": "Q1 Revenue Review",
    "author": "Steve Dickson"
  },
  "microtables": {
    "summary": {
      "caption": "Q1 by Product",
      "styles": {
        "header": { "fontWeight": "bold", "backgroundColor": "#f5f5f5" },
        "money":  { "textAlign": "right", "fontVariantNumeric": "tabular-nums" }
      },
      "columns": [
        { "id": "product", "label": "Product",    "styleName": "header" },
        { "id": "q1",      "label": "Q1 Revenue", "styleName": "money"  },
        { "id": "trend",   "label": "Trend" }
      ],
      "values": [
        ["Widget A", 42500, null],
        ["Widget B", 38100, null],
        ["Widget C", 29700, null]
      ],
      "presentation": [
        [null, null, null],
        [null, null, null],
        [null, null, { "type": "sparkline", "values": [10,12,15,14,18] }]
      ]
    }
  }
}

The data lives in matrices. values is a 3 × 3 grid. presentation is the same shape, with cell content overrides where a richer cell type is wanted. Styles are named once and referenced by string. Sparse overrides are available for tables where most positions are empty.

The shape is rectangular, the parsing is JSON, the rendering is one HTML table with one stylesheet. Implementations that go further — multi-sheet workbooks, the worksheets and workbooks dictionaries arriving in v0.2 — extend the same root container.

5.Roadmap

Public spec at xlli.org. Reference implementations open-source. Conformance test suite shared.

6.Get involved

xlli is a coordination format. It works best when more than one implementation exists and more than one ecosystem uses it. We are particularly interested in talking to:

• EPPlus users and contributors. EPPlus is the natural .NET distribution channel; v0.2 ships an addin that exposes .xlli via ExcelPackage extension methods.
• Browser-side spreadsheet authors. SheetJS, jspreadsheet, anyone building structured tables in the DOM. The microtables dictionary was designed to fit naturally into your data model.
• Python data folks. The Rust+PyO3 binding gives you .xlli as a structured format that interoperates pleasantly with pandas and Polars without competing with them.
• Excel power users and VBA legends. You know which 5% of features matter for 95% of real usage. We need the second opinion.

7.More

• Founder — Steve Dickson: lineage from Edinburgh 1990 through Lehman OPTMODEL to today
• Glossary: technical terms used across xlli.org, with cross-references to where each concept is discussed
• xlli architecture document — private draft, available on request
• Reference implementation repositories — TBA, opening with v0.1