Subject: [Json] Schema for config files Re: Human JSON (Hjson)

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 May 2016 12:31:43 -0400

It isn't on topic for the encoding discussion, but is for the schema we
keep discussing.

Over the past 20 odd years I have designed a lot of languages. At least 30.
And about a dozen of those look very much like a schema sort of language.

All that my Goedel tool is, is a front end that allows me to quickly create
a parser that reads an input file and converts it to a DOM like tree and a
back end that is simply a scripting language that then expands it.

This is a very powerful way to code if you want to write stuff quickly.

The one thing that I have in Goedel that isn't in the JSON schemas I have
seen is that I have a 'Label' construct similar to an XMLSchema ID. Labels
are very useful in Goedel because the parser automatically links them in
both directions.

If I specify a label 'Foo' in one part of the input file, the parsed data
structure will have a list of links to every part of the data structure
that references it. (And vice versa of course).

This is very useful in config files because it allows you to do things like
specify the parameters for a network connection in one place and then
instantiate it in multiple places.

I don't see any need to specify ranges on integers, number of sub items
that can appear or anything of that sort. But labels are very very powerful.

The other thing that I have found I want but never implemented is to have
the backing structure automatically collect up references to lists of
options.

So in my current UI scheme I have a UI that can contain a list of Wizards,
Dialogs, menus and such. [NB, the convention here is label follows type,
something else I would like to fix some day]

GUI MyUI
   Wizard CreateProfile
       ... wizard def
   Menu MainMenu
   Dialog Print
   Dialog Exit

So right now, the backing structure in C# is

class GUI : Object {
    Label Name;
    List <Object> Entries;
    }

Which is OK only my scripting language then ends up being full of code to
filter on particular types of entry. A better scheme would be:

class ObjectSet {
    List <Object> Object;  // All objects
    List <Wizard > Wizard  ;  // filtered to Wizard
    List <Menu> Menu ;
    List <Dialog> Dialog ;
    ...
    }

class GUI : Object {
    Label Name;
    ObjectSet Entries;
    }

Supporting a JSON like serialization properly would be fairly
straightforward. I would just have to work out how to redesign the parser
so that the object name always precedes the object data. Which is the JSON
way and actually a better way to do things:

MyUI GUI
   CreateProfile Wizard
       ... wizard def
   MainMenu Menu
   Print Dialog
   Exit Dialog

The reason this is better is that a label is always an atom whereas a type
can have parameters.

I suspect that what it would take is to distinguish between objects and
structures. The difference being that an object always has an identifier
and can be the target of a label and a structure does not.

class Object {
    Label Name;
    }

class GUI : Object {
    ObjectSet Entries;
    }

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 May 2016 18:56:09 +0200

Phillip Hallam-Baker wrote:
> This is very useful in config files because it allows you to do things
> like specify the parameters for a network connection in one place and
> then instantiate it in multiple places.

Yep, that is exactly why YAML turned out to be more useful for
configuration files than other formats I have tried.

Grüße, Carsten