91–100 of 274 posts
You know, when XML looks like this, I don't mind it so much: The thing is, XML in the real world never looks like this . In the real world, XML has an avalanche of obscure namespaces, weird " The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. Of course, you CAN make unreadble JSON as well, XML just makes it so much easier.
Fixed that for you :) https://www.youtube.com/watch?v=wA9kQuWkU7I
You know, when XML looks like this, I don't mind it so much: The thing is, XML in the real world never looks like this . In the real world, XML has an avalanche of obscure namespaces, weird " The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. Of course, you CAN make unreadble JSON as well, XML just makes it so much easier.
Good article, but for some reason he doesn't mention one the best XML UI systems: WPF.
https://docs.microsoft.com/en-us/visualstudio/xaml-tools/des...
Earlier quoted context omitted.
{ "type": "div", "children": [ "The ", { "type": "a", "attributes": { "href": " https://www.json.org/" }, "children": [ "JSON format" ] }, " was invented by ", { "type": "a", "children": [ "Douglas Crockford" ] } ] } I think I prefer the XML :-) Edit: I agree that tagged text is a clear win for XML - for pretty much everything else I'd go for JSON. Edit2: HN ate my formatting, but probably not a bad thing ;-)
["div", "The ", ["a", {"href": " https://www.json.org/" }, "JSON format"], " was invented by ", ["em", "Douglas Crockford"], "."]
> This means there’s no officially supported way to represent the list of movies in an element attribute. We can hack this by encoding the list into an attribute using a comma delimiter:
Michael
Scott
Diehard
Threat Level Midnight
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
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
At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…
The JSON version of the employee org chart is much more semantic and human understandable (to me) as it "cleanly" describes the relationship for reports as a property called "reports" (for those who manage people - they have that property).
But the org chart as XML was anything but obvious to my human eyes, as it was just nested employee elements and at first glance, looked like a single list of employees. Visually interpreting it to know who's a manager, and who reports to whom seems far more difficult in the XML.
But, again, it's in the eyes of the beholder, and one person's clean solution is another person's confusing tangle of brackets.
At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…
It also has the advantage over code that it can be modified with a visual interface designer.
Earlier quoted context omitted.
"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.