3 ms·

I like JSON a lot more than XML for what JSON is used for. XML did have some advantages, like more standards for schemas and templating, but the JSON ecosystem

by jchw 5y ago

I like JSON a lot more than XML for what JSON is used for. XML did have some advantages, like more standards for schemas and templating, but the JSON ecosystem has at least decent facsimiles for these facilities. But the real star of the show is the data model: XML is a markup language. Jamming data structures into it is awkward. Not so for JSON, which has two aggregate types, a list type and a map type, followed by the usual suspects of primitive types: string, number, boolean, null. I can implement a full, strict, compliant JSON parser in an afternoon, maybe even less time. It is simple enough to parse that you can even do it in pure C with relative ease. XML is a lot more complex and a lot of implementations skimped pretty hard on the details. I mean I have fond memories of tinyxml2, and if you take apart any app made in the 2000s you have a good chance of finding reference to it (or on Windows-only apps, MSXML3, or on Linux, libxml...) but it certainly let you do a lot of surprising things. I saw a lot of apps doing XML documents with multiple root nodes. And Apple's plist format is a nightmare. It's so easy to fuck up interpreting XML plist, that Apple did, and it lead to one of the more entertaining privilege escalation bugs in iOS history. I have some fond memories, but I just don't miss XML. :)

skissane 5y ago
One thing I miss from XML is namespaces. Made it easy to extend an existing format with some custom extensions, with the likelihood that tools that didn't know the extensions would just ignore them, and that your extensions wouldn't conflict with anybody else's or with future versions of the underlying format. I haven't seen any widely-adopted equivalent in JSON. I've seen some proposals floating around but none of them seem to have really taken off.
- XorNot 5y ago
  God no. No one handles XML namespaces well. They are an absolute nightmare to deal with in almost every language. We already have this in JSON: add a hashmap key with a prefix. It's at least as robust provided tools do the sensible thing and ignore keys they don't care about. But as with XML, sometimes, they don't, or do, or something.
  - skissane 5y ago
    > add a hashmap key with a prefix Maybe I'm paranoid, but I worry someone else will pick the same prefix as me. If you make the prefix something like a domain name, e.g example.com:myExtension, nobody else is going to use the same prefix assuming you own example.com. That avoids the risk, but it can be a lot of typing. Whereas, if the prefix is something short and obviously meaningful (e.g "doc:"), there is a risk someone else will use the same prefix in a conflicting way. What I liked about XML namespaces is the indirection: the prefixes can be whatever you want, and then what makes them unique is the URIs they are defined to map to in each document. The one point at which I think it didn't work very well, was when people started using prefixed names in attribute values. You can't tell whether "foo:bar" is a reference to the XML namespace with prefix "foo:", or some unrelated string of "foo:bar", without looking at the schema.
    - XorNot 5y ago
      In practice though this doesn't really happen: nothing stops someone coming up with the same seemingly unique namespace URI, or using the same namespace prefix. But none of that is really the problem - the problem is that the implementations and parsing are evidently sufficiently difficult that people just don't get them right - hence the hassle. I would argue also that having indirection like this is just a negative all around - having to look elsewhere in the file to figure out what I'm looking at just creates problems, and in practice it doesn't look like this capability was ever really used - the only times I run into it are when I'm dealing with some vendor-specific implementation (that Python or Go or whatever can't handle so string-templating winds up being easier) and it turns out that what I need to have happen is to match the semantics of example XML exactly to get anything to work. Which is really the point: the extra complexity in parsing means the probability you're dealing with a broken parser shoots through the roof, at which point you've lost any advantages. Whereas with JSON, the minimum bar is arrays and maps and the basic types work. Stay within those bounds, and whatever namespacing that happens will "just work".
      - skissane 5y ago
        > nothing stops someone coming up with the same seemingly unique namespace URI If people use URLs, then DNS gives uniqueness to URLs. Of course each registrant has to enforce uniqueness within their registered domain – for a standards organisation or large software vendor, they often adopt a formal system (spreadsheet, database, naming convention, etc) for tracking which parts of the namespace under their domain name are reserved for which products/standards/etc. Of course, that relies on the vendor/organisation to do it properly – but if (e.g.) Microsoft were to create a mess by letting different Microsoft products use conflicting namespace URIs under microsoft.com, well that would be Microsoft's fault, and not the responsibility of any standard or technology to fix it. (There is still one issue–what if the domain changes ownership? Some standards, for example ISO 19770, have tried to address this by constructing namespaces based on a domain name with its registration date, so if the domain later expires and is reused by a different organisation they won't clash since they'll have a new registration date.) > the extra complexity in parsing means the probability you're dealing with a broken parser shoots through the roof A lot of that is because namespaces were added to XML later, rather than being there from the start; they are effectively an optional feature. So then you have some parsers that support them, some parsers that don't, some parsers where it depends on a flag you have to set (which may default to true or false). I guess trying to add namespaces to JSON now would encounter the same problems. But if someone was to design a new serialisation format from scratch, and had namespace support in it from day 1, I don't think these issues would happen.
