Information is stored and used as data in digital systems. Digital systems rely on defined structures to store, retrieve and manipulate data in a consistent manner.

A data model is a structured representation of the data that describes the properties of the data, the relationships between different data elements, and any rules or constraints that govern the data.

Data modeling is the process of creating a data model.

Many data modeling languages exist, each with its own syntax and semantics.

Commonly languages that define data models are called “conceptual modeling languages”.

While many data modeling languages are used to define data models in a way that is independent of underlying technologies used, most data modeling languages do not provide a way to define how data is represented in an information system.

For example, information models in UML are mostly used for diagramming and documentation purposes, and do not provide a way to define how the data can be accessed or used in programming languages.

Serialization is the process of converting data structures or objects into a format that can be stored or transmitted between systems. Typically, this involves converting the data into a string of bytes that can be written to a file or sent over a network.

Serialization formats are very important in allowing systems to exchange structured information in an interoperable manner without loss of semantics.

Serialization formats often come with a schema language that allows for the definition of particular data structures that data needs to conform to.

Typically, languages that define serialization formats are called “schema languages”.

A conceptual model may be realized (“implemented”) in multiple serialization formats. For example, some standards define a conceptual model in UML and provide manually-defined transformation rules to XML and JSON.

Information defined by conceptual data models and serialization schema languages are not directly usable in a native manner in programming languages or APIs.

At the conceptual data model level, there is no direct mapping to programming language constructs. For example, a UML class diagram does not directly map to a Java class.

There are tools that attempt to generate code from UML models, yet the generated code will require manual integration and intervention to be usable in software.

At the serialization schema language level, there is again no direct access from the programming language to the schema language constructs. For example, a JSON Schema does not directly map to a Java class. Typically developers will write code that parses the schema and/or implement code to read and write data in the format defined by the schema.

The lack of direct access to data models and serialization formats in programming languages makes it difficult to work with structured data in a consistent manner across different systems and technologies.

Conceptual modeling focuses on the definition of the existence and relationships of data elements.

Serialization data modeling focuses on low-level details of how data is represented in a particular format.

For example, a conceptual model may define that a Date object hasyear, month, day attributes, and each of them are of an Integer type and potentially the numbering constraints for each attribute, and that there are certain restrictions to what the attributes can be at an attribute level (valid values of month range from 1 to 12), or at the object level (only a leap year is allowed to have 29 days in February). It does not specify how many bytes are to be used to represent an Integer or how the Date object is to be written in a file.

A serialization data model (using a schema language) may define that a Date object is represented as a sequence of 3 Integers, each representing the year, the month, and the day, respectively, and that the Integer type is represented as a 4-byte unsigned integer. While the schema language may support value constraints that the month attribute must be between 1 and 12, it is unlikely that the schema language supports object-level complex constraints such as “only a leap year is allowed to have 29 days in February”. Schema languages typically do not have the expressive power to define such complex constraints.

This presents a conundrum for the data modeler, who needs to define the entire structure and constraints, but also needs to decide where and how to define constraints that may not be definable in a schema language. This complexity explodes exponentially as the need for the same data to be represented in additional schema languages arises.

How much of the constraints should be defined in the conceptual model? How much of the data model constraints should be defined in the serialization schema language? Do we need to define duplicated constraints in both the conceptual model and the serialization schema language if allowed? This is a question that haunts developers and data modelers alike.

LutaML is a system that aims to simplify users to easily define data models and work with information that conforms to those data models.

The goal of LutaML is to allow these steps to flow seamlessly:

1. Define a platform-independent data model in a human-readable format. (LutaML language)

2. Allow the data model to be directly useable in a programming language. (LutaML runtime)

3. Allow the data model to be expressed in a serialization schema language. (LutaML language)

4. Allow the data model to be directly serializable to a serialization format. (LutaML runtime)

5. Support the loading of data from a serialization format into a programming language. (LutaML runtime)

