Hacker News Reader

Comment by brilee | Hacker News Reader

There's this structured data format called XML, and typically you put a XML schema definition at the top (example: <xs:schema xmlns:xs="http://maven.apache.org/xsd/settings-1.0.0.xsd"> for a Maven config file). XML code editors then fetch the XML schema declaration, which contains information like what fields are expected, whether those fields are repeatable, whether they are required, and so on. Java library using XML as configuration will typically have published an XSD.

Fun fact: XML schema declarations are themselves XML documents, and there exists an XSD describing allowable XSDs. https://www.w3.org/2001/XMLSchema.xsd

View on HN

I'm confident that everyone knows about XML and that you're a worse troll than I am.

Nobody contests XML's capability. It was unpleasant to write and read.

It's a troll post, but the point stands: JSON is reinventing XML.

XML is ugly, but complicated JSON isn't much better IMO. It has an only slightly less human-unfriendly syntax: Why do I have to use double quotes on keys? Why are there no comments? Then come things like schemas, queries, and transformations: XSD, XPath, and XSLT are very powerful tools. Their implementation sucks, but it's arguably better than people coming up with their own half-documented solution whenever they need something XSD/XPath/XSLT provides.

XML protects JSON: people needing extra power choose the complexity in the XML ecosystem, keeping JSON simple.

The problem is usages that grow in their need for power over time, with high switching costs. Instead of choosing, they add pressure to XMLify the JSON ecosystem.

JSON's doom seems distant but inevitable, but it will instead be defeated by the rise of yet another format.

> Why there are no comments?

Here's the answer: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

Not sure if I agree with it or not, nevertheless that was the reasoning.

JSON has huge advantages from a security perspective. The feature-richness of XML is also a richness of sources of security vulnerabilities.

Is it even possible to make a 100% standards conforming parser that is not vulnerable to at least DoS attacks?

(Automatically fetching XSDs e.g. sounds nice in practice, until you realize that it means your server will make HTTP requests to user-supplied URLs, so most parsers come with an option to disable it, which may or may not break documents relying on it.)

Json forbids comments. It makes writing it much less pleasurable than it might be.

For good reason though. From Crockford:

> 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.

via https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

I'd say "for reasons" not necessarily "good" ones. In particular, I think the jury is still out. The hacks that people have done to get comments into npm files are really quite illuminating.

It's funny. He says use a preprocessor to remove comments. Thus not using JSON. It's almost a joke. Except Microsoft does exactly that in their hip project.json format.

Double quotes everywhere are more annoying to read than end tags. If we're going to invent nonstandard formats, why not remove the redundant tag name in the XML end tag. Problem solved.

My own contribution to the world's specification bloat: luxem

https://github.com/rendaw/luxem

A perhaps lightly more rigorous specification:

https://github.com/Rendaw/luxemj/blob/master/src/main/resour...

It allows optional quotes and comments, plus trailing "," and element type specifications. I think it's easier to read and hand-write, as well as write a parser/generator.

Looks like a good take. Your readme would benefit from an example of what luxem looks like, ideally the first thing I'd see, below a short tagline, rather than having to read a lot of text and try to picture what you're describing.

What good reason? Many programming languages have tools that parse comments for various things. With that 'good reason' we should remove comments from all programming languages.

Comments wouldn't be usefull (mostly) for data sent on the wire --and JSON is quite good for that-- but for configuration files, they're indispensable. INI (like git's) is way better of a configuration format than JSON. Easier both to read and to write.

For sending things over the wire, a few way more efficient formats exist. JSON's appeal was simplicity and human-readability. The first goal is achieved OK; the second, so-so.

Is it really that sacrilegious to just put your comments inside of a parseable data format?

Python provides programmatic access to docstrings, for example, and it has many valid uses.

The raw format may be. But with a good IDE it's pretty easy. Just like, well, most computer languages actually.

We don't always have the luxury of an IDE when working on a remote machine or debugging.

Despite JSON's shortcomings, the developer community found it on the whole more pleasant to work with.

It's the same argument that Lisp users make. The two are more expressive, more capable, more safe. It's also very dense and intimidating.

You can come up with all the justifications you'd like. It won't win the hearts of developers.

Even without an IDE, it's much easier to see where a scope ends with </tag> than it is with curly braces.

JSON has JSON Schema, with similar features and some similar editor integrations; see: http://json-schema.org

Now we just need jslt and we've come full circle.

afraid to google in case its actually a thing... :P

http://ajaxian.com/archives/jslt-a-javascript-alternative-to...

XML is the best way to communicate 20 characters worth of information using 1000.

It's certainly second to any Bootstrap&JQuery based website.

Quick, 1998 is calling.

"Old = bad" is not an argument against XML, or any technology for that matter.

Indeed, XML-RPC is surprisingly good protocol to this day. The only three non-unimportant issues with it are (a) verbose XML (which was common back then), (b) lack of null/none/nil tag, and (c) lack of named arguments (very uncommon back then).

Reply on news.ycombinator.com