I get that it's a richer format than JSON, with the introduction of sets, dicts and so on, but what I felt wasn't explained was the "extensible" part. Can someone give an example of this?
> But isn't it backwards to have the generator suggest where to put trigger points instead of the consumer?
No. edn is self-describing, and all descriptions bottom out on built-in types. Having each date/instant or extended type proclaim it is an #inst or #whatever means a single handler will ensure they all become proper types on the consumer side, with no knowledge of the application or document structure at all. And if no specific handler is installed, a generic handler can at least ensure that the value returned keeps track that the tagged element was tagged, and how, rather than just silently yielding a string with some encoded cruft in it.
The world you are describing is that 'context-sensitive' world mentioned in the edn rationale, where the consuming app must know that the cruft inside the dob: string inside a particular map in a particular context is actually a date or :id is a uuid or whatever, and also know how they represented. Ditto the lastEdited: field, startDate: and foo: fields etc. Are they all the same? Handling any particular document means having complete knowledge of such details.
Context-sensitivity greatly complicates applications and thwarts generic processing.
