8 ms·

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad

by wtbob 10y ago

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is <adverbial-particle modifies="#123">so</adverbial-particle> <adverb id="123">incredibly</adverb> <adjective>verbose</adjective>. Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would have been far less likely in a less-arcane format. XML is not bad at making markup languages (and indeed, in those languages attributes make sense); it is poor at making data-transfer languages. JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). It's still more verbose than a data transfer format should be, and people default to using unordered hashes instead of ordered key-value pairs, so it's not ideal. The best human-readable data transfer format is probably canonical S-expressions; the best binary format would probably be ASN.1, were it not so incredibly arcane. As it is, maybe protobufs are a good binary compromise?

ZenoArrow 10y ago
> "The best human-readable data transfer format is probably canonical S-expressions" I personally think TOML is a bit more readable... https://github.com/toml-lang/toml https://github.com/toml-lang/toml
- legulere 10y ago
  For configuration files, not for data serialisation.
  - ZenoArrow 10y ago
    Let's put it like this... what can you express in JSON that you couldn't express in TOML?
    - lmm 10y ago
      I can cleanly parse JSON, serialize it, and be confident I haven't lost anything. That can't be done for a language that allows comments without complicating the AST.
- crdoconnor 10y ago
  YAML is more readable than TOML though.
FunnyLookinHat 10y ago
> JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight. I think you could also make the argument that JSON was conceptually easier for programmers to wrap their minds around. You could just pretty-print it and quickly get an idea for the object's format, attributes, etc.
- ams6110 10y ago
  XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs. <person name="John" age="42" />
  - rimantas 10y ago
    Now do the nested objects in both. One line does not show much.
    - Mikhail_Edoshin 10y ago
      <person id="123" name="John" age="42" sec:checksum="..."> <family-member type="spouse" ref="456""/> <family-member type="child" ref="789" /> <fin:credit-rating score="A" last-change="2016-02-04T12:34:56Z" /> <уфмс:статус значение="42" /> </person> Here we can describe `person/@id` as element ID and `family-member/@ref` as a reference to an ID so our XML tools can link these together. Also note three more elements from different namespaces: `@sec:checksum` could be some kind of technical information about the record, `fin:credit-rating` is added by the finanical module. The `@last-change` is defined as datetime so as we read it with other XML tools we'll get it as datetime type. The next one is a tag in Russian language that describes something related to Russia; XML can use the whole Unicode in tag and attribute names. Also, XML names are globally unique by design so there's no clash between all the different pieces and the tools can easily be configured to ignore parts they don't understand or work as a glue between different areas. We can still efficiently validate the syntax the whole piece or parts of it as we see fit.
616c 10y ago
I think the worst of this is what I call semantic incoherence. I have a system that has things like <Task ID="6">Blah</Task>. Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? Another favorite: <ExecuteCommand>[CDATA[Batchfile.bat]]</ExecuteCommand>, while a binary or something else will be <ExecuteCommand>"program.exe /argument:f /argument2:x"</ExecuteCommand>. By the way, this is an enterprise as it gets: a software tool from a four-letter hardware company, quite huge, trying to sell off its software division. I wonder why. XML is like all other "crap" tools: Java, PHP, SOAP: some people do not grok the spirit of the law, and they do weird things that reflect their discomfort and hurried need to operate with it. Many write it off. I agree with your points, this is just my corrolary. The sad thing is SEXPR and XML are not far removed, one is arguably a subset of the other, and notice how people lose their shit when you ask them to consider Lisp languages for daily works because "all those parens are stupid" and how the culture surrounding a potentially viable tools makes people close up without delving in with curiosity. https://en.wikipedia.org/wiki/SXML https://en.wikipedia.org/wiki/SXML http://arclanguage.org/item?id=19453 http://arclanguage.org/item?id=19453
- ams6110 10y ago
  > Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.
  - 616c 10y ago
    That was not quite my point. Why pretend it is a string at all? <Task> <ID>3</ID> </Task> I should have been more clear. Sometimes you have these argument type deals <Task ID="3"> where I would at least hope for <Task ID=3> or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same config for the same function of this multi-stage system. I am not even a novice programmer, and I find the variation annoying, and sometimes hard to reason about when I want to know what the hell the programer was thinking. The valid part for the CDATA portion has changed several times in minor releases, so when our server team upgrades, I get to figure out the new syntax. I thought XML was proposed to avoid these things! Haha. Again, tools in the hands of "wise men" like me are dangerous. I am probably as ignorant as them, I just think I know better!
