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?
When I worked in public sector I used to encourage my colleagues to keep the original messages for audit to look at (typically a year after the data exchange), but there was not much appetite for that. Obviously such details of data processing will vary a lot.
Were those messages ephemera? I can imagine colleagues getting rid of ephemera. But not all "data or documents" which governments collect are ephemera.
Best regards,
—Jim DeLaHunt
----
On Sat, 13 Nov 2021 at 09:03, Jim DeLaHunt <list+xml-dev@jdlh.com> wrote:
I think you are still framing the question differently than I would. It sounds like you regard the data as a transient artifact, and the real value lies in the computation done at the origin end or at the receiving end in the present time.
But when you said, "governments currently require data or documents to be sent to them in XML format", I'm thinking of that data as a potentially valuable and long-lasting asset in its own right. 20 years later, someone in the government may want to read the second paragraph of the document you sent back in 2021, because it answers a question they will have then.
Right now, I am in an email conversation with someone about a community project I worked on in year 2000. I am looking through the archive of files and email that were on my computer 21 years ago to answer their questions. The data or documents I used then, I stored in the formats I was using back then. I did some computation (reading, editing, printing, discussing, whatever) on the content at the time, and their formats served that purpose. But they have a additional value now for what they can remind me about the old project. The formats I chose then affect the value of this content to me today. That experience teaches me to choose formats today that are likely to still be usable in the future.
Best regards,
—Jim DeLaHunt
On 2021-11-13 00:50, Stephen D Green wrote:
Hi Jim
Isn’t that on an assumption that the data is persisted in the format it was exchanged? Wouldn’t it be more likely that the exchange format will be transient, deleted immediately it has been deserialised?
RegardsStephen Green--
On Sat, 13 Nov 2021 at 03:10, Jim DeLaHunt <list+xml-dev@jdlh.com> wrote:
Stephen:
Your question below frames the choice as about serialisation options ("is there more reason to serialize it as XML or as another format"). I would instead frame the choice as about what kind of information artifact do you want to have: a pile of information encoded using XML, or using CSV, or using JSON? I would make that choice in part with an eye to how long will that pile of information persist, and what someone might want to do with it 20 or 30 years in the future.
What I take from the conversation on this list is that if the information is encoded using the right XML language (and schema etc.) then it will be a more comprehensible, re-usable, and thus more valuable asset in future decades with future systems, than will be the same information encoded as CSV, or worse yet, JSON. I could be wrong about that. I'm not an expert.
But I do think that it matters how you frame the choice.
—Jim DeLaHunt
On 2021-11-12 04:58, Stephen D Green wrote:
Given that systems typically hold data in some kind of code model before it is serialized to a final character encoded format required by the government such as XML, CSV (yes, right) or JSON, is there more reason to serialize it as XML or as another format such as CSV or JSON? Or is serialization to JSON so commonplace that there is little reason to look any further if given the choice? I could understand it if serialization to JSON poses a problem when the government puts necessary constraints on that JSON. Is the understanding of the practicalities of the possibilities for constraining the final, transferred data/document a reason to stick with XML? UTF-*, escaping, choices of alternatives in the text syntax, etcetera?
--
On Tue, 9 Nov 2021 at 16:30, Stephen D Green <stephengreenubl@gmail.com> wrote:
Hi XML Dev’ers,
Do you have any opinion on how long software systems communicating with each other (one-way or two-way) using XML might be able to continue to use XML this way? If, say, governments currently require data or documents to be sent to them in XML format, what professional advice would you suggest about how long would be reasonable before this use of XML should be replaced? Or do you think such uses of XML could reasonably be perpetual?
Many thanks for your consideration.
Stephen Green--
----Stephen D Green
----Stephen D Green
----Stephen D Green-- . --Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada Canada mobile +1-604-376-8953
----Stephen D Green
----Stephen D Green
--
. --Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
multilingual websites consultant
2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada
Canada mobile +1-604-376-8953