> Like 'jc ls' gives json output with following entry format: { "filename": "[actual-filename-string]" }

> Then I start asking: why not simply { "[actual-filename-string]" } ?

Because the first at least has a stab at being self-documenting, and maybe even forwards- and backwards-compatible: The file is saying what the values are (unless you're kinda dumb when choosing keys) and, since programs can ask for values by name, older programs won't have to deal with keys added by newer versions and newer programs can deal with missing values more gracefully than abandoning a whole parse because the record has six values instead of ten.

> But then why not:

> { { "metakeyword": "keyword", "metavalue": "filename" }, { "metakeyword": "value", "metavalue": "[actual-filename-string]" } }

Same information, now more verbose. Is there ever going to be a key other than "metakeyword" in that slot? If not, drop it.

    { "[actual-filename-string]" }

...isn't valid JSON. As for going up the metatower, my personal take on this would be to strive for brevity. That is, what's the least structure we can get away with to unambiguously serialise what is needed? In most(?) cases, this is probably best:

    { "filename": "whatever", "foo": "bar", "etc": "etc" }

However, maybe there are instances where:

    [
      { "attribute": "filename", "value": "whatever" },
      { "attribute": "foo", "value": "bar" },
      { "attribute": "etc", "value": "etc" }
    ]

...is more appropriate. If, for example, you need to encode a flexible schema, rather than a fixed one.

If brevity is what you want then what’s wrong with the default field record ls output? It’s even a regular language!

For a related discussion, see "Evolution of a Haskell Programmer": https://willamette.edu/~fruehr/haskell/evolution.html