Long-term stable technology?

[plnelson]

For decades I've kept a journal in the form of handwritten sheets of paper and photos (I'm a serious photographer).

About 10 years ago I converted it all to HTML, and shortly later I added CSS. Now it's hundreds of HTML pages and hundreds of photos and other documents, and it grows steadily. My goal is to keep it in a form that's platform (XP, Max, Linux, etc) independent and which will still be readable many years from now without having to own a computer museum.

Professionally I'm a sw engineer and I've been getting up to speed on XML technologies (XHTML, XSLT, XSD, etc), and I can see the handwriting on the wall. Most of the tags in my massive journal are in the process of being deprecated!

When do I need to convert this out of traditional HTML by, and what should I convert it TO that will be a long-term stable technology? I don't want to have to go to all the work of convereting this to XHTML 1.1-valid format, only to have to do it all over again a few years later when "XXHTML" comes out!

[vgarcia]

Once your content is in an XML-based format like XHTML, it's much easier to convert to other formats as needed. If I were you I'd move the content up to XHTML 1.0 at least, and use something like XSLT to run the conversion to a new format when/if you ever need it. At that point all you'd have to do is write one stylesheet and run a transformation on your current files to move to a new format

[plnelson]

Once your content is in an XML-based format like XHTML, it's much easier to convert to other formats as needed. If I were you I'd move the content up to XHTML 1.0 at least, and use something like XSLT to run the conversion to a new format when/if you ever need it. At that point all you'd have to do is write one stylesheet and run a transformation on your current files to move to a new format

But the CURRENT philosophical paradigm that got us XHTML 1.1 and stylesheets is the idea of separating the description of the data and its presentation. Sure, that makes sense to us TODAY and it seems perfectly obvious. But it wasn't perfectly obvious to the people in the early 1990's who gave us HTML. Likewise, in a few years there may be a whole DIFFERENT paradigm that will cause some new alphabet-soup of standards. I don't know why that conversion process will be easier until we know what it is.

I recently scanned in dozens of Kodachrome slides my father took 55 years ago. They were in great shape and I scanned them using a Nikon Coolscan V ED that I just bought. Think about it: a 55 year-old presentation standard - a photographic slide - that could still be read with the latest technology!

No one in the interim had to be technologically vigilant to keep converting the slides to the latest technology every 10 years. If that was necessary they would be lost to history. I'm trying to minimize the amount of technological vigilance it takes to keep my journal readable for future generations.

[vgarcia]

But the CURRENT philosophical paradigm that got us XHTML 1.1 and stylesheets is the idea of separating the description of the data and its presentation. Sure, that makes sense to us TODAY and it seems perfectly obvious. But it wasn't perfectly obvious to the people in the early 1990's who gave us HTML. Likewise, in a few years there may be a whole DIFFERENT paradigm that will cause some new alphabet-soup of standards. I don't know why that conversion process will be easier until we know what it is.

As long as the next generation of document formats is text-based (meaning can be written out in some kind of ASCII format), XSLT can transform to it. XSL doesn't just go from tag-based format to another tag-based format. I've seen XSLT that generates C# and Java code and even PDF documents, I don't see why another format would be so hard to target.

[plnelson]

As long as the next generation of document formats is text-based (meaning can be written out in some kind of ASCII format), XSLT can transform to it. XSL doesn't just go from tag-based format to another tag-based format. I've seen XSLT that generates C# and Java code and even PDF documents, I don't see why another format would be so hard to target.

You could say the same thing about going from my current HTML/CSS files to XHTML/stylesheet/whatever files. Sure; it can be done, as long as whoever is doing it has the skills/tools/time/ and alertness to when it's necessary to do it.

I'm a software engineer, so I could do it. But what if something happens to me and my wife wants to leave all this to the local historical society, or some other archives? The idea here is to keep it in a form which preserves the basic benefits of HTML - typographical and page formatting and hyperlinks - in a least-common-denominator fashion that can be read in the future.

That's why I mentioned my father's slides - a presentation format that was still perefectly readable with the technology 55 years later without requiring geeky intervention by all the people iwho had them between.

One thing I'm wondering about is this: Currrently, worldwide, there's more plain-old HTML files floating around than XML-compliant files, partly because XML is newer technology, and partly because it's "geekier" (more complex, more to learn, stricter). Google estimates that they currently index over 4 BILLION HTML documents and they still only index a fraction of the total. XML may be more of the new stuff, but even most of those are probably XHTML 1.0 "Transitional", which means they are practically HTML anyway.

So it may be a very long time before HTML is so obsolete that no one can read it anymore. If that's true then it may make more sense to keep this in HTML and only transition when the NEXT thing after XML comes along.

[zcorpan]

I think tag soup will still be usable in 55 years from now...