XION

Xion is JSON with one addition, and the addition is a good one. Any value - object, array, string, number - may be preceded by a name, and that name is a type tag:

1
2
3
4
5
6
7

EmployeeList [
  Person {
    name : PersonNameJa "板東 とんきち",
    tel  : TelNo "03-0000-9999",
    age  : Age 26
  }
]

Strip the tags and this is legal JSON. With them, the document says something JSON cannot: that this string is a Japanese personal name, that one is a telephone number, and that 26 is an age. The tags are not validated and carry no built-in meaning. They are hooks. The host program registers a converter for each tag it knows, and a second pass over the parsed tree calls those converters, so the file is read not into maps and lists but into Person objects.

The entire project is two alpha releases, five weeks apart, from the autumn of 2006.

History and origins

The timing is the most interesting thing about Xion. RFC 4627 - the first time JSON was written down as anything more authoritative than a page on json.org - was published in July 2006. The oldest Xion files are dated 16 July 2006. Whoever was writing this was reacting to JSON at the precise moment JSON stopped being a folk format.

The reaction was a familiar one, then and since: JSON is a wonderful wire format and a poor document format, because it cannot say what anything is. Douglas Crockford’s design had deliberately dropped comments and deliberately offered exactly six types. A decade of formats would be built on top of that gap - tagged types in CBOR, tagged elements in edn, annotations in Amazon Ion, a whole generation of configuration languages - and in October 2006, a single developer in Japan got there early, published 217 KB of Java to SourceForge under the project name chimaira-xion, and stopped four months later.

The author is the account aiue3, display name dsksh, created two days before the project and attached to nothing else. Everything human in the distribution is in Japanese: the commit messages, the Javadoc, the exception text, the Ant help target. The jar in the 0.2 release was built on Apple’s JDK 1.5.0_06 by a user named ishii.

There is no documentation. The doc/ directory ships empty in both releases, and the only description of the language that was ever written is the three-sentence blurb on the SourceForge page. The specification, such as it is, is tmp/xion.lex, a JFlex file.

The grammar

Reading that lexer is the fastest way to understand the language, and what it shows is restraint. JSON’s punctuation, literals and string escapes are reproduced exactly - {, }, [, ], ,, :, true, false, null, and the full \" \\ \/ \b \f \n \r \t \uXXXX set. Three things are added:

Tags. A Name token may appear before any value. The Name production is not invented; it is XML 1.0’s, lifted down to the BaseChar and Extender character-class ranges:

1
2
3

NameStartChar = "_" | [a-zA-Z] | {BaseChar}
NameChar      = {NameStartChar} | [\-\.] | [0-9] | {Extender}
Name          = {NameStartChar}({NameChar})*

That inheritance is why the test suite can write 名前 [141, firstName "tonkichi", ["pi", 3.14]] and have it lex. In 2006 a Japanese developer extending JSON did not reach for Unicode identifier rules from a programming language; they reached for XML’s, which were the rules everyone in the data-format world already had in a spec on their desk.

Comments. Both // and /* */, as lexer states that discard their contents. JSON’s most-requested missing feature, added in the first version.

Separate integer and decimal tokens. JSON has one number type. Xion’s lexer emits INTEGER and DECIMAL as distinct tokens, and the model has distinct XionInteger and XionDecimal classes - a decision later formats would relitigate endlessly, usually landing in the same place.

One further relaxation is implicit: a Xion document may be a bare scalar. 42 parses, and so does ja "x". RFC 4627 required a JSON text to be an object or an array; it would be nearly eight years before RFC 7159, in March 2014, allowed any value at the top level. Xion allowed it in 2006, almost certainly without thinking about it.

Design philosophy: the two-stage read

The architecture is the idea. Xion does not deserialize; it parses and then realizes, and the two are separate objects with separate error types.

A XionContext is nothing but a map from tag name to XionConverter, and a converter is a two-method interface - tag() returns the prefix it claims, convert() turns a model node into whatever the application wants:

1
2
3
4
5
6
7
8

public static class PersonConverter implements XionConverter<XionObject, Person> {
    public String tag() { return "Person"; }
    public Person convert(XionObject data) {
        return new Person((String)data.get("name"),
                          (String)data.get("tel"),
                          ((XionInteger)data.get("age")).intValue());
    }
}

Register that under Person, hand XionRealizer.realize() a reader and the context, and a file full of Person { ... } comes back as a List<Person>. Untagged nodes pass through as model objects. An unknown tag is an error, not a silent pass.

This is recognisably the design that data-binding libraries would converge on - and Xion’s version of it is notably cleaner than most 2006 alternatives, which either required a schema (XML Schema, JAXB) or required annotating the target classes. Xion requires neither. The mapping lives in a third place, outside both the document and the domain model.

