Re: [xml-dev] It's too late to improve XML ... lessons learned?
I might suggest another influence? I think XML's initial methodology of "don't reinvent the wheel but trim it down and remove some spokes" is identical to the one that was used for JSON.
It is the opposite of Perl's kitchen-sinkism (and HTML 5?): lets pull out the embedded little languages into things in their own right.
(I think XML could still progress along those lines further by chucking the internal subset of the prolog and banning all explicit general entity declarations (by building in the standard mappings by default). This would have left DTDs as pure schemas with no overrides or character issues, and a better path to XSD for people who need standard entities. )
Plus JSON implementers outside _javascript_ took the XML approach that there was not a single mapping from the JSON text to native data structures: though, sure, less abstract than XMLs. This made JDON different, I think, to CORBA IDL.
I think XML was itself the legacy of other currents of thought: little languages from LINUX, abstract datatype (Panasonic etc), compiler compilers (SGML), separation of representation and implementation (IBM, SQL and databases). Tim Bray identofied "dare to do less", "minimum progress to declare victory", "worse is better" (Richard Gabriel) and "You Ain't Gonna Need It" (XP).
So of TeX, NROFF, GML, Scribe grew out of the thinking of the 1970s, SGML grew out of the software engineering zeitgeist of the early 1980s; XML grew out of the resulting zeitgeist in the early 1990s (but had been delayed by the stymieing at ISO); and JSON grew out out the resulting millennial zeitgeist, which also saw the fracturing of markup language syntaxes to pre-SGML incompatibility: markdown, etc.
Why has this tide of innovation (and spliiting out) followed by consolidation (aggregation) stopped in the last decade?
I tend to think it is the deadening hand of the large frameworks: the problem people want to solve is not "how do I solve this problem in a moderately portable way?" But "what do I do to get the job done given that I have to fit in with this framework?" In other words, we hoped in the 1990d we would entered a world where the platform (Windows, Mac, Linux) would not dictate mutually exclusive solutions and ecosystems, but the ubiquity of frameworks has made it worse. (Tangential evidence: job ads that list 20 or 30 frameworks as required knowledge.)
Cheers
Rick
