3 ms·

In the first example you show simple but verbose XML. Then you show typical JSON. Then you show concise XML; this last example shows the parsing overhead when X

In the first example you show simple but verbose XML. Then you show typical JSON. Then you show concise XML; this last example shows the parsing overhead when XML is being concise. Suddenly you go from just tags with content between them to key=value pairs and a flag to skip a check for the closing tag. Parser complexity creeps in on that last example in particular. The first example was probably in the form the (possibly) easiest of all three examples to parse. This all shows XML needing to support at least two different but related mechanisms. I'm not saying any of this is bad or that it makes parsing impossible: its just a source of complexity. JSON has key value syntax as well. XML has this flexibility but it quickly adds up. This is not a fault - it's the whole point of XML. I'm not sure what your goal here is. I've got hard data for the work I'm doing showing XML doesn't provide significant benefits in exchange for its added complexity. Others likely have done similar for their purposes. Matching the solution to the problem is generally a good idea. Are you perhaps too biased towards a single solution without considering the alternatives? I don't/can't know. Something to consider. (I don't consider XML as useful now because it has shown itself no longer a match for the types of problems I'm solving YMMV)

datalist 7y ago
I provided exactly one example and that was a comparison between XML and JSON. The follow up was just an additional remark that idiomatic XML would be even shorter. I am afraid I cannot follow your argument about complexity as any parser worth its money WILL BE ABLE to parse XML without any significant overhead and - as I mentioned numerous times - issues do not stem from how an XML document is built but from the fact that (mostly) Java parsers attempted to implement about each possible OOP pattern instead of going for KISS. The code over-engineering is the issue, not the document structure. I am really not sure what point you are trying to make and why you are diverting from the actual topic I addressed. I am slightly surprised about your bias remark, as it seems to be you who is strongly biased towards JSON despite my initial comments as well as the "significant benefits" as I never made any such claim, on the contrary it is you once again who seems to make such about JSON. Maybe you can post the "hard data" you referred to. Bottom line (once again), XML and JSON are extremely similar and saying one is better than the other simply shows lack of experience. Then of course, if you parse 70 kilobyte JSON documents with a lean parser, but parse 12 megabyte XML documents with a typical Java parser, nobody needs to be surprised the latter will perform abysmally compared to the former, but that would be a whole different subject.
- datalist 7y ago
  Not that it actually matters much[1] but as you insist very much on performance here a benchmark http://www.navioo.com/ajax/examples/json/test.php http://www.navioo.com/ajax/examples/json/test.php In the first example XML actually is a tad faster, in the second example it is practically a tie (JSON wins by three or four milliseconds). [1] Are we seriously arguing about milliseconds when it comes to document parsing?
- rs23296008n1 7y ago
  To answer your followup post, your defence of XML is interesting but I'm not referring to milliseconds, its about hours. Not talking about bits or bytes, I'm referring to gigabytes of RAM and i/o. Compressed data streams assumed, with data i/o requirements a definite important factor but not the only one. I'm not an evangelist for JSON, I'm someone who ran tests and came to conclusions with the help of multiple others. These weren't a generic benchmark for random or general academic purposes. These were representative samples of datasets we're actively going to be or actually are already using. Even in my other interests I'm using JSON for configuration and data transfer. It shines there quite nicely. XML was generally suitable but its verbosity didn't provide any real advantage and the library support tried to drag in too many dependencies. TSV files weren't suitable even though they were simpler and we had control of the data sources. You mention Java / Javascript but neither is what we're using. There's probably some irony in not using javascript for JSON i/o but it is what it is. (The purists will agree there's no requirement and so do we). You also didn't mention in passing any of the other interchange / file and document formats we actively compared. JSON / XML etc were just some of the candidates. Thank you for letting me know that the teams I work with demonstrate "lack of experience". I've forgotten which logical fallacy that is but I'll leave that to someone else to know or look up. I'm just glad I've kept beginner's mind: its a key aspect of neuro-plastic mindset. Its a requirement for keeping an open mind. We won't be ignoring our testing on real data subsets. The results are clear enough. (The samples we tested with were around 5MB, 50Mb, 1GB, 10GB and 50GB in size as various combinations of lists and trees etc.)
  - datalist 7y ago
    Most definitely no offence meant, but if you are talking about gigabytes in the context of JSON, XML, or any other text based format you are doing something wrong. And yes, in this case I will stand by my "lack of experience" concerning your entire team, I am sorry. However you havent really addressed your use case anyhow but you just threw keywords around - gigabyte, IO, compressed, etc. You might want to elaborate on where you have to use XML files of the size of 50 gigabytes. It doesnt really matter what you are using, Java was just one example. If the XML parser you employ has similar issues you must not be surprised if the outcome is similar. And you seem to be coming back over and over to software support (dependencies). Yes, particularly Java was poor when it came to that but as I said quite some time ago, that is an issue with that software not the document format. I will disregard the 10M+ tests, but could you publish somewhere the results of the 5MB files? Again, JSON and XML are way too similar to be anywhere close to what you described and aforementioned benchmark highlighted that. Yes, its dataset is average but I am sure you'll be able to extrapolate that for larger sets. Apart from the apparent improper use for data of that magnitude, I could only imagine you used an XML parser that simply was not fit for the task and if you do that you shouldnt be surprised that it does not work.
