This document specifies the format interfaces of the Plurimath system:

• the interface model: readers and writers as typed boundaries over the formula tree;

• the reader contract: accepted types, options, error behaviour, and the guarantees every reader makes about the tree it yields;

• the writer contract: entry points, determinism, and the display-style option;

• the per-format rules for AsciiMath, MathML, OMML, UnicodeMath, LaTeX and HTML, including how the uncertainty encodings of PM 1002 read;

• image rendering through the optional renderer;

• round-trip properties and their exceptions;

• conformance of an implementation.

This document does not specify:

• the grammar of each input notation in the abstract — the accepted surface is what the readers accept, and the writer surfaces are defined in PM 1001 and PM 1002;

• the math model itself (PM 1001) or the uncertainty fields (PM 1002);

• numeric evaluation (PM 1004).

Implementers of Plurimath, authors of independent readers or writers that must interoperate with it, and applications embedding the system.

Every interface reads or writes the one tree of PM 1001; none of them defines content of its own.

Interface signatures are written as parse(text, type, **options) and to_<format>(options) following the implementation’s shape; this document specifies behaviour, not a language binding. Format names follow PM 1001.

Examples carry an Expected outcome paragraph stating observable behaviour. Where an example shows reading, the outcome states the resulting tree; where it shows failure, the typed error and its message shape.

The encodings read and written here are the ones defined in PM 1001 (surfaces) and PM 1002 (uncertainty); this document adds the reading rules, not new encodings.

Where an example says “the corpus freezes” an outcome, the frozen vector is the example with its provenance; the corpora are external, versioned artifacts, and this document’s examples are their illustrations.

Every exchange with the outside world passes one of two boundaries:

A reader receives text of one accepted type and yields a formula tree. A writer receives a tree and emits one surface’s bytes. Neither boundary exposes anything else: no parser objects, no intermediate representations, no partial trees.

Every failure crossing a boundary is a typed error (Annex A). A reader that cannot complete raises a ParseError or one of its specialized subclasses; a writer does not fail on a well-formed tree — render totality is a model guarantee of PM 1001 — and the renderer’s failures are the rendering errors of clause 13.

The interfaces compose without glue: the tree a reader yields satisfies every writer. An application may read AsciiMath, inspect the tree, evaluate it (document 1004), and write OMML in one pipeline; no format-specific steps exist between the boundaries.

Four invariants hold at both boundaries, and the clauses that follow make each precise:

• Typed failures. only Annex A’s errors cross; internals stay inside.

• Tree guarantees. readers yield PM 1001 trees; writers consume them without inspection of provenance.

• No hidden state. a boundary call depends on its arguments and the configuration only — no reader remembers the previous call, no writer caches by identity.

• Composition. any reader’s output feeds any writer; nothing between the boundaries knows formats exist.

The unitsml type is a reader without a writer: it reads one unit expression (CalConnect 36817) into the unit embedding the tree carries. It exists so applications can validate and embed units independently of a surrounding formula, and its failure mode is the parse error naming the unit expression.

The two boundaries carry symmetrical obligations, which the rest of this document discharges:

An implementation audit walks these two tables; the conformance classes of clause 15 are their operational form.

Reading goes through one entry point, parse(text, type, **options):

1. The type is validated: an unknown type raises InvalidTypeError, before the text is examined.

2. The options are validated: only the supported options (locale) are accepted, and an unknown option raises ParseOptionError; a locale passed for a type that does not localize raises the same error naming the type.

3. The text is parsed by the type’s reader; success yields a formula tree whose input_string is the original text.

4. Failure raises the specialized error the failure maps to, or ParseError carrying the text and the type.

The entry point never raises any other error. An internal exception escaping a reader is a defect of the reader; the boundary converts everything it can into the typed errors and preserves the specialized ones unchanged.

The localized types accept the locale option, which selects the language-specific readings of symbols and function names (for instance, localized function names in LaTeX and HTML inputs). The markup types do not localize: a MathML document says what it says.

A reader yields a tree that satisfies PM 1001: node classes from the model, operands in the class-defined order, no formatting in descendant nodes, and — for inputs carrying uncertainty encodings — uncertainty nodes per PM 1002. A reader never yields a tree it cannot itself render.

The yielded tree records the input text verbatim. Diagnostics, error messages and the math zone printers may show it; the tree’s identity does not depend on it: two trees read from equal inputs carry the same input_string and are equal; two equal trees from different inputs differ only in that field.

