41–50 of 120 posts
Well JSON also lets you get around browsers' same-domain policy without having to set up a proxy, which I think might be more important.
if you are talking about JSONp: JSON is by no means required to do that. You could in theory easily pass a string containing XML to the callback function.
Earlier quoted context omitted.
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.
I'm not sure what you think your JSON parser is doing.
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.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
Earlier quoted context omitted.
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.
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.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
Earlier quoted context omitted.
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.
I'm not sure what you think your JSON parser is doing.
thingy1 ...
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
How? I'm evaluating strings that are built with my javascript code or from my server code, not arbitrary user input from other users. Yes the user is able to enter parenthesis into a textbox, and those become part of the evaluated string, but I regex replace out everything but the actual parenthesis.
Every security assessor's favorite answer to a threat: "but I regex out everything unsafe".
Here is the regex for what I allow (only '[' & ']'):
value.replace(/[^(]/g, '').replace(/\(/g, '[')
value.replace(/[^)]/g, '').replace(/\)/g, '],')
http://blogs.msdn.com/ericlippert/archive/2003/11/01/53329.a...
I can't really understand all the XML-bashing. Of course it isn't the right tool for any job, but I like it for its schema and validation features.
I can't really understand all the XML-bashing. Of course it isn't the right tool for any job, but I like it for its schema and validation features.
The trouble was that it was the all-purpose data exchange tool for a long time, and everyone has seen XML put to all sorts of ungodly purposes. If it were invented today, nobody would be bashing it, because it would be less widely used -- the few people who did decide to use it would be putting it to good use, so they would love it. Everyone else would be using something else that was simpler.