4 ms·

I have yet to read anything that convinces me that XML is good for anything. Just because XML in certain cases is less bad than some other cherry-picked technol

I have yet to read anything that convinces me that XML is good for anything. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options. See also Erik Naggum's legendary rant: https://www.schnada.de/grapt/eriknaggum-xmlrant.html https://www.schnada.de/grapt/eriknaggum-xmlrant.html

mettamage 7y ago
How about simple DSL layouts?
- michaelmior 7y ago
  Do you mean a simple DSL for layouts?
sacado2 7y ago
Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): I have yet to read anything that convinces me that XML is good for anything. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options.See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a> What would be the JSON/YAML/TOML equivalent?
- ben509 7y ago
 The HTML doesn't represent the classes properly. The LaTeX would take a simpler approach: \begin{spanned} I have yet to read \textit{anything}... \end{spanned} Since there's no Javascript, probably no need for the class variables. And, of course, you can just write your own macros as you need them.
- ChrisSD 7y ago
 Side note: You've overdone the character entities a bit more than necessary.
 - sacado2 7y ago
 I know, not my fault, I just copy/pasted the actual source code of the page while I was commenting.
- adamlett 7y ago
 In order for me to answer that, you must be more specific about the purpose of the representation. For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.
 - sacado2 7y ago
 That's a very good point. Thing is, markdown (or a subset of it, as on HN) is very limited. Great for short comments, bad when you want to do something a little more complex, like a blog post (I always end up addding some HTML here and there in my markdown blog posts, when I want to include a video for instance). The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too. So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
 - adamlett 7y ago
 So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information. If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.
austincheney 7y ago
Before reading this please note that I am not advocating for or against XML. A well reasoned XML instance can replace HTML for most things from presentation, accessibility, interaction, content negotiation, and so forth. You can apply JavaScript and CSS immediately to an XML instance. You don't get any of that capability with JSON, YAML, or anything similar. I really think the people who hate XML the most are those are those who lack the imagination to move beyond raw data and query relationships. I agree XML isn't good at this, which is why it completely offloads that capability to a sibling technology: DOM. I have also never seen anybody with a comfortable understanding of the DOM believe JSON, YAML, and the like fill that void, but then these other technologies do not primarily exist to structure human consumable content directly for human consumption. The most important part of the article you linked to describes markup relevance as a percentage of syntax overhead. The more the described content becomes an extraction of computer oriented data the more that percentage goes up thus making XML progressively a bad decision, but the opposite is also true. The article really nails its bias in this regard by fixating on data as a facet opposed to information as a structure. When the goal is to provide primarily a structure, as opposed to fundamentally offering a syntax, the cost to scale grows inversely to the quantity of content provided. That is largely thanks to lexical scope, which allows a richer interpretation of context without any additional or specified syntax. That is the nature of information versus data. Conversely, data conveyance schemes that exist to primarily offer a syntax scale proportionally to the content provided because the ratio of syntax to content is static without any additional meaning. For some clarity on the difference between data, information, and knowledge I suggest the DIKW model: https://en.wikipedia.org/wiki/DIKW_pyramid https://en.wikipedia.org/wiki/DIKW_pyramid

mettamage 7y ago

How about simple DSL layouts?

michaelmior 7y ago
Do you mean a simple DSL for layouts?

sacado2 7y ago

Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): I have yet to read anything that convinces me that XML is good for anything. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options.See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a> What would be the JSON/YAML/TOML equivalent?

ben509 7y ago
The HTML doesn't represent the classes properly. The LaTeX would take a simpler approach: \begin{spanned} I have yet to read \textit{anything}... \end{spanned} Since there's no Javascript, probably no need for the class variables. And, of course, you can just write your own macros as you need them.
ChrisSD 7y ago
Side note: You've overdone the character entities a bit more than necessary.
- sacado2 7y ago
  I know, not my fault, I just copy/pasted the actual source code of the page while I was commenting.
adamlett 7y ago
In order for me to answer that, you must be more specific about the purpose of the representation. For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.
- sacado2 7y ago
  That's a very good point. Thing is, markdown (or a subset of it, as on HN) is very limited. Great for short comments, bad when you want to do something a little more complex, like a blog post (I always end up addding some HTML here and there in my markdown blog posts, when I want to include a video for instance). The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too. So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
  - adamlett 7y ago
    So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information. If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.

austincheney 7y ago

Before reading this please note that I am not advocating for or against XML. A well reasoned XML instance can replace HTML for most things from presentation, accessibility, interaction, content negotiation, and so forth. You can apply JavaScript and CSS immediately to an XML instance. You don't get any of that capability with JSON, YAML, or anything similar. I really think the people who hate XML the most are those are those who lack the imagination to move beyond raw data and query relationships. I agree XML isn't good at this, which is why it completely offloads that capability to a sibling technology: DOM. I have also never seen anybody with a comfortable understanding of the DOM believe JSON, YAML, and the like fill that void, but then these other technologies do not primarily exist to structure human consumable content directly for human consumption. The most important part of the article you linked to describes markup relevance as a percentage of syntax overhead. The more the described content becomes an extraction of computer oriented data the more that percentage goes up thus making XML progressively a bad decision, but the opposite is also true. The article really nails its bias in this regard by fixating on data as a facet opposed to information as a structure. When the goal is to provide primarily a structure, as opposed to fundamentally offering a syntax, the cost to scale grows inversely to the quantity of content provided. That is largely thanks to lexical scope, which allows a richer interpretation of context without any additional or specified syntax. That is the nature of information versus data. Conversely, data conveyance schemes that exist to primarily offer a syntax scale proportionally to the content provided because the ratio of syntax to content is static without any additional meaning. For some clarity on the difference between data, information, and knowledge I suggest the DIKW model: https://en.wikipedia.org/wiki/DIKW_pyramid https://en.wikipedia.org/wiki/DIKW_pyramid