I’ve always used ‘canonical S-expressions’ to refer to Rivest’s S-expressions proposal: https://www.ietf.org/archive/id/draft-rivest-sexp-13.html, a proposal which has canonical, basic transport & advanced transport representations which are all equivalent to one another (i.e., every advanced transport representation has a single canonical representation). I don’t know where I first saw it, but perhaps it was intended to distinguish from other S-expressions such as Lisp’s or Scheme’s?

Maybe I should refer to them as ‘Rivest S-expressions’ or ‘SPKI S-expressions’ instead.

> S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string.

Neither does JSON, as this whole thread indicates. This applies to other data types, too: while a Rivest expression could be

    (date [iso8601]2025-05-24T12:37:21Z)

    {
      "date": "2025-05-24T12:37:21Z"
    }

I really disagree. The whole reason YAML exists is to make JSON more readable. Within limits, the more data one can have in a screenful of text, the better. JSON is so terribly verbose if pretty-printed that it takes up screens and screens of text to represent a small amount of data — and when not pretty-printed, it is close to trying to read a memory trace.

Edit: updated link to the January 2025 proposal.

927 can be avoided, but it's way harder than it seems, which is why we have the proliferation of standards that fail to become universal.