Suggestions to get closer to JSON Schema and current OpenAPI variant

[epoberezkin]

• elements. Why not “items"? Lots of people would feel more at home and it would simplify migration to JSL - more schemas would just work out of the box.
• no “nullable". It’s a very common use case that the value can be null. I would suggest adding to type form nullable: true
• tag. Why not “discriminator” for clarity of the form and consistency with OpenAPI?
• "strict instance semantics": suggest make it default and recommend that implementations support non-strict mode. What is the reason to create ambiguity here?
• "Implementations SHOULD support producing errors in this standard form." - suggest MUST
• "types": feels like there are too many, also "timestamp" as a type is very strange... I understand that the idea could be to match SQL or some language types, but depending on the language there may be other types... I would just follow JSON Schema: string, number, integer (or maybe "int" and "uint"), boolean. Also why would you not accept integer where float is expected (I mean what's the use case to require "float" at all)? Multiple types feel like some bad substitution for value ranges tbh that many people would miss... Also maybe we can have optional "size" in bytes for both strings and numbers, instead of multiple types?
• why no JSL for schema itself?
• how to link multiple files? or it's for implementations to decide?

The rest looks good.

Happy to make PRs for this items

[epoberezkin]

also: require (allow?) type array/object (but must be compatible with the form). If you require, you would be able to define loose meta-schema for all forms. For object, there is no reason not to consider discriminator and properties as one form allowing all three keywords, where in case of discriminator, properties and optionalProperties would define shared properties for all mappings - it would also allow to define the schema for tag e.g. string or number as you cannot imply it from the schema.

So in general, love the simplicity, but it violates "explicit better than implicit" idea and does not allow creating meta-schema. It would be very easy to rectify.

[epoberezkin]

One more thing:

"values": I would allow schema for "keys", particularly if you support "size" in addition to "type". That would allow defining sparse arrays for example or limit the size of the dictionary keys.