4 ms·

What about Zish? It's like JSON but with comments, a timestamp type, a decimal type and a bytes type: https://github.com/tlocke/zish https://github.com/tlocke/

by tlocke 9y ago

What about Zish? It's like JSON but with comments, a timestamp type, a decimal type and a bytes type: https://github.com/tlocke/zish https://github.com/tlocke/zish (as the author, I'm biased)

billpg 9y ago
My unsolicited comments. I really want to see a good JSON-done-right out there and your spec is maybe 90% there. I'd rather only /* */ comments were allowed. By allowing //, you've now got two varieties of white-space the parser needs to be aware of. Because of this, I can't take multiple lines of ZISH and join them together into a single line. (Something both JSON and XML can do.) What is a "line"? CR, LF, CRLF, LFCR, FF, VT, U+0085, U+2028, U+2029? Am I required to treat ZISH files as "binary"? Could I convert all of those end-of-line bytes into my OS's preferred form without losing data? The notation of ending a line with a \ also prevents joining multiple lines into a single line. Maybe formalize "string"+"string" as an explicit string joining notation? (Or if not +, some other character to notate string concatenation.) Given you have the decimal type, is float necessary? Values with a "e" are still expressed with decimal digits. Is there a limit to numeric types? What if my ZISH file contained a several hundred 9s in a row? Sets seems unnecessary given you already have lists. You can take a list and treat it as a set after parsing with no loss of data. I very much like the addition of timestamps and binary without needing a string. This is my big pet peeve of JSON. Your examples include uses of null and true, but your spec doesn't define those values. (Or false for that matter.) The description of map doesn't specify if the order of keys is significant. Is {"a":"b", "c":"d"} the same as {"c":"d", "a":"b"} ?
- tlocke 9y ago
  This is quite brilliant, thanks billpg. I'm also amazingly grateful that someone's taken an interest in Zish :-) These questions will all require some thought to properly understand and respond to, with no-doubt some changes to the spec. So I've opened an issue and put the comment at: https://github.com/tlocke/zish/issues/2 https://github.com/tlocke/zish/issues/2
- Flenser 9y ago
  Sets could be reordered to improve compression. Not a big benefit but it would depend on your data.

by tlocke 9y ago

What about Zish? It's like JSON but with comments, a timestamp type, a decimal type and a bytes type: https://github.com/tlocke/zish https://github.com/tlocke/zish (as the author, I'm biased)

billpg 9y ago

My unsolicited comments. I really want to see a good JSON-done-right out there and your spec is maybe 90% there. I'd rather only /* */ comments were allowed. By allowing //, you've now got two varieties of white-space the parser needs to be aware of. Because of this, I can't take multiple lines of ZISH and join them together into a single line. (Something both JSON and XML can do.) What is a "line"? CR, LF, CRLF, LFCR, FF, VT, U+0085, U+2028, U+2029? Am I required to treat ZISH files as "binary"? Could I convert all of those end-of-line bytes into my OS's preferred form without losing data? The notation of ending a line with a \ also prevents joining multiple lines into a single line. Maybe formalize "string"+"string" as an explicit string joining notation? (Or if not +, some other character to notate string concatenation.) Given you have the decimal type, is float necessary? Values with a "e" are still expressed with decimal digits. Is there a limit to numeric types? What if my ZISH file contained a several hundred 9s in a row? Sets seems unnecessary given you already have lists. You can take a list and treat it as a set after parsing with no loss of data. I very much like the addition of timestamps and binary without needing a string. This is my big pet peeve of JSON. Your examples include uses of null and true, but your spec doesn't define those values. (Or false for that matter.) The description of map doesn't specify if the order of keys is significant. Is {"a":"b", "c":"d"} the same as {"c":"d", "a":"b"} ?

tlocke 9y ago
This is quite brilliant, thanks billpg. I'm also amazingly grateful that someone's taken an interest in Zish :-) These questions will all require some thought to properly understand and respond to, with no-doubt some changes to the spec. So I've opened an issue and put the comment at: https://github.com/tlocke/zish/issues/2 https://github.com/tlocke/zish/issues/2
Flenser 9y ago
Sets could be reordered to improve compression. Not a big benefit but it would depend on your data.