RE: It's too late to improve XML ... lessons learned?

[Roger L Costello <costello@mitre.org>]

Thank you Michael and Peter for the incredibly fascinating description of the complex, evolutionary forces on technologies/standards.

Michael wrote:

> progress is often achieved by stripping out the debris
> of complexity that accumulates over time, and starting
> afresh with a clean sheet of paper.

Recently I watched a TED talk in which the physicist Leonard Susskind recalls his friend Richard Feynman. Michael's comment about "stripping out the debris of complexity" reminded me of the following words [1] from Susskind’s talk:

"Feynman’s scientific style was always to look for the simplest, most elementary solution to a problem that was possible. If it wasn’t possible, you had to use something fancier. No doubt part of this was his great joy and pleasure in showing people that he could think more simply than they could. But, he also deeply believed, he truly believed, that if you couldn’t explain something simply, you didn’t understand it." 

/Roger

[1] https://youtu.be/6Waurx8e-1o?t=548

From: Peter Hunsberger <peter.hunsberger@gmail.com> 
Sent: Friday, January 7, 2022 9:56 AM
To: Michael Kay <mike@saxonica.com>
Cc: Alexander Johannesen <alexander.johannesen@gmail.com>; xml-dev@lists.xml.org
Subject: [EXT] Re: [xml-dev] It's too late to improve XML ... lessons learned?

The other major influence is the "network" effect.  For TCP/IP, it was easier and cheaper to use than Token Ring, so it crept into more places faster and once that happened it made no sense to have multiple standards.  The same thing happened with JSON; Javascript became widely available on the browser, so using some JavaScript like datatype to work with the server was extremely compelling.  Once that happened why use another data format to connect your server to other servers?  You already had something that worked well enough for data transport.  The major difference here is that XML and JSON can coexist much easier than TCP/IP and Token Ring so it wasn't an all or nothing victory in the case of JSON.

The network effect also helps explain why we haven't seen much evolution in XML even where it is established.  Unless the changes can be backwards compatible it usually impacts your entire ecosystem to make a change, it's rarely a point to point change and even when it is, you have to own both sides of the data exchange to make it happen.  Yes, API versioning happens all the time, but this is much deeper, you can't just add another endpoint, you've got to have frameworks designed to support multiple serializers and in the world where XML grew up that was extremely rare.  At least until JSON came along, but now you've got JSON so who needs another version of XML? The XML serializer is there just to talk to that old mainframe in the corner that nobody is ever going to touch...


Peter Hunsberger


On Fri, Jan 7, 2022 at 3:16 AM Michael Kay <mailto:mike@saxonica.com> wrote:
Some excellent points here from Rick and Alexander.

I think with most technologies/standards we tend to see

(a) an era of experimentation, where lots of people invent new things

(b) followed by an era of consolidation, where a small number of winners emerge

The number of winners after phase (b) is highly variable. With database technology, it got down to one (SQL). Similarly with the networking stack (TCP-IP), and the web (HTTP / HTML / CSS / JS), and character sets (Unicode). With operating systems it got down essentially to two (Unix / Windows). In most of these cases there were epic contests before winners emerged. With procedural programming languages it never got down to less than half a dozen, though Java looked like a promising convergence point for a while. Some other technologies, like 4GLs and NoSQL databases, withered on the vine primarily because they failed to achieve this convergence.

The forces that determine whether convergence happens and how long it takes are essentially a battle between the desire for innovation and the desire for interoperability. (The pressure for innovation comes primarily from vendors who want a USP rather than from users who want new features, of course).

Once consolidation is achieved, things tend to remain stable for a very long time: it becomes very hard for anyone to break the consensus. If a breakaway does occur, it's most likely to emerge from a niche, or from some technological disruption (voice over IP, say). If anyone ever breaks the 50-year-old duopoly of Windows and Unix, it will probably be some operating system designed for a niche market.

So where does XML fit in this picture? Until 1998 there was a very long period of experimentation; there were some standardisation candidates (SGML, ASN.1, EDI) but by and large, the scene was highly fragmented. The convergence on a single standard was unusually sudden, and I've always been puzzled as to what exactly were the industry dynamics that led to such an explosion of rapid adoption: one of them undoubtedly was the low cost of implementation and adoption. But I think that the very rapidity of this adoption also meant that the consolidation phase was an unstable equilibrium: because it was the only game in town, people embraced it a bit too eagerly for things it was never designed to do. Unlike databases, operating systems, and character sets, it's an area where the benefits of doing something different can exceed the costs, so it was easy for a breakaway niche such as JSON to emerge.

When a breakaway occurs, it's usually a technology that's simpler, less capable, but better suited to the needs of people who need something simple. The old guard maintaining the consensus thus tend to dismiss it as kids' stuff. This ignores the lesson that progress is often achieved by stripping out the debris of complexity that accumulates over time, and starting afresh with a clean sheet of paper.

Michael Kay
Saxonica

> On 7 Jan 2022, at 05:37, Alexander Johannesen <mailto:alexander.johannesen@gmail.com> wrote:
> 
> Stephen D Green <mailto:stephengreenubl@gmail.com> wrote:
>> I think JSON succeeded because it was already existing and got discovered so it was free
>> and already had traction and some sanction as part of Javascript.
> 
> Let us all not forget that there was a huge shift in data usage,
> control and manipulation from the old days of powerful servers and
> rubbish browsers, to the new world of all-singing-all-dancing
> standardized browsers of speed and power. JSON came with that new
> platform when XML wasn't looking.
> 
> I've spent my whole life on both sides of this chasm, and, well, I
> certainly wish that smarter people could create an XPath-like
> implements (right in JS/TS itself, not as yet another bloody
> library...) for JSON (all the current libraries are ... umm, not in
> the ballpark of what's needed ... I used to be an XPath wiz, and look
> at me now *sigh*) both for schemas as well as object/data access.
> 
> Because all the smart heavy-hitters on the backend were too busy with
> XML (making it more bloated and complex), the lighter punters on the
> browser side forgot the typification aspect in JSON. Damn, we were
> *this* close!
> 
> 
> Cheers,
> 
> Alex
> -- 
> Information Alchemist, tone modulator, swords master
> http://thinkplot.org | http://linkedin.com/in/shelterit | http://sheltered-objections.blogspot.com
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: mailto:xml-dev-unsubscribe@lists.xml.org
> subscribe: mailto:xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: mailto:xml-dev-unsubscribe@lists.xml.org
subscribe: mailto:xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php