The Fixing-JSON Conversation
tbray.org
The Fixing-JSON Conversation
1–10 of 55 posts
Re: The Fixing-JSON Conversation
#2He summarized the most upvoted posts from the last thread [1] really well.
[1] https://news.ycombinator.com/item?id=12328088
Regarding datetimes, it's worth pointing out the conversation that TOML had about it. It's a pretty long read [2][3][4][5] with lots of points raised for and against, but it also shows some of the process of how consensus was eventually forged: through trial-and-error, some enlightening realizations, expert opinions, and a willingness to leave some aspects of the behavior it up to parser, to avoid requiring all other languages to reimplement half of Java 8 Time.
[2] https://github.com/toml-lang/toml/pull/414
[3] https://github.com/toml-lang/toml/pull/362
[4] https://github.com/toml-lang/toml/issues/412
[5] https://github.com/toml-lang/toml/issues/263
The salient point being that RFC 3339 does not in truth describe exactly one datatype, so you can't just reference the spec and hope everyone reads it the same way. EDIT: Specifically, RFC 3339 says:
"Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.", but then goes on to define [6] a number of different syntaxes in ABNF, to indicate the subsets of ISO 8601 that "SHOULD be used in new protocols on the Internet." It essentially never defines what a 'valid' RFC 3339 object looks like, it doesn't explicitly say which ones are considered complete representations, so it's not clear if, say, '2016' is a valid RFC 3339 object... but the ones towards the bottom contain more than one discrete term, and can be presumed to be 'complete' representations. These are:
[A] partial-time: HH:MM:SS(.SSS)
[B] full-date: YYYY-MM-DD
[C] full-time: 'partial-time' +/- offsetFromUTC(HH:MM)
[D] date-time: 'full-date' "T" 'full-time'
Out of these, [D] is clearly a timestamp of an absolute instant in time, but the rest are debatable.
Re: The Fixing-JSON Conversation
#3Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can change retroactively. The only reliable time stamp is UTC without leap seconds. (Speaking of leap seconds, who thought seconds going from 0 - 60 rather than 0 - 59 was a good idea?)
Accurate time is one of the most difficult things to model in computer science.
Re: The Fixing-JSON Conversation
#4Personally, I would really like to see integer object keys (as opposed to only string keys). For simple numeric transformations, strings feel really heavy and require annoying conversion in languages. E.g. {"10": 60, "42": 2}.
Re: The Fixing-JSON Conversation
#5Personally, I would really like to see integer object keys (as opposed to only string keys). For simple numeric transformations, strings feel really heavy and require annoying conversion in languages. E.g. {"10": 60, "42": 2}.
The flipside is that an integer-keyed map is similar in meaning to an array, which associates by virtue of placement, an integer with the value sitting at that index.
While it's possible to spec it to forbid this interpretation, Lua has made this interpretation a language feature, and it'd become impossible to construct an unambigous parser/printer in Lua for this new format.
Re: The Fixing-JSON Conversation
#6JSON (for the most part) is a nice format to work with, aside from loosely defined datetimes as mention.
The two areas where I believe the format can greatly be improved; 1# having a standard to define the structure (sometimes schemas can be handy!); 2# a stranded binary format, yes right now with have UBJSON (which doesn't have a date format, this is worse in binary) and BSON (which contains some MongoDB specific stuff).
I'm not saying they don't have their place, but.. Protocol Buffers are more akeen to .net or Java serialization, in the they're quite fragile if used with different versions and/ or with different vendors.
Re: The Fixing-JSON Conversation
#7SDLang !!!! : https://sdlang.org/
Full example : https://github.com/Abscissa/SDLang-D/wiki/Language-Guide#exa...
Examples:
Creating a Tree
plants {
trees {
deciduous {
elm
oak
}
}
}
myMatrix {
4 2 5
2 8 2
4 2 1
}
folder "myFiles" color="yellow" protection=on {
folder "my images" {
file "myHouse.jpg" color=true date=2005/11/05
file "myCar.jpg" color=false date=2002/01/05
}
folder "my documents" {
document "resume.pdf"
}
}
# create a tag called "date" with a date value of Dec 5, 2005
date 2005/12/05
# a date time literal without a timezone
here 2005/12/05 14:12:23.345
# a date time literal with a timezone
in_japan 2005/12/05 14:12:23.345-JSTRe: The Fixing-JSON Conversation
#8JSON (for the most part) is a nice format to work with, aside from loosely defined datetimes as mention. The two areas where I believe the format can greatly be improved; 1# having a standard to define the structure (sometimes schemas can be handy!); 2# a stranded binary format, yes right now with have UBJSON (which doesn't have a date format, this is worse in binary) and BSON (which contains some MongoDB specific st…
MessagePack is better supported than UBJSON and has far more implementations in almost every language.
JSON Schema draft 4 is the defacto schema standard for JSON.
http://json-schema.org/latest/json-schema-core.html
Having used both XML schema and this one, I much prefer using JSON schema.
Re: The Fixing-JSON Conversation
#9I think now is a good time to re-quote the man himself... Douglas Crockford..
https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.Re: The Fixing-JSON Conversation
#10Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can…
Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value.
This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM
Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types.
(If you just use "civil time + offset from UTC" like RFC 3339 does, then you can convert it to an absolute time, but you can convert only that one specific value using that offset, and not any other - i.e. that offset is not a substitute for an actual timezone identifier.)