I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc
I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job.
JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format.
And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...])
I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.
The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain).
However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)
XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc.
IMO most of the problem with XML, and the reason why I hate using XML but find JSX and HTML perfectly fine, is that every XML document needs to start with some bullshit like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
or:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
It's not only verbose and extremely ugly but also impossible to remember.
I found them on a website listing the doctors for various XML-based file formats, I didn't realise it was out of date, sorry. Still, that doesn't change anything, my point stands. XML typically has horrible doctypes which are impossible to remember and ugly to look at or parse. I'm not critiquing SVG but XML after all.
Its one optional line in a header that you don't even need to use if you don't want to. But sure, lets throw out the baby with the bathwater. The fact that JSON cannot have comments is a far more serious drawback than a single line at the top of the document.
I like formats which are XML except without the <?xml?> and xmlns stuff. However, most XML I encounter does have that stuff, so it's a reason why I usually hate dealing with XML. This shouldn't be difficult to comprehend. You don't have to run defence for a file format like this.
This reads more like a case of you having left ambiguity in what exactly you disliked. And rather than defending the position, I found the reply fitting towards what it seemed like you disliked: the need for rather specific header tags. Now you've clarified it further, and it's clearer that it's not the need for header tags specifically that is the problem.
For what it's worth, I do agree that the syntax may be a tad strange. But I feel that, as with many of these issues, this is a tooling issue. Now, whether or not tooling will be made or not, for these kinds of problems, is unrelated.
As an aside, I rarely remember the HTML header tag; but that's fine, I have tooling that does it for me.
If you just use it in the browser, <svg> is all you need. The browser is smart enough to parse it as SVG based on the context (e.g. if it's embedded inside HTML, if it's linked from an <img>, or if it's served as Content-Type: image/svg+xml). And you can omit the version.
The hype curve seem to have run its course and we should prepare for the backlash against JSON.
SVG often appears embedded in HTML so it makes sense to have it use similar angle-brackets syntax. Unless they also want to recast HTML in JSON (which I’m sure someone have proposed).
Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.
I honestly disagree that YAML is human editing friendly, the rules about where the indentations should go is not intuitive. Like when you have a key/value pair where the value is a list, are the dashes indented like this:
array:
- string one
- string two
or like this:
array:
- string one
- string two
I've found that the easiest way for me to edit YAML (when I have to, which is pretty much exclusively when dealing with CI stuff) is to write it in one of those YAML -> JSON converters online.
Then that's a problem in itself: in an indentation based language where more indentation == more deeply nested, allowing multiple levels of indentation to correspond to the same level of nesting is really confusing.
I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc
I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job.
JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format.
And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...])
I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.