auganov 10y ago
S-expressions is basically no syntax. Human-readability depends solely on the person that comes up with the schema. I mean there's many reasons to love S-expressions but human-readability is an unusual one. edn [0] is an interesting compromise (as is clojure). XML is actually IMO not that bad at human readability, it's pretty good. It's terrible at human writability. Conversely S-exps are lovely to work with. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
legulere 10y ago
The problem is that XML maps badly to data structures in common programming languages. JSON maps perfectly to structs and datastructures as lists/arrays/maps. S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. I also can't see how they map easily into datastructures of imperative programming languages or even statically typed functional programming languages like haskell.
- wtbob 10y ago
  > S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581; https://news.ycombinator.com/item?id=12198581; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arrays; canonical S-expressions consist of bytes and lists. I contend that one can easily encode strings, numbers and booleans alike as bytes, and both objects and arrays as lists. Consider: { "id": 1234, "isEnabled": true, "props": ["abc", 123, false], } This could be encoded in canonical S-expressions as: (object (id "1234") (is-enabled "true") (props (abc "123" "false"))) Granted, one still must convert the strings "1234," "true," "123," and "false" into the expected types, but with JSON one still must check the expected types anyway; it's not that big a difference. And I honestly think that the S-expression version is far more attractive.
  - PeterisP 10y ago
    There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.
    - wtbob 10y ago
      > There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected. You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different from, in your code, parsing "123" as an integer, or throwing an error. In JSON one must check that every value is the type one expects, or throw an error. With canonical S-expressions, one must parse that every value is the type one expects, or throw an error. There's really no difference. If one is willing to use a Scheme or Common Lisp reader, of course, then numbers &c. are natively supported, at the expense of more quoting of strings (unless one chooses to use symbols …).
MichaelGG 10y ago
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.
JoshTriplett 10y ago
> I think that XML's bad reputation comes from the fact that it is <adverbial-particle modifies="#123">so</adverbial-particle> <adverb id="123">incredibly</adverb> <adjective>verbose</adjective>. > Also, the whole child/attribute dichotomy is a huge, huge mistake. Those two factors run counter to each other. Attributes decrease verbosity, compared to child elements. I agree, though. A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements much less verbose, and reduces the need for attributes.
- wtbob 10y ago
  > A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements much less verbose, and reduces the need for attributes. Then just change '<tagname>' to '(tagname,' and '</>' to ')' and you'll have S-expressions. Consider this: (feed (version 1) (title "Example Feed") (link http://example.org/) (updated "2003-12-13T18:30:02Z") (author (name "John Doe")) (id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6) (entry (title "Atom-Powered Robots Run Amok") (link http://example.org/2003/12/13/atom03) (id urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a) (updated "2003-12-13T18:30:02Z") (summary "Some text."))) That is a canonical S-expression (for a Scheme or Common Lisp reader, just quote the URIs too) version of: <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements. And compare to your proposed version: <feed> <title>Example Feed</> <link>http://example.org/</> <updated>2003-12-13T18:30:02Z</> <author> <name>John Doe</> </> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</> <entry> <title>Atom-Powered Robots Run Amok</> <link>http://example.org/2003/12/13/atom03</> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</> <updated>2003-12-13T18:30:02Z</> <summary>Some text.</> </> </> I think it's pretty clear which is the most readable and elegant.
Mikhail_Edoshin 10y ago
The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority. Child and attribute "dichotomy" is not a mistake. What you mean is that these two samples appear to be equivalent: <foo value="123" /> <foo>123</foo> But they are not equivalent. The first line (with an attribute) is there solely for the computer. When the document is rendered, the human user is not supposed to see anything there unless the computer adds it. The second line (with text content) is there for both the computer and the human user. The text "123" is for the human user; the fact that this text is something called "foo" is for the computer. When the document is rendered, the human user will see "123" here. Maybe computer will enhance something or maybe it will just use it as index or reference, whatever. Most people who don't like XML seem to only encounter it in config files. In config files there's normally no content that needs to be there for the end users, so all data can happily go into attributes. The text content starts to matter when we deal with natural language texts.
- wtbob 10y ago
  > The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority. Which seems pretty wasteful. > Child and attribute "dichotomy" is not a mistake. It's not for a markup format — as I mentioned, it can make sense there — but, as you mentioned, it doesn't make sense in a config or data file format.

