RE: [xml-dev] The year is 2027, and we need to examine archived XML docu

["Paul Kiel" <paul@xmlhelpline.com>]

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@uai.com] 
Sent: Tuesday, September 11, 2007 3:50 PM
To: Tim.Bray@Sun.COM; abcoatesecure-xmldev@yahoo.co.uk
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] 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@Sun.COM [mailto:Tim.Bray@Sun.COM] 

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@lists.xml.org
subscribe: 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