6 ms·
> Apparently web standards folks in the early 2000s thought the future was XML all the way down. It should have been, but just like the masses rejected LISP fo
by zelly 6y ago
> Apparently web standards folks in the early 2000s thought the future was XML all the way down.
It should have been, but just like the masses rejected LISP for its parens, the masses rejected XML for the closing tag. We could have avoided PHP and the zoo of MVC frameworks.
- arpa 6y agoWe could have avoided the bedlam of javascript hacks if browsers had supported XSLT2.
- rabidrat 6y agoI tried programming in XSLT and it was not fun. I'm sure if it took off we'd have the equivalent of Clojure that compiled down to it, but by itself it is not a hacker's language, if you know what I mean.
- mst 6y agoSXML and SXSLT did that in scheme and were really rather good fun.
- recursive 6y agoIf only XML wasn't so damn complicated, it might have had a chance. People love to point at close tags, but there's a long list of more serious problems. External entities, namespaces within namespaces, CDATA, namespaces that confusingly look exactly like URLs, but aren't, parser vulnerabilities.
- int_19h 6y agoThe way XML does namespaces is one of the best things about it - you can host any XML dialect within another, with no name clashes, and without losing the schema identity of embedded parts. Infinite data composability, subject only to the constraints placed by schema authors. And namespaces are URIs, so they can be URLs. The bad smell was mostly coming from all the things inherited from SGML - CDATA, entities etc. Although I would also add that separation into elements and attributes is not a particularly convenient way to model many things; it mixes up differences that should really be orthogonal (ordered/unordered, atomic/composite etc).
- recursive 6y agoI don't see why you even need the concept of namespaces to do that. In my schema, I have a <foreignDocument> element, whose contents is defined to be a foreign document.
- zelly 6y agoAll of the things you mentioned serve a purpose that, at scale, would have to be replicated in some ad-hoc manner in JSON. Yes XML is more expensive to parse, but so is all the extra stuff you have to do to get around the various limitations of JSON, which could have been done cheaply by an optimized XML parser.
- otabdeveloper4 6y ago> We could have avoided PHP and the zoo of MVC frameworks. I doubt that. Javascript frameworks have their value inside a corporation - they enable replaceable cog worker programming. The result sucks, but hiring and replacing React programmers is easier.
- lattay 6y agoProgramming languages are addressed to humans, XML is addressed to machine. That is the difference. BTW the problem with lisp is not the parens, it is that it is too powerful for its own good. C++ and Java got there popularity from there restrictions really.