datalist 7y ago
To also address this part which I seem to have missed earlier > This all shows XML needing to support at least two different but related mechanisms. I'm not saying any of this is bad or that it makes parsing impossible: its just a source of complexity. JSON has key value syntax as well. XML has this flexibility but it quickly adds up. This is not a fault - it's the whole point of XML. It is not really two different mechanisms. It simply is part of XML's syntax, just in the same way as these two JSON examples are very similar [ { "hello": "world"}, { "hello": "world"}, { "hello": "world"}, { "hello": "world"} ] { "1": { "hello": "world"}, "2": { "hello": "world"}, "3": { "hello": "world"}, "4": { "hello": "world"} } Does any of that add complexity? Yes of course it does. If you dont want complexity you should probably go with a "Hello world" program, which incidentally will be also relatively bug-free ;) However saying the additional syntax support of XML adds complexity which adds hours of CPU time when processing the same data in different formats (JSON and XML) borders ludicrous. Unless your XML parser is (deliberately) slow of course.

datalist 7y ago

I provided exactly one example and that was a comparison between XML and JSON. The follow up was just an additional remark that idiomatic XML would be even shorter. I am afraid I cannot follow your argument about complexity as any parser worth its money WILL BE ABLE to parse XML without any significant overhead and - as I mentioned numerous times - issues do not stem from how an XML document is built but from the fact that (mostly) Java parsers attempted to implement about each possible OOP pattern instead of going for KISS. The code over-engineering is the issue, not the document structure. I am really not sure what point you are trying to make and why you are diverting from the actual topic I addressed. I am slightly surprised about your bias remark, as it seems to be you who is strongly biased towards JSON despite my initial comments as well as the "significant benefits" as I never made any such claim, on the contrary it is you once again who seems to make such about JSON. Maybe you can post the "hard data" you referred to. Bottom line (once again), XML and JSON are extremely similar and saying one is better than the other simply shows lack of experience. Then of course, if you parse 70 kilobyte JSON documents with a lean parser, but parse 12 megabyte XML documents with a typical Java parser, nobody needs to be surprised the latter will perform abysmally compared to the former, but that would be a whole different subject.

datalist 7y ago
Not that it actually matters much[1] but as you insist very much on performance here a benchmark http://www.navioo.com/ajax/examples/json/test.php http://www.navioo.com/ajax/examples/json/test.php In the first example XML actually is a tad faster, in the second example it is practically a tie (JSON wins by three or four milliseconds). [1] Are we seriously arguing about milliseconds when it comes to document parsing?
rs23296008n1 7y ago
To answer your followup post, your defence of XML is interesting but I'm not referring to milliseconds, its about hours. Not talking about bits or bytes, I'm referring to gigabytes of RAM and i/o. Compressed data streams assumed, with data i/o requirements a definite important factor but not the only one. I'm not an evangelist for JSON, I'm someone who ran tests and came to conclusions with the help of multiple others. These weren't a generic benchmark for random or general academic purposes. These were representative samples of datasets we're actively going to be or actually are already using. Even in my other interests I'm using JSON for configuration and data transfer. It shines there quite nicely. XML was generally suitable but its verbosity didn't provide any real advantage and the library support tried to drag in too many dependencies. TSV files weren't suitable even though they were simpler and we had control of the data sources. You mention Java / Javascript but neither is what we're using. There's probably some irony in not using javascript for JSON i/o but it is what it is. (The purists will agree there's no requirement and so do we). You also didn't mention in passing any of the other interchange / file and document formats we actively compared. JSON / XML etc were just some of the candidates. Thank you for letting me know that the teams I work with demonstrate "lack of experience". I've forgotten which logical fallacy that is but I'll leave that to someone else to know or look up. I'm just glad I've kept beginner's mind: its a key aspect of neuro-plastic mindset. Its a requirement for keeping an open mind. We won't be ignoring our testing on real data subsets. The results are clear enough. (The samples we tested with were around 5MB, 50Mb, 1GB, 10GB and 50GB in size as various combinations of lists and trees etc.)
- datalist 7y ago
  Most definitely no offence meant, but if you are talking about gigabytes in the context of JSON, XML, or any other text based format you are doing something wrong. And yes, in this case I will stand by my "lack of experience" concerning your entire team, I am sorry. However you havent really addressed your use case anyhow but you just threw keywords around - gigabyte, IO, compressed, etc. You might want to elaborate on where you have to use XML files of the size of 50 gigabytes. It doesnt really matter what you are using, Java was just one example. If the XML parser you employ has similar issues you must not be surprised if the outcome is similar. And you seem to be coming back over and over to software support (dependencies). Yes, particularly Java was poor when it came to that but as I said quite some time ago, that is an issue with that software not the document format. I will disregard the 10M+ tests, but could you publish somewhere the results of the 5MB files? Again, JSON and XML are way too similar to be anywhere close to what you described and aforementioned benchmark highlighted that. Yes, its dataset is average but I am sure you'll be able to extrapolate that for larger sets. Apart from the apparent improper use for data of that magnitude, I could only imagine you used an XML parser that simply was not fit for the task and if you do that you shouldnt be surprised that it does not work.

datalist 7y ago

To also address this part which I seem to have missed earlier > This all shows XML needing to support at least two different but related mechanisms. I'm not saying any of this is bad or that it makes parsing impossible: its just a source of complexity. JSON has key value syntax as well. XML has this flexibility but it quickly adds up. This is not a fault - it's the whole point of XML. It is not really two different mechanisms. It simply is part of XML's syntax, just in the same way as these two JSON examples are very similar [ { "hello": "world"}, { "hello": "world"}, { "hello": "world"}, { "hello": "world"} ] { "1": { "hello": "world"}, "2": { "hello": "world"}, "3": { "hello": "world"}, "4": { "hello": "world"} } Does any of that add complexity? Yes of course it does. If you dont want complexity you should probably go with a "Hello world" program, which incidentally will be also relatively bug-free ;) However saying the additional syntax support of XML adds complexity which adds hours of CPU time when processing the same data in different formats (JSON and XML) borders ludicrous. Unless your XML parser is (deliberately) slow of course.