4 ms·

I kinda get this criticism, but this is also a bit like lamenting that we write the same libraries for different programming languages. I mean... yeah. Some ide

by rtpg 9y ago

I kinda get this criticism, but this is also a bit like lamenting that we write the same libraries for different programming languages. I mean... yeah. Some ideas are good across protocols. That's why they're copied. On a merits-based thing, if you're just looking at XML, it has a lot of things going against it .If someone sends me something "in JSON", I can have a good guess what it'll look like. Not as much luck with XML. XML punishes you for using attributes (because you can't place composed types within them), but the awkward alternative is placing attributes in sub-elements. I have a list of products with prices. I store the price as a quantity attribute on a <product>. I decide later on to store currencies for all my "money" objects. Do I now double the amount of attributes? It's all super awkward, and JSON's mental model is more straightforward, even if you end up with approximations.

jimktrains2 9y ago
Why is it super awkward and how does JSON solve this problem any better?
- simonw 9y ago
  When you’re designing an XML schema, answering the question “should this be an attribute or a nested elember” is awkward because there is rarely an obvious correct answer. With JSON, the answer is always a name/value pair.
  - dragonwriter 9y ago
    That's a problem with XML Schema, not XML. A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.
- tchaffee 9y ago
  JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus <employees> <employee> <name>John Crichton</name> <gender>male</gender> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees>
  - skocznymroczny 9y ago
    Or <employees> <employee name="John Crichton" gender="male" /> <employee name="Aeryn Sun" gender=female" /> </employees>
    - Matt3o12_ 9y ago
      I believe that was OP's point. Using the annotation you cannot add an attribute with subattributes. What if you wanted to add the employee's last six salaries. Suddenly you need to restructure your xml: <employees> <employee> <name>John Crichton</name> <gender>male</gender> <salaries> <salary>10000</salary> <salary>10000</salary> <salary>10000</salary> <salaries> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees> Using JSON, you just so: “salaries”: [10000,10000,10000] JSON is not only less verbose, it is also more flexible and easier to read and understand. You don’t have to worry about should I use tags or attributes for that because I late might have to use sub tags, and that makes it far easier to use (and honestly parse as well because many XML documents I have gotten are very inconsistent).
      - bouke 9y ago
        Why do you need to restructure the xml? You can just keep the attributes. To add the salaries there are quite a few options, as XML is just as flexible as well. Using a List (XSD List) type: <employees> <employee name="John Crichton" gender="male" salaries="10000 10000 1000" /> <employee name="Aeryn Sun" gender="female" /> </employees> And using mixed content (complexType): <employees> <employee name="John Crichton" gender="male"> <salary>10000</salary> <salary>10000</salary> <salary>10000</salary> </employee> <employee name="Aeryn Sun" gender="female" /> </employees>
- bryanrasmussen 9y ago
  JSON has data types built into it, XML needs its data type understanding defined by an external technology - often in the form of an irritating schema language that is hard for many people to understand, extraordinarily verbose, and which also has the downside of not being able to describe many of the constraints often encountered in actual XML formats.

by rtpg 9y ago

jimktrains2 9y ago

Why is it super awkward and how does JSON solve this problem any better?

simonw 9y ago
When you’re designing an XML schema, answering the question “should this be an attribute or a nested elember” is awkward because there is rarely an obvious correct answer. With JSON, the answer is always a name/value pair.
- dragonwriter 9y ago
  That's a problem with XML Schema, not XML. A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.
tchaffee 9y ago
JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus <employees> <employee> <name>John Crichton</name> <gender>male</gender> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees>
- skocznymroczny 9y ago
  Or <employees> <employee name="John Crichton" gender="male" /> <employee name="Aeryn Sun" gender=female" /> </employees>
  - Matt3o12_ 9y ago
    I believe that was OP's point. Using the annotation you cannot add an attribute with subattributes. What if you wanted to add the employee's last six salaries. Suddenly you need to restructure your xml: <employees> <employee> <name>John Crichton</name> <gender>male</gender> <salaries> <salary>10000</salary> <salary>10000</salary> <salary>10000</salary> <salaries> </employee> <employee> <name>Aeryn Sun</name> <gender>female</gender> </employee> </employees> Using JSON, you just so: “salaries”: [10000,10000,10000] JSON is not only less verbose, it is also more flexible and easier to read and understand. You don’t have to worry about should I use tags or attributes for that because I late might have to use sub tags, and that makes it far easier to use (and honestly parse as well because many XML documents I have gotten are very inconsistent).
    - bouke 9y ago
      Why do you need to restructure the xml? You can just keep the attributes. To add the salaries there are quite a few options, as XML is just as flexible as well. Using a List (XSD List) type: <employees> <employee name="John Crichton" gender="male" salaries="10000 10000 1000" /> <employee name="Aeryn Sun" gender="female" /> </employees> And using mixed content (complexType): <employees> <employee name="John Crichton" gender="male"> <salary>10000</salary> <salary>10000</salary> <salary>10000</salary> </employee> <employee name="Aeryn Sun" gender="female" /> </employees>
bryanrasmussen 9y ago
JSON has data types built into it, XML needs its data type understanding defined by an external technology - often in the form of an irritating schema language that is hard for many people to understand, extraordinarily verbose, and which also has the downside of not being able to describe many of the constraints often encountered in actual XML formats.