4 ms·
That's a very useful and sobering view actually. Unfortunately for the XML format it wasn't designed to prevent its own abuse. But anyway, XML is for documents
by mojuba 7y ago
That's a very useful and sobering view actually. Unfortunately for the XML format it wasn't designed to prevent its own abuse. But anyway, XML is for documents sounds like a good and acceptable paradigm.
That being said, one subtle and important (and often overlooked) difference between XML and, say JSON is that you can stream XML while parsing it on the application level, whereas JSON can not be parsed by the application due to arbitrary ordering of keys. (Of course lower level parsers use streaming anyway, but that's not the point)
In fact you not only can but you should parse XML while streaming it. This is another common abuse: wherever you look you see some high level function that loads an entire parsed XML structure into memory at once. But once you start asking yourself where the file may be coming from you realize that your system may be open to denial of service attacks. E.g. is your system ready to receive a 16GB XML file?
- Bouncingsoul1 7y agoExactly this, last time I checked the dump of german wikipedia was around 16GB so you'll find these files in the wild
- fanf2 7y agoThere is no reason you can’t do a SAX-style parser for JSON. A quick bit of searchengineering will find dozens, eg. https://github.com/dgraham/json-stream https://github.com/dgraham/json-stream
- mojuba 7y agoYou can in principle, but because the order is not guaranteed, you may find yourself accumulating things in memory. It depends on the task of course, but neither standard parsers nor generators are required to send adjacent JSON entities in a specific order. I remember someone describing a trick where instead of sending a JSON array they'd just send a stream of JOSN objects, one per line, so that the receiving end could parse the data in a streaming fashion. But that's not JSON anymore.