What is OT?

The week of handwritten markup languages at Habrahabr. An article about AXON reminded me of my ot - object template language. In it, I connected interesting ideas from XML, YAML and others.

What, one more?

Bicycles are different. For example, I was interested in trying to create the data description language and, to some extent, the markup language.

TL; DR

 <note status="saved"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>

 note: status :: saved; to: "Tove"; from: "Jani"; heading: 'Reminder'; body: `Don't forget me this weekend!`; ;

Concept

Initially, I wanted something like a programming language inside the DOM, so that the code is always executed in the context of a node, so that you can navigate through the DOM language control instructions, variables and runtime objects to the DOM node of the context, etc. etc. As a result, the first version of the concept successfully lost its memory.

The second option is much simpler and generally not about programming as such. It is rather about templates in the form in which they are represented in JSP technology, when xhtml is mixed with control elements. At the same time, it was noted that jsp is not bad for pure template making without programming. But there is also XML, great and terrible.

And what is the replacement for except JSON, YAML and TOML (.ini on steroids)? The first one describes the primitive types, objects and arrays of javascript, the second one does the same thing, but without quit-brackets, and the third is not about that at all.

Only one thing distinguishes them from XML, they describe an object through its properties. It is assumed that, if necessary, the user will add a type field to the object and describe the object class. In XML, an object is described directly as an instance of a class and then, if necessary, additional fields may be specified, such as an identifier.

What happens if you combine the simplicity of YAML and the concept of objects from XML? That's right - object template language, an experimental human-readable language for describing data, structures, and templates.

Ot

Schematically, the entire OT can be described with one line module~class(id): content; that is, it is a modular language for recursive object patterns. In addition, there are additional data types in addition to strings and there are no associative arrays that are of type objects from JSON, as a non-conceptual entity.

In addition to text identifiers, string, boolean, integer, and real constants, there are some characters that allow you to describe tree object structures (object model). There is also a reference type for building other types of graph structures.

Any empty space between identifiers, groups of identifiers, markup characters and constants is ignored and used to separate meaningful characters, but is not included in the contents of the object. Inside quotes, any empty space is counted.

Object model

Any template is a single object that is the root. Any object, incl. root, represented at least as an object class identifier and optionally with module identifiers and a unique object identifier:

 module~class(id)

For example, for an html page, there is an object of the body class, which can be preceded by the identifier of the module from which this class is taken ( html~body ). This object is given an identifier index-page , by which you can establish a connection with the object through the link @index-page .

 body html~body html~body(index-page) @index-page

Objects can be nested into each other, so the first object will contain the second object, the parent-child connection is established.

 html: body ;

The internal contents of the object begin after the symbol : All content up to the corresponding character ; will be considered as belonging to the parent object. If the object has no content, the characters:; not specified.

It is important to remember that a class identifier of an object is mandatory for any object, that is, two or more identical class identifiers in a template will correspond to two or more instances of the class.

 html: body: br br br; ;

Reuse

For objects, the contents of which can be described in several places of the template, it is possible to specify such a description mode of the content in which the creation of a new instance of the class will not be performed, and all the contents will belong to one instance of this class within the parent object. This is achieved using the symbol :: opening content.

 xml: attr :: id: "my-xml"; ; attr :: xmlns: "urn:oberon:ot"; ; ;

In the reuse mode, not only the class but also other parameters of the object, its module and identifier are taken into account.

Modularity

Modularity in the simplest form allows you to visually separate the same-name classes of objects of different nature. For example, html~body and human~body . Modularity in the object model also implies the presence of context support for some modules, the extended functionality of which allows for expanding the possibilities of working with the template in runtime.

Standard modules and classes

Standard modules provide additional runtime options for the object model.

core

The core module is a built-in module, as well as a basic module. To start using the core module, you need to create an instance of the core~template class as the root object of the template. Thus, the entire contents of the root element can access the core module classes. In other cases, the core module functionality is disabled.

 core~template: (*   *) ;

The core module provides an import class that allows you to describe template dependencies on third-party templates (standard, custom, virtual, etc.).

 core~template: import: context; ;

Implicitly specifying a module for known classes, such as import , operates on an object of type core~template , and the same rule applies to imported classes, so there is no need (but the possibility remains) to specify the core module and other imported modules each time.

For example:

 core~template: import: html; html: body: p: ", !";;; ;

The html , body and p classes belong to the html module and their ownership is controlled by runtime, but it is clearly not required to specify their module.

Templates and user data

context

The core module provides a context class which is the identifier of the context module.
The context module provides access to the context data of the object model. Accessing model objects through special classes of the context module will allow to place data from runtime in the template contents.

For example, the class context~$ allows you to access context data by identifier or hierarchical set of identifiers.

 core~template: import: context; $(hello-world-text)`, `$(user-names/hello-world-user)`!` ;

Thus, depending on the data placed in the context in some way and accessible by the given identifiers, after processing the template text and building the object model we will get the final object with the specified values.

 core~template: import: context; `` `, ` `` `!` ;

Implementation

The first prototype of the parser was written on golang, some template modules were implemented nearby, core course, and another module for storing binary information in the form of zbase32 strings, an excellent format, deserves special mention the design document of this format, as people carefully analyzed the situation with the baseXXX formats .
Later, an incomplete prototype of the OT parser for javascript was implemented, which became the basis for the language of describing structural atoms in the language ... and yet this is another story.