XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] The year is 2027, and we need to examine archived XML documents from 2007 ...

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS