Skip to content
John Jenkins edited this page Feb 21, 2014 · 2 revisions

Here are some of the most frequently asked questions and the best responses I have heard to date.

How does this relate to JSON Schema / Avro / etc.?

Concordia is the result of using several of these specifications and seeing several prevailing patterns which I wanted to address.

  • Strong typing vs. weak typing - Strong vs. weak typing in a programming language is one thing, but in a schema language it seems almost counterproductive. If you are defining what the data looks like, why would you say, "sometimes it's a number; sometimes it's a complex object." Instead, give each representation its own field name. That is, as long as you say...

  • "null" is not a type - null is equivalent to there being no data. It may imply something else (no data vs. attempted to get data and couldn't), but it is not it's own type. If you treat it as its own type then you run into the problem above where you need to be able to have multiple "types" for a field (e.g. "number" and "null").

  • Don't put data in field names - When defining an object's field in JSON Schema, you use the keys in the definition as the keys in the data. To me this feels like a slippery slope. Going further, you can use regular expressions for the field names, so one definition may define any number of fields in the data. While it may seem like you are saving space and making things more efficient, in practice you end up making things much more complicated for the consumers. Here is a great explanation: http://vimeo.com/35005701#t=7m17s

  • Extensibility - JSON Schema defines "min" and "max" for the number type. A question may be, are they exclusive or inclusive or a combination (e.g. "min" is inclusive, but "max" is exclusive). Instead, we went with a decorator approach where users can add their own schema and data validation. When a number schema is being validated, you can inject some additional code to check that things like "min" and "max" (if present) are numbers, and, when the data for that schema is being validated, you can ensure that the value is greater than (or equal to, if you want) the "min" value.
    More generally, it means that you aren't bound by Concordia (or JSON Schema or anyone) regarding what these fields mean and when new fields will be added. Schemas (and their data) are allowed to have additional fields that aren't understood by other systems. For example, I could still parse your schema with "min" and "max" even though I don't know what they mean; I could also parse data without the knowledge that all numbers will fall between "min" and "max".

Clone this wiki locally