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

[Frank Richards <frank@therichards.org>]

Xml is text. Archival text storage is a well understood issue. Rag paper 
in a proper climate has a demonstrated life of centuries, which can be 
reasonably extrapolated to millennia. And you get to store not only your 
metadata but your decoding instructions the same way.

Len Bullard wrote:
> That was the kind of problem that led me to SGML originally.  NASA could not
> recover Mariner data.   The US Army was still selling HAWKs with carbon
> copied documents typed in the late 50s and so on.   From the time when
> hardware was so diverse that software had to bridge the chasm until now,
> there have been very dramatic improvements.  At every meeting, the phase
> 'long lifecycle' was heard.  The fortunate occurrence was the conjunction of
> long lifecycle and interoperability in the same discussion as people began
> to realize the low hanging fruit with the most sugar was data portability,
> thus markup, despite the hairy near run beginning came to the fore.  At the
> same time, hypertext was a fad, then a possibility and now a necessity as
> the problem of intersystem controls was realized and solved, once again,
> with data portability (aka, loose coupling) emerging as the low hanging
> fruit.
>
> So today we are in pretty good shape with the complexity of operation
> possible over the web testifying that we can do what we thought two decades
> ago would not be done in our lifetimes.  On the other hand...
>
> The challenge is still that as we can do more, we do more.  When we were
> working on the US Navy MID, John Junod asked about virtual reality and the
> team thought that so far in the future, we wouldn't discuss it.  Less than
> three years later, VRML was born.  Now we have Second Life, et al and
> Serious Games plus real-time visualization, so the scope of reuse and the
> range of presentations keeps increasing.   Integration is deeper and more
> co-dependent. We also are doing more server-side representation (eg, ASP
> user controls) that have an XML representation but where the metaMeat isn't
> what we need.  The beef is in the code behind and the information is not
> declared; it is computed.
>
> As that happens, the ability of XML to be the sole bridge is diminishing
> because the dreaded 'S' work really is a problem in that true
> interoperability and long lifecycle semantics remain the challenge for the
> 2027 or 2127 timeframe.  We are pushing more and more complex relationships
> into ever smaller devices with different kinds of storage models.  Getting
> it out in 20 years may be precisely the same problem you have with your mag
> strips and I have with my 9-track tapes. 
>
> Medium is mechanical and XML isn't much help there.  Or is it?
>
> len
>
> From: Paul Kiel [mailto: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
>
>
> 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
>
>