by wtbob 10y ago

ZenoArrow 10y ago

> "The best human-readable data transfer format is probably canonical S-expressions" I personally think TOML is a bit more readable... https://github.com/toml-lang/toml https://github.com/toml-lang/toml

legulere 10y ago
For configuration files, not for data serialisation.
- ZenoArrow 10y ago
  Let's put it like this... what can you express in JSON that you couldn't express in TOML?
  - lmm 10y ago
    I can cleanly parse JSON, serialize it, and be confident I haven't lost anything. That can't be done for a language that allows comments without complicating the AST.
crdoconnor 10y ago
YAML is more readable than TOML though.

FunnyLookinHat 10y ago

> JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). Disagree. JSON became popular because it was extremely easy to implement (both for marshaling and consuming), and because it was extremely lightweight. I think you could also make the argument that JSON was conceptually easier for programmers to wrap their minds around. You could just pretty-print it and quickly get an idea for the object's format, attributes, etc.

ams6110 10y ago
XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs. <person name="John" age="42" />
- rimantas 10y ago
  Now do the nested objects in both. One line does not show much.
  - Mikhail_Edoshin 10y ago
    <person id="123" name="John" age="42" sec:checksum="..."> <family-member type="spouse" ref="456""/> <family-member type="child" ref="789" /> <fin:credit-rating score="A" last-change="2016-02-04T12:34:56Z" /> <уфмс:статус значение="42" /> </person> Here we can describe `person/@id` as element ID and `family-member/@ref` as a reference to an ID so our XML tools can link these together. Also note three more elements from different namespaces: `@sec:checksum` could be some kind of technical information about the record, `fin:credit-rating` is added by the finanical module. The `@last-change` is defined as datetime so as we read it with other XML tools we'll get it as datetime type. The next one is a tag in Russian language that describes something related to Russia; XML can use the whole Unicode in tag and attribute names. Also, XML names are globally unique by design so there's no clash between all the different pieces and the tools can easily be configured to ignore parts they don't understand or work as a glue between different areas. We can still efficiently validate the syntax the whole piece or parts of it as we see fit.

616c 10y ago

I think the worst of this is what I call semantic incoherence. I have a system that has things like <Task ID="6">Blah</Task>. Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? Another favorite: <ExecuteCommand>[CDATA[Batchfile.bat]]</ExecuteCommand>, while a binary or something else will be <ExecuteCommand>"program.exe /argument:f /argument2:x"</ExecuteCommand>. By the way, this is an enterprise as it gets: a software tool from a four-letter hardware company, quite huge, trying to sell off its software division. I wonder why. XML is like all other "crap" tools: Java, PHP, SOAP: some people do not grok the spirit of the law, and they do weird things that reflect their discomfort and hurried need to operate with it. Many write it off. I agree with your points, this is just my corrolary. The sad thing is SEXPR and XML are not far removed, one is arguably a subset of the other, and notice how people lose their shit when you ask them to consider Lisp languages for daily works because "all those parens are stupid" and how the culture surrounding a potentially viable tools makes people close up without delving in with curiosity. https://en.wikipedia.org/wiki/SXML https://en.wikipedia.org/wiki/SXML http://arclanguage.org/item?id=19453 http://arclanguage.org/item?id=19453

ams6110 10y ago
> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.
- 616c 10y ago
  That was not quite my point. Why pretend it is a string at all? <Task> <ID>3</ID> </Task> I should have been more clear. Sometimes you have these argument type deals <Task ID="3"> where I would at least hope for <Task ID=3> or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same config for the same function of this multi-stage system. I am not even a novice programmer, and I find the variation annoying, and sometimes hard to reason about when I want to know what the hell the programer was thinking. The valid part for the CDATA portion has changed several times in minor releases, so when our server team upgrades, I get to figure out the new syntax. I thought XML was proposed to avoid these things! Haha. Again, tools in the hands of "wise men" like me are dangerous. I am probably as ignorant as them, I just think I know better!

auganov 10y ago

