AXON: What & why?

AXON is an acronym for An eXtended Object Notation – simple text based notation for representation and interchanging of the objects, documents and data.

There is an easy & simple JSON. Why yet another object notation?

JSON is an excellent object notation for everything that may be represented by superposition of lists and dicts (in python viewpoint) or arrays and objects (in javascript viewpoint). Almost everything can be expressed by this way, but sometimes that adds useless overhead.

In order to explain let's consider simple JSON sample:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"},
      null,
      {"value": "Exit", "onclick": "Exit()"}          
    ]
  }
}}

One can see that the following pattern:

{"menu": {
    ...
}}

in the example is just a way to notate a named object.

In XML world this is an element:

<menu ...>
    ...
</menu>

AXON extend JSON's notion of object by a named object – mapping in current terminology of AXON:

menu {
    ...
}

One can see that AXON pattern is more compact and converted into a single named object instead of a proxy object containing actual object as an attribute.

Here is another pattern in this sample:

{"menuitem": [
    {...}
    .....
    {...}
]}

One can see again that this is a JSON-ish way to represent list of values that correspond to the same tagname.

In XML world this is an element that acts as container:

<menuitem>
    ...
</menuitem>

AXON can represent this pattern as:

menuitem {
...
}

Last pattern is almost the XML-like representation, but less verbose.

Let's now consider AXON version of the example in expression formatted form:

menu { 
  id: "file"
  value: "File"
  popup {
    menuitem { 
        {value: "New" onclick: "CreateNewDoc()"}
        {value: "Open" onclick: "OpenDoc()"}
        {value: "Close" onclick: "CloseDoc()"}
        null
        {value: "Close" onclick: "CloseDoc()"}
    }
  }
}

One can see that last AXON version is almost the XML version, but with less verbose notation (without closing tags). This is expression based notation in AXON for representation named complex structures. In statement based form AXON representation looks like YAML:

menu
  id: "file" 
  value: "File"
  popup
    menuitem
      {value: "New" onclick: "CreateNewDoc()"}
      {value: "Open" onclick: "OpenDoc()"}
      {value: "Close" onclick: "CloseDoc()"}
      null
      {value: "Close" onclick: "CloseDoc()"}

And finally JSON version may be expressed in AXON in less verbose form:

{menu: {
 id: "file" value: "File"
 popup: {
   menuitem: [
     {value: "New" onclick: "CreateNewDoc()"}
     {value: "Open" onclick: "OpenDoc()"}
     {value: "Close" onclick: "CloseDoc()"}
 ]}
}}

One can see the difference:

• no commas between values;

• no double quotes around indentifier-like keys.

There are another reasons to introduce AXON:

• to add decimal, datetime values;
• to add support of cross references for representation of complex graphs of data;
• add comments.

How AXON is related to XML?

AXON often looks like XML, but less verbose. Let's consider some examples.

AXON like XML supports representation of tree-like structures natively by introducing named complex values – Nodes:

Empty node:

tag{}

• has only a name.

It corresponds to XML representation:

<tag />

Named mapping:

tag {
    name_1: value_1
    ...............
    name_m: value_m
}

• has a name,

• have attributes (name:value pairs).

It corresponds to XML representation:

<tag name_1="value_1"
        ...
     name_m="value_m">
</tag>

Named sequence:

tag {
    value_1
    .......
    value_m
}

• has a name,

• contains values of any kind.

It corresponds to XML representation:

<tag>
    <tag_1>
        ...
    </tag_1>
    ...
    <tag_N>
        ...
    </tag_N>
</tag>

Element:

tag {
    name_1: value_1
    ...............
    name_m: value_m
    tag_1 {
        ...
    }
    ...
    tag_N {
        ...
    }
}

• has a name,

• have attributes (name:value pairs) and

• contains values of any kind.

It corresponds to XML representation:

<tag name_1="value_1"
        ...
     name_m="value_m">
    <tag_1>
        ...
    </tag_1>
    ...
    <tag_N>
        ...
    </tag_N>
</tag>

Why not to translate these XML-ish data to JSON?

Yes, you can.

The mapping

tag {
    name_1: value_1
    ...............
    name_m: value_m
}

translates to:

{"tag": {
    "name_1": value_1,
    .................,
    "name_m": value_m
}}

The sequence

tag {
    value_1
    .......
    value_m
}

translates to:

{"tag": [
    value_1,
    .......,
    value_N
]}

The element

tag {
    name_1: value_1
    ...............
    name_m: value_m
    tag_1 {
        ...
    }
    ...
    tag_N {
        ...
    }
}

translates to:

{"tag": [
    {"name_1": value_1,
     .................,
     "name_m": value_m},
    [{"tag_1": ...}, 
      .......,
     {"tag_N": ...}]
]}

One can see that translation much of XML-ish structures will make things more complex and less readable.

There are no ways to avoid this overhead especially if data are simestructured and contains values of many types in different combinations.