|
I’m not so sure that use of XML will be swapped out from the many, many, many domains where, as Ihe says, it is a fit-for-purpose technology and a key part of a technology stack that works, for another one just because the other one is extremely widely used
in other, different kinds of domains.
There will very likely be some FOMO driving changes here and there, but there will also be plenty of domain-specific needs driving the opposite, of not breaking something that works and moving to a less sophisticated solution - with all the time,
expense, and broken interfaces that entails, until maturity is eventually again reached with the new interface - without some pretty important benefits from using the new interface. At present, I can’t see what those benefits are. You speak of a larger pool
of resources, but it’s not like the use of XML as a means of data exchange is either esoteric or particularly difficult, and so I don’t see the benefit of spending all that time, money and inconvenience in order to convenience a pool of people that, by your
definition, don’t currently use these interfaces. If they do use these interfaces then they are obviously knowledgeable enough with the use of XML to, well, use these interfaces.
More likely, as new interfaces are needed, and implemented, they will use JSON where appropriate - and continue to use XML where that is appropriate. XML is one of those underlying technologies that have actually aged really well - plenty of people
tried to use it for plenty of things it’s not very suitable for, and, guess what, we don’t use it for those things any more; similarly, there are plenty of things it’s the best solution we have for, and it’s very, very widely used for those things, even though
lots of people who used to use it for those other things it wasn’t suited for aren’t necessarily aware of that.
It’s been extremely interesting for me as a programmer providing an XML editor application over the past 10+ years, that my users’ use cases were never what I grew up using XML for - enterprise programming ecosystems, such as JEE, where XML was
used for anything and everything, and was a poor fit for much of them - but rather are wherever people need to exchange information between loosely coupled systems, and it is extremely widely used there, even today.
Cheers,
Damian
Yes, Ihe, thanks, that well describes the mechanics of IT/software inertia especially for government bodies. The forcefield analysis would surely show, however, that the opposing forces will reduce over time and the forward progress
forces will grow and eventually things will shift. I just wonder if anyone has considered the timescale. (BTW I no longer work directly as employee or even as consultant for public sector so my view of this is from private sector side and how we might be affected
in our dealings with public sector, and from private professional concerns as a software engineer.)
On 2021-11-13 01:20, Stephen D Green wrote:
Data sent to a government body usually has to be deleted after a certain period of time. It cannot be kept longer than is needed.…
Well, that depends on the data and on the government body, doesn't it?
My government has a National Archives body which keeps a lot of data for decades, and tries to keep some data forever. (Which is not all that long, so far, because my country is pretty young. But we have aspirations.)
I imagine agencies like that observe earth and space might want to keep some of their observation data for centuries, because their successors may want to compare future observations to past observations.
While it is being kept, it could be kept in a system,…
"In a system", eh? But systems need some amount of attention and improvement, or they stop working after a while. The OS on which they run change. The hardware on which they run stops being made. And so on. There are few "systems" which keep running
for decades. But data and content can persist for decades and centuries. If I'm writing a contract, and the contractor will generate content which will be important for decades, it seems I should carefully choose the data format, not just the "system".
so the original message might not be what is kept.…
If I am paying Very Much Money to Expensive Government Contractor to produce a manual for my Durable Infrastructure Project, why would I ask them to deliver that manual in anything but the format which I want to keep?
In order for Stephen's initiative to be approved an Expensive Government Contractor will have had to recommend it to the government and because (as I mentioned earlier) FOMO applies to government IT you can be pretty sure the technical aspects
of this have already been looked at.
Assume arguendo that Stephen's initiative passes technical muster. Somebody in govt is going to have to approve Very Much Money for it's implementation as well as navigate the organizational politics of advocating for a technology that is known
to work and to be fit for purpose being swapped out. In that regard I don't see where Stephen's argument is giving that Emperor anything to wear other than "XML is legacy".
Let's talk about the XML is legacy angle. The easiest way to sell that is to piggy back on the cloud native bandwagon because cloud vendors XML support is sparse. However the reasons that is so are ideological, not infrastructural or technical.
IOW they are capable of change as soon as an enterprising cloud vendor sees that there are govt contracts to be won (and therefore money to be made) by supporting XML for govt institutions and (by implication) large enterprises.
The Expensive Government Contractor hired to look into this is best served by putting all this in their report (lest they get sued). So it will be Here you are government - these are the facts - now you go make the decision (or not).
Factored into that decision will be the likelihood and appetite for the decision maker to appear in front of a parliamentary or congressional committee explaining this use of public funds in the event that the end result of forcing a technology
to fulfil a role it was never designed or intended to is everything going tits up. IOW risk and what the reward for taking it is.
--
|
