3 ms·

I love the idea, but i'm a little wary of the implementation, we are heavy json-schema users, so i worry that this schema data is not going to track the json-sc

I love the idea, but i'm a little wary of the implementation, we are heavy json-schema users, so i worry that this schema data is not going to track the json-schema standard. we got burned with swagger, where in V2 they where pretty much fully J-S compliant, but then for some reason dumped compliance in v3, so we had to kiss them goodbye. I don't need my schema's tied up in yet another propriety format, even if it is close to J-S. I cant see any compliance statements on the site that tell me what level of compliance exists.

thawkins 7y ago
Bad form replying to my own response, but i have inspected it some more and have some comments. 1. The site says schema.org is included, but schema.org is mainly just documentation, I woukd like something more like json-schema that I can actualy use the schema data directly. 2. I dont get why the validators have function names, surely the validator is anonymous, and its name should be a function of the property path, the argumant is always "value", and it always returns a boolean. So why do you need to declare a name at all. 3. If you cant support json-schema then you need an export function that allows you to export valid draft v8 json-schema. 4. Some way of anotating properties for graphql endpoint generation would be cool, ie generating .graphql files, or mongodb bson.
- IsaiahShiner 7y ago
  Let me see if I can boil down your comments to specifc questions that I can answer. "Is DitaBase compliant with JSON-Schema?" The answer to this question is critical to understand about how DitaBase is different: if you want it to, then yes! The validators and converters are fully Turing complete, and not limited to Javascript either. If you can make a language interpreter in C/C++ (think Javascript V8), then you can use it with DitaBase. So whatever format you want, just rebuild it in (or port it to) dit schemas. Therefore, it isn't possible for DitaBase to not be compliant with something (at least, as far as I can think) because if someone thinks its important, they'll rebuild it in dit schemas. "Schema.org is just documentation. Are there programatic, queryable schemas?" Yes, but only optionally. In theory, all that is required to be a dit is a validator. You could inherit from "thing" and just directly have some text and a validator. But if you want to use Controllors (CRUD for a specific schema), Containers (abstract the shape of the data from the content) and other things like that, then yes, you need programatically defined schemas, just like in J-S. If someone has them, then you can use them. If not, in theory, if their schema is public, then you could just make a pull request with the relavent additions. DitaBase is very open compared to something like Swagger. "Uh, anonymous functions? Duh?" Oh, yes that makes much more sense that the ridiculous names I was giving those in the example. That actually just never occured to me. Of course these things will have to get slowly fleshed out over time, and I suppose there's no reason you couldn't have both. "GraphQL, BSON, custom tools, cool things" This is the great thing about DitaBase. Since you know the exact structure of any dit, and everything about dits is generic, you can just build all of this on top, without any overhead. DitaBase will almost certainly build some things like this in house, especially something like GraphQL, and some data analysis and statistical plotting utilites. Or perhaps, similar to how VScode absorbs open source projects into itself when they get really popular, DitaBase could probably do the same.
jgotti92 7y ago
Can you expand a bit more how did you get burned with it? Did you had some issues because Swagger changed the usage of some keywords from Json Schema?
- thawkins 7y ago
  we where using swagger to manage both API's and schemas, and also extracting schema files to validate the results of api calls, validate the structure of records in mongodb. When swagger dropped json-schema compliance we lost that ability.
  - jgotti92 7y ago
    Did you try using JSON Hyper Schema for defining APIs maybe?

thawkins 7y ago

Bad form replying to my own response, but i have inspected it some more and have some comments. 1. The site says schema.org is included, but schema.org is mainly just documentation, I woukd like something more like json-schema that I can actualy use the schema data directly. 2. I dont get why the validators have function names, surely the validator is anonymous, and its name should be a function of the property path, the argumant is always "value", and it always returns a boolean. So why do you need to declare a name at all. 3. If you cant support json-schema then you need an export function that allows you to export valid draft v8 json-schema. 4. Some way of anotating properties for graphql endpoint generation would be cool, ie generating .graphql files, or mongodb bson.

IsaiahShiner 7y ago
Let me see if I can boil down your comments to specifc questions that I can answer. "Is DitaBase compliant with JSON-Schema?" The answer to this question is critical to understand about how DitaBase is different: if you want it to, then yes! The validators and converters are fully Turing complete, and not limited to Javascript either. If you can make a language interpreter in C/C++ (think Javascript V8), then you can use it with DitaBase. So whatever format you want, just rebuild it in (or port it to) dit schemas. Therefore, it isn't possible for DitaBase to not be compliant with something (at least, as far as I can think) because if someone thinks its important, they'll rebuild it in dit schemas. "Schema.org is just documentation. Are there programatic, queryable schemas?" Yes, but only optionally. In theory, all that is required to be a dit is a validator. You could inherit from "thing" and just directly have some text and a validator. But if you want to use Controllors (CRUD for a specific schema), Containers (abstract the shape of the data from the content) and other things like that, then yes, you need programatically defined schemas, just like in J-S. If someone has them, then you can use them. If not, in theory, if their schema is public, then you could just make a pull request with the relavent additions. DitaBase is very open compared to something like Swagger. "Uh, anonymous functions? Duh?" Oh, yes that makes much more sense that the ridiculous names I was giving those in the example. That actually just never occured to me. Of course these things will have to get slowly fleshed out over time, and I suppose there's no reason you couldn't have both. "GraphQL, BSON, custom tools, cool things" This is the great thing about DitaBase. Since you know the exact structure of any dit, and everything about dits is generic, you can just build all of this on top, without any overhead. DitaBase will almost certainly build some things like this in house, especially something like GraphQL, and some data analysis and statistical plotting utilites. Or perhaps, similar to how VScode absorbs open source projects into itself when they get really popular, DitaBase could probably do the same.

jgotti92 7y ago

Can you expand a bit more how did you get burned with it? Did you had some issues because Swagger changed the usage of some keywords from Json Schema?

thawkins 7y ago
we where using swagger to manage both API's and schemas, and also extracting schema files to validate the results of api calls, validate the structure of records in mongodb. When swagger dropped json-schema compliance we lost that ability.
- jgotti92 7y ago
  Did you try using JSON Hyper Schema for defining APIs maybe?