This is the proposed new ViewModel data textual representation.

Goals: Text-based modeling, more to-the-point, less bloated, in an easier-to-write format than JSON (especially true if you consider attribute values that in turn are strings that may have special chars like ',",{ etc).

How the Format Looks:

viewmodel ValueOfFirstColumn{  
  column NameOfAColumn{ValueOfThatColumn}  
  column NameOfAColumn1{ValueOfThatColumn}  
  column NameOfAColumn2{ValueOfThatColumn}  
  column NameOfAColumn3{ValueOfThatColumn}  
  nesting ValueOfFirstColumnOfNestedObject{    
    column NameOfAColumn{ValueOfThatColumn}  
    column NameOfAColumn1{ValueOfThatColumn}  
    column NameOfAColumn2{ValueOfThatColumn}  
    column NameOfAColumn3{ValueOfThatColumn}  
    }  
    
  nesting ValueOfFirstColumnOfNestedObject{    
    column NameOfAColumn{ValueOfThatColumn}  
    column NameOfAColumn1{ValueOfThatColumn}  
    column NameOfAColumn2{ValueOfThatColumn}  
    column NameOfAColumn3{ValueOfThatColumn}  
    }  
}  

An example of when the ViewModel is named "Class", has a nesting "Attribute" and another nesting "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}  } 
}

Definition of the Format

classifier+space+Key{ ===content===}

The ===content=== is defined as: [classifier+space+]Key{===content===}

Every key must be unique in its list.

Format treats multi or single relations the same - and to a certain extent, even attributes.

A list property can be set in 2 ways:

• classifier+space+key{} repeated with unique keys
• or nameoflist{key1{} key2{} key3{}} (explicit form)

Why have classifiers and not always use the explicit form: easier for the eye to read and resembles C#.

What are classifiers: The definition of the target structure is a ViewModel, ViewModelName, and NestingNames

How does the format differ from JSON?

• JSON has "" on identifiers - MDrivenText does not.

• JSON makes heavy use of commas as separators - MDrivenText does not.
• JSON handles arrays differently than properties with [ enclosures; MDrivenText derives this knowledge from context.
• MDrivenText has a special meaning ViewModel/Nesting classifier separate from other properties.
• JSON must handle multi-links as arrays whereas MDrivenText collects keys based on the Nesting classifier to build lists.
• MDrivenText only has three language fixed elements: the {}, space, and double quote - the first builds structure, the second separates definitions, and the third is standard string enclosure. All other characters are part of the content.

What are use-cases?

Initially, a use-case will be used in MDrivenDesigner to provide text-based editing of classes, Statemachines, ViewModels, and Actions. This in turn will be the initial format when experimenting with other ways (than MDrivenDesigner) to change the model.

How will the format be implemented - is this a new transformation?

• We will use TajSon functionality and route all logic through the TajSon Mechanisms.

Plans are to allow for a generic editable textual representation of any ViewModel.