6. Allow importing a serialization schema language to define a data model. (LutaML runtime)

7. Allow the conversion of serialization formats to another through the data model. (LutaML runtime)

The LutaML language provides a way to represent structured data in a human-readable format.

Primitive values are the basic building blocks of LutaML.

All primitive types have names that start with uppercase.

LutaML supports the following primitive values:

• String (e.g., "high-fire"),

• Integer (e.g., 42).

• Float (e.g., 3.5),

• Boolean (e.g., true),

• TimeWithoutDate (e.g., 12:00:00),

• DateTime (e.g., 2024-01-01T12:00:00+00:00),

• Time (e.g., 2024-01-01T12:00:00+00:00),

• Decimal (e.g., 3.14159),

• Hash (e.g., { "key": "value" })

A declaration is a keyword that represents an action or a statement.

Syntax:

Where,

{declaration}

the declaration keyword

{*argument}

zero or more arguments

{*block}

an optional blocks

An argument is a string, which can be a primitive value or a reference to another object.

A block is delimited by curly braces and provides a context for inner declarations.

LutaML supports the following constructs.

The package construct is used to define a collection of classes and enums.

Syntax:

Where,

{name}

the name of the package

{*block}

an optional block

The package construct can be nested. You can also define other packages within a package, which helps in organizing related classes and enums.

Within the block, the following declarations are available:

• class

• enum

• definition

• package

The class construct is used to define a class which is a collection of attributes.

Syntax:

Where,

{name}

the name of the class

{*block}

an optional block

Class attributes can be restricted to a specific set of values using thevalues declaration.

It is possible to also define values with model instances. See for syntax to declare model instances.

Within the block, the following declarations are available:

• attribute

• definition

• values / value

The attribute construct is used to define an attribute of a class.

Syntax:

Where,

{name}

the name of the attribute

{type}

the type of the attribute

{*block}

an optional block

An attribute can have a cardinality constraint when it is a collection.

Syntax:

Where,

{min}

the minimum number of values

{max}

the maximum number of values

An attribute can have a values constraint.

Syntax:

Where,

{value1, value2, …​}

the values that the attribute can take, or an Enum.

An attribute that accepts a string value accepts value validation using regular expressions.

Syntax:

Where,

{regex}

the regular expression to validate the string value

An attribute can have a default value using the default option. The default option can be set to a value or a lambda that returns a value.

Syntax:

Within the block, the following declarations are available:

• definition

• values

• cardinality

The value construct is used to define a value.

Syntax:

Where,

{name}

the name of the value

{*block}

an optional block

An enum construct is used to defined a named collection of values. Objects inside an Enum may be primitive values or instances of objects.

Syntax:

Where,

{name}

the name of the enum

{*block}

an optional block

{value-name}

the name of the value

{*value-block}

an optional block

Enums accept instances as values as well.

Within the block, the following declarations are available:

• value

• definition

LutaML supports the following constructs for serialization.

Key-value formats are serialization formats that represent data as a collection of key-value pairs.

These include YAML, JSON, TOML and others.

An instance construct is used to define an instance of a class.

To assign values to attributes, the attribute name is followed by an equal sign and the value.

Syntax:

Where,

{name}

the name of the instance

{*block}

an optional block

Within the block, the following declarations are available:

• attributes of the class

• definition

• values

Instances are representations of classes with values assigned to their attributes as a collection.

Syntax:

Where,

{name}

the name of the instance

{*block}

an optional block

Within the block, the following declarations are available:

• instance

Use require to import definitions from other files.

Link instances using ref:.

Class names are scoped to their model (e.g., Materials::CeramicTile).

1. Mandatory fields (cardinality 1) must be populated.

2. Values must match the declared type (e.g., float for thickness).

1. Unique names within a model.

2. Attribute names unique within a class.

• ref: must resolve to a valid instance path.

• Circular references are invalid.