aqua VS json5-spec

Instead I use https://github.com/aquaproj/aqua.

In this post, I describe the update of aqua in 2022.

Aqua is a packaging tool that I'm testing out. Very interesting conceptually, and if you like chezmoi (I use it, too), then I think you'll find it worth a peek.

$ aqua init $ aqua g -i mitchellh/gox $ cat aqua.yaml --- # aqua - Declarative CLI Version Manager # https://aquaproj.github.io/ registries: - type: standard ref: v2.19.0 # renovate: depName=aquaproj/aqua-registry packages: - name: mitchellh/[email protected] $ aqua i INFO[0000] create a symbolic link aqua_version=1.9.0 env=darwin/arm64 link_file=/Users/shunsukesuzuki/.local/share/aquaproj-aqua/bin/gox new=aqua-proxy package_name=mitchellh/gox package_version=v1.0.1 program=aqua registry=standard registry_ref=v2.19.0 INFO[0000] download and unarchive the package aqua_version=1.9.0 env=darwin/arm64 package_name=mitchellh/gox package_version=v1.0.1 program=aqua registry=standard registry_ref=v2.19.0 INFO[0000] building Go tool aqua_version=1.9.0 env=darwin/arm64 exe_path=/Users/shunsukesuzuki/.local/share/aquaproj-aqua/pkgs/go/github.com/mitchellh/gox/v1.0.1/bin/gox file_name=gox go_build_dir=/Users/shunsukesuzuki/.local/share/aquaproj-aqua/pkgs/go/github.com/mitchellh/gox/v1.0.1/src/gox-1.0.1 go_src=. package_name=mitchellh/gox package_version=v1.0.1 program=aqua registry=standard registry_ref=v2.19.0 go: downloading github.com/hashicorp/go-version v1.0.0 go: downloading github.com/mitchellh/iochan v1.0.0

For the version control, we recommend aqua.

One of the larger issues I've run into is duplicates. Douglas Crockford, JSON's inventor, tried to fix the duplicate issue but it was decided it was too late. Although Douglas Crockford couldn't change the spec forcing all implementations to error on duplicate, his Java JSON implementation errors on duplicates. Others use last-value-wins, support duplicate keys, or other non-standard behavior. The JSON RFC states that implementations should not allow duplicate keys, notes the varying behavior of existing implementations, and states that when names are not unique, "the behavior of software that receives such an object is unpredictable." Duplicate fields are a security issue, a source of bugs, and a surprising behavior to users. See the article, "An Exploration of JSON Interoperability Vulnerabilities" Disallowing duplicates conforms to the small I-JSON RFC, which is a stricter JSON. The author of I-JSON, Tim Bray, is also the author of JSON RFC 8259. See also the JSON5 duplicate issue.

Virtually any sequence is not the same as adopting a specification five years after it’s been published and adopted by industry: https://spec.json5.org/

I appreciate that SQLite can’t write the format, because those changes are human afordances

That's why you pick a superset of JSON that already has some adoption, like JSON5: https://spec.json5.org/

The "dual" standard RFC 8259 [1] (both are normative standards under their respective bodies, ECMA and IETF) is also a useful comparison here. It's wording is a bit stronger than ECMA's, though not by much. ("Good interoperability" is its specific call out.)

It's also interesting that the proposed JSON 5 (standalone) specification [2] doesn't seem to address it at all (but does add back in the other IEEE 754 numbers that ECMA 404 and RFC 8259 exclude from JSON; +/-Infinity and +/-NaN). It both maintains that its numbers are "arbitrary precision" but also requires these few IEEE 754 features, which may be even more confusing than either ECMA 404 or RFC 8259.

[1] https://datatracker.ietf.org/doc/html/rfc8259#section-6

[2] https://spec.json5.org/#numbers

For anyone coming back to this, I just wrote a small proposal to define JSON5 duplicate object name behavior. I'd love any support on the issue:

https://github.com/json5/json5-spec/issues/38