Re: [xml-dev] It's too late to improve XML ... lessons learned?

On 30 Dec 2021, at 10:44, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

I think the lesson is that a standard technology will ultimately die when its community fractures into groups who take a win/lose approach of cavilier veto-ing whatever they don't need: there is a Mexican standoff and stagnation. (Look at SGML in 1994, for example.)

This disinterest in the needs of others can take the forms of both minimalism ("I don't use feature X" as a justification for completely getting rid of it) and giantism ("I might need feature Z" as a justification for adding it as a required feature in the bundle some faction rams through: despite those who don't need it: XSD?)

This fracturing is almost assured as soon where the community is dominated by U.S. corporations, due to their sociopathic hyper-competitiveness: whatever advances my enemy is my enemy too.

Contrast with the win-win attitude, which allows modest evolution: it does not remove a feature without providing workable alternatives. And it does not add features which shift the complexity goalposts of the standard much (in the wrong direction.)

I prefer to think of the standardisation process in terms that assume less evil intent. There are a lot of local actors thinking about what will work best for them and their customers in the short term; sometimes they will see an opportunity for collaborating with others, sometimes an opportunity for competing with them; sometimes they will decide to implement a standard because they think their customers need it, sometimes they will decide to diverge from a standard because they think their product will be better as a result. All these actors make independent moves; very occasionally (as happened with XML, and briefly with Java) everyone converges on a single standard; more commonly, the industry splits into two camps supporting rival standards; sometimes (as with 4GLs or post-relational databases) it never gets anywhere near a standard.

Occasionally of course (as with Microsoft's abandonment of Java) there is a genuine strategic decision which may include doing things designed to damage competitors. Much more commonly, fragmentation happens slowly and by accident: part of the community decides that an existing standard doesn't meet its needs, so it develops a new version, or a new standard, and the user base splits into two camps.

Fragmentation also happens through an accumulation of non-conformant implementations. Implementors drop or defer features of standards if it reduces the implementation cost without affecting too many users (e.g. XML parsers on node.js don't implement DTDs), and implementors enhance standards if they think it will give them competitive advantage without causing their customers too many interoperability problems.

I don't think there's a rational explanation of why standards are more successful in some areas than others. Clearly there are some things that couldn't happen at all without standards (the web, email), and some where economic forces inevitably result in convergence around a small number of standards (operating system APIs, programming languages, music formats). Standardisation is more difficult when there's rapid technology change (15 years ago all the light fittings in my house were compatible, today I have a dozen different varieties that all take different light bulbs). But a lot, I think, is down to chance.