A reader’s refusals are part of its contract. The general ParseError names the input and the type; the specialized errors name their cause: an ambiguous decimal in uncertainty reading raises AmbiguousDecimalError, a missing parsing dependency raises MissingDependencyError. The message shapes of Annex A are stable within an edition.

The entry point validates in a fixed order, so callers can predict which error they see first:

1. the type — InvalidTypeError before anything else;

2. the options — ParseOptionError next;

3. the input — parse errors last.

A call with both an unknown type and an unknown option reports the type. A call with a bad option and a malformed input reports the option. No reader runs before the boundary checks pass.

Every reader, for every input it accepts, yields a tree with these properties:

• the node classes and operand orders of PM 1001;

• numbers as exact decimals of the grammar PM 1002 states, wherever the tree carries numbers;

• uncertainty nodes constructed through the validation of PM 1002 — a reader never assembles a malformed uncertainty;

• units as UnitsML embeddings read from the content language;

• no reference to the reader, the type or the options inside the tree.

The last property keeps trees portable: a tree does not remember which reader made it, and PM 1001’s syntax-independence invariant holds at the boundary.

Readers translate structure; they do not evaluate, simplify, reorder or repair. An input that says 2 + 2 yields a tree that says 2 + 2; whether that is 4 is evaluation’s business (document 1004). An input with a suspicious construct — a division by a zero-valued expression, an inverted interval — reads as written; the evaluators and the checkers flag, the readers transcribe.

The reading rules per format, in one place (the full rules are PM 1002’s encodings plus the clauses above):

A marker and its shape disagreeing is a producer defect; the reader takes the marker, and the next write emits a consistent pair. The corpora include a stale-shape vector per markup format so the authority is tested, not stated.

A tree writes to each surface through one entry point: to_asciimath, to_mathml, to_omml, to_latex, to_unicodemath, to_html. The surfaces, their outer elements and their stability rules are PM 1001’s; this document adds the interface obligations.

Writers are deterministic and byte-stable per PM 1001. This document adds: a writer emits only through its own boundary — no writer depends on a reader having produced the tree, and no writer consults the tree’s input_string.

The root’s display flag (PM 1001) may be forced per call: a writer asked for display style renders the display form regardless of the root’s flag, and one asked for inline renders inline. Absent an override, the root’s flag decides.

A writer given a well-formed tree does not fail. A writer given a tree that violates PM 1001 — an operand missing, an unknown node class — is outside the contract; implementations report it as a programming error, not as a parse or rendering error.

The writers’ family obligations, at the level this document pins them (the per-construct detail is PM 1001’s mapping and PM 1002’s encodings):

Every cell is discharged by the corpora: each family’s row in each surface’s column has corpus vectors, and a writer claim covers its column end to end.

A tree may be built by construction — an application assembling nodes — rather than by reading. Writers treat constructed trees identically: the boundary knows no difference between a read tree and a built one. This is what makes evaluation pipelines possible: document 1004’s output trees write like any others.

Writing a tree twice yields identical bytes. Writing a read-back tree yields the same bytes as writing the original: the round-trip property plus writer determinism give write-read-write idempotence per lossless format. The corpora assert it.

The AsciiMath reader accepts the linear form: symbols and function applications of the registry vocabulary (PM 1001), grouping, scripts, fractions, nary constructions, text in text(...) and in quoted strings, and the uncertainty forms of PM 1002.

The quoted string is content: "unitsml(kg*m/s^2)" is the UnitsML channel, read as a unit embedding; any other quoted string is upright text. The reader does not interpret inside a quoted string beyond the UnitsML channel check.

The uncertainty reading follows PM 1002:

• the calls ustd(v, m), uexp(v, m, k, p) and ucov(v, l, u, p, kind) read to their categories with the given fields;

• the reporting form v(digits) reads to a standard uncertainty with notation concise and the magnitude reconstructed by the decimal-places rule;

• the interval kinds spell shortest and symmetric on input, reading to the model’s kinds;

• a malformed form — wrong arity, non-decimal arguments, an unknown kind — is a reading error: AmbiguousDecimalError where the ambiguity is the decimal place count, ParseError otherwise.

The AsciiMath writer emits per PM 1002’s encodings: the calls with their argument orders, the concise reporting form for concise nodes, the quoted UnitsML channel for expressible units and the visible unit otherwise.

