You can use MDriven Text Format to express a ViewModel-shaped structure as compact text when editing or experimenting with model data structures outside a JSON representation.

Status and purpose

MDriven Text Format is a proposed textual representation for ViewModel data. Its goal is to make structures easier to read and write than JSON, particularly when values themselves contain characters that often require escaping in JSON.

The intended initial use is text-based editing of classes, state machines, ViewModels, and actions in MDriven Designer. It is also intended as an initial format for experimenting with ways to change a model other than working directly in MDriven Designer.

This format describes structured ViewModel data. It is not a display-formatting mechanism for values shown in an application. To control how a ViewModel column is rendered in a user interface, use Documentation:Text formatting.

Read the structure

A MDriven Text document consists of entries. Each entry has:

• An optional classifier, followed by a space.
• A key.
• A brace-delimited content block: {...}.

The general form is:

classifier Key{
  content
}

For example, this entry has the classifier class, the key Thing, and content that describes the class:

class Thing{
  SuperClass{SomeSuper}
}

Within a content block, you add further entries. An entry can represent a value, a nested structure, or an item in a list, depending on its classifier and the ViewModel structure.

Core syntax

The format uses three language-level elements:

Element	Meaning	Example
{ and }	Create a content block and therefore the structure of the document.	Type{string}
Space	Separates a classifier from its key.	attribute Attribute1{...}
Double quote	Standard string enclosure.	A string value can be enclosed in double quotes.

Other characters are content. Unlike JSON, identifiers are not written with double quotes and entries are not separated by commas.

Entry grammar

An entry is written as:

[classifier ]Key{content}

The brackets in this description mean that the classifier and its following space are optional. They are not literal characters to write.

The content of an entry is itself a sequence of entries:

[classifier ]Key{
  [classifier ]Key{content}
  [classifier ]Key{content}
}

Every key must be unique within the same list.

Classifiers, ViewModels, and nestings

A classifier tells the reader and the format which target structure an entry represents. The target structure is defined by the ViewModel, its ViewModel name, and its nesting names.

The format gives special meaning to ViewModel and nesting classifiers. This lets it identify nested objects and collect repeated nesting entries into lists. In contrast, ordinary properties can be written without a classifier when their meaning is clear from the ViewModel context.

For example:

class Thing{
  SuperClass{SomeSuper}
  attribute Attribute1{
    Type{string}
  }
}

In this example:

• class identifies the outer structure.
• Thing is the outer entry key.
• SuperClass is an ordinary property with the value SomeSuper.
• attribute identifies a nested structure.
• Attribute1 is the key for that nested structure.
• Type{string} is content inside Attribute1.

Example: a class with an attribute and a role

The following example represents a class named Thing. It has a superclass, one attribute, and one role:

class Thing{
  SuperClass{SomeSuper}
  attribute Attribute1{
    Type{string}
  }
  role Detail2{
    Cardinality{0..*}
    TargetType{Detail}
    BackName{Thing2}
    BackCardinality{0..1}
    Aggregation{composite}
    IsNavigable{true}
    RoleClass{TheRoleClass}
  }
}

The role entry is classified as role. Its key is Detail2; its content contains properties such as cardinality, target type, and navigation information.

Represent list properties

The format treats single relations, multi-relations, and, to an extent, attributes in the same way: as entries in a structure. A list property can be expressed in either of the following forms.

Repeated classifier form

Repeat entries with the same classifier and give each entry a unique key:

attribute Attribute1{
  Type{string}
}
attribute Attribute2{
  Type{integer}
}
attribute Attribute3{
  Type{boolean}
}

This form is intended to be easier to scan because the classifier appears next to each item and resembles C#-style declarations.

Explicit list form

Place the list items inside an explicit list property:

Attributes{
  Attribute1{
    Type{string}
  }
  Attribute2{
    Type{integer}
  }
  Attribute3{
    Type{boolean}
  }
}

Use unique keys for the items in the list. The repeated classifier form and explicit list form provide two ways to express a list; the ViewModel context determines how the entries are interpreted.

Comparison with JSON

MDriven Text Format and JSON both represent structured data, but they use different conventions.

Area	MDriven Text Format	JSON
Identifiers	Identifiers are not enclosed in double quotes.	Property names are enclosed in double quotes.
Entry separators	Entries are separated by structure and whitespace; commas are not used as separators.	Properties and array items are separated by commas.
Collections	The ViewModel and nesting classifier provide context for collecting repeated entries into lists.	Arrays use square brackets.
ViewModel structure	ViewModel and nesting classifiers have a special meaning.	JSON does not have a separate ViewModel or nesting classifier concept.
Multi-links	Repeated entries with a nesting classifier can be collected as a list.	Multi-links are represented as arrays.

For example, JSON requires quoted identifiers, commas, and an array for several attributes:

{
  "Attributes": [
    { "Name": "Attribute1", "Type": "string" },
    { "Name": "Attribute2", "Type": "integer" }
  ]
}

The corresponding MDriven Text style can instead repeat the nesting classifier:

attribute Attribute1{
  Type{string}
}
attribute Attribute2{
  Type{integer}
}

Intended implementation

The planned implementation uses TajSon functionality and routes format logic through the TajSon mechanisms. The stated direction is a generic, editable textual representation for any ViewModel.

Related formats

MDriven Text Format is intended for a textual ViewModel representation. It is different from other formats and features used for other purposes:

• Documentation:Xmi is the XML-based interchange format supported for model collaboration with other tools.
• Documentation:Modlr describes the MDriven Designer model file format used by MDriven Server for model upload and download.
• Documentation:Text formatting controls the presentation of bound values in supported user-interface technologies.

See also

• Documentation:Xmi
• Documentation:Modlr
• Documentation:Text formatting