Nitro XML: porting ChristopherVR/ooxml to Rust and WebAssembly

This plan is reconciled with PRODUCT_SPEC.md v3 (full Rust/WASM design lock), which wins wherever they disagree. Decisions: §6.1. Board: Nitro XML project. Repo: jgridifier/nitro-xml. Licence: Nitro XML is MIT-licensed; files ported or derived from ooxml remain under Apache-2.0 (NOTICE, LICENSE-THIRD-PARTY, PROVENANCE.md).

Project: Nitro XML · Repo: jgridifier/nitro-xml · Rust crates: nitro-xml-opc (shared foundation: zip, xml, opc and drawingml modules), nitro-xml-xlsx, nitro-xml-docx, nitro-xml-pptx, nitro-xml-wasm and the umbrella crate nitro-xml (all unclaimed on crates.io on 2026-10-11) · npm package: nitro-xml (unclaimed on 2026-10-11).

Upstream analysed: https://github.com/ChristopherVR/ooxml at commit e66aaec24adc0b68472eae1fc42aa4598e09c352 (2026-10-11), from a read-only shallow clone. The repo pins this commit as the parity oracle and the source of the painters.

Core principle (unchanged): rendering stays fully client-side in the browser.

Design lock (Jared, 2026-10-11): "This is a full Rust/WASM project. If something doesn't exist we will build it." Everything that ships is Rust/WASM: package, model, layout, renderers, viewer shell, editor UI (ribbons, dialogs), text input, selection and caret, commands, history and writer. The only JS is a minimal loader (wasm bootstrap, event forwarding and the per-frame command-buffer applier) with its own gated size budget. ProseMirror, the upstream Lit UI and the TS painters are not shipped. The upstream TS engine is test-only: correctness oracle, perf baseline and pixel reference. There is no runtime fallback; if wasm cannot run, the component shows an "unsupported browser" message. The goal is the fastest, most efficient, highest-quality OOXML renderer and editor available, beating the original on every format at every size.

0. Read this first: the upstream is much larger than a "renderer"

The brief describes a browser-client renderer for docx, pptx and xlsx. The upstream repository is a full Office suite monorepo. It contains:

• a headless library (ooxml-core) that reads, edits, validates and writes Word, Excel, PowerPoint and Visio
• a Lit web-component UI (ooxml-ui) with ribbons, editors and dialogs
• bindings for React, Vue, Angular, Svelte, Solid and vanilla JS
• a formula engine (README: 380 to 480+ functions)
• Yjs real-time collaboration, MCP servers, an "OpenTeams" chat app, a Tauri desktop wrapper and an integrated "OOXML Office" PWA

cloc counts about 1.56 million lines of TypeScript code (excluding blank lines and comments) in 12,989 files. About half of that is tests.

Original recommendation (superseded): port only the read and view path. Current scope (Jared): the full editor suite for docx, xlsx and pptx, built viewer first (Milestone 1) and then editor (Milestone 2), all in Rust/WASM. Formats: .docx, .xlsx and .pptx plus their macro-enabled and template variants (.docm/.xlsm/.pptm, .dotx/.xltx/.potx, .dotm/.xltm/.potm; macros never execute, vbaProject.bin round-trips byte for byte). Legacy .doc/.xls/.ppt, password-protected or encrypted files, CSV, Visio and every other upstream format are out and show an "unsupported format" message. Also out: Teams, MCP, macro execution, framework bindings beyond the web component; collaboration and export (default out). This is far larger than the original 25k to 45k line estimate: the roughly 217k production lines of src/ui are now rebuilt in Rust as well, and no credible estimate exists until R0 (PRODUCT_SPEC Q3).

1. Architecture map

1.1 Language, framework, tooling

1.2 Package layout

src/core     ooxml-core: ALL logic, DOM-free (areas: xml, opc, units, color, geometry, drawingml,
             chart, diagram, text, math, docx, xlsx, pptx, visio, collab, crypto, digest, teams, automation…)
src/ui       ooxml-ui: Lit web components; DOM only; product editors under ooxml-ui/<product>
viewers/*    docx, xlsx, pptx, visio, teams: framework bindings, docs sites, viewer MCPs
demos/*      demo apps per product (docx: demo-vanilla; pptx: react/vue/angular/svelte/vanilla…)
e2e/*        Playwright suites and fixtures
apps/office-suite, site/, desktop/ (Tauri), mcp/, scripts/, schemas/ecma-376-transitional

Dependency direction (from the README): bindings -> ooxml-ui (DOM) -> ooxml-core (logic) -> ole2, emf-converter, mtx-decompressor. The core never imports the UI. This is the seam Nitro XML uses.

1.3 Lines of code (cloc 2.04, code lines only)

"prod" excludes *.test.*, *.spec.*, *.generated.*, __tests__, __fixtures__ and fixture folders.

Realistic Rust port surface (read path for three formats plus shared layers): roughly 25k to 45k lines of TS logic, dominated by pptx. This is an estimate, not a count.

1.4 Entry points (read path)

• xlsx: loadXlsx(bytes) in src/core/xlsx/read/load.ts (loadWorkbook in xlsx/load/detect.ts adds legacy .xls, CSV and passwords)
• docx: loadDocx(bytes) in src/core/docx/parse.ts (loadDocument in docx/load/detect.ts)
• pptx: PptxHandler (src/core/pptx/core/PptxHandler.ts, extending PptxHandlerCore)
• docx layout: layoutDocumentModel(model, measurer, options) in src/core/docx/layout/layout.ts
• xlsx view: buildItems(input): CellItem[] in src/core/xlsx/ui/grid/cell-items.ts

1.5 Parsing pipeline: zip, then XML, then model

1. Zip: jszip (most areas; e.g. xlsx/read/package.ts, opc/package.ts) and fflate (core dependency). Bounded by MAX_INPUT_BYTES (50 MB), MAX_PARTS (10,000), MAX_UNCOMPRESSED_BYTES (300 MB) and MAX_PART_BYTES (200 MB) in xlsx/read/package.ts.
2. OPC: src/core/opc handles [Content_Types].xml, relationships, part path resolution, the hyperlink safety policy, properties and signature detection. Writes use string surgery to keep untouched bytes identical.
3. XML: two parser families.
   • The shared xml area (parseXml) uses @xmldom/xmldom DOM and rejects DTD and ENTITY declarations. xml/lite.ts is a fast reader for large <sheetData> that falls back to the full parser.
   • The pptx area still uses fast-xml-parser objects (about 50 files under pptx/core/core/runtime). The roadmap calls moving it to the shared model "One XML model".
4. Model:
   • xlsx: Workbook with sheets, styles, shared strings and theme. Unknown parts are kept in workbook.source.parts.
   • docx: DocumentModel (blocks, sections), with media collected separately.
   • pptx: PptxData with a 16-kind PptxElement union (text, shape, connector, image, picture, table, chart, SmartArt, OLE, media, group, ink, content part, zoom, 3D model, unknown) and theme, master, layout and placeholder inheritance.

1.6 Rendering pipeline

1.7 Viewer UI and demo apps

• The viewers are Lit custom elements (<docx-editor>, <xlsx-editor>, the pptx web controls) with thin framework bindings.
• Demo apps: demos/docx/demo-vanilla, demos/xlsx/demo-vanilla, demos/pptx/demo-{react,vue,angular,svelte,vanilla,three-parity}, plus apps/office-suite (the integrated PWA, published at christophervr.github.io/ooxml/).

1.8 External runtime dependencies

• ooxml-core: jszip, fflate, fast-xml-parser, @xmldom/xmldom, utif, emf-converter (Apache-2.0), mtx-decompressor (MPL-2.0), prosemirror-*, yjs, y-prosemirror, y-protocols, lib0. Optional peers: node-forge, xml-crypto, @napi-rs/canvas.
• ooxml-ui: lit, dompurify, opentype.js, prosemirror-*, yjs, zod, emf-converter.
• @christophervr/ole2 (Apache-2.0) is inlined in the pptx bundle.

1.9 Tests and fixtures

• Test files: 1,765 in src/core, 1,195 in src/ui, and 472 Playwright specs.
• Fixtures:
• docx: 158 files, 3 KB to 67 KB (median 14 KB)
• xlsx: 11 files, 5 KB to 23 KB
• pptx: 473 files, 4 KB to 36.8 MB. This includes 229 SmartArt gallery decks and large real-world decks of 1.8 MB to 36.8 MB in e2e/pptx/fixtures.
• Gap: there are no large docx or xlsx files, so the perf track has to generate them.

1.10 Activity and issues

• The GitHub repo was created on 2026-10-01 (it imports older viewer repositories with their history) and was last pushed on 2026-10-11. It has 11 stars, 0 open issues, 15 closed issues and 35 PRs.
• Recent closed issues are mostly xlsx editing semantics (filters, structured references, SUBTOTAL) and pptx fidelity (Morph, line spacing, thin strokes).
• It is a fast-moving target. Pin a commit.

2. Feature coverage per format (from the READMEs and parity docs)

xlsx (viewers/xlsx/README.md, docs/xlsx-parity-status.md, updated 2026-10-08) - Renders: - grid with frozen panes - fonts, fills, borders, alignment, number formats, merges, column and row sizes - conditional formatting (rules, colour scales, data bars, icon sets) and validation lists - common charts as SVG (8 families), pictures and sparklines - File types (upstream): .xlsx, .xlsm, .xltx, legacy .xls and CSV. Nitro XML opens .xlsx, .xlsm, .xltx and .xltm; legacy .xls and CSV show an "unsupported format" message. - Gaps: - pivot tables, slicers, external links and Power Query are kept but not shown - shapes, SmartArt and form controls show as placeholders (SmartArt is drawn from the cached drawing) - no iterative calculation - The project's own assessment: "Full 1:1 Microsoft Excel parity has not been achieved". There is no lossless saving and no whole-workbook pixel equivalence.

docx (docs/word-parity-review.md, viewers/docx/docs/outstanding-work.md) - Renders: - paragraphs, runs and character styles, theme colours and fonts - numbering and lists - sections, breaks, columns, and read-only headers, footers and notes - tables (grid, merges, borders, shading, styles), inline pictures, hyperlinks and bookmarks - tracked changes and comments - charts drawn read-only for bar, column, line, area, pie, doughnut, scatter and radar - equations as read-only MathML (Print Layout shows [Equation]) - Gaps: - Print Layout is read-only and editing is continuous - complex typography, floats and Word font metrics are incomplete - floating and unsupported drawings show as placeholders - floating (wp:anchor) charts are not placed in Print Layout - bubble, stock, surface and chartex charts show only a labelled frame - no general shape or SmartArt editing

pptx (viewers/pptx/README.md, docs/guide/limitations.md) - Renders: - 187 preset shapes, custom geometry - gradient, pattern and picture fills, shadows, glow, reflection, soft edges, 3D bevels and cameras, WordArt warps - tables, SVG charts, SmartArt, EMF and WMF, embedded fonts, ink, audio, video and GLB models - transitions and animations - Known gaps: - SmartArt re-layout without a cached drawing is approximate (228 of 229 gallery fixtures produce the same shape set as PowerPoint) - metal 3D materials have a residual error - some WordArt can presets are off at certain depths - pie bestFit label spacing is approximated - 3D model camera details are unverified - saving an edited slide can still change minor markup - At runtime, unsupported features are reported in data.warnings.

What this means for Nitro XML: the TS renderers are mature and tuned against Office. Under the design lock they are rebuilt in Rust, so they become the pixel reference: every Rust renderer must re-earn the visual thresholds format by format (pptx effects especially).

3. Port design

3.1 What is built in Rust/WASM (everything that ships)

3.2 The interface between JS and WASM

• The loader is the only JS. It instantiates the wasm (streaming compile, cached compiled module, pre-warmed worker), loads a small core module and per-format modules on demand, and forwards batched browser events (input, pointer, wheel, keyboard, composition, resize) into wasm. Its size has its own ceiling (#37).
• Handles. The headless API exposes document handles that own the model in linear memory (open → handle, queries, commands, save, free), with a FinalizationRegistry safety net.
• Bulk transfer, never per-cell calls (#14): struct-of-arrays typed-array views over wasm memory for bulk data, interned string tables, Uint8Array views for media.
• Per-frame command buffer. Each frame's canvas draw calls or DOM-building operations cross the boundary as one batched handoff applied by the loader; no per-element WASM-to-JS calls in the render path. Text measurement follows upstream, batched per layout pass (#14).
• Workers: one worker per document, ArrayBuffer transferred. The split follows upstream's drawing technology per painter: DOM-building painters apply on the main thread, canvas painters may use OffscreenCanvas in the worker (R0, #36).
• Memory: linear memory never shrinks; one worker per document; upstream limits enforced; crash recovery reloads in a fresh worker (viewer) or replays the op journal (editor).
• Threads: none by default (no SharedArrayBuffer, no COOP/COEP needed by embedders). Only the perf harness serves COOP/COEP.

3.3 Rust crates considered

All versions and licences are from the crates.io API on 2026-10-11.

Licence constraints: - Nitro XML is MIT-licensed. Files ported or derived from ooxml remain under Apache-2.0 (see NOTICE, LICENSE-THIRD-PARTY and PROVENANCE.md). The repo ships LICENSE (MIT) and LICENSE-THIRD-PARTY (upstream Apache-2.0 text); package.json says "license": "MIT"; crates with only original files say license = "MIT" and crates containing ported upstream files say license = "MIT AND Apache-2.0". Ported files carry the SPDX header Apache-2.0 plus a provenance line; new files use MIT. - Upstream is Apache-2.0, so ported logic is a derivative work. Apache-2.0 §4 allows distributing derivative works under other terms, provided its conditions are met: NOTICE crediting upstream (ChristopherVR/ooxml) is carried forward, copyright notices are kept, and changes are stated in PROVENANCE.md (one entry per ported or derived module, mirroring upstream's own convention). - mtx-decompressor is MPL-2.0 (file-level copyleft). It is not in scope for v1 and the licence check does not allow MPL. - jszip is dual MIT or GPL-3.0 and is used under MIT. It is not ported; Rust uses zip. - font-advance-widths*.generated.ts holds glyph widths measured in PowerPoint through COM (NOTICE). It is data under Apache-2.0; #98 records its provenance and asks upstream (non-blocking for renderer work). - The CI licence check (#31) allows only MIT, Apache-2.0, BSD-2/3-Clause, ISC, Zlib and Unicode licences, for crates and npm production dependencies.

3.4 Test strategy

1. Golden fixtures: fixtures/manifest.json with sha256, tier, features and licence (#4). Large docx and xlsx fixtures are generated with fixed seeds.
2. Parity against the TS oracle (#5):
   • Run the pinned ooxml-core and dump a normalised "view IR": CellItem[] for xlsx viewports, LayoutResult for docx, PptxElement trees for pptx.
   • Diff it against the Rust output, with float rounding and an allow-list that needs a reason per entry.
   • For docx, both sides use upstream's deterministic createFakeMeasurer(), so fonts never cause a diff.
3. Testing policy (Jared): no coverage targets; the differential suites (items 2, 4, 5 and 8) are the main check. A new bug becomes a new corpus file first, and a unit test only when no file can isolate it; each unit test's first line names the bug it catches; tests that restate the code are rejected. Upstream Vitest suites are not ported wholesale; their inputs are mined into corpus tables (numfmt codes, XML edge cases, safe-href cases) and run differentially.
4. Visual diffs (#45): the TS engine renders references (test-only) at DPR 1 and 2 plus print-to-PDF; the Rust renderer must stay within pixelmatch thresholds (xlsx ≤0.1% per viewport; docx ≤0.5% per page with the same page count; pptx ≤0.5% per slide). Same Chromium build and fonts.
5. Renderer and editing-surface gates: accessibility (axe plus an AX-tree screen-reader script, #42), selection and caret parity (#43), bidi (#44, #57), CJK IME (#56), spellcheck (#58), crash recovery (#30, #62), and the ship check that no shipped artefact imports TS (#38).
6. Fuzzing: cargo-fuzz on zip, XML, OPC and each format entry point (#30). Port the upstream *.fuzz.test.ts cases.
7. Performance gate: see §4.1. Every stage gate includes it.
8. Editor gates (M2): lossless round trip with validators (#48, #49), edit round trip (#50), undo/redo parity (#51), edit-path perf (#52); see PRODUCT_SPEC §5.

4. Staged plan

Gates (PRODUCT_SPEC §5). Every stage from Stage 3 must pass: view-IR parity, visual at DPR 1 and 2 plus print-to-PDF, unsupported content at 0 for the format at its stage gate, accessibility, bidi, selection and caret, and the perf gate. Perf timing rule: every commit posts numbers; until a format has a full open-to-first-paint path in Rust the gate is regression-versus-main only; from that commit on, WASM must beat TS at every tier (S, M, L, XL), at 1x and 4x CPU, on first paint (including wasm fetch, compile and instantiate), cold parse, scroll/view-query latency and peak memory. "Beats" = lower median and the 95% bootstrap CI of the WASM/TS ratio entirely below 1.0; a tie fails; never relaxed. Foundation PRs (zip, XML, OPC) are tracked, not gated against TS. Bundle and loader ceilings are fixed at R0 and only go down.

Sizes: S is part of one agent session; M is about one full session; L is several sessions and should be split at claim time.

Milestone 1, viewer

Post-port redesign (Jared), backlog, not claimable: DOM-vs-canvas comparison (#92), in-wasm text shaping (#93), metric-compatible open fonts (#94); labelled blocked-redesign.

Milestone 2, editor (labelled blocked-m2 until the M1 gate passes and Jared confirms the budget)

Parallelism: - Stage 1 needs only the fixture corpus (#4), so the TS baseline is ready before the first Rust parser lands. The parse race (#40) starts in the foundation stage. - R0 inventory (#34) and loader budget (#37) start early (after #1 and #2/#14); mapping (#35) and the worker split (#36) follow the inventory; model work in Stages 3 to 5 (#15 to #17, #20, #21, #24 to #26) can proceed before R0 closes, renderer work cannot. - The integration issues (#19, #23, #27) are the serial points and arm each format's hard perf gate.

4.1 Performance-eval track (Stage 1, Jared's requirement)

• Harness:
• A local static server sets COOP and COEP headers, which performance.measureUserAgentSpecificMemory needs.
• Minimal host pages mount the upstream TS renderers (test-only reference and baseline) and the Nitro XML components. A ?engine=ts|wasm switch selects which one is measured.
• A Playwright (Chromium) runner opens a CDP session per page. Runs are fully offline.
• Corpus: size tiers S (<100 KB), M (<1 MB), L (<10 MB) and XL (>=10 MB) per format, with at least 3 files per tier. Large docx and xlsx are generated (xlsx up to 1M cells; docx up to 500 pages). pptx uses upstream's 1.8 MB to 36.8 MB decks, once their redistribution licence is confirmed.
• Metrics:
• parse time (bytes-ready to parse-end)
• time to first paint, including wasm fetch, streaming compile and instantiate (double rAF)
• scroll/view-query latency and time to interactive
• full render time
• peak JS heap: CDP Runtime.getHeapUsage sampled every 10 ms, plus measureUserAgentSpecificMemory and post-GC retained heap
• WASM linear memory (memory.buffer.byteLength)
• JS bundle and .wasm size (raw, gzip, brotli)
• main-thread long tasks: count and total blocking time
• Method:
• cold runs use a fresh context with no HTTP, V8 or WASM code cache; warm runs reuse one context after a discarded warm-up
• enough iterations for a meaningful 95% bootstrap CI of the WASM/TS ratio (start at 10 cold and 20 warm, raise as needed)
• report the median, p95 and the CI
• CPU throttle at 1x and 4x (a mobile proxy)
• History:
• perf/history.jsonl lives on a perf-data branch, with one line per (commit, engine, fixture, mode, env) and {median, p95, min, max} per metric
• main-branch runs append; PR runs only compare
• Gate:
• Regression vs main (always): timings +10% and +5 ms; memory +10% and +2 MB; brotli size +3% and +10 KB; TBT +15% and +20 ms; baseline = median of the last 5 main runs. perf-regression-accepted with a written reason can override this part only.
• WASM beats TS (per format, armed by #19, #23, #27; never relaxed): every tier, 1x and 4x, first paint, cold parse, scroll/view-query and peak memory; lower median and 95% CI of the ratio below 1.0; a tie fails. Editing (keystroke-to-paint, IME commit-to-paint, undo, save) gets the same rule in M2.
• No performance-based fallback of any kind. A loss is a red gate fixed by design (streaming compile, cached module, pre-warmed worker, small core plus lazy per-format modules).
• Bundle and startup: per-format initial-payload ceiling (brotli, including any fonts and data shipped) and loader ceiling, fixed at R0, ratchet down only; time to interactive gated.
• Dashboard and public scoreboard: a static page (inline SVG, no chart library) on Pages, navy, black and white, published from every main commit: TS and WASM on the same axes, plus the parse, render-to-first-paint and open-edit-save races against pinned competitors (#39 to #41, #70): SheetJS, ExcelJS, calamine, umya-spreadsheet, docx-preview, mammoth.js, docx-rs, PPTXjs, the LibreOffice WASM build, other Rust/WASM viewers found during vetting, and always upstream ooxml TS. Entries that do less are shown as "not comparable"; losses are published as prominently as wins.

5. Issue breakdown

97 planned issues on GitHub (#1 to #96 and #98; #97 is the Stage 0 kickoff tracker), generated from issues.json (gen_issues.py). Plan numbers equal GitHub issue numbers; each issue has a Depends on #X line. Milestone 2 issues carry blocked-m2; post-port redesign issues (stage PP) carry blocked-redesign.

• Agent fit: Codex (on the 6.1 sol model only) for well-specified mechanical ports; Claude Code for design-heavy or cross-cutting work; Cursor for CI, browser integration and dashboards; OpenCode (free NVIDIA models) may be added after evaluation; Grok Build (Grok 4.7) is last-resort overflow once the three primaries are out of credits; a human Developer owns the scoreboard races; Head Of Product signs off the R0 record (#33); Jared owns the post-port redesign (#92 to #94).
• Every issue follows AGENTS.md (claim, branch issue-<N>-<slug>, PR with Closes #N, handoff comment).

6. Risks and open questions for Jared

Top risks

1. Scope mismatch. The upstream is a 1.56M-line editor suite, not a small renderer. Unless the port is limited to the read and view path for three formats, it will not fit a limited credit budget. pptx alone is about 146k production lines in core.
2. Moving upstream. The repo was created on 2026-10-01, is pushed daily and is mid-refactor (the pptx XML model migration, DrawingML extraction). Pin a commit and re-sync on purpose, each time with parity re-runs.
3. Renderer fidelity. The TS renderers are tuned against Office captures, and the Rust renderers must re-earn the pixel thresholds; pptx effects are hardest. Mitigation: parity harness, visual diffs at DPR 1 and 2 plus print, per-format gates. The biggest new risk is the Rust text-editing surface (IME, bidi, spellcheck, accessibility, mobile keyboards), now its own stage (E-text).
4. Text measurement across the boundary. Fonts and measurement follow upstream for now, so measurement requests must be batched per layout pass (#14) or they erase WASM gains. In-wasm shaping and open fonts (Carlito, Caladea) are Jared's post-port redesign (#93, #94).
5. Small-file startup is a hard gate. Instantiation and boundary costs can lose to V8 on 3 to 60 KB files; with no fallback, the answer is design (streaming compile, cached module, pre-warmed worker, small core module), never routing to TS.
6. Memory behaviour. Linear memory never shrinks. Use one worker per document and enforce the limits.
7. Bundle size. wasm plus any fonts and data shipped must stay under per-format ceilings smaller than TS's payload (#46); track it from day one.
8. Fixture licensing. Several large pptx samples look like third-party downloads, and their licence is unknown.

Open questions for Jared (from PRODUCT_SPEC v3 §7; reply "defaults" to accept all)

1. Renderer technology: decided. Port upstream's approach as-is (batched per frame); you redesign after the conversion (post-port milestone, #92 to #94).
2. Threads: default none (no SharedArrayBuffer or COOP/COEP); a threaded build only on request.
3. Budget: the scope is far beyond the original estimate; default M1 first, M2 blocked-m2 until the M1 gate and your confirmation.
4. iOS Safari: default full target with functional, accessibility and IME smoke tests; perf gated in Chromium.
5. CI cadence: default PRs run S/M tiers at 1x plus parity, round trip, accessibility and IME; main and nightly run the full corpus at 1x and 4x, validators and the scoreboard.
6. Viewer edits (#29): which ones?
7. ASK items: docx review features, speaker notes and thumbnails, print, collaboration, export. (Formats are settled: .docx, .xlsx, .pptx and their macro-enabled and template variants.)

6.1 Decisions (current calls, open to change)

7. Files

• docs/PLAN.md (this file)
• docs/index.html (mobile-readable version, published on GitHub Pages)
• docs/PRODUCT_SPEC.md (v3, the source of the gates)
• GitHub issues #1 to #96 in jgridifier/nitro-xml (generated from issues.json)