Not an obvious win as far as I can tell, wouldn't like to fix an ummatched bracket in a document ending in >>>> rather than e.g. </form><div></body></html>. But your mileage may vary.
His other ideas have more or less been implemented, with varying success. XML-Schemas have been introduced which is more powerful that DTD's. Some schema languages can indeed do complex computations for better or worse.
The macro-expansion approach is how XSL-formatting worked, and it turned out it was not as powerful or elegant as the CSS approach. It made sense when coming from a publishing background, but didn't predict dynamic interactive web pages.
"Not an obvious win as far as I can tell, wouldn't like to fix an ummatched bracket in a document ending in >>>> rather than e.g. </form><div></body></html>. But your mileage may vary."
HTML would then be an acronym for Lots of Irritating Single Angle Brackets.
But in a big HTML you'll still be lost if you don't use indenting or a tool. At the end of the file you'll still have several close-tags one way or the other
One way would be to rewrite this in an easier way (but less canonical). In math there are several ways of doing that, for example:
Operator precedence and some defaults simplify, so you can write 3+2x(3+4) instead of (3+(2x(3+4)))
But it would probably make things worse for a text markup language.
I think he's more suggesting that XML is a fail because it attempts to take patterns that were designed (and work well) for document markup, and just mindlessly apply them to a very different task - data definition.
XML's totally fine for markup. It's also totally fine for situations where the primary content of the file is the XML tags themselves. For example, it's got its share of irritating gaffs but overall I'm rather fond of XAML as a way to define user interface layout.
But I've also seen a lot of monstrosities in XML. Situations where the tags themselves comprise 80% of the file, and yet are almost entirely redundant. Situations where the markup primarily serves to obfuscate the data itself. Situations where a file format changes to XML, bringing about a switch to routines that use an off-the-shelf XML parser. . . that still manage to consume twice as many lines of code as the from-scratch custom parser they replace.
His other ideas have more or less been implemented, with varying success. XML-Schemas have been introduced which is more powerful that DTD's. Some schema languages can indeed do complex computations for better or worse.
The macro-expansion approach is how XSL-formatting worked, and it turned out it was not as powerful or elegant as the CSS approach. It made sense when coming from a publishing background, but didn't predict dynamic interactive web pages.