- sireat 5y ago
  Namespaces in XML might be ok in theory. In practice not so much. You will curse namespaces when you encounter some XML with multiple namespaces and your favorite parser starts choking on them.
glouwbug 5y ago
> I can implement a full, strict, compliant JSON parser in an afternoon, maybe even less time. Can you really? Doesn’t look like anyone else can: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- theamk 5y ago
  If you actually look at this, the results are not nearly as bad as title suggests. There are are many parsers which perfectly parse every valid JSON document (like every Perl, Python and PHP parser and many others). They got non-perfect score because they accepted some JSON which standard says they should not have -- like a NaN value or a trailing comma. While using such parsers can potentially cause problems -- perhaps because your data generator has a bug, and your not-strict-enough parser ignores this bug -- this happens very rarely in practice.
- jchw 5y ago
  Maybe? :) I haven’t tried. I did do this one actually in an afternoon: https://github.com/pangbox/rugburn/blob/master/src/json.c https://github.com/pangbox/rugburn/blob/master/src/json.c ... but I will say that it is intentionally very limited in its API due to its intended use case and desired footprint. (And because it’s designed to compile with OpenWatcom 2 with no libc for only Win32, but those particular constraints are not very interesting for this.) I would imagine if I did try, I would have a fighting chance at making something properly strict. But I admittedly don’t know how to handle recursion in a stackless manner. Edit: specifically for C, it would be hard to do it properly unless I had access to an implementation of Clinger and Steele & White. Go would be easier since it has better floating point algorithms with strconv, but relying on C strtod/etc. is probably a bad idea due to variability. That having been said, maybe you could do Clinger in the same afternoon; I’d be worried about edge cases, but simply put, I haven’t tried.
- bjoli 5y ago
  I am not a programmer, and I have written one over the course of a week. It passed all the tests in the particular JSON test suite mentioned in the article except one, by design. It allowed bad unicode in parts of the document, because that was the data it was being fed. I am not even a programmer by profession. Anyone that can write a recursive descent parser can write a JSON parser.

by jchw 5y ago

skissane 5y ago

One thing I miss from XML is namespaces. Made it easy to extend an existing format with some custom extensions, with the likelihood that tools that didn't know the extensions would just ignore them, and that your extensions wouldn't conflict with anybody else's or with future versions of the underlying format. I haven't seen any widely-adopted equivalent in JSON. I've seen some proposals floating around but none of them seem to have really taken off.

XorNot 5y ago
God no. No one handles XML namespaces well. They are an absolute nightmare to deal with in almost every language. We already have this in JSON: add a hashmap key with a prefix. It's at least as robust provided tools do the sensible thing and ignore keys they don't care about. But as with XML, sometimes, they don't, or do, or something.
- skissane 5y ago
  > add a hashmap key with a prefix Maybe I'm paranoid, but I worry someone else will pick the same prefix as me. If you make the prefix something like a domain name, e.g example.com:myExtension, nobody else is going to use the same prefix assuming you own example.com. That avoids the risk, but it can be a lot of typing. Whereas, if the prefix is something short and obviously meaningful (e.g "doc:"), there is a risk someone else will use the same prefix in a conflicting way. What I liked about XML namespaces is the indirection: the prefixes can be whatever you want, and then what makes them unique is the URIs they are defined to map to in each document. The one point at which I think it didn't work very well, was when people started using prefixed names in attribute values. You can't tell whether "foo:bar" is a reference to the XML namespace with prefix "foo:", or some unrelated string of "foo:bar", without looking at the schema.
  - XorNot 5y ago
    In practice though this doesn't really happen: nothing stops someone coming up with the same seemingly unique namespace URI, or using the same namespace prefix. But none of that is really the problem - the problem is that the implementations and parsing are evidently sufficiently difficult that people just don't get them right - hence the hassle. I would argue also that having indirection like this is just a negative all around - having to look elsewhere in the file to figure out what I'm looking at just creates problems, and in practice it doesn't look like this capability was ever really used - the only times I run into it are when I'm dealing with some vendor-specific implementation (that Python or Go or whatever can't handle so string-templating winds up being easier) and it turns out that what I need to have happen is to match the semantics of example XML exactly to get anything to work. Which is really the point: the extra complexity in parsing means the probability you're dealing with a broken parser shoots through the roof, at which point you've lost any advantages. Whereas with JSON, the minimum bar is arrays and maps and the basic types work. Stay within those bounds, and whatever namespacing that happens will "just work".
    - skissane 5y ago
      > nothing stops someone coming up with the same seemingly unique namespace URI If people use URLs, then DNS gives uniqueness to URLs. Of course each registrant has to enforce uniqueness within their registered domain – for a standards organisation or large software vendor, they often adopt a formal system (spreadsheet, database, naming convention, etc) for tracking which parts of the namespace under their domain name are reserved for which products/standards/etc. Of course, that relies on the vendor/organisation to do it properly – but if (e.g.) Microsoft were to create a mess by letting different Microsoft products use conflicting namespace URIs under microsoft.com, well that would be Microsoft's fault, and not the responsibility of any standard or technology to fix it. (There is still one issue–what if the domain changes ownership? Some standards, for example ISO 19770, have tried to address this by constructing namespaces based on a domain name with its registration date, so if the domain later expires and is reused by a different organisation they won't clash since they'll have a new registration date.) > the extra complexity in parsing means the probability you're dealing with a broken parser shoots through the roof A lot of that is because namespaces were added to XML later, rather than being there from the start; they are effectively an optional feature. So then you have some parsers that support them, some parsers that don't, some parsers where it depends on a flag you have to set (which may default to true or false). I guess trying to add namespaces to JSON now would encounter the same problems. But if someone was to design a new serialisation format from scratch, and had namespace support in it from day 1, I don't think these issues would happen.
sireat 5y ago
Namespaces in XML might be ok in theory. In practice not so much. You will curse namespaces when you encounter some XML with multiple namespaces and your favorite parser starts choking on them.

glouwbug 5y ago

> I can implement a full, strict, compliant JSON parser in an afternoon, maybe even less time. Can you really? Doesn’t look like anyone else can: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php

theamk 5y ago
If you actually look at this, the results are not nearly as bad as title suggests. There are are many parsers which perfectly parse every valid JSON document (like every Perl, Python and PHP parser and many others). They got non-perfect score because they accepted some JSON which standard says they should not have -- like a NaN value or a trailing comma. While using such parsers can potentially cause problems -- perhaps because your data generator has a bug, and your not-strict-enough parser ignores this bug -- this happens very rarely in practice.
jchw 5y ago
Maybe? :) I haven’t tried. I did do this one actually in an afternoon: https://github.com/pangbox/rugburn/blob/master/src/json.c https://github.com/pangbox/rugburn/blob/master/src/json.c ... but I will say that it is intentionally very limited in its API due to its intended use case and desired footprint. (And because it’s designed to compile with OpenWatcom 2 with no libc for only Win32, but those particular constraints are not very interesting for this.) I would imagine if I did try, I would have a fighting chance at making something properly strict. But I admittedly don’t know how to handle recursion in a stackless manner. Edit: specifically for C, it would be hard to do it properly unless I had access to an implementation of Clinger and Steele & White. Go would be easier since it has better floating point algorithms with strconv, but relying on C strtod/etc. is probably a bad idea due to variability. That having been said, maybe you could do Clinger in the same afternoon; I’d be worried about edge cases, but simply put, I haven’t tried.
bjoli 5y ago
I am not a programmer, and I have written one over the course of a week. It passed all the tests in the particular JSON test suite mentioned in the article except one, by design. It allowed bad unicode in parts of the document, because that was the data it was being fed. I am not even a programmer by profession. Anyone that can write a recursive descent parser can write a JSON parser.