4 ms·

because JSON is in the following sense "universal": every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-in

by Garlef 1mo ago

because JSON is in the following sense "universal": every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON and that's pretty much the barebones you need for a configuration language (of course you can argue about the syntax)

stagas 1mo ago
Lack of comments is pretty big though for a human editable config.
- dd8601fn 1mo ago
  It’s just one person’s opinion, but I think two things are true enough, here… 1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch. 2) If you insist that someone manually edit a significant amount of it, you kinda fucked up. Just my opinion, but it feels like two separate things.
- krapp 1mo ago
  JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing. <whispers>but Lua tables are even better.</whispers>
- arcanemachiner 1mo ago
  You can always use JSONC or JSON5.
- 6510 1mo ago
  I just put them in as values. In a GUI I sometimes render them as a editable textarea.
deaf_coder 1mo ago
It's so simple and straightforward, and that's why Douglas Crockford claims he "discovered" it, rather than invented it.
zzo38computer 1mo ago
That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN). ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used). I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).
- pseudohadamard 1mo ago
  Do you have the details of ASN.1X posted somewhere? Would be interesting to see what you've done with it, particularly after the ASN.1 standards folks came up with a mechanism that requires you rebuild your brain inside out in order to understand it.
  - zzo38computer 1mo ago
    I do not use the ASN.1 schema format, and have not written a specification for how the new ASN.1X features would be used in the ASN.1 schema format, although someone who is interested to do so might be able to help to write such a thing. (An alternative might be to make up a different schema format for use with ASN.1X.) ASN.1X is mostly just a list of additional types, although there is also another serialization format called SDER which is between BER and DER (any valid DER is also valid SDER and any valid SDER is also valid BER), and is intended for when you do not quite need a canonical form but still want the simplicity of DER; one of the things that it allows is overlong length encodings (which is useful when the encoder wants to encode items to a file individually but then go back to encode the length afterward). The additional types include: - UTF-16 string: Same as BMP string but non-BMP characters are also allowed (as surrogate pairs). The type number is the same as BMP string. - OBJECT IDENTIFIER RELATIVE TO: Either a absolute or a relative object identifier; what it is relative to might be either fixed or given elsewhere in the data, depending on the schema. This is equivalent to a type given in the appendix of the official specification of ASN.1, except that it is now a standardized type, and the canonical form (even in SDER, so that a reader does not need to check for both cases) is required to use the relative format if possible. - BCD string (64): A string of 4-bit characters, with the high nybble first in each byte. The characters come from the character set 0 1 2 3 4 5 6 7 8 9 * # + - . space and it should be padded with a space on the end if necessary. - PC string (65): A string of characters in the PC character set (or a related character set in some cases). Note that control characters can also be used as graphic characters. - TRON string (66): A string of TRON characters, encoded as TRON-8. - Key/value list (67): A set of keys (without duplicates) with associated values. The keys and values can be any type allowed by the schema. In canonical form, they must be sorted by keys in the same order that a SET is sorted (but the values are kept with the corresponding keys). (This is the only one of these nonstandard types which is used for representing JSON data; all of the other JSON types correspond to standard ASN.1 types.) - Out of band (72): The format and usage of this type depends on the communication channel being used, and is intended for including things inside of the ASN.1X data which is separate from the ASN.1X data, such as file descriptors. This type is not intended for storage in files, and some programs that relay messages may need special handling of this type if it is used (for this reason, it should not be IMPLICIT). - Reference (74): A reference to another node within the same file (schemas may restrict which nodes can be referenced). The encoding is like a relative OID but the first number is how many times to go to the parent node (0 means the reference itself), and then the rest of the numbers are the zero-based index into the node referenced by the previous number. - Identified data (75): Contains a set, followed by the payload (of any type), followed by an optional key/value list where the keys are OIDs. The set is used to identify the format, and it can contain OIDs, object descriptors (only expected to be used in error messages and stuff like that), and sequences who first element is a OID; and should not have duplicates. This type may be used as the top-level type in a file in order to identify the file format, but can also be used inside of the file in case the existing types are considered to be insufficient for this purpose. - Rational number (76): Contains two integers, being the numerator and denominator. The denominator must be greater than zero. If it is canonical form, then it must be lowest terms. - Translation list (77): A key/value list where the keys specify the languages (null means the default), and is expected to be used where it could be replaced by the appropriate value according to the l10n. - Scientific number (78): Same as a real number except that the number of digits (or bits) is considered to be significant. Decimal numbers must be NR3, and if it is canonical form then there must be exactly one digit before the dot. There are also additional situations where the standard ASN.1 schema format does not seem to specify (although as I mentioned above, there is currently no standardized schema format for these things), such as: regular expressions for octet strings (and bit strings), constraining types as though it is another type (e.g. limiting a UTF-8 string to a number of bytes instead of (or in addition to) code points), constraints about what control characters are allowed in a General string (I think it is rarely useful to allow all control characters), etc. (Also, I disagree with the standard recommendation to use automatic tags; I think that manual tags are better and make both the schema and the data files clearer and easier to understand.)

