+ Kurtis Knodel

Introducing EON (Extensible Object Notation)

Posted on: Fri Dec 31 2021

I recently found myself needing a system to describe objects that was easy to parse like JSON, but more extensible and less clunky than something like XML or YAML. After a bit of Googling, I came up empty handed. Thus,

Enter EON


EON is an object notation that's built from the ground up to be 1) easy to parse, and 2) extensible. In this post, I'll go over how EON achieves these two things, and why you would want to use it. Let's begin.

1. Easy Parsing

First, I should define easy. Easy means that implementing a parser shouldn't be particularly difficult (less code), and there are very few edge cases (or none at all). I think I've achieved this for EON. As an example, here's an EON object:

(
    uid: 0,
    email: 'thearchitect@example.com',
    nickname: 'The Architect',
    position: Administrator,
    joined_on: { 01 JAN 0001 },
    email_notifications: true,
)

Just looking at this, it's pretty self-explanatory (at least I'd think so). The only iffy parts are the joined_on and position fields. Why does joined_on have weird brackets? position looks like a string, but it has no quotes. Why?

This is because joined_on is an expression. It tells the EON parser, "don't parse this, just skip to the closing brace and copy this value verbatim." As such, instead of using an expression for a date, you could use it for a mathematical expression or function. Then, once the EON object is loaded, the expression can be parsed further outside of EON.

The position field is a name. A name in EON is almost any string that doesn't have whitespace, parentheses, brackets, braces, or quotes. While this is very similar to a string (indeed, a string has less restrictions), the type of data adds meaning. The intent of a name is to reference something else in the host program's code, such as a namespace or variable. For example,

(
    uid: int,
    email: string,
    nickname: string,
    position: position,
    joined_on: date,
    email_notifications: bool,
)

Using names, we now have a type description of our object from before. Neat, right?

All of this can be parsed in ~500 lines of Rust (a very verbose language), and I'm sure this can be whittled down using simpler languages like Python (something I plan on doing). Thus, easy parsing (probably).

2. Extensibility

Making EON extensible was something I thought a lot about before designing the reference parser. In an object notation, this is actually pretty hard to do. What I came up with were expressions and names, which was talked about earlier.

I think these two things achieve extensibility because they allow for the parser to parse them no matter their value, but give valuable data to programs that know how to read that extra data. For example, if an EON object for one specific program is loaded in another program, the "wrong" program will be able to parse the EON no problem - However, any expressions or names specific to the "right" program may be meaningless.

Why EON?


I think EON is for anyone who needs some sort of portable object notation that is more powerful than JSON. While it's not nearly as ubiquitous, it's very easy to parse and a reference parser is already available for Rust here. A specification and more reference parsers are also coming soon, but release dates on those are TBD. If you have any questions or comments, please feel free to reach out to me here.

Thanks for reading,

Kurtis

Back