Use YAML as alternative representation of DSL model

[matthewadams]

Support entity and conversation specifications to be stored as YAML (and thereby JSON) as an alternative representation to the *.ydm & *.yc DSLs. This allows us

• to make the Xtext-based DSL machinery optional, reducing prerequisites and simplifying the codebase, and
• to offer a solution to those who feel that using a DSL would consider it to be vendor lock-in.

[matthewadams]

Also opens up the door to use something like lodash templates for code generation, too. While it takes away a custom editor, it does allow the use of standard YAML editors. If desirable enough, we could layer our model logic/constraints over existing YAML editors.

[matthewadams]

Further, creation of a JSON/YAML schema describing entity & conversation documents would allow for the leverage of schema-aware editors, making a custom editor less work.

[vbacvanski]

YAML would definitely beat JSON for user friendliness. I've seen some state machine specs in YAML (for some Google Cloud tasks and PHP) - nothing too complicated, but they were easy to read. YAML may be attractive to novices, as they would be no special symbols - everything would be spelled out in plain English.

[matthewadams]

I think the bigger issue is the perception of a proprietary DSL versus a proprietary YAML schema, not YAML vs JSON. Using YAML lands with a bit lighter emotional impact than using the DSL. If the DSL were somehow standardized, then I think the first impression would be more favorable, but I don't think anyone would even flinch at the YAML solution, even if the scheme were proprietary. In either case, the supporting machinery that YAML would require is definitely lighter in weight than our current Xtext-based tooling.

[vbacvanski]

You are right! Using YAML is unlikely to antagonize anybody at first contact. The emotional impact of a syntax is not to be underestimated. A lighter machinery would also be an advantage.