3 ms·

If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious

If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. The fundamental issue with XML is its impedance mismatch with common data structures which forces using Object to XML mappers (whether explicitly or implicitly). It's more or less solved with XML Schemas or DTDs, but if you're looking at just XML, you can't tell whether some element is an array or a single node. Thus JSON is better suited for serialization.

quietbritishjim 6y ago
> If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. That is really not what attributes are for. I feel a bit of a fraud posting that because I'm not an XML expert and so not really clear what they actually are for. (This reenforces the parent's point: you need to be an expert to know what such a fundamental feature is for.) I remember it's something like "something used to help interpret the actual value" e.g. units of measurement. But most of the time, even if it's non-repeating with no children, you're supposed to use elements rather than attributes. One problem here is that attributes are so much more compact (and so often easier to read) than elements that it's tempting to use them in places where you ought to use an element (and many people over time have given in to that temptation). Another problem is that the distinction between attributes and elements is almost never useful. That was the parent comment's point by the looks of things. > The fundamental issue with XML is its impedance mismatch with common data structures That's probably part of it, but I think at least as problematic is that it has many features that most of the time you don't need and don't want to have to care about. Things like CDATA (also mentioned by the parent comment), custom entities, external entities, DTDs (which can be inline in XML files so you need to know all about DTDs to understand XML properly). That's why there are all sorts of weird XML vulnerabilities that JSON doesn't have. Did you know you can make an XML file that reads your /etc/passwd file when it's parsed? That is not an issue with JSON.
- sergeykish 6y ago
  HTML tag and attribute is markup. Strip it and document would be still legible for a human being. Markup is non human part - presentation, semantic web. Confusion arise once a human observer is lost.
  - quietbritishjim 6y ago
    Thanks, I found this explanation really helpful, and almost obvious in retrospect (as the best explanations often are!). I had been thinking that all of these extra features that XML have are just a case of massive overengineering that no one would ever need. In fact it's a case of taking something fundamentally meant for text documents with extra markup, as the name implies, and misapplying it to config files and IPC messages which are just not the original domain at all.
    - sergeykish 6y ago
      Thank you. I think we should draw on XML strength points. People read articles in browser, not plain text. "Add to cart" is just a POST request with id curl -d id=foo yet we have forms and interactivity. Like in literate programming text and data live together, interactive application like a Smalltalk image. In XML we can separate data from presentation. <?xml-stylesheet type="text/css" href="foo.css"?> <?xml-stylesheet type="text/xsl" href="bar.xsl"?> <root>... Machine receives data, human receives application with documentation, builder. That's exactly what we have today except UI can be plugged to any stored document. To good to be true. I think XML was killed by poor usability. Plain text XML, XHTML and XSLT authoring is not fun. I am trying to uncover it from DOM perspective [1], so far I like it more than Markdown. XHTML and HTML is just a serialization format. HTML is not a good one [2], [3], [4]. XSLT may have nice GUI or compact syntax like RELAX NG. [1] http://sergeykish.com/live-pages http://sergeykish.com/live-pages [2] http://sergeykish.com/script-style-is-cdata-in-html http://sergeykish.com/script-style-is-cdata-in-html [3] http://sergeykish.com/pre-newline-ignored-in-html-test http://sergeykish.com/pre-newline-ignored-in-html-test [4] http://sergeykish.com/content-after-html-appended-to-body-in-html http://sergeykish.com/content-after-html-appended-to-body-in...

quietbritishjim 6y ago

> If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. That is really not what attributes are for. I feel a bit of a fraud posting that because I'm not an XML expert and so not really clear what they actually are for. (This reenforces the parent's point: you need to be an expert to know what such a fundamental feature is for.) I remember it's something like "something used to help interpret the actual value" e.g. units of measurement. But most of the time, even if it's non-repeating with no children, you're supposed to use elements rather than attributes. One problem here is that attributes are so much more compact (and so often easier to read) than elements that it's tempting to use them in places where you ought to use an element (and many people over time have given in to that temptation). Another problem is that the distinction between attributes and elements is almost never useful. That was the parent comment's point by the looks of things. > The fundamental issue with XML is its impedance mismatch with common data structures That's probably part of it, but I think at least as problematic is that it has many features that most of the time you don't need and don't want to have to care about. Things like CDATA (also mentioned by the parent comment), custom entities, external entities, DTDs (which can be inline in XML files so you need to know all about DTDs to understand XML properly). That's why there are all sorts of weird XML vulnerabilities that JSON doesn't have. Did you know you can make an XML file that reads your /etc/passwd file when it's parsed? That is not an issue with JSON.

sergeykish 6y ago
HTML tag and attribute is markup. Strip it and document would be still legible for a human being. Markup is non human part - presentation, semantic web. Confusion arise once a human observer is lost.
- quietbritishjim 6y ago
  Thanks, I found this explanation really helpful, and almost obvious in retrospect (as the best explanations often are!). I had been thinking that all of these extra features that XML have are just a case of massive overengineering that no one would ever need. In fact it's a case of taking something fundamentally meant for text documents with extra markup, as the name implies, and misapplying it to config files and IPC messages which are just not the original domain at all.
  - sergeykish 6y ago
    Thank you. I think we should draw on XML strength points. People read articles in browser, not plain text. "Add to cart" is just a POST request with id curl -d id=foo yet we have forms and interactivity. Like in literate programming text and data live together, interactive application like a Smalltalk image. In XML we can separate data from presentation. <?xml-stylesheet type="text/css" href="foo.css"?> <?xml-stylesheet type="text/xsl" href="bar.xsl"?> <root>... Machine receives data, human receives application with documentation, builder. That's exactly what we have today except UI can be plugged to any stored document. To good to be true. I think XML was killed by poor usability. Plain text XML, XHTML and XSLT authoring is not fun. I am trying to uncover it from DOM perspective [1], so far I like it more than Markdown. XHTML and HTML is just a serialization format. HTML is not a good one [2], [3], [4]. XSLT may have nice GUI or compact syntax like RELAX NG. [1] http://sergeykish.com/live-pages http://sergeykish.com/live-pages [2] http://sergeykish.com/script-style-is-cdata-in-html http://sergeykish.com/script-style-is-cdata-in-html [3] http://sergeykish.com/pre-newline-ignored-in-html-test http://sergeykish.com/pre-newline-ignored-in-html-test [4] http://sergeykish.com/content-after-html-appended-to-body-in-html http://sergeykish.com/content-after-html-appended-to-body-in...