New better alterative to XML, JSON and YAML

Original Article ↗ Hacker News Discussion ↗

A new text-based data format called Xenon is proposed as a “better,” more terse alternative to XML, JSON, and YAML, promising built‑in support for arrays, graphs, types, and human‑readable multiline text. Most responses question whether its heavy use of angle brackets and special symbols is actually easier to read or write, and argue that marginal gains in terseness do not compensate for added complexity, unclear semantics, and the absence of tooling or adoption. Several technical critiques also highlight issues around typing, numeric and Unicode handling, canonicalization, and security, with many suggesting that established formats or more modest extensions to JSON or XML are preferable.

Overall reception

  • Majority of comments are skeptical or negative; several call the syntax ugly, confusing, or “XML-lite.”
  • A few commenters express interest, praising the idea of something more structured than JSON/YAML but less verbose than XML.
  • Some meta-discussion criticizes rude replies and stresses being constructive, while others defend blunt “comment card” style opinions.

Claims about Xenon’s advantages

  • Author repeatedly claims Xenon is more terse than JSON and XML, citing fewer characters for key–value pairs and native array syntax.
  • Advertised features: readable multi-line text, native arrays and graphs (multiple parents per node), type hints for serialization, no attributes, comments, named top-level document, and potential for very fast, “mode-less” tokenization.

Syntactic and usability critiques

  • Many find the angle-bracket-heavy syntax hard to read and type, especially array markers like <<Name> … <<$>.
  • Unbalanced and multi-character delimiters (<<, <&>, <<$>, #id, @id, % for comments) are seen as cryptic and high cognitive load.
  • Several argue JSON is simpler, more familiar, and usually at least as terse once editor auto-completion is considered.
  • Some say “terse” here veers into “cryptic,” undercutting the “efficient to write by hand” goal.

Data model, typing, and graphs

  • Critics say the spec’s data model is underspecified and scattered; key concepts (objects, arrays, scalars, names, types, IDs, references) and their relationships are not clearly defined.
  • Lack of explicit scalar types is viewed as a major interoperability risk (string vs number vs boolean vs datetime, etc.), echoing long-standing XML issues.
  • Native graph support is contentious: author insists graphs must be first-class; others argue most data is tree- or DAG-shaped and that built‑in references increase complexity and DoS risk (e.g., XML-style “billion laughs”).

Performance, encoding, and canonicalization

  • “Mode-less tokenizer” and “blazingly fast” claims are challenged as unsubstantiated; no clear benchmarks are shown in the thread.
  • Debate over requiring/recommending UTF‑8 BOM; several note Unicode explicitly discourages BOM for UTF‑8.
  • Numeric formatting with commas and locale assumptions draws strong pushback; seen as unnecessary and non-universal.
  • Lack of a clear canonical subset is criticized, especially for cryptographic or deterministic uses; author replies that “well‑formed Xenon” via a DOM could serve.

Ecosystem, positioning, and tone

  • Commenters stress that XML/JSON’s main advantages are adoption, tooling, and schema ecosystems; a “better” format must address this, not just terseness.
  • Several say the marketing (“best way,” “better alternative”) is overconfident given immature tooling and minimal community.
  • Some perceive the author as dismissive or defensive (“silenced all criticism”), further souring reception.