3 ms·

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/isaiah

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/whats-the-point.md 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 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.

IsaiahShiner 7y ago
Hmm, I can see how I'm being confusing. This is partially trying not to give information overload with poorly written explanations, especially for features which I haven't added yet. It's also because dit is really trying to solve everything with Perfect Data all at once, and I need to go back and be clear about when I'm talking about which concepts. To solve Perfect Data, we need a single system that can do: - Validation: This is for when you ask for a name and get "4jZw3ef\n". This already exists in database constraints, APIs, and, as you said, in things like JSON-Schema and Avro. The key difference is that the 'schema languages' are not languages. They don't have full flow control, libraries, classes, not even simple string functions. Dit does, by proxy of allowing for embedded languages, which let you do whatever you want. - Schemas: Obviously other schema languages already do this. This is covered by dit classes. To solve the "FirstName", "LastName" issue, you just make sure you're using a Name schema like the one I demonstrated, in which Name contains a FamilyName/GivenName. But then everyone is using different classes for the same data, which you can solve by... - Global Online Schemas: The only one really doing this is Schema.org. Everyone can agree that https://schema.org/Person https://schema.org/Person is a reasonable official schema for a person. However, they have no validation, and changes are decided by a consortium, not free change. DitaBase.io would have a sort of copy of GitHub, in which each class is it's own page, and doesn't explicitly belong to anyone. Using meritocracy, democracy, and compromise, the community would agree on which exact schema of Person is best. If someone disagrees, they can make their own style and try to explain why it's better, while offering easy conversion between their style and the old style. - Format Support/Universality: This is what I was getting at when I said "you can't write data in dit". Dit cannot afford be locked into one technology platform, the way JSON-Schema is locked to JSON, and the Semantic Web is locked to HTML. How do I write down data when you ask for it outside of a dit? In .json, .csv, .xml? Why not .yaml, .toml, .xlsx or .gsheet? There's no way to serialize data raw data as dit, only take data written in a .dit and print it some other way. The print functions and query system should allow you to request data in any format you want, including more than one. And ultimately, dit could never provide all of the features people could want. https://ipld.io/ https://ipld.io/ is basically doing a JSON-Schema style of thing, specifically for the block chain. Dit isn't going to replicate their custom block chain features, so instead dit should support IPLD, by allowing data to be read and printed in their format, and converted every which other way you can think of. I mentioned DitaBase having it's own object model, but the truth is this would almost certainly reference Schema.org, at least by extension. Perhaps the thing I was least clear on overall is that dit is still an evolving concept. I know where dit is now, and I know where dit wants to go, but I'm not really sure how to get there. Maybe assigners are a terrible way to solve that specific problem. That's fine, we'll throw them out and make something better. All I know is that Perfect Data needs to be solved, is solvable, and dit has a much better chance of solving it than any other existing solution.

IsaiahShiner 7y ago

Hmm, I can see how I'm being confusing. This is partially trying not to give information overload with poorly written explanations, especially for features which I haven't added yet. It's also because dit is really trying to solve everything with Perfect Data all at once, and I need to go back and be clear about when I'm talking about which concepts. To solve Perfect Data, we need a single system that can do: - Validation: This is for when you ask for a name and get "4jZw3ef\n". This already exists in database constraints, APIs, and, as you said, in things like JSON-Schema and Avro. The key difference is that the 'schema languages' are not languages. They don't have full flow control, libraries, classes, not even simple string functions. Dit does, by proxy of allowing for embedded languages, which let you do whatever you want. - Schemas: Obviously other schema languages already do this. This is covered by dit classes. To solve the "FirstName", "LastName" issue, you just make sure you're using a Name schema like the one I demonstrated, in which Name contains a FamilyName/GivenName. But then everyone is using different classes for the same data, which you can solve by... - Global Online Schemas: The only one really doing this is Schema.org. Everyone can agree that https://schema.org/Person https://schema.org/Person is a reasonable official schema for a person. However, they have no validation, and changes are decided by a consortium, not free change. DitaBase.io would have a sort of copy of GitHub, in which each class is it's own page, and doesn't explicitly belong to anyone. Using meritocracy, democracy, and compromise, the community would agree on which exact schema of Person is best. If someone disagrees, they can make their own style and try to explain why it's better, while offering easy conversion between their style and the old style. - Format Support/Universality: This is what I was getting at when I said "you can't write data in dit". Dit cannot afford be locked into one technology platform, the way JSON-Schema is locked to JSON, and the Semantic Web is locked to HTML. How do I write down data when you ask for it outside of a dit? In .json, .csv, .xml? Why not .yaml, .toml, .xlsx or .gsheet? There's no way to serialize data raw data as dit, only take data written in a .dit and print it some other way. The print functions and query system should allow you to request data in any format you want, including more than one. And ultimately, dit could never provide all of the features people could want. https://ipld.io/ https://ipld.io/ is basically doing a JSON-Schema style of thing, specifically for the block chain. Dit isn't going to replicate their custom block chain features, so instead dit should support IPLD, by allowing data to be read and printed in their format, and converted every which other way you can think of. I mentioned DitaBase having it's own object model, but the truth is this would almost certainly reference Schema.org, at least by extension. Perhaps the thing I was least clear on overall is that dit is still an evolving concept. I know where dit is now, and I know where dit wants to go, but I'm not really sure how to get there. Maybe assigners are a terrible way to solve that specific problem. That's fine, we'll throw them out and make something better. All I know is that Perfect Data needs to be solved, is solvable, and dit has a much better chance of solving it than any other existing solution.