Xenon 1.0

The xenon document itself is a named object, array or scalar. All of the examples here are both valid documents and could be inserted inside an object.

Objects

Objects, in addition to scalars show above may also contain other objects or arrays: <Book> <Name=A Plan> <Author> <Name=Eric Harrison> <Mobile=+64 24 240 990> <$> <<Reviews> Fascinating. <&> Of interest. <&> Worth reading. <$>> <$>

When objects are stored in arrays one leaves out the nameless object <> and <$>. <<People> <> <Name=Fred> <Disposition=Friendly> <$> <&> <> <Name=Jane> <Disposition=Aloof> <$> <$>>

Scalars

Similarly in named scalars the text is intuitively processed. <Label= | A useful description> The example above also extracts to “ A useful\r\n  description”.

It is an error to have any of the lines below the | start on or before the |. In this case the document shall be rejected. <Report= | The sailing could have been better>

Arrays

Inside arrays themselves arrays do not have a name so one leaves that out. We use the same <<: <<To-Do-Lists> <<> Parse document <&> Write summary <$>> <&> Go on holiday <$>> Here is an array of “Parse document” and “Write summary” is inside the array called To-Do-Lists along with the “Go on holiday” item.

An array of one empty item is not an empty array. The following shows an array with one item, the empty string “”. <<Comments> <$>>

Graph Structure

Xenon documents can be graphs/networks rather than just trees. Items can have more than one parent. This is required for serialization where the data structure may also contain loops. Items may be labeled with a id, e.g. #24 and referred to later using a reference, e.g. @24. References are always scalars even if the entity being referred to is an object or array.

Types

To support serialization entities can be labeled with types. For example when a field is declared as a base class of the object being serialized, we need to know what was actually stored. Types are stored in the same place as #ids, using :type after then name or :type; before the item in arrays. The following example shows a car vehicle object and a dog and a fish pet array items. The fish also has an id. The #id and :type can be in either order.

Document Object Model

To aid understanding the data structure a Document Object Model is presented. This is not the grammar of the language but a data model.

After references are resolved items such as scalars may have multiple parents, e.g. a NamedScalar and an Array.

Comments

Comments prefixed with % may appear where whitespace may, between <> bracketed tokens. The comment is terminated with a newline. Comments may not appear inside scalars. Special characters do not need to be escaped within comments.

Escaping

\ is used to escape characters. The following characters must be escaped in any place except inside comments: <>=$&#@:;|\%!. Line feed (“newline”) is represented with \n, carriage return with \r and tab with \t. Unicode characters can be escaped with \u{X...} where X... is one to six hexadecimal digits, e.g. \u{1F62D} for a loudly crying face 😭, he has had to write in a markup language that is too verbose. The character following the \ must be in lower case but the hex digits of \u{X...} should be upper case but may be lower case. The values in \u{X...} must be in the valid Unicode range \u{0} to \u{10FFFF} excluding surrogates D800 to DFFF. <Details=The two lines\r\nmade I \u{1F60A}> Is the equivalent of: <Details= The two lines made I 😊>

Recommended Formats

Scalars may represent many different types of information. To facilitate interoperability xenon defines how various kinds of information should be represented: Implementations may support additional types.

Booleans

Booleans are stored as true or false. Processors must decode upper or lower case, e.g. False.

Integers

Integers should be stored with commas for readability. Processors must decode commas. Processors must handle signed 32 bit numbers. Processors should handle signed 64 bit numbers.

Real numbers

Real numbers should be stored with commas for readability. Processors must decode commas. Implementations must handle ieee 64 bit double precision floating point numbers including the special values infinity ∞, negative infinity -∞, negative zero -0, and not a number NaN. Numbers may use the e notation, e.g. 4.2957e24 for 4.2957 × 10²⁴. Processors may handle 32 bit single precision numbers. An implementation must interpret both upper and lower case e.

Dates and Times