<html> <body> Hi, This message contains some replies to recent mail, plus a proposal at the end.  <blockquote type=cite class=cite cite="">It is naive to assume the software on which the data is accessed will not change.</blockquote> I think that if you go back and read my note you will find that I acknowledge this.  The difference is that if you choose software that is not widely used, you are more likely to incur the expense of creating its own conversion software.  By going with established software packages, it is more likely that you will be able to get the necessary conversion software from the community. <blockquote type=cite class=cite cite="">The requirements for the Museum digital repository extend beyond the requirements of the SPG.</blockquote> I don't claim to know the specific charter of the SPG.  However, a committee charged by the museum with "software preservation" should have essentially the same requirements as the museum.  Can you please clarify how the preservation requirements that the museum would have us investigate are any different from the preservation requirements of the museum itself? <blockquote type=cite class=cite cite="">there seems to be a rush to choose a technology solution </blockquote> The discussion has gone on for over 2 years.  We still don't have a decision on the technology, or apparently even the requirements.  So let's take the requirements that we have and select a technology to start our first iteration.  The rush is to change the way that we've been working and the time scale that we've been operating on. <blockquote type=cite class=cite cite="">Would the collective 'we' on this list please refrain from suggesting solutions to this 'problem' until the museum staff has time to actually generate a REQUIREMENTS document?</blockquote> The discussion about technology has been going on in the SCC/SPC for over 2 years.  I don't know how much of that time a requirements document has been an issue.  So let's get the requirements document done this month.  Also, since the SPC is apparently chartered with the preservation of software, it should be involved in generating the requirements document. <blockquote type=cite class=cite cite="">The critical requirement is that the data entrusted there be verifiable and invariant.</blockquote> Good!  A requirement!  Let's get more of these. Can you please clarify for me what the "verifiable" requirement is?  I know of multiple kinds of verification, and want to understand what the museum's needs are for verification. As I stated in my previous note, there are numerous documents that the museum should be managing (whether considered as part of the archive or not) that will need to change (in the sense that a new version will replace the old for general use, not that the original version can't be retrieved.)  Are you suggesting that such documents won't be part of the museum's collection?  Or are you proposing that we have two management systems, one for documents that we expect will never change, and one for those that we expect might change? <blockquote type=cite class=cite cite="">Subversion, or any other system based on mySQL or postgres ain't it.</blockquote> What is the requirement that they violate?  Unless the requirements are clearly stated, we can't make wise choices.  There are thousands of projects out there entrusting their software to Subversion.  As a software project completes, they still keep their software in its care:  they expect it to be there for them when they need it.  They expect that their software won't have somehow been transformed.  While we may be looking at a longer time horizon, I don't see that our requirements differ much from theirs.  <blockquote type=cite class=cite cite="">I'm sorry about being so blunt, but as an engineer I cannot understand how any sort of rational discussion on this subject can be made until the actual problem to solve is presented.</blockquote> In the sessions that I've attended, the participants seem to have a very good grasp of the problem.  Sure, they don't necessarily know all of the details that should be brought out in a requirements analysis, but the main problem to be solved is understood. But the need for a REQUIREMENTS document as in the waterfall model is not at all clear.  But as Grady Booch stated in his reply, we do need to have an iterative solution that grows incrementally.  Based on a number of requirements that came out of a discussion a couple of meetings ago, I chose Subversion as the initial technology for only a low level portion of the software archival system.  Implementing that proposal will let us refine the requirements and experiment with technology that layers on top of it so that we can define the next round of requirements.  MY PROPOSAL I.  In the April SPC we have a discussion of requirements for the archive layer.  I would like to see the museum's requirements as they are currently understood.  I hope that the current draft standard for the 3-layer model will be presented at this meeting so that we can better understand what the standards group thinks is required.  Hopefully differences in requirements can be resolved after the meeting through e-mail. II.  In the May SPC we have a discussion of possible technologies for archive software, and how well they meet the requirements.  We should have a finalized version of requirements for the June pilots. III.  In the June SPE we make the final selection of one or several technologies for creating a pilot archive.  Following the meeting, we begin to create the pilot(s).  IV.  In the July SPE we have a discussion about how we will evaluate the pilots.  Specific use cases are presented.  Methods of testing these use cases for the pilot(s) are discussed.  Comments are of course welcome. Bob </body> </html>