4 ms·

I would mention date and time. XML has them standardized, see xs:dateTime, xs:time, xs:date. In JSON everyone is inventing their own incompatible representation

I would mention date and time. XML has them standardized, see xs:dateTime, xs:time, xs:date. In JSON everyone is inventing their own incompatible representation, can be various ISO string formats, or various numbers (seconds, milliseconds, etc) from some epoch, look at that mess: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoch_dates_in_computing https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc... C# has XmlReader and XmlWriter classes in the standard library. Technically they are not event based, but conceptually they’re pretty close to SAX, i.e. they implement streaming forward-only parser, and streaming producer.

tasogare 6y ago
C# also has Linq to Xml and the XDocument et al. classes which are a nice way of reading / writing XML. I personally like XML. It’s a bit on the verbose side, but that makes is way more easy to figure out the position in the tree than it is in JSON. It is also more easily extensible thanks to attributes and namespaces. It supports comments which is mandatory for any configuration format for obvious reasons. It has powerfull transformation engine as well as schema capabilities. JSON schema keep producing new draft of its spec, yet the result is not on par with XML, and more painful to write. I’d like for XML to make a come back, not as the behemoth it was once, but for case it makes sense, and configuration files is definitely one of those.
- Const-me 6y ago
  > Linq to Xml and the XDocument et al. classes Yep, pretty sure the OP meant just them when they placed that green icon in the DOM column and C# row. However, the red cross icon in the table says SAX is missing in C#.
roenxi 6y ago
> ...everyone is inventing their own incompatible representation, can be various ISO string formats... If only we had some sort of international body to standardise these representations. This and the original articles "JSON has no comments [and this is how you do a comment in JSON]" undermine the complaint on a technical basis. String with an ISO standard datetime is perfectly reasonable. And quite standard. Use UTC+0 where possible.
- tingletech 6y ago
  CCYY-Www-dd and CCYY-ddd are part of the same ISO "standard" that CCYY-MM-dd are from
- Const-me 6y ago
  > String with an ISO standard datetime is perfectly reasonable The standard defines more than one format. Another thing, because it’s not on the spec, people went creative. It’s too late to fix I’m afraid, some widely used APIs already have these seconds in their JSONs.
  - dragonwriter 6y ago
    The same thing happened with XML, XML Schema and it's datatype support was after the fact of XML popularity, same as JSON Schema, which already solves this for JSON where adopted, with respect to JSON. While adoption takes time, the fact that you don't even realize that XML had this problem (far worse than JSON with dates) demonstrates that it's not too late for JSON schema to solve it for JSON.
    - Const-me 6y ago
      > demonstrates that it's not too late Back in nighties' and early 2000-s the landscape was different. Now there're too many internet connected things that aren't a PC (phones, tablets, home appliance, cars, etc.) who run native code which consumes these JSON APIs. Some of these things aren't upgradeable, many of them aren't easily upgradeable.
- SamWhited 6y ago
  The problem isn't that there is no standard date time format, it's that there is no standard way to represent the standard date time formats (plural) in a JSON document.
dragonwriter 6y ago
> XML has them standardized, XML Schema, a separate and later layer on top does. > In JSON everyone is inventing their own incompatible representation JSON Schema, like XML Schema, does in fact specify standard time, date, and datetime types and their representation.

tasogare 6y ago

C# also has Linq to Xml and the XDocument et al. classes which are a nice way of reading / writing XML. I personally like XML. It’s a bit on the verbose side, but that makes is way more easy to figure out the position in the tree than it is in JSON. It is also more easily extensible thanks to attributes and namespaces. It supports comments which is mandatory for any configuration format for obvious reasons. It has powerfull transformation engine as well as schema capabilities. JSON schema keep producing new draft of its spec, yet the result is not on par with XML, and more painful to write. I’d like for XML to make a come back, not as the behemoth it was once, but for case it makes sense, and configuration files is definitely one of those.

Const-me 6y ago
> Linq to Xml and the XDocument et al. classes Yep, pretty sure the OP meant just them when they placed that green icon in the DOM column and C# row. However, the red cross icon in the table says SAX is missing in C#.

roenxi 6y ago

> ...everyone is inventing their own incompatible representation, can be various ISO string formats... If only we had some sort of international body to standardise these representations. This and the original articles "JSON has no comments [and this is how you do a comment in JSON]" undermine the complaint on a technical basis. String with an ISO standard datetime is perfectly reasonable. And quite standard. Use UTC+0 where possible.

tingletech 6y ago
CCYY-Www-dd and CCYY-ddd are part of the same ISO "standard" that CCYY-MM-dd are from
Const-me 6y ago
> String with an ISO standard datetime is perfectly reasonable The standard defines more than one format. Another thing, because it’s not on the spec, people went creative. It’s too late to fix I’m afraid, some widely used APIs already have these seconds in their JSONs.
- dragonwriter 6y ago
  The same thing happened with XML, XML Schema and it's datatype support was after the fact of XML popularity, same as JSON Schema, which already solves this for JSON where adopted, with respect to JSON. While adoption takes time, the fact that you don't even realize that XML had this problem (far worse than JSON with dates) demonstrates that it's not too late for JSON schema to solve it for JSON.
  - Const-me 6y ago
    > demonstrates that it's not too late Back in nighties' and early 2000-s the landscape was different. Now there're too many internet connected things that aren't a PC (phones, tablets, home appliance, cars, etc.) who run native code which consumes these JSON APIs. Some of these things aren't upgradeable, many of them aren't easily upgradeable.
SamWhited 6y ago
The problem isn't that there is no standard date time format, it's that there is no standard way to represent the standard date time formats (plural) in a JSON document.

dragonwriter 6y ago

> XML has them standardized, XML Schema, a separate and later layer on top does. > In JSON everyone is inventing their own incompatible representation JSON Schema, like XML Schema, does in fact specify standard time, date, and datetime types and their representation.