The most elegant consequence is that the mapping can be a Xion document:

1
2
3
4
5
6
7
8

XionRealizerContext [
  JavaClass "EmployeeListConverter",
  XionRealizerContext {
    Person       : JavaClass "EmployeeListConverter$PersonConverter",
    PersonNameJa : JavaClass "EmployeeListConverter$PersonNameConverter"
  },
  JavaClass "EmployeeListConverter$TelNoConverter"
]

LoadableContext realizes this with two hard-wired bootstrap converters; JavaClass calls Class.forName(...).newInstance() on each string. The configuration of the Xion reader is written in Xion, tagged with Xion’s tags, and read by Xion. For a project with an empty doc/ folder, that is a surprisingly confident piece of design.

The state it was left in

Xion was marked alpha and the label was earned. Running the shipped 0.2 jar on a current JVM turns up the seams immediately:

1
2
3
4

[1, 2, 3]              ==>  [1, 2, 3]
[1, true, 2]           ==>  [1, true, true, 2]
{a : true, b : false}  ==>  XionHandleException: duplicated keys are detected
[null]                 ==>  NullPointerException in XionArray.toString

Integers, decimals, strings, tags, comments, nesting and the full realize pipeline all work. Booleans and null do not. The cause is visible in the model package, which contains five classes - XionObject, XionArray, XionString, XionInteger, XionDecimal - and no boolean or null type at all. The lexer returns the tokens; nothing downstream knows what to do with them, so a boolean is emitted twice and a null is stored as a Java null that the container’s own toString then dereferences. Two of JSON’s six types were never finished.

Set against that: the jar is Java 5 bytecode built with Ant 1.6.5 in October 2006, and it compiled and ran against OpenJDK 25 in 2026 with no flags, no shims and no deprecation warnings, producing java.awt.geom.Rectangle2D$Double[x=10.0,y=100.0,w=200.0,h=300.0] from the sample geometry document. The JVM’s compatibility record is the reason this page can report behaviour at all rather than guessing at it.

Evolution

There are two releases and a tail of eleven commits, and the shape of the change is instructive.

Version 0.1 is one programmer’s straightforward library: XionLexer, XionReader, a model, a converter interface, a FileContext. Version 0.2 is the same library taken apart and rebuilt as components - every stage split into a Cmp implementation class and a PI port interface, connected through explicit fields, with a small dependency-injection framework (org.chimaira.fi: @Provide, @Require, Occurence, Result) written specifically to wire them. The commit messages for the refactor read “componentized some classes using the ‘field injection’ technique.”

Then, on 14 January 2007, it came back out. The annotations were removed, XionConverter was de-genericised, and the components went back to being wired by hand in constructors. The org.chimaira.fi classes are still in the tree; every @Provide and @Require at a use site is commented out. It is a very recognisable arc - a two-thousand-line library growing an injection container because 2006 Java had just discovered injection containers, and then quietly shedding it.

The last four commits, on 18 February 2007, move the parser into its own package. Nothing follows. No release, no announcement, no farewell message, no final version bump.

Current relevance

None, in any practical sense, and the page should not pretend otherwise. Xion has no users, no documentation, no spec, no successor and no citations. Its homepage never existed. The problem it addressed was real and was solved several times over by formats with committees behind them: CBOR got tags in 2013, edn and Amazon Ion shipped with tagged values, YAML had typing tags before Xion was written, and JSON Schema took over the business of saying what a string means.

What Xion retains is evidential value, and rather a lot of it for something this small. It is a precisely dated snapshot - to the week - of how a competent programmer outside the English-speaking standards conversation read JSON in the months after RFC 4627: as obviously right in its syntax, obviously insufficient in its type system, and fixable by one orthogonal addition. That the fix they chose has since appeared independently in half a dozen widely used formats is the interesting part.

Why it matters

Most dead languages die of neglect after a period of use. Xion died of something more common and less discussed: it was finished enough to demonstrate and not finished enough to use, and its author appears to have learned what they wanted to learn and moved on. Eighteen weeks, 58 files, 23 revisions, an empty documentation folder, two broken literals, and one genuinely good idea.

It is also a small rebuke to the way these lists get compiled. A name in an encyclopedia row - XION, 2006, Declarative, Configuration, Dormant - looks like it should be easy to look up and turns out to resolve to nothing searchable at all: no Wikipedia article, no Wayback capture, no forum post, no mention anywhere by anyone other than the author. The only way to find out what Xion was is to download the zip, read the JFlex file, and run the jar. That those three things are all still possible twenty years later is, in its own quiet way, the most impressive fact on this page.