Re: Re: How long before services sending/receiving XMLmight ne

On Sat, Nov 13, 2021 at 4:35 AM Jim DeLaHunt <list+xml-dev@j...> wrote:

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 [expletive deleted] up. IOW risk and what the reward for taking it is.