Letter to DC

letter-to-dc.txt

Hi,

I'm noticing that a disturbing number of package managers[1] and other software projects[2] are making use of JSON as a
configuration format, which is starting to bother me (probably more than it should), since JSON is a data serialization
format, and was not intended for this purpose (as I understand it).

Have you considered writing a new specification for a format that is more suited to such uses? Something similar to
JSON5 or YAML. YAML is pretty cool, but people don't like/use it because (I assume):

1. It has a stupid name.
2. They don't know that JSON is valid YAML, and they dislike the significance of whitespace.
3. They're used to using JSON in other places, and a YAML parser is not always available for their language of choice.
4. JSON is simple to understand, and certain aspects of YAML can be complicated/confusing.
5. The project may appear somewhat dead, and is not used by many open source projects.
6. It is not backed by someone who is well-known in the industry (I don't think?)
7. etc.

Having a related format alongside JSON that is config-friendly would allow developers to choose the right tool for the
job.

It could be developed in stages, with later stages all being optional. For example:

Stage 1a:
    * Support for single and multi-line comments (this is an absolute must, and as you know has been requested many many
    times)
    * Whitespace preservation (good for making automated changes to config files without causing unnecessary line
    changes in VC systems)
    * Support for "directives" and a directive to set the version of the document (f.e. $version 6.1.2 – I dislike
    versioning with the file extension, like .json5)
    * A new file extension and MIME type

Stage 1b:
    * Support for most of the other things in JSON5 (unquoted keys, single quotes, trailing commas, multi-line strings,
    etc.)

Stage 2:
    * Support for a more terse syntax, similar to YAML, where braces, commas, etc. are optional if whitespace is used
    (remember, this is *optional*)

Stage 3:
    * Support for various other features like referencing existing values, schema/namespace directive, tabular format,
    import directive (import one file into another), etc.

Valid JSON would always be valid input (omitting the version directive means "attempt to parse as basic JSON"), and a
valid X document (whatever it's called) could always be written out to JSON if desired (imports expanded, version/schema
directives removed, etc.)

The format would also work well for data serialization. Both use cases would be supported (and with stage 2, it would
require less bandwidth as well).

One thing that I disagree with is the advice that extra functionality can be supported by a JSON parser without a change
in file extension. IMHO, this is not a good idea, and can lead to confusion and incompatibility. I should be able to
open any *.json file with any spec-compliant JSON parser.

Please let me know what you think.

Regards,

Glen.

[1] NPM, Bower, Composer, etc.
[2] DNX project and solution files, TypeScript config, etc.