5 ms·

XML's bad rep for verbosity is almost entirely due to the nonsensical, terrible idea of requiring names in the end tag. Without that, it's about the same level

XML's bad rep for verbosity is almost entirely due to the nonsensical, terrible idea of requiring names in the end tag. Without that, it's about the same level of verbosity as JSON. And personally, after writing plenty of both by hand, XML is easier to get right. JSON, with it's poor quoting rules (mandatory quotes on names??) and lack of comments is very annoying to do by hand and seems visually more noisy.

erlehmann_ 10y ago
An advantage of names in end tags is human readability. Consider this XML fragment: <a>12<b>34<c>56<d>78<e>90</e></d></c></b></a> Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose: (12(34(56(78(90)))))
- mikeash 10y ago
  If they're all <a> then you're back to square one. JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too. Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.
  - erlehmann_ 10y ago
    It is rare in real-world XML that elements have children with the same type. Do you have a (non-divitis) example where the tags are all the same?
    - lmm 10y ago
      It happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.
      - erlehmann_ 10y ago
        Did the elements often have immediate child elements that had immediate child elements (and so on) of the same type? Like: <contract><contract><contract><contract> […]
        lmm 10y ago
        No, there were a couple of layers in that case. But that doesn't actually help you add a child at the correct level, because the end of a contract would look something like: ... </contract> </subcontracts> </content> </contract> </subcontracts> </content> </contract>

erlehmann_ 10y ago

An advantage of names in end tags is human readability. Consider this XML fragment: <a>12<b>34<c>56<d>78<e>90</e></d></c></b></a> Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose: (12(34(56(78(90)))))

mikeash 10y ago
If they're all <a> then you're back to square one. JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too. Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.
- erlehmann_ 10y ago
  It is rare in real-world XML that elements have children with the same type. Do you have a (non-divitis) example where the tags are all the same?
  - lmm 10y ago
    It happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.
    - erlehmann_ 10y ago
      Did the elements often have immediate child elements that had immediate child elements (and so on) of the same type? Like: <contract><contract><contract><contract> […]
      - lmm 10y ago
        No, there were a couple of layers in that case. But that doesn't actually help you add a child at the correct level, because the end of a contract would look something like: ... </contract> </subcontracts> </content> </contract> </subcontracts> </content> </contract>