Cart
[Home] [By Thread] [By Date] [Recent Entries]
From a long term storage view - and for an archivist, that means 2127 instead of 2027, xml is still ideal. And the possibility that parsers may or may not be around in 2127 is perhaps even expected. One must also think in terms of the physical memory. I found an old "mag card" in a collection of materials back in my archivist days. It was basically a punch card sized strip of magnetic material. No one could read it. I even called the local IBM site (who logo on the card told me they manufacturer of the card) and they could not read it either. So I was faced with either throwing out the data or paying a company an exorbitant amount of money to try and find equipment to read the thing. Paul -----Original Message----- From: Len Bullard [mailto:len.bullard@u...] Sent: Tuesday, September 11, 2007 3:50 PM To: Tim.Bray@S...; abcoatesecure-xmldev@y... Cc: xml-dev@l... Subject: RE: The year is 2027, and we need to examine archived XML documents from 2007 ... Given that XML became possible only once the costs of memory and CPUs dropped, the power increased and UNICODE became available, another way to look at the question is to ask if anything lower in the stack (say hardware or other language standards) might change such that XML becomes obsolete the way that SGML did. XML simplified SGML. What might change to make XML become 'too hard'? With XML, a sort of rabbit trail was left back to SGML through Clark's XML/SGML Declaration although I don't know of anyone using it yet. If changes did occur, what would be the XML rabbit trail? Since this is a speculative question, one might want to consider all the possible changes. For example, if the researcher does manage to get memory to work in the third dimension (the racetrack), and density takes another quantum leap forward, or quantum computing becomes practical, what changes might occur? As the costs of the iron go down and the power increases, the code practices become sloppier and programmers begin to do less 'to the metal' work. One might consider that as the user/machine interface became more intelligent, less rigor could be required in the instructions. In 2027, the entity looking at dredging up the XML might not be a human. It might be the case that the rabbit trail consists of little bridges the humans were adding to ensure data goes forward just as markup was added (metadata can be seen as a bridge among islands of certainty). len From: Tim.Bray@S... [mailto:Tim.Bray@S...] Maybe I'm missing something, but XML feels like a safer long-term bet to me if only because almost all those tools are (a) open-source, and (b) written in mainstream languages and (c) written for portability. So you won't get the situation you get in some IT shops I've seen where a horrible old PDP-11 or Unisys box is kept limping along at great expense because they occasionally need some long-forgotten black-box proprietary app. I.e., whatever it is we call a "computer" in 2027 will probably run libxml2 and Jing just fine. -T This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________________________________ 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: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
