4 ms·

I can easily have a JSON parser up and running in basically any language in my toolkit usually in minutes. This is not the case with XML. JSON exists between t

I can easily have a JSON parser up and running in basically any language in my toolkit usually in minutes. This is not the case with XML. JSON exists between the bureaucratic XML at the top and the anarchy of csv/tsv at the bottom. I'd rather operate on JSON data: fast to process, easily pulled apart, etc. CSVs are a free-for-all that are either well formed or a subtle spaghetti of loose commas and bad quoting. What XML has that the others don't is verbosity and that helps in rebuilding damaged data. I can rebuild an XML record easier than JSON and XML lets me see where records are incomplete/malformed. These are its strengths. But every new project I work on has JSON because the parsers run fast and everything is legible. I can edit a JSON file without it becoming a sea of text like XML. To each their own, XML has a place and so does JSON. I know as fact that for my purposes XML uses much more time and memory and both of those cost money.

datalist 7y ago
I am afraid you are still mixing two unrelated things. The document format and potential libraries. Yes, XML libraries tend to be unnecessarily complex (particularly with Java) and are often a drag, but this is not about about the format. Even the bureaucracy you mentioned is not inherent to XML itself. You can perfectly use XML without schema insanity, just like JSON. XML is quite more verbose (which might help in a rebuild you mentioned) but is generally quite alike to JSON. Even the performance and memory issues you mentioned are not specific to XML but rather to libraries which went bananas. My point is JSON is not more popular these days because it is inherently superior. JSON is more popular because it was the default choice in a JavaScript environment and - probably - because those who implemented JSON libraries were a tad more sane than their XML counterparts.
- rs23296008n1 7y ago
  If the spec produces bad implementations often enough then the spec itself becomes suspect. It implies too many misunderstandings are occurring. I find XML tooling far more bulky than that for JSON. For data interchange between C++, python and lua plenty of support for JSON makes this clean and painless. The files are relatively clean and easy to maintain and fast to read/write. I'd not even suggest XML now since initial prototyping showed it too inconvenient for what we do.
  - datalist 7y ago
    I dont think we need to go down the where there is smoke there is fire route. These implementations are bad for a variety of reasons but not because XML is bad itself. As I said, XML on Java is often a hassle but that is neither XML's fault nor Java's but the responsibility of those developers who thought going bananas on interfaces, factories, and alike is actually a good idea. As for XML, its syntax is somewhat more verbose than JSON's but thats about it. ----- Just to provide one very basic example XML <people> <person> <name>John Doe</name> <dob>2000-01-01</dob> </person> <person> <name>Peter Smith</name> <dob>2001-01-01</dob> </person> </people> JSON [ { "name": "John Doe", "dob": "2000-01-01" }, { "name": "Peter Smith", "dob": "2001-01-01" } ] Apart from XML being more verbose (but also providing more context), these two documents are virtually identical, they even have the same number of lines. And if one used XML actually idiomatically the example would slim down by a lot <people> <person name="John Doe" dob="2000-01-01" /> <person name="Peter Smith" dob="2001-01-01" /> </people>
    - deleted 7y ago
      [deleted]
    - rs23296008n1 7y ago
      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 am afraid you are still mixing two unrelated things. The document format and potential libraries. Yes, XML libraries tend to be unnecessarily complex (particularly with Java) and are often a drag, but this is not about about the format. Even the bureaucracy you mentioned is not inherent to XML itself. You can perfectly use XML without schema insanity, just like JSON. XML is quite more verbose (which might help in a rebuild you mentioned) but is generally quite alike to JSON. Even the performance and memory issues you mentioned are not specific to XML but rather to libraries which went bananas. My point is JSON is not more popular these days because it is inherently superior. JSON is more popular because it was the default choice in a JavaScript environment and - probably - because those who implemented JSON libraries were a tad more sane than their XML counterparts.

rs23296008n1 7y ago
If the spec produces bad implementations often enough then the spec itself becomes suspect. It implies too many misunderstandings are occurring. I find XML tooling far more bulky than that for JSON. For data interchange between C++, python and lua plenty of support for JSON makes this clean and painless. The files are relatively clean and easy to maintain and fast to read/write. I'd not even suggest XML now since initial prototyping showed it too inconvenient for what we do.
- datalist 7y ago
  I dont think we need to go down the where there is smoke there is fire route. These implementations are bad for a variety of reasons but not because XML is bad itself. As I said, XML on Java is often a hassle but that is neither XML's fault nor Java's but the responsibility of those developers who thought going bananas on interfaces, factories, and alike is actually a good idea. As for XML, its syntax is somewhat more verbose than JSON's but thats about it. ----- Just to provide one very basic example XML <people> <person> <name>John Doe</name> <dob>2000-01-01</dob> </person> <person> <name>Peter Smith</name> <dob>2001-01-01</dob> </person> </people> JSON [ { "name": "John Doe", "dob": "2000-01-01" }, { "name": "Peter Smith", "dob": "2001-01-01" } ] Apart from XML being more verbose (but also providing more context), these two documents are virtually identical, they even have the same number of lines. And if one used XML actually idiomatically the example would slim down by a lot <people> <person name="John Doe" dob="2000-01-01" /> <person name="Peter Smith" dob="2001-01-01" /> </people>
  - deleted 7y ago
    [deleted]
  - rs23296008n1 7y ago
    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)