3 ms·

Yeah, but the downside to doing that with XML is it's frickin crazy. I have to parse this whole thing into memory and then pull out the part I want? The CPU i

by jbooth 17y ago

Yeah, but the downside to doing that with XML is it's frickin crazy. I have to parse this whole thing into memory and then pull out the part I want? The CPU is spending more time dealing with XML than it is doing useful work. If it's a big file, this is very significant. In JSON, you get the same expressiveness without the hassle.

tptacek 17y ago
I'm not sure what you think your JSON parser is doing.
- 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.... "\"
- jbooth 17y ago
  Well, in XML you're prone to files like (lets see how news.yc renders this): <thingies> <thingy> <name>thingy1</name> </thingy> <thingy> ... </thingies> I've seen that a billion times, if you're doing DOM, you have to pull that whole thing into memory and then run over it again. Most JSON-based storage systems I've seen recently are more record based so you can stream it through. So I guess my beef on that one isn't specifically with XML, you could split the above snippet into separate entities.. but I'll note that it still involves about 90% markup and 10% data. Not exactly the most efficient thing possible.
m_eiman 17y ago
I have to parse this whole thing into memory and then pull out the part I want? You do that with JSON too, don't you? Are there SAX-like parsers for JSON? If it's a big file it'll be big in JSON too.
- loup-vaillant 17y ago
  If the file is big, chances are that it is basically a sequence of relatively small chunks. You don't need SAX parsing for this. Just read the file one chunk at a time.
- jmillikin 17y ago
  There are a few event-based JSON parsers; yajl is the most famous, though its interpretation of the JSON spec is a bit liberal for my tastes.

by jbooth 17y ago

tptacek 17y ago

I'm not sure what you think your JSON parser is doing.

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.... "\"
jbooth 17y ago
Well, in XML you're prone to files like (lets see how news.yc renders this): <thingies> <thingy> <name>thingy1</name> </thingy> <thingy> ... </thingies> I've seen that a billion times, if you're doing DOM, you have to pull that whole thing into memory and then run over it again. Most JSON-based storage systems I've seen recently are more record based so you can stream it through. So I guess my beef on that one isn't specifically with XML, you could split the above snippet into separate entities.. but I'll note that it still involves about 90% markup and 10% data. Not exactly the most efficient thing possible.

m_eiman 17y ago

I have to parse this whole thing into memory and then pull out the part I want? You do that with JSON too, don't you? Are there SAX-like parsers for JSON? If it's a big file it'll be big in JSON too.

loup-vaillant 17y ago
If the file is big, chances are that it is basically a sequence of relatively small chunks. You don't need SAX parsing for this. Just read the file one chunk at a time.
jmillikin 17y ago
There are a few event-based JSON parsers; yajl is the most famous, though its interpretation of the JSON spec is a bit liberal for my tastes.