cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X

Archived data

AndyEsslinger
1-Newbie

Archived data


Recently I had some issues that involved data from an archived job that
originated in 1999 or 2000. Since the last time it was worked
everything had changed: the DTD, the FOSI, the version of Adept Editor,
even the operating system.

I was just wondering if anyone else keeps source SGML and ancillary
files so that a job can be re-created again in the future. If so, how
much time would pass before you think it would be unreasonable to expect
to be able to re-create a job? If I "document" a time limit it becomes
a feature instead of a bug.

I suspect that Adept Editor may not run on Windows Vista or Windows 7.
I would have to have to reload Windows NT 3.51 for one of these antique
jobs.

Thanks for your opinion,
-Andy
\ / Andy Esslinger LM Aero Tech Order Data
_____-/\-_____ (817) 279-0442 Box 748, Mail Zone 4285
\_\/_/ (817) 777 3047 Ft. Worth, TX 76101-0748

5 REPLIES 5

We keep source SGML for certain documents, but we also keep a PDF
archive of the docs that we retain SGML sources for.

Between the changes caused by DTDs, FOSIs, OS updates, and updates to
the composition engine (I have yet to see an update that maintained
perfect pagination fidelity with current production), the PDF is used to
reprint relics from the past. If we need to revise the SGML source, we
issue a revision against the document/MRU to bring it up to code.

We don't archive prior DTDs/FOSIs. We do our best to maintain
backwards-compatibility, when possible. When it isn't possible, we
usually use some scripting and bring datasets up to date on an
as-revised basis.

And yeah, it's a pain. All legacy is a pain, when you think about it 🙂

-Jason

I also have an archive, dating back to 1995, from Adept 5.0 through 9.0.
All the archives include the SGML source files, DTD and FOSIs, graphics
and any ACL files, for each document. We also have Postscript and PDF
versions of all published documents, so our only need for the SGML
source would be if an revision needed to be published.

It's been a couple of years now since I 'exercised' any of these
archived documents. On Solaris, using Epic 4.3.1, the documents could
be opened in context, although improvements in the parsing of the DTD
did highlight some problematic content models. FOSIs of course were a
different story, none of the pre-Adept 8 FOSIs are compatible without
being converted. Since I was only running the exercise as a point of
interest, I never went to the trouble of converting one.

Most of our documents have had a very consistent structure and the
changes that have happened over the past 14 years mostly involve
extensions to the structure and new composition formats and features.
Just in the last two weeks the possibility of resurrecting 4 documents,
originally published in 1997, has been raised by our technical authors.
However these would be published in the current format and so the 1997
source only needs to be transformed to match the present DTD before it
can be used.

As far as running Adept on Windows XP or Vista, they both have a
Compatibility Mode that allows old programs to 'run' as if on older
Windows versions (back to Windows 95). It would be interesting to see
if this would work - if only there was more time to play!

Cheers,

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

After all the talk of Virtual Machines, this would be the perfect
use-case for a VM instance. Simply hive away the complete O/S,
software, licensing and configuration dependencies in one VM. Whether
it's a Windows NT with Adept or Solaris with Epic, it should all "just
work" when you load it up in a VM application.

However, in your archive it would be important to ensure you have a
versioning scheme or some such that indicates what markup relates to
what VM. Perhaps you can do it by DTD revision number, but I suppose
it depends on the practices at your own workplace.

Even in the future when software and operating systems are totally
different, I think the x86 platform has been so successful that there
will always be methods available to run VMs of x86 instances.

I imagine on their quantum photon computers our grandkids will be able
to run at least 100 different quad core VMs at once 🙂

Cheers,
Gareth

Andy,

Though I am not working with production, I have numerous older files I have kept over the years. SGML and XML. Unlike others (but then this was my job), I maintained a history of previous DTDs and to some degree FOSI's. So opening older files was less problematic.

How long should one keep a file? I guess that is dependent on the file it self. If it is one actively changed through out its life, then I'd probably keep the changes and original from the last revision (unless you have a contractual requirement to maintain ALL the history, but then I'd even go so far as to maintain the DTD and FOSI used to generate the file) If the file is low maintenance, you'll probably keep it just because it is the primary file.

If files go back to the Adept days of Arbortext, then you're going to have some problems with FOSIs (already mentioned in another response). But I have had only minor problems opening a file with the DTD it was done with in current versions of Epic. Even it it was done in SGML. In fact, I really can't go back to the Adept world any longer. I had to reformat the machine they were on a year or so ago.

I agree with David when he says legacy is always a pain. Especially when the legacy maintainers don't want to change. I deal with one group who hammer DTD changes because it does not allow them to continue with the "that's the way we've always done it" mentality. We're trying to move forward by maintaining the legacy as is. 😞

So bottom line, I don't know how long is a valid time. At some point a decision must be made as to dispose, update or what ever the archived data. You may want to periodically test old files in new versions of Epic. If there are major problems then it is probably time to address what to do with them.

Lynn


---- "Esslinger wrote:
>
> Recently I had some issues that involved data from an archived job that
> originated in 1999 or 2000. Since the last time it was worked
> everything had changed: the DTD, the FOSI, the version of Adept Editor,
> even the operating system.
>
> I was just wondering if anyone else keeps source SGML and ancillary
> files so that a job can be re-created again in the future. If so, how
> much time would pass before you think it would be unreasonable to expect
> to be able to re-create a job? If I "document" a time limit it becomes
> a feature instead of a bug.
>
> I suspect that Adept Editor may not run on Windows Vista or Windows 7.
> I would have to have to reload Windows NT 3.51 for one of these antique
> jobs.
>
> Thanks for your opinion,
> -Andy
> \ / Andy Esslinger LM Aero Tech Order Data
> _____-/\-_____ (817) 279-0442 Box 748, Mail Zone 4285
> \_\/_/ (817) 777 3047 Ft. Worth, TX 76101-0748
>
>

We archive all of our old FOSIs, ACL, DTDs and other source code in
Microsoft Visual SourceSafe, but not OS's or Arbortext/Adept Editor
code. We would have to reload the correct version of Arbortext/Adept
editor onto the applicable OS. Some old jobs might require reloading of
the Windows NT 4.0 operating system. Not a pleasant prospect.
Top Tags