Skip to content

Suggestion: consider optional comments in TOON for non-transport use cases #1

@osjimenez

Description

@osjimenez

JSON was designed primarily as a lightweight data-interchange format, so it deliberately excluded comments. That makes perfect sense for APIs where every byte counts and human annotations are unnecessary.

However, JSON is now widely used beyond transport—for example, in application configuration files and illustrative data samples. In these contexts, comments are genuinely useful to explain the meaning and intent of specific parameters.

Today, some serializers (e.g., in C#) allow non-standard comments, which leads to inconsistency across tools and editors: some accept them, others reject the file entirely. Looking ahead, if TOON continues to be used in scenarios that benefit from human readability, it might be helpful for the specification to define an optional, interoperable way to include comments. Systems that prioritize minimal size could simply omit comments, while configuration and documentation use cases could opt in.

This is a suggestion for discussion. What do you think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions