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

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

I'd think that something higher in the stack would be more likely to
supersede XML.  XML (or any other such markup) makes explicit what was
previously implicit.  Because it is explicit, it can be processed
reliably by computer with minimal human intervention.  Advances in
storage devices solve the explosion in size that results from explicit
markup.  Some might argue that advances in text processing could make it
unnecessary to explicitly mark many, if not all, of the 350 plus
elements in our current publishing DTD.  I think that's a pipedream, but
such advances should at least be able to separate markup from content.  

Physical obsolescence and logical obsolescence are distinct, even if
intertwined.

The USPTO publishes some 10,000 documents per week in XML, so this
discussion has some relevance to our work.  When a patent file wrapper
reaches age 40, we send it to NARA.  What we will do when the file
wrapper is not paper, is not yet determined, but one possible scenario
is that the USPTO will retain responsibility for keeping archived file
wrappers accessible indefinitely as a kind of adjunct to NARA.  Yes,
"indefinitely" is the correct term.

Much more problematic is how to deal with documents we did not create,
but received from applicants.  If a court wants to see what was
submitted, not what it was transformed into for internal processing or
publishing, will it be possible to render it as it would have been seen
at the time of submission?

In the end, I suspect that the technological uncertainties will drive
legal decisions that will drive cultural and policy changes that will
reshape our concept of "archives" to something much more abstract than
it is at present.  Ink on paper sealed with red wax has a beauty all its
own, but the Magna Carta survives even if that artifact is lost.
Perhaps anything that has not achieved a comparable level of
independence from its physical storage deserves to be forgotten.

(Forgive me, it's late and I'm tired.)

Bruce B Cox
Manager, Standards Development Division
Systems Development and Maintenance Group
U.S. Patent & Trademark Office

Views expressed in this message are my personal opinions and do not
represent official policy of the USPTO.

-----Original Message-----
From: Len Bullard [mailto:len.bullard@uai.com] 
Sent: 2007 September 11, Tuesday 15:50
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
X ML 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.