In the encoding examples, I would prefer showing ASCII characters that encode themselves as literals. So for the "hello" (format B) example, which is currently shown as:

    55 68 65 6C 6C 6F

it would make sense to me to display it as something like:

    <55> h e l l o

or

    55 <h> <e> <l> <l> <o>

depending on which version you prefer.

Good idea, thanks, will do.

If I understood right annotations are part of the parsed data? Are they idempotent then? I know some people maintain that you can add comments in JSON but I hate that they disappear on a deserialize/serialize unlike XML comments.

The idea is that in most programs, you'd write code as if the annotations were not there. Annotations should, as a rule of thumb, not affect control flow of your programs at all.

But implementations should let programs access the annotations if the program explicitly asks to do so.

This lets us write "ordinary" programs, where the annotations are transparent, and "meta-level" programs, where the annotations actually do something - think IDEs, debuggers, message-tracing-annotators, provenance-annotators, etc.

The equivalence over values is defined so that annotations are ignored for comparison purposes. So `{ @a "a": 1 }` is equal to `{ "a": 1 }`.

[ETA] Implementations should take care to preserve annotations during round-trips; but to do so in such a way that "ordinary" programs don't even notice they're there.

Finally, annotations are the most "experimental" part of the design at the moment, so feedback on annotations in particular is most welcome.