(Do you prefer to write HTML documents as S-expressions?)
Having explicit end tags makes it harder to make well-formed documents that don't clash their closing tags.
Consider a very typical sort of HTML error:
<table>
<tr>
<td>
</tr>
</td>
</table>
Interleaving tags is never correct, yet XML allows us to do it (and I've seen it happen a lot).The comparable S-Expr shows how it is just plain impossible to interleave tags:
(table
(tr
(td)))
You might ask yourself, "which close paren closes which list?" if the document were particularly gnarly. But if we're talking about particularly gnarly documents, then XML can be just as ambiguous. You'd be using a text editor that highlighted matching parens for you, at that point, just as much as you'd be using one that highlights matching close- and end-tags.Actually, yes. I use CL-WHO[1] a lot, in which one can write:
(:html
(:head
(:title "Foo bar")
(:link :rel "stylesheet" :href="baz.css"))
(:body
(:p "Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Vestibulum ullamcorper efficitur purus, at suscipit nunc luctus vitae.")
(:ol
(:li "Cras vel est accumsan, malesuada leo eu, iaculis nulla.")
(:li "Proin nec mi feugiat, posuere enim in, vehicula erat.")
(:li "Morbi vitae purus nec neque posuere pharetra ultricies in nibh.")
(:li "Nam maximus lectus faucibus, ullamcorper lectus aliquam, aliquam lectus."))))
Which I contend is prettier than the equivalent HTML.I can't say anything about liking verbose tags, which seems to me a matter of taste, but moving around S-expression blocks is easy: C-SPC to set the point, M-C-f to move forward one S-expression, C-w to cut the current region, navigate to where one wants it, C-y to yank the cut region.
Granted, this is using emacs, which really had better have good S-expression-editing capabilities after 40 years!
And I like that XML block moving is even manageable with ed, which I actually use sometimes. Well, and vi.
This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is one data element I want the most help with serializing/deserializing, it's freaking Dates. All the other ones are super easy in comparison. There's just way to much subjective, dirty, human culture tied up in Dates.
The only thing that I think is objectively better in all cases about JSON over XML is the less verbose end-structure syntax. I think XML only has Attributes because Tags have this silly need to state their name both as they enter and exit the room.
For simple, unnestable data elements, having the more efficient Attribute starts to look attractive.If XML were more the form:
It's actually only one more additional, required character to add than if the attribute value were specified as an element instead. Heck, why stop there? Do we really need to have quite all of those angle brackets now? How about we just get rid of all the ones we can assume: And finally, who even likes angle brackets? I've never enjoyed the dual duty they play as delimiters in XML and operators in other languages. Let's use a common set delimiter, something like square brackets or maybe parentheses. Now where have I seen this before?PS: JSON that is as nearly as equivalent as I can make it is not much less verbose than original XML, and requires some level of convention to make up for the differences:
Though I'm sure in common practice it'd have a lot of the original metadata of the XML version thrown away: