Mostly I have just used XML files to store config info and to provide elementary data persistence. Now I am building a website where I need to store some XML type data. However I am already using JSON extensively throughout the whole thing. Is it bad to store JSON directly instead of XML, or should I store the XML and introduce an XML parser.
+3
A:
It's just data, like XML. There's nothing about it that would preclude saving it to disk.
Robert Harvey
2009-09-22 01:52:11
+2
A:
Define "bad". They're both just plain-text formats. Knock yourself out.
Glenn
2009-09-22 01:52:29
I think he mean if there are obvious downsides or violations of best practices in doing that :)
DVK
2009-09-22 03:09:50
+7
A:
Not bad at all. Although there are more XML editors, so if you're going to need to manually edit the files, XML may be better.
JW
2009-09-22 01:52:49
I'd argue it's just as easy to read JSON these days with javascript syntax highlighting and code folding in most editors.
Glenn
2009-09-22 02:00:38
+1
A:
one potential issue with JSON, when there is deep nesting, is readability, you may actually see ]]]}], making debugging difficult
vtd-xml-author
2009-09-22 01:57:39
+6
A:
Differences between using XML and JSON are:
A lot easier to find an editor supporting nice way to edit XML. I'm aware of no editors that do this for JSON, but there might be some, I hope :)
Extreme portability/interoperability - not everything can read JSON natively whereas pretty much any language/framework these days has XML libraries.
JSON takes up less space
JSON may be faster to process, ESPECIALLY in a JavaScript app where it's native data.
JSON is more human readable for programmers (this is subjective but everyone I know agrees so).
Now, please notice the common thread: any of the benefits of using pure XML listed above are 100% lost immediately as soon as you store JSON as XML payload.
Therefore, the gudelines are as follows:
If wide interoperability is an issue and you talk to something that can't read JSON (like a DB that can read XML natively), use XML.
Otherwise, I'd recommend using JSON
NEVER EVER use JSON as XML payload unless you must use XML as a transport container due to existing protocol needs AND the cost of encoding and decoding JSON to/from XML is somehow prohibitively high as compared to network/storage lossage due to double encoding (I have a major trouble imagining a plausible scenario like this, but who knows...)
UPDATED: Removed Unicode bullets as per info in comments
DVK
2009-09-22 03:19:15
It's not necessarily true that JSON is faster to parse in JavaScript: if you use Crockford's json2.js rather than eval then I've observed it being slower than parsing equivalent XML in IE. I have no benchmarks to hand though, sorry.
Tim Down
2009-09-22 08:30:11
Which library do you use to parse the XML (out of sheer curiosity, in case I need to do fast XML parsing later in life?)
DVK
2009-09-22 11:26:40
None, just the browser's built-in XML parsing stuff. DOMParser in non-IE browsers and the Microsoft.XMLDOM ActiveX object in IE.
Tim Down
2009-09-22 14:47:41
@J.F. - For example, ADA has XML support but not JSON based on my cursory Googling. That affects many projects doing government-oriented (especially DoD) work.
DVK
2009-09-22 19:57:18
my view is that JSON is not as readable as XML... its delimiters(, ; [ and ]) can become confusing at times
vtd-xml-author
2009-11-22 02:58:02
+2
A:
If your storing the data as a cache (meaning it was in one format and you had to process it programatically to "make" it JSON. Then I say no problem. As long as the consumer of your JSON reads native JSON then it's standard practice to save cache data to disk or memory.
However if you're storing a configuration file in JSON which needs human interaction to "process" then I may reconsider. Using JSON for simple Key:Value pairs is cool, but anything beyond that, the format may be too compact (meaning nested { and [ brackets can be hard to decipher).
null
2009-09-22 19:01:35