Comment by anentropic

The project makes a bunch of big vague claims, like:

> Someday, there will be no file extensions: every file will be a dit.

reading: https://github.com/isaiahshiner/dit-cli/blob/master/docs/wha... ...seems to imply you want to solve the problem where:

  "Name": "John Doe"
  
  vs.
  
  "Name": {
      "FirstName": "John",
      "LastName": "Doe"
  }

represents the same data?

But for me it's completely unclear if or how Dit solves this though.

https://www.ditabase.io/faq.html says:

> Dit is not a format, it is a container. It's trying to be a bridge between other formats, and that means it relies on them heavily. You can't write data in dit format, only wrap data in a dit.

So it sounds like a schema language, an alternative to JSON-Schema, Avro etc?

But then it also bundles in a bunch of other things...

Apparently contradicting the above, the are 'assigners' and a sort of query language which seem to create and return records in this format which you "can't write data in":

  // Assign an existing object
  myName.givenName = name;

  // Use the 'n' assigner inside a list
  myName.middleNames = [n('Leopold'), n('Koser')];

  // Assign the string directly
  myName.familyName.value = 'Shiner';

  dit query name.dit '@@print(myName)'
  "Hi! My name is Isaiah Leopold Koser Shiner"

And then there are the validators and printers, as chunks of embedded python or javascript code.

But it's still hard to see how any of this solves the "John Doe" problem?

If dit is meant to be a bridge between silos of incompatible data maybe it would be useful to show some examples of that use case.