Minimal Object Description Language
MODL (sounds like "doddle") is a compact, plain text data serialisation language for describing objects in as few characters as possible. It's designed to be character efficient when stored or in transport and developer friendly to receive and work with. In this introduction we compare MODL with other data serialisation formats and demonstrate how MODL can store an identical collection of objects using 61% fewer characters than JSON.
Example MODL Object
This is a basic MODL example:

MODL can be minified by removing newlines and comments:

Comparison vs JSON & YAML
Let's compare MODL with the two most popular plain text data serialisation languages: JSON and YAML.
Data Type Comparison
We'll compare JSON, YAML and MODL for assigning each data type to the key x
.
In all cases, we'll use the most character efficient way to assign a value.
We'll show a character count (including new line and space characters) and a percentage reduction for YAML and MODL compared to JSON.
String
Number
Array
- 1
- 2
- 3
Object / Map
'y': z
True
False
Null
Single Object Comparison
To compare the three formats for storing a simple object, we'll use the example object from json.org . YAML is the only format with a requirement for spacing, but for comparison each is formatted with 2 space indenting and no extra spacing.

- JSON (535 chars)
- YAML (431 chars)
- MODL (433 chars)
Reduce Repeating Data
One way to make an object more efficient is to reduce the repetition of data. JSON has no facility to do this but YAML can repeat nodes. MODL deals with repeating data with object referencing and the object index. For illustration, we've highlighted the parts that deal with repeating data in YAML and MODL:

- JSON (535 chars)
- YAML (430 chars)
- MODL (430 chars)
In the MODL object above you will notice percent prefixed numbers %0
, %1
and also the percent encapsulated number %1%
, these represent references to the object index. The object index is defined on the first line with the key ?
. The reference %1.i
instructs the interpreter to run the method i
on the second object in the index, which capitalises the first letter of the reference value.
The character efficiency gains in this example are negligible but reducing repeating data can clearly help make larger objects more character efficient.
Minification
It's common practice to minify objects. There are two steps in minification – reducing keys and removing spaces. We've replaced the original keys with 1 or 2 character alternatives and removed all spacing from the JSON and MODL examples. YAML requires spacing for structure so it can't be fully minified:

- JSON (273 chars)
- YAML (353 chars)
- MODL (209 chars)
We've had to make significant sacrifices in readability to achieve these character savings. This makes our object difficult for developers to work with. MODL interpreters can automatically unpack this data, returning it to it's original developer friendly state using classes, which we'll come to in a moment.
As a data serialisation format for storing a single object, we've demonstrated that MODL is more character efficient than JSON and YAML – in this example we've seen a 24% reduction when compared to JSON and over 40% reduction compared to YAML.
Storing a Single Object
Multiple Object Comparison
MODL offers even more efficiency when describing multiple objects of the same type. Using our previous example as inspiration, we'll describe the three languages that we've been comparing: JSON, YAML and MODL. First of all, we'll compare them without using MODL's class functionality:

- JSON (938 chars)
- YAML (845 chars)
- MODL (748 chars)
Classes
MODL classes allow us to define an object type, which an interpreter will use for all instances of it. Here's a class for our language
object:

In MODL, asterisk prefixed keys provide instructions to the interpreter and never appear in the output object. In the class above, we're instructing the interpreter to create a new class
with the id=l
and name=language
. We're telling it that this class is a child of the map
class. We're also telling it how to assign
values that are passed to it by an array.
Now we can describe our languages like this:

Minifying Classes
Classes can be minified too. Interpreters recognise *c
as well *class
, *i
as well as *id
, *n
as well as *name
, *s
as well as *superclass
and *a
as well as *assign
. Here is our class minified:

Loading a Class File
We've seen how to instruct the interpreter to create a class, we can also instruct the interpreter to load another MODL file using the key *load
or *l
. In this example, we're defining our classes in a separate file so we can easily re-use them. We'll call our file c.modl
, we can import it simply using *l=c
since the interpreter automatically uses the .modl extension if one hasn't been provided.
Let's compare the JSON and YAML minified objects with MODL using an imported class and object referencing to reduce repetition of data:

- JSON (530 chars)
- YAML (629 chars)
- MODL (363 chars)
Storing Multiple Objects
Minified and Developer Friendly
In the section above, we looked at how classes can make objects more efficient, they also make output developer friendly. MODL interpreters can output unpacked MODL (pretty printed with original keys) but can also output JSON. To round up, let's look at an input object and an output object.
MODL Input
As we saw above, the MODL input to describe our three languages is 363 characters with an imported MODL class file. It's 468 characters to include the class definition in the file itself. Here it is using the import:

After being processed by the MODL interpreter, the output object is unpacked and developer friendly.
Developer Friendly Objects
MODL / JSON Output
After being processed by the MODL interpreter, the output object is unpacked and developer friendly.

- JSON (938 chars)
- MODL (748 chars)
Added Functionality
MODL offers extra functionality that typical data serialisation formats don't, including the ability to describe an object conditionally. For detailed information about how MODL works, read the Technical Specification. To get started on your own project take a look at the Developer Libraries.