|
toro has asked for the wisdom of the Perl Monks concerning the following question:
This is not a how-to question, more of an opinion question. I have the option of getting some data in either XML or JSON. Which way should I ask for it?
I haven't used either parser but I note there are tools available on CPAN. JSON seems like the "newer, slicker" technology and I find the plaintext JSON files more readable. But neither of those are good reasons for choosing to learn one parser over the other. What are your thoughts, monks? |
Re: JSON or XML?
by Tanktalus (Canon) on Apr 25, 2012 at 19:25 UTC
|
tye introduced me to JSON via the CB some years ago. It has become the lingua franca here. Everything we transmit from one app to another is going either through a database (SQL) or JSON. XML exists, but only with third-party apps that we don't control, and, for the most part, we don't interact with them through their XML anyway. JSON has a simpler API for both encoding data and extracting data. And that simpler API is language-agnostic: join '', map { "Using JSON in $_ is easier than using XML in $_.\n" } qw( Perl Java JavaScript ActionScript ) And both are downright horrible in shell script. So we don't do that.
JSON also is less verbose. Which makes it better suited for tracing inputs/outputs in our trace files. (When objects are involved, it becomes a bit tricky, but XML serialisation has the same issue.) Our trace files grow fairly big fairly quickly already, keeping bloat down is always a win.
| [reply]
[d/l] |
Re: JSON or XML?
by grantm (Parson) on Apr 25, 2012 at 21:41 UTC
|
Since you just seem to be looking for opinions, here's mine: I've found XML to be useful for 'documents' - the type of data that you might want to transform or filter or style (perhaps with XSLT). Pretty much any other type of data (e.g.: records, serialised objects, querys, result sets etc) I prefer JSON.
| [reply] |
|
|
| [reply] |
Re: JSON or XML?
by JavaFan (Canon) on Apr 23, 2012 at 23:33 UTC
|
You're not giving any information for someone to give you a rational suggestion. I'm not sure what kind of answer you're expecting. | [reply] |
|
|
I'm not sure what kind of answer you're expecting.
"XML sux! JSON rules!" ?
I have a hard time imagining any data that I'd rather get in XML than in JSON. No, actually, I am completely failing to imagine data that I'd rather get in XML than in JSON.
Have you ever tried to deal with an XML parser? What a recipe for frustration! Have you ever tried to programmatically generate XML? I find that to be an excellent way to find many modules that provide cumbersome (and worse) interfaces for a task.
I guess XML has the potential to let you create a DTD (or even just namespaces). Though, I have yet to have a DTD actually prove useful (and my experience with XML namespaces is "100% pain" so far). I can see the theoretical benefit of such. But, no, I don't see that out-weighing the many other significant pains from dealing with XML. I think the need to invent the complex thing that is a DTD is mostly a demonstration of how painful XML is to work with, creating the need for advanced tools to compensate.
Then there is the complete refusal of XML to allow "data" to include something as mundane as a form-feed character. Sure, you can come up with some additional encoding to embed into the XML... For example, you could encode your binary data into the extremely simple and capable format of JSON and then embed the JSON into the XML.
I also sometimes wish JSON allowed for comments and ordered pairs. But, really, you can just use a list for ordered pairs. And there are even advantages for defining how to include the comments as part of the data (if you don't want to just go slightly outside the JSON standard and allow Java-style comments). (And I sometimes wish JSON didn't allow any types of scalar data other than strings.)
I guess using JSON as a mark-up language for a 98%-text document (like a web page) seems a bit strange. But I suspect, in practice, if you define the structure well, it won't be any worse than trying to edit HTML. But that's a bit of a stretch for something that I'd call "data" anyway.
Pretty much when I say "data", I mean "something that fits in JSON". JSON came along and nicely defined the crux of "what is data?" when talking about sending data between end-points not confined to a single process. It is just too bad that it wasn't formalized much earlier. It would've greatly simplified the HTTP protocol, for example.
| [reply] |
|
|
| [reply] |
|
|
Thanks!
DTD So this means something like defining your own language? E.g.
<barber></barber>, <scissors></scissors> instead of <paragraph></paragraph>, <bold></bold> etc. ?
But, really, you can just use a list for ordered pairs. You can even pass an entire time series with JSON. http://vimeo.com/35005701
I sometimes wish JSON didn't allow any types of scalar data other than strings. "Numbers are not quoted. It would be insane to require quotes around numbers." —Douglas Crockford http://www.json.org/fatfree.html | [reply] |
|
|
Just fishing for opinions in the community. What should I be telling you?
| [reply] |
|
|