S-expressions is basically no syntax. Human-readability depends solely on the person that comes up with the schema. I mean there's many reasons to love S-expressions but human-readability is an unusual one. edn [0] is an interesting compromise (as is clojure). XML is actually IMO not that bad at human readability, it's pretty good. It's terrible at human writability. Conversely S-exps are lovely to work with. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn

legulere 10y ago

The problem is that XML maps badly to data structures in common programming languages. JSON maps perfectly to structs and datastructures as lists/arrays/maps. S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. I also can't see how they map easily into datastructures of imperative programming languages or even statically typed functional programming languages like haskell.

wtbob 10y ago
> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581; https://news.ycombinator.com/item?id=12198581; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arrays; canonical S-expressions consist of bytes and lists. I contend that one can easily encode strings, numbers and booleans alike as bytes, and both objects and arrays as lists. Consider: { "id": 1234, "isEnabled": true, "props": ["abc", 123, false], } This could be encoded in canonical S-expressions as: (object (id "1234") (is-enabled "true") (props (abc "123" "false"))) Granted, one still must convert the strings "1234," "true," "123," and "false" into the expected types, but with JSON one still must check the expected types anyway; it's not that big a difference. And I honestly think that the S-expression version is far more attractive.
- PeterisP 10y ago
  There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.
  - wtbob 10y ago
    > There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected. You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different from, in your code, parsing "123" as an integer, or throwing an error. In JSON one must check that every value is the type one expects, or throw an error. With canonical S-expressions, one must parse that every value is the type one expects, or throw an error. There's really no difference. If one is willing to use a Scheme or Common Lisp reader, of course, then numbers &c. are natively supported, at the expense of more quoting of strings (unless one chooses to use symbols …).

MichaelGG 10y ago

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.

JoshTriplett 10y ago

> I think that XML's bad reputation comes from the fact that it is <adverbial-particle modifies="#123">so</adverbial-particle> <adverb id="123">incredibly</adverb> <adjective>verbose</adjective>. > Also, the whole child/attribute dichotomy is a huge, huge mistake. Those two factors run counter to each other. Attributes decrease verbosity, compared to child elements. I agree, though. A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements much less verbose, and reduces the need for attributes.

wtbob 10y ago
> A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags (<tagname>value</>), which makes child elements much less verbose, and reduces the need for attributes. Then just change '<tagname>' to '(tagname,' and '</>' to ')' and you'll have S-expressions. Consider this: (feed (version 1) (title "Example Feed") (link http://example.org/) (updated "2003-12-13T18:30:02Z") (author (name "John Doe")) (id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6) (entry (title "Atom-Powered Robots Run Amok") (link http://example.org/2003/12/13/atom03) (id urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a) (updated "2003-12-13T18:30:02Z") (summary "Some text."))) That is a canonical S-expression (for a Scheme or Common Lisp reader, just quote the URIs too) version of: <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements. And compare to your proposed version: <feed> <title>Example Feed</> <link>http://example.org/</> <updated>2003-12-13T18:30:02Z</> <author> <name>John Doe</> </> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</> <entry> <title>Atom-Powered Robots Run Amok</> <link>http://example.org/2003/12/13/atom03</> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</> <updated>2003-12-13T18:30:02Z</> <summary>Some text.</> </> </> I think it's pretty clear which is the most readable and elegant.

Mikhail_Edoshin 10y ago

The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority. Child and attribute "dichotomy" is not a mistake. What you mean is that these two samples appear to be equivalent: <foo value="123" /> <foo>123</foo> But they are not equivalent. The first line (with an attribute) is there solely for the computer. When the document is rendered, the human user is not supposed to see anything there unless the computer adds it. The second line (with text content) is there for both the computer and the human user. The text "123" is for the human user; the fact that this text is something called "foo" is for the computer. When the document is rendered, the human user will see "123" here. Maybe computer will enhance something or maybe it will just use it as index or reference, whatever. Most people who don't like XML seem to only encounter it in config files. In config files there's normally no content that needs to be there for the end users, so all data can happily go into attributes. The text content starts to matter when we deal with natural language texts.

wtbob 10y ago
> The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority. Which seems pretty wasteful. > Child and attribute "dichotomy" is not a mistake. It's not for a markup format — as I mentioned, it can make sense there — but, as you mentioned, it doesn't make sense in a config or data file format.