by Garlef 1mo ago

stagas 1mo ago

Lack of comments is pretty big though for a human editable config.

dd8601fn 1mo ago
It’s just one person’s opinion, but I think two things are true enough, here… 1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch. 2) If you insist that someone manually edit a significant amount of it, you kinda fucked up. Just my opinion, but it feels like two separate things.
krapp 1mo ago
JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing. <whispers>but Lua tables are even better.</whispers>
arcanemachiner 1mo ago
You can always use JSONC or JSON5.
6510 1mo ago
I just put them in as values. In a GUI I sometimes render them as a editable textarea.

deaf_coder 1mo ago

It's so simple and straightforward, and that's why Douglas Crockford claims he "discovered" it, rather than invented it.

zzo38computer 1mo ago

That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN). ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used). I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).

pseudohadamard 1mo ago
Do you have the details of ASN.1X posted somewhere? Would be interesting to see what you've done with it, particularly after the ASN.1 standards folks came up with a mechanism that requires you rebuild your brain inside out in order to understand it.
- zzo38computer 1mo ago
  I do not use the ASN.1 schema format, and have not written a specification for how the new ASN.1X features would be used in the ASN.1 schema format, although someone who is interested to do so might be able to help to write such a thing. (An alternative might be to make up a different schema format for use with ASN.1X.) ASN.1X is mostly just a list of additional types, although there is also another serialization format called SDER which is between BER and DER (any valid DER is also valid SDER and any valid SDER is also valid BER), and is intended for when you do not quite need a canonical form but still want the simplicity of DER; one of the things that it allows is overlong length encodings (which is useful when the encoder wants to encode items to a file individually but then go back to encode the length afterward). The additional types include: - UTF-16 string: Same as BMP string but non-BMP characters are also allowed (as surrogate pairs). The type number is the same as BMP string. - OBJECT IDENTIFIER RELATIVE TO: Either a absolute or a relative object identifier; what it is relative to might be either fixed or given elsewhere in the data, depending on the schema. This is equivalent to a type given in the appendix of the official specification of ASN.1, except that it is now a standardized type, and the canonical form (even in SDER, so that a reader does not need to check for both cases) is required to use the relative format if possible. - BCD string (64): A string of 4-bit characters, with the high nybble first in each byte. The characters come from the character set 0 1 2 3 4 5 6 7 8 9 * # + - . space and it should be padded with a space on the end if necessary. - PC string (65): A string of characters in the PC character set (or a related character set in some cases). Note that control characters can also be used as graphic characters. - TRON string (66): A string of TRON characters, encoded as TRON-8. - Key/value list (67): A set of keys (without duplicates) with associated values. The keys and values can be any type allowed by the schema. In canonical form, they must be sorted by keys in the same order that a SET is sorted (but the values are kept with the corresponding keys). (This is the only one of these nonstandard types which is used for representing JSON data; all of the other JSON types correspond to standard ASN.1 types.) - Out of band (72): The format and usage of this type depends on the communication channel being used, and is intended for including things inside of the ASN.1X data which is separate from the ASN.1X data, such as file descriptors. This type is not intended for storage in files, and some programs that relay messages may need special handling of this type if it is used (for this reason, it should not be IMPLICIT). - Reference (74): A reference to another node within the same file (schemas may restrict which nodes can be referenced). The encoding is like a relative OID but the first number is how many times to go to the parent node (0 means the reference itself), and then the rest of the numbers are the zero-based index into the node referenced by the previous number. - Identified data (75): Contains a set, followed by the payload (of any type), followed by an optional key/value list where the keys are OIDs. The set is used to identify the format, and it can contain OIDs, object descriptors (only expected to be used in error messages and stuff like that), and sequences who first element is a OID; and should not have duplicates. This type may be used as the top-level type in a file in order to identify the file format, but can also be used inside of the file in case the existing types are considered to be insufficient for this purpose. - Rational number (76): Contains two integers, being the numerator and denominator. The denominator must be greater than zero. If it is canonical form, then it must be lowest terms. - Translation list (77): A key/value list where the keys specify the languages (null means the default), and is expected to be used where it could be replaced by the appropriate value according to the l10n. - Scientific number (78): Same as a real number except that the number of digits (or bits) is considered to be significant. Decimal numbers must be NR3, and if it is canonical form then there must be exactly one digit before the dot. There are also additional situations where the standard ASN.1 schema format does not seem to specify (although as I mentioned above, there is currently no standardized schema format for these things), such as: regular expressions for octet strings (and bit strings), constraining types as though it is another type (e.g. limiting a UTF-8 string to a number of bytes instead of (or in addition to) code points), constraints about what control characters are allowed in a General string (I think it is rarely useful to allow all control characters), etc. (Also, I disagree with the standard recommendation to use automatic tags; I think that manual tags are better and make both the schema and the data files clearer and easier to understand.)