1.1. Purpose and Goals

The Model Editions Partnership is developing a series of sample editions for delivering historical documents on the World-Wide Web. The Partnership includes the editors of seven on-going documentary editions as well as leaders from the Text Encoding Initiative and the Center for Electronic Text in the Humanities. The project began in July 1995 with major funding from the National Historical Publications and Records Commission (U.S.) and the University of South Carolina. The first six phases will be completed in June 1998. The goals for that three-year period are:

• To help define the scholarly frameworks for tomorrow's historical editions.
• To develop practical solutions for creating and delivering those editions.
• To establish sample editions which demonstrate a variety of solutions to the first two goals.
• To move the editorial community into the mainstream of electronic text.
• To help lay the foundation for a national database to enhance the use of historical editions.

1.2. SGML Markup

The Partnership is predicated on the view that SGML markup can be used to create the scholarly frameworks required and that SGML markup offers a practical method for preparing and delivering documentary editions. A close study of the scholarly issues involved in preparing documentary editions led to the publication of "A Prospectus for Electronic Historical Editions" in May 1996 (http://mep.cla.sc.edu/prostoc.htm). The Prospectus set forth a series of design principles; a typology of the kind of editions which might be expected to develop; and a discussion of importance of markup. (A report on the Prospectus was given at the ALLC/ACH conference in Bergen.) The Bergen report also noted the Partnership's development of two Document Type Definitions based on a subset of the TEI Guidelines. The data-capture DTD

• Defines a new MEP header for each historical document.
• Redefines <docGroup> and other elements to accommodate the way in which scholarly editors typically organize material in the editions.
• Eliminates many of the TEI prose elements like <opener> used to group elements at the beginning and end of documents.
• Substitutes explicit elements in place of the <hi> (highlight) element and its attributes.
• Defines new elements as appropriate.

The archival DTD retains the MEP header and the redefinition of <docGroup> and the other elements required for the structure of historical editions. However, divisional units like >opener< are restored as is the more familiar highlight element with its attributes. This transformation is done mechanically. The premise here is that future migration of the data will be more easily accomplished if the archival markup of the data conforms more closely to current TEI markup.

2.1 Evolution of Markup

Despite the intensive review of documents which provided the basis for the development of the data-capture DTD, experience shows that markup systems evolve over time. Some changes may be made for the convenience of data entry; others, because new textual features are identified; and still others, because textual features previously ignored assume importance in the eyes of the scholar. The presentation will review our experience in these areas with explicit examples of where we chose to expand the DTD as well as other cases where we chose not to expand the DTD. Beyond the markup questions which arise from the texts are those which will undoubtedly arise as we move the data into the delivery environments.

2.2 Implementation of Delivery Software

We expect to deliver the sample editions using both SoftQuad's Panorama and Electronic Book Techology's DynaWeb. At this point, we have created small mockups with Panorama, but we have no experience with DynaWeb. (We have been accepted in EBT's Higher Education Grant program and our full application is currently pending.) Markup issues associated with implementing the samples in each software package are important and the ACHALLC97 presentation will summarize our findings in this area. To put it another way, we will look at the following questions. Which markup is easier to implement in each of the delivery systems? Are there adjustments in either DTD which would make it easier? What are the trade-offs if DTDs are modified to facilitate delivery? Modification of the DTDs can, of course, be avoided by transforming the existing data to meet the required formats for the delivery software. This can be accomplished with macros or filters and is a common practice used in print publishing. At the same time, we have sometimes found that the markup we were using could have been modified with no loss of information and with significant gains in processing--thus reducing costs.