[Mirror copy of document from ftp://naggum.no/pub/SGML94/; poster delivered by Erik Naggum at SGML '94 at Tyson's Corner, VA] Implementing the Long-Term Information Investment Protector You can do it once, or you can do it every time you need it. So far, the tools available with SGML systems don't easily allow you to build "filters" or "layers" that you can plug and play with -- which means you do it every time you need it, and you don't think you need it very often. After all, long-term investment is not something you care about when the darn thing won't even print right. One major difference between database systems and SGML systems is that the database system owns and controls the data. This is also true of the proprietary software solutions, but they don't offer the standardized access languages that databases do. Databases maintain consistency because you may manipulate your data only through a well-defined interface. With SGML systems, you can walk right in and clobber the data, and you have to maintain consistency by other means. This makes the kind of changes that frequently occur in DTDs and in operating environments over even the shorter time spans into an administrative nightmare. If your application poses it own demands on your data, validating those and updating historic documents to conform will take an increasing share of your time. For each of your applications, you may want to build tools that can take a small change (delta) and make sure that they do no damage to previously valid documents, and perhaps make the changes that are required to maintain consistency. This is a non-trivial task, but it will be less complicated if you don't have to fight SGML's delimiter recognition at the same time. Well-behaved data lives longer! If you would like to help fund the research into migratory change (delta) management and further requirements to more robust SGML, please drop me a line at .