3 ms·

I don't understand the complant that JSON doesn't support a date/time format. It supports numbers and strings. You can use unix timestamps, you can use ISO 860

by ripter 14y ago

I don't understand the complant that JSON doesn't support a date/time format. It supports numbers and strings. You can use unix timestamps, you can use ISO 8601, you can use any format that makes sense for your application. JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. Now if you want to complain that the JSON parsers don't automatically convert ISO 8601 dates into Date/Time objects, I understand. To me 50% less bullshit means 50% less typing and maybe getting something wrong. JSON is easy to read and write by hand, which happens a lot. XPath/XQuery and XSLT are nightmares in my opinion. I'd much rather type `Foo.bar` or `_.each(Foo.items, function(item) {...})` and be able to easily debug when something goes wrong.

emn13 14y ago
Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex. I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good). Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist. Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.
corresation 14y ago
JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. XML doesn't support objects, but there was enough thought put into the implementation that it has an easy way to document and define the types, with validated ways of representation. ISO 8601 for the xsd:dateTime, for instance. There is no ambiguity or uncertainty, no hand-rolled varieties of crazy, quite unlike JSON world where there are a hundred ways to represent a date or date/time, all of them broken in some way or other.

by ripter 14y ago

emn13 14y ago

Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex. I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good). Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist. Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.

corresation 14y ago

JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. XML doesn't support objects, but there was enough thought put into the implementation that it has an easy way to document and define the types, with validated ways of representation. ISO 8601 for the xsd:dateTime, for instance. There is no ambiguity or uncertainty, no hand-rolled varieties of crazy, quite unlike JSON world where there are a hundred ways to represent a date or date/time, all of them broken in some way or other.