4 ms·

Come on. Any one of us could write a JSON parser in a page of code. An XML parser is significantly more work due to the overcomplexness of XML. Both to write, a

by axod 17y ago

Come on. Any one of us could write a JSON parser in a page of code. An XML parser is significantly more work due to the overcomplexness of XML. Both to write, and for the CPU to run. And it's larger. In fact I'm struggling to think of something XML has that is good. (And please no one respond with "it's extensible" or I may explode). An XML parser has to track open tag names, with JSON it doesn't matter. XML has all stupid entities like & which look ugly and need to be parsed. I think "time to write a parser" should be a good metric on how sane a data format is. The fact that writing an XML parser that covers all bases/eventualities is a major undertaking says alot about the data format.

tptacek 17y ago
You know, I know we're just geeking out here so please don't read too much into me taking the devil's advocate position, but: yes, XML is harder to parse, but the underlying data that gets encoded in JSON and XML isn't substantially different. In both cases --- and let's take the C implementation case --- you're still building a poorly specified buggy implementation of Tcl to actually hold the data and answer questions about it. That's the point I'm trying to make.
- jbooth 17y ago
  Dunno why you got downmodded there.. Anyways, if they're equivalent, and JSON is both easier to parse and has a far higher data density.. why would anyone ever use XML for anything?
  - eru 17y ago
    Three-legged races are fun.
  - uriel 17y ago
    > why would anyone ever use XML for anything? I ask myself that every day. XML is a huge scam perpetrated on the software industry, but now it is too late because a huge parasitic 'industry' has built around it, and too many people (specially too many PHBs) have invested their reputations on XML being the ultimate standard for representing data.
- axod 17y ago
  Can you explain what is lacking in JSON? What is poorly specified or buggy?
jerf 17y ago
XML brings a lot of other baggage to the party. Some of it can be useful. I particularly like XML namespaces, because when used properly there's hardly an equivalent in any other standardized serialization format I know. (And part of the problem is that you really need it standardized at the serialization format level for it to work; you can hack things into any other format but by definition you're not doing it in a standard way.) However, that statement should be understood through the filter of the fact that I've only seen one thing that uses XML namespaces properly, and that's XHTML. Everything else I've seen gets it wrong, and that includes most things trying to deal with XHTML.... You also get a "free" and modestly powerful validation system, a serialization format that has seriously thought through encoding issues and has answer for them (JSON does too, but a lot of other fly-by-night stuff doesn't), a fairly powerful format for tagged text (JSON-tagged text is a hack no matter how you slice it). You also get XSL, which floats some people's boats, though I wouldn't be caught dead working in it. If you don't need any of that, don't use it. I don't very often. But when you need it, do. Also: "An XML parser has to track open tag names, with JSON it doesn't matter." This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage. "XML has all stupid entities like & which look ugly and need to be parsed." This is equivalent to the escape sequences in JSON: http://json.org/string.gif http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that.
- axod 17y ago
  >> This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage. JSON can simply count brackets. That makes for a very simple parser indeed. XML needs to cope with invalid nesting, end tag names not matching start tag names etc. End tag names are just wasted space. >> This is equivalent to the escape sequences in JSON: http://json.org/string.gif http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that. But those are sane. We all escape double quotes and backslashes in pretty much every programming language. They make sense in a very simple encoding. Why should I need to replace & with %amp; they seem arbitrary, and the replacements aren't simple. " ?? seriously? you're naming characters with odd abreviations, and then expecting people to remember those? why not just escape them with a prefix such as erm.... "\"

by axod 17y ago

tptacek 17y ago

You know, I know we're just geeking out here so please don't read too much into me taking the devil's advocate position, but: yes, XML is harder to parse, but the underlying data that gets encoded in JSON and XML isn't substantially different. In both cases --- and let's take the C implementation case --- you're still building a poorly specified buggy implementation of Tcl to actually hold the data and answer questions about it. That's the point I'm trying to make.

jbooth 17y ago
Dunno why you got downmodded there.. Anyways, if they're equivalent, and JSON is both easier to parse and has a far higher data density.. why would anyone ever use XML for anything?
- eru 17y ago
  Three-legged races are fun.
- uriel 17y ago
  > why would anyone ever use XML for anything? I ask myself that every day. XML is a huge scam perpetrated on the software industry, but now it is too late because a huge parasitic 'industry' has built around it, and too many people (specially too many PHBs) have invested their reputations on XML being the ultimate standard for representing data.
axod 17y ago
Can you explain what is lacking in JSON? What is poorly specified or buggy?

jerf 17y ago

XML brings a lot of other baggage to the party. Some of it can be useful. I particularly like XML namespaces, because when used properly there's hardly an equivalent in any other standardized serialization format I know. (And part of the problem is that you really need it standardized at the serialization format level for it to work; you can hack things into any other format but by definition you're not doing it in a standard way.) However, that statement should be understood through the filter of the fact that I've only seen one thing that uses XML namespaces properly, and that's XHTML. Everything else I've seen gets it wrong, and that includes most things trying to deal with XHTML.... You also get a "free" and modestly powerful validation system, a serialization format that has seriously thought through encoding issues and has answer for them (JSON does too, but a lot of other fly-by-night stuff doesn't), a fairly powerful format for tagged text (JSON-tagged text is a hack no matter how you slice it). You also get XSL, which floats some people's boats, though I wouldn't be caught dead working in it. If you don't need any of that, don't use it. I don't very often. But when you need it, do. Also: "An XML parser has to track open tag names, with JSON it doesn't matter." This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage. "XML has all stupid entities like & which look ugly and need to be parsed." This is equivalent to the escape sequences in JSON: http://json.org/string.gif http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that.

axod 17y ago
>> This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage. JSON can simply count brackets. That makes for a very simple parser indeed. XML needs to cope with invalid nesting, end tag names not matching start tag names etc. End tag names are just wasted space. >> This is equivalent to the escape sequences in JSON: http://json.org/string.gif http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that. But those are sane. We all escape double quotes and backslashes in pretty much every programming language. They make sense in a very simple encoding. Why should I need to replace & with %amp; they seem arbitrary, and the replacements aren't simple. " ?? seriously? you're naming characters with odd abreviations, and then expecting people to remember those? why not just escape them with a prefix such as erm.... "\"