When a JSON file becomes a DSL

Consider this portion of a JSON file.

 {
               "DisplayName": "Job Run Options",
               "Type": "select",
               "Options": [
                  "1-High Priority",
                  "2-Medium High Priority",
                  "3-Medium Priority",
                  "4-Medium Low Priority",
                  "5-Low Priority",
                  "6-Overnight Batch Job"
               ],
               "CurrentValueList": [
                  {
                     "Val": "1-High Priority"
                  }
               ]
            },

It's used to auto-create controls in Angular (or any other framework). It closely resembles HTML. This is a select element with options and a current value. While this works quite well in granting the ability to auto-create HTML elements from the back-end, it is it's own DSL Domain Specific Language.

We've spoke in the past about problems with DSLs. The top-most being the inability; when refactoring, to have a code symbol rename also find all the symbols in the JSON file.

This implies other problems too, you cannot refactor DSLs in the manner of making things lean and mean like one can do in code. You have to pretty much make all these changes manually.

If you are doing something like this, the best way to proceed is to keep your DSL simple. Don't allow large JSON hierarchies to exist, because refactoring each and every one of them is a big job.