KDL Schema Language v2
This is an updated version of the KDL Schema modeled after a combination of JSON Schema and XSD. This PR should be used for general discussion of the spec as we edit it, and suggestions can be made in-thread or in the form of PRs against the zkat/schema-v2 branch it's based on.
Most of the work on the spec is happening in the schema/ksl-schema.kdl file, which is the KSL Schema for the KSL Schema Language itself, which will eventually be translated to a more formal prose spec in the spec markdown itself. Please ignore the current spec file, as it is out of date.
Status
- [x] New baseline for v2 schema language
- [ ] Make sure
@ksl:schemacan be disabled - [ ] Do a first-pass review of the current draft
- [ ] Something like JSON Schema's
dependentRequired - [ ] Something like JSON Schema's
dependentSchemas - [ ] Something like JSON Schema's
If-Then-Else - [ ] Something like JSON Schema's composition keywords (
anyOf,allOf,oneOf,not). This might also be something we do using an API like XSD's<xsd:group>and associated element types. - [ ] some utility mechanism(s) to help feed information into LSP semanticTokens for folks who are doing DSLs, so things will be automatically highlighted with those special classes, using schema information.
- [ ] Translate
ksl-schema.kdlto a proper prose spec doc (wait a bit)
How do you specify that a property is "nullable" (for example a property that is allowed to be a date-time or null)?
@LHolten type string #null
I can't seem to resolve review comments I've opened, so feel free to resolve and hide any of those threads that feel resolved!
Looks like lots of exciting updates — I'll aim to take a look this evening!
Also something you may have already thought about, but a massive part of the KDL validation I've been doing is maybe something I saw a comment referring to "cross-validation" about?
In a shortened version of the example I already shared in this thread:
residues {
types {
Monosaccharide {
// SNIP ...
}
AminoAcid {
// SNIP ...
}
}
Monosaccharide "g" "N-Acetylglucosamine" {
composition "C8H15NO6"
}
// SNIP ...
AminoAcid "A" "Alanine" {
composition "C3H7NO2"
}
// SNIP ...
All of the children in the residues section have to have node-names that match one of the types in residue.types!
That would be a super helpful validation to have for schema where there is some sort of definitions section!
Finally (for today), is the plan to have a working validator implementation before stabilizing the schema? It would be very very helpful to actually test writing some real schemas, and I'm sure would be invaluable for making sure the ksl-schema.kdl file is valid before it's stabilized!
Also something you may have already thought about, but a massive part of the KDL validation I've been doing is maybe something I saw a comment referring to "cross-validation" about?
In a shortened version of the example I already shared in this thread:
residues { types { Monosaccharide { // SNIP ... } AminoAcid { // SNIP ... } } Monosaccharide "g" "N-Acetylglucosamine" { composition "C8H15NO6" } // SNIP ... AminoAcid "A" "Alanine" { composition "C3H7NO2" } // SNIP ...All of the children in the
residuessection have to have node-names that match one of thetypesinresidue.types!That would be a super helpful validation to have for schema where there is some sort of definitions section!
Cross validation is in the todo list
Finally (for today), is the plan to have a working validator implementation before stabilizing the schema? It would be very very helpful to actually test writing some real schemas, and I'm sure would be invaluable for making sure the
ksl-schema.kdlfile is valid before it's stabilized!
Yes I'm planning on starting an implementation soon