The AsciiMath interface is lossless: writing a tree and reading the result yields an equal tree, for every tree the model defines. The one deliberate asymmetry: a concise node writes the reporting form and reads back concise — the notation survives the round trip, as a field of the node.

The reader accepts the construct families below, in the spellings of the registry vocabulary. The table states each family’s AsciiMath shape and the node it yields; the vocabulary itself is the registry of PM 1001.

The reader applies the notation’s precedence: scripts bind tighter than adjacency, fractions tighter than addition, and explicit grouping overrides. The tree is the precedence-correct reading; an author who means something else parenthesises. This document does not restate the precedence table — the reader’s behaviour is its definition, and the corpus pins it vector by vector.

The localized symbols and function names follow the active locale: an Italian locale reads sen as the sine function where an English reading sees a symbol sequence. Localization affects which tokens map to which nodes; it never changes the tree shape a construct yields.

The reader’s refusals are pinned by the corpus alongside its successes: every reading error of Annex A that the AsciiMath surface can produce has a corpus vector whose expected outcome is the error and its message shape.

A quoted string in AsciiMath input is content, with exactly one special case: text matching the UnitsML channel shape unitsml(<expression>) becomes a unit embedding. The check is on the whole string, after trimming nothing: " unitsml(g)" with a leading space is text, "unitsml(g)" is the channel. Anything inside the channel that the unit reader refuses is a reading error naming the expression — the channel never silently degrades to text, because a unit intended as a unit must not become prose.

On reading the reporting form v(digits):

1. the value is the text before the parenthesis;

2. the digit string is the text inside;

3. the magnitude’s decimal places are the value’s decimal places — the count that made the form well formed;

4. the magnitude is the digit string with its last digit(s) moved behind a decimal point at that place count, prefixed with 0. when the place count is positive;

5. the node is constructed with notation concise, through PM 1002’s validation.

A digit string that cannot be reconstructed at the value’s place count — more digits than places is unambiguous, fewer or mismatched is not — raises AmbiguousDecimalError. The reconstruction never invents places: 10(2) reads magnitude 2 at zero places; 10.3(25) refuses.

The AsciiMath kind token symmetric reads to probabilistically-symmetric before node construction; the model never sees the short spelling. Writing a probabilistically-symmetric node emits symmetric in AsciiMath and the full name everywhere else. The asymmetry is spell-level and pinned in both corpora.

The table classes write in the bracket forms; Align and Eqarray write with the ampersand alignment their reads accept. Alignment points are structural for these classes and survive the round trip; a writer that drops them fails the corpus.

The AsciiMath reader’s symbol vocabulary is the registry’s AsciiMath token set. The families, with representative tokens (the full set is the registry; the corpus exercises it):

Function-name tokens follow: sin, cos, tan and kin, log, ln, lg, exp, min, max, gcd, lcm, mod, det, dim, deg, exp, hom, ker, lim with its variants — each reading to its function class. Locale-selected alternatives exist for a number of them, per clause 6.

text(...) reads its content as upright text with grouping; quoted strings read as text with the UnitsML channel exception of this clause. The two forms differ in one observable way: text(...) may contain AsciiMath commands, a quoted string never does — quotes are literal, which is what makes them the right channel for content a formula must not interpret.

The AsciiMath corpora carry, at minimum: every registry family with a representative per entry-group; every construct family of the table above, in plain and grouped forms; the uncertainty forms of PM 1002 with all categories, notations and kinds; the quoted channel with expressible, inexpressible and refused units; the localization pairs; and the error table’s rows. 143 cases formed the first frozen generation; later generations extend, never rewrite.

The MathML reader accepts a MathML 4 document or fragment. It reads the presentation markup into the tree: mi, mn, mo, mrow, mfrac, msqrt, mroot, scripts, tables, and the constructs the model names. Two rules govern semantics:

• the intent attribute is authoritative for uncertainty (PM 1002): where an mrow carries an uncertainty marker, the fields come from the marker’s arguments and the row’s visible content is regenerated;

• a semantics element carries its annotations as annotation data on the tree, and its first child as the expression.

Unknown presentation elements are read as their content where they are containers and refused where they are not: the reader does not silently drop structure it cannot represent.

The MathML writer emits MathML 4 per PM 1001’s surface rules: mathvariant from font styles, intent markers from uncertainty nodes, mtable families from tables, mn/mi/mo per the registry entries. The display attribute follows the root’s flag or the call’s override.

