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 whic

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.