MathML is lossless for the constructs the model defines, with the intent-authority rule for uncertainty. A MathML document using constructs the model does not define reads to the closest model content it can represent and records nothing else — such documents are outside the losslessness claim.

The reader’s element mapping, at family level:

Significant whitespace in MathML is structural; the reader treats mspace per its width semantics and collapses presentation-only whitespace, as MathML itself prescribes. Trees carry structure, not spacing.

A MathML input that mixes constructs the model cannot represent reads to its representable core; the reading corpora contain such vectors with their expected trees, so the boundary between “reads with loss” and “refuses” is pinned, not folklore.

The MathML reader walks the document in order:

1. the root element fixes the fragment’s bounds; a stray text outside it refuses;

2. each element maps per the table of this clause; containers recurse;

3. intent markers are collected as the elements carrying them close, and the marked element’s node is reconstructed from the marker per PM 1002;

4. annotations ride with their Semantics node;

5. the resulting parameters form the tree’s top level, in document order.

Because markers are authoritative, a MathML producer has exactly one way to be wrong about uncertainty: emit a marker whose arguments contradict the visible content. That document reads to the marker’s fields. A producer that wants the visible shape to win must not carry a marker; but then the node is not an uncertainty node, and the shape reads as ordinary constructs.

Named entities (&#x3b1;) and numeric character references read through the registry’s MathML renderings — an entity the registry knows reads to its entry; an unknown entity is a reading error naming it.

The uncertainty markers of PM 1002 write as the intent attribute value on the enclosing mrow: intent="standard-uncertainty(10.3,0.2)". The attribute is the whole machine-readable contract; a MathML consumer that understands intent reads the fields, one that does not sees the shape. The writer never splits a marker across elements or abbreviates it — the grammar of PM 1002 is the attribute’s entire alphabet.

The OMML reader accepts DrawingML mathematics (ECMA-376, m: namespace): runs, run properties, fractions, radicals, scripts, nary constructs, matrices, delimiters, and phantom boxes.

The marker convention is authoritative for uncertainty: a run holding an uncertainty marker string (PM 1002’s grammar) marks the construct that follows; the fields come from the marker and the shape runs are regenerated. A consumer that never learned the convention sees one extra run of text; a conforming reader consumes it.

Run properties map to font styles; m:nary to the nary classes with their character; matrices to the table classes; m:d delimiters to Fenced. As with MathML, structure the model does not define is read to its closest representable content.

The OMML writer emits per PM 1001: run properties from font styles, m:nary from nary nodes, m:m matrices with the table class’s delimiters, m:d from fences, and the marker run before the shape runs for uncertainty nodes, with the unit boxed. The display form wraps in m:oMathPara per the root’s flag.

OMML is lossless for the model’s constructs under the marker-authority rule.

The marker run is an ordinary m:r whose text matches PM 1002’s marker grammar. The reader scans for it at the start of a construct it marks; on a match, the construct’s fields come from the marker and the shape runs are skipped. A run that resembles a marker but is ordinary text — inside another run, or after the construct it would mark — is text. The convention is positional: marker first, shape after.

Fonts, styles and script positioning in run properties map to the font style nodes and the script placement the model defines; properties without a model counterpart (kerning, colour) are dropped on read, as presentation the tree does not carry.

The OMML reader walks the m: tree:

1. runs accumulate into content; a marker-matching run switches to marker handling;

2. construct elements (m:f, m:rad, script and nary elements, m:d, m:m) map per the table;

3. delimiter and matrix properties select the table class and its fences;

4. a marker reconstructs the following construct’s uncertainty node per PM 1002 and consumes its shape runs;

5. document-level properties outside the model are dropped as presentation.

Two OMML constructs have model-specific treatment: pre-sub/superscript (m:sPre) reads to Multiscript, and the equation-array constructs read to Align/Eqarray with their alignment. Everything else maps one to one.

The table classes write to m:m with delimiter properties per class: Matrix plain, Pmatrix parenthesised, Bmatrix braced, Vmatrix barred, Cases with the asymmetric brace. The nary classes write to m:nary with m:chr carrying the character and the limits in m:sub/m:sup; a limit absent leaves the element empty rather than omitted, which is how OMML spells “no limit here”.

The UnicodeMath reader accepts the linear format of UTR #28 as the implementation defines its surface: symbols, fractions, scripts, nary constructs, and the intent wrapper ⓘ("marker" visible).

The wrapper is authoritative for uncertainty: the marker string inside the quotes carries the fields; the visible shape inside the wrapper is regenerated. The ⓐ(unit ...) form inside the wrapper carries the unit. Outside wrappers, the linear format reads per its own conventions — ^, _, / grouping, named symbols from the registry’s UnicodeMath tokens.

The UnicodeMath writer emits per PM 1001 and PM 1002: the linear forms of the constructs, the intent wrapper for uncertainty nodes with the marker and the regenerated visible shape, and ⓐ(unit ...) for the unit.

UnicodeMath is lossless for the model’s constructs under the intent-authority rule.

UnicodeMath has no comment or annotation mechanism the model carries; the ⓘ wrapper is the single channel for machine-readable intent. An ⓘ whose quoted text does not match the marker grammar is a reading error, not text — the wrapper is reserved.

As with AsciiMath, the reader applies the linear format’s precedence and the corpus pins it. Fraction and script grouping in parentheses follows UTR #28’s conventions as the implementation defines them.

The UnicodeMath reader scans the linear text:

1. literal characters and named tokens read through the registry’s UnicodeMath tokens;

2. structural characters (/, ^, _, parentheses) build the corresponding nodes;

3. an ⓘ opens a wrapper: the quoted marker reads per PM 1002’s grammar, the visible shape is skipped or regenerated, and ⓐ inside carries the unit;

4. a ⓐ outside a wrapper is unit text;

5. everything else reads per the linear format’s precedence, as the corpus pins.

The visible shape inside a wrapper was produced from the marker’s fields; re-reading it would invite the stale-shape problem the marker exists to prevent. The reader reads the marker, reconstructs the node, and moves past the visible shape.

The LaTeX reader accepts the fragment-level LaTeX the writer emits, plus the common mathematical core: commands of the registry vocabulary, environments for tables and alignment, and math-mode grouping. It does not accept document preamble, packages or free text outside math.

LaTeX is a lossless direction for the model’s constructs: writing and reading returns an equal tree, with the exceptions the registry records (constructs whose LaTeX rendering is approximate carry the approximation in both directions and are equal as trees).

The LaTeX writer emits per PM 1001 and PM 1002, with the statements of PM 1002 after the unit.

HTML is a display surface. The writer emits an HTML fragment optimised for browser presentation: nested elements for structure, sub/sup for scripts, and the encodings of PM 1002 for uncertainty. HTML does not read: the interface has a writer only, and round-trip claims do not include it.

Preamble, \usepackage, document environments and free prose between math are refused: the interface is a math fragment interface. A document that carries formulas in prose extracts the formulas first; that extraction is outside this interface.

The HTML writer emits nested presentational elements: spans for structure, sub/sup for scripts, fraction layouts with borders, tables for matrices, and the statement spans of PM 1002. Class names are stable within an edition and the corpus freezes them.

The HTML writer’s shape, for the power example of PM 1001:

The class names are the writer’s stable surface: editions may add classes, never rename them. Presentational decisions (fonts, sizes) belong to the host page’s styles; the fragment carries structure and semantics only.

The same tree in LaTeX:

and the quadratic formula:

The writer emits the linear fraction form when the tree was read from one and the \frac form when built as Frac; both read back to equal trees, and the round-trip corpus carries both shapes.

Beyond the text surfaces, a tree renders to images — SVG, PNG, PDF and PostScript — through the optional renderer, which delegates to the lasem library. Rendering goes through one entry point, render(text, type, format:, **options): it parses per clause 6 and renders the parsed tree to the requested image format.

Image rendering is available when the lasem gem and its native extension are present; it is never available under Opal. Availability is queryable and never raises: render_available? answers the question, and render raises the typed errors when called without it.

The renderer’s failures are typed: RenderingUnavailable when the library is missing, UnsupportedRenderFormat for a format it does not offer, RenderingFailed when rendering fails on a tree that parsed. Parsing failures surface as the parse errors of clause 6 — the renderer never masks a parse failure as a rendering failure.

Rendering composes two boundaries: parse per clause 6, then render the tree to the image format through the library. Options split the same way — parse options to the parse step, the rest to the renderer. The pipeline is one entry point so that callers cannot interleave a broken state: either the image bytes or a typed error, nothing in between.

The corpus freezes one image per format at a reference size; raster differences at other sizes are not drift.

The renderer’s availability follows the library’s platform support: native where the extension builds, absent under Opal and on platforms without the native stack. Applications probe availability once and degrade to text surfaces where images are unavailable; the interface makes degradation explicit rather than failing mid-document.

Image output depends on the library’s rendering of the intermediate form; it is byte-stable per model version plus library version, and the corpus records both. A library upgrade that changes bytes is a corpus regeneration with provenance, the same discipline as any other byte change.

The lossless directions of the system:

A round trip composes the writer and the reader of one format: read(write(tree)) equals tree, under the structural equality of PM 1001, for trees built from the model’s constructs. The input_string after a round trip is the written form, not the original — identity of trees does not depend on it.

Every model field survives every lossless round trip: operands, order, uncertainty categories, fields, notation, interval kinds, units, intent annotations. The encodings of PM 1002 were designed so that no lossless format is the weak link: each carries the marker or the call that reconstructs the node.

Three things do not survive, by design and stated here so that no one searches for them:

• the original input text (the input_string after a round trip is the written form);

• presentation choices that live outside the tree — display style survives, ad-hoc spacing does not;

• constructs outside the model, which read to their closest representable content on the way in and therefore cannot survive a round trip unchanged.

Start from the tree of Result two of PM 1002’s Annex D: the expanded uncertainty 10.3 g, U = 0.5 g (k = 2, p = 95%).

1. Write to AsciiMath: uexp(10.3, 0.5, 2, 0.95) "unitsml(g)".

2. Read it back: the tree, equal, input_string now the written call.

3. Write to MathML: the intent expanded-uncertainty(10.3,0.5,2,0.95) over the fenced ± shape.

4. Read that back: the tree, equal again.

5. Write to LaTeX: (10.3 \pm 0.5) g~(k = 2,~(p = 0.95))-shaped output.

6. Stop — LaTeX does not read back; the claim ends at the bytes.

Expected outcome. after each lossless leg the tree is equal to the original in every field; the input_string differs at every leg, and identity is unaffected.

Reading one format’s output with another format is not a round trip; it is two round trips joined by the tree. The composition works because every reader yields model trees and every writer consumes them: AsciiMath in, OMML out, OMML read, HTML out — each boundary checks per its own clause.

The round-trip corpora freeze, per format: a spread of trees covering every node family, the uncertainty categories, units, and the registry’s approximate-rendering cases. A conforming implementation replays them all; one failure is nonconformance.

Conformance to this document is claimed per interface class. Every claim is discharged by replaying frozen vectors; nothing here is satisfied by assertion.

A read-<format> claim carries the model claim of PM 1001; a roundtrip-<format> claim carries both directions’ claims.

The reading corpora are frozen sets of inputs with frozen trees; the round-trip corpora are frozen trees replayed through write and read. Entries state provenance and never change within an edition.

A reader that yields a tree differing from the corpus for the same input does not conform. A writer whose bytes differ from the render corpus does not conform at the corpus’s model version. Drift is resolved by fixing the implementation or moving the model version, and recording which moved.

A conformance claim names its classes, the model version, and the corpus generation. A claim without a corpus generation is not checkable and is not a claim.

The contracts are written for more than the reference implementation: an independent reader that yields model trees per clause 6 and passes the reading corpora conforms, whatever its internals. An independent writer that passes the byte corpora conforms, whatever its codegen.

The typed errors are part of the contract and carry their own vectors: each error class has corpus entries whose expected outcome is the error with its message shape. An implementation that succeeds where the corpus expects a refusal does not conform — refusals are behaviour, not friction.

Claims name the generation they were checked against; a claim against generation N is void for generation N+1 until rechecked. The validator of the register build enforces the naming.

These are the only errors that cross an interface boundary. Message shapes are stable within an edition; the messages carry the input, the type, or the field responsible.

Specialized parse errors are subclasses of ParseError: an implementation catching ParseError catches them all, and one catching the subclass catches the specific case.

Parser internals, XML library exceptions, encoding errors and assertion failures never cross a boundary as themselves: a reader converts them to ParseError with cause information retained for diagnostics. A boundary that leaks a foreign exception is nonconforming.

The locale value follows the implementation’s locale keys. A locale the implementation does not know raises ParseOptionError — silently ignoring a locale would read the wrong language and report success.

Unknown options at any boundary raise the typed option error; no boundary guesses.