Documentation

Versioning Machine 3.2

by Lara Vetter, Maryland Institute for Technology in the Humanities, Summer 2003; Jarom McDonald, Maryland Institute for Technology in the Humanities, January 2005; Sean Daugherty, University of Maryland Libraries, November 2006, March 2007, and July 2007



Overview

The Versioning Machine (VM) is a software tool designed by a team of programmers, designers, and literary scholars at the Maryland Institute for Technology in the Humanities (MITH), and currently maintained by the Office of Digital Collections and Research at University of Maryland Libraries for displaying and comparing multiple versions of texts. The display environment seeks not only to provide for features traditionally found in codex-based critical editions, such as annotation and introductory material, but to take advantage of opportunities of electronic publishing, such as providing a frame to compare diplomatic versions of witnesses side by side, allowing for manipulatable images of the witness to be viewed alongside the diplomatic edition, and providing users with an enhanced typology of notes. The Versioning Machine debuted at the 2002 ALLC/ACH (Association for Literary and Linguistic Computing/Association for Computers and the Humanities) Conference in Tubingen, Germany, July 2002.

The VM supports display of XML texts encoded according to the guidelines of the Text Encoding Initiative (TEI). To display your texts in the VM, you may encode witnesses individually, in separate files, or you may use TEI's "critical apparatus tagset" (TEI.textcrit) to encode all witnesses in one XML file. Because the critical apparatus tagset offers the most efficient and thorough methodology for inscribing variants in a structured, machine-readable format, choosing the method utilizing this tagset can be more complicated in terms of markup but rewards the editor by offering more functionality in the VM display environment, including line numbering and line matching, and by eliminating time-consuming repetition in encoding; however, the choice to encode files simply and individually still allows users to take advantage of other VM features, such as note typology and toggling, image viewing, and side-by-side display of multiple witnesses. Because using the critical apparatus tagset can be difficult initially, more comprehensive instructions are provided below.

Installation & Requisites

The VM 3.2 will run on Windows, Mac OS X, and Linux-based platforms. XML versions of texts may not display correctly on all browsers. Manuscript image viewing in XML versions is currently only supported on Internet Explorer 6.0+ or Safari 1.2+. HTML versions may be viewed on any Windows, Mac OS X, or Linux-based computer running Internet Explorer 5.5+, Mozilla Firefox 1.5+, Netscape 7.0+, Safari 1.2+, or Opera 8.5+.

To install VM 3.2, fill out the registration form on the website and you will be given a choice to download via a zip file.

Additionally, if you would like to ensure that people viewing your documents with IE 5.5+ or current Mozilla / Netscape browsers can do so, or to avoid known bugs in the XSLT transformation of several browsers, it would be best to perform the file transformation to HTML manually using another XSLT processor. To perform file transformations manually, you will need to download an XSLT processor like SAXON to transform the XML files into HTML. Please note that you will need a processor capable of handling XSLT 1.0 transformations. The last version of SAXON to support XSLT 1.0 transformation is version 6.5.5.

Once downloaded, use an unzipping program like WinZip to extract all files in the archive. The contents should unzip into a folder entitled v-machine. To view a description of the product, documentation, and samples, open the file v-machine/index.html in a supported web browser.

To uninstall the VM: if you installed using the zip file, simply remove the folder v-machine from your hard drive.

Encoding: Using Individually Encoded Witnesses

This section provides instructions for how to use the VM with separately encoded documents. Using basic TEI encoding, you may encode individual witnesses of poems or prose in separate XML files, and VM 3.2 is able to display side-by-side the texts of these independent files. The advantage of using this encoding methodology is that the markup itself is much simpler to learn and use; the chief disadvantages are these: (1) encoding documents separately can entail much time-consuming repetition of data entry; and (2) the VM's line numbering and line matching features are not supported for this encoding method.

Displaying Header Information

The VM supports the display of many TEI header tags. Header information is displayed in the Bibliographic Information popup window in the VM, with information from headers for individual files listed sequentially and separated by horizontal rules in the order you have chosen them to appear in the VM.

From the <fileDesc>, the following are supported in the display:

From the <encodingDesc>, the following are supported in the display:

Note that since the VM will display all of the header information for every witness in the Bibliographic Information popup, you will want to customize information in the <titleStmt> as much as possible so that users can distinguish between the various versions.

To use one of our samples as an example, rather than titling the three versions of Emily Dickinson's poem "There Are Two Ripenings," we included within the <title> information that pertains to the manuscript or printed source in order to distinguish them. Thus, one version is entitled "A456: A poem sent to unknown recipient," another is "A Tr60a: A poem sent by Mabel Loomis Todd to Kate Anthon," and still another "H47: Fascicle 14, version 2." When the user scrolls through the information regarding each witness, it is clear which set of information pertains to which displayed version.

Encoding the Body

There are no special instructions for encoding the body in this method because the VM relies only upon the basic core tags. The DTD you use should be TEI-conformant, but it does not matter which tagsets you choose to include or ignore. You are directed to the TEI Guidelines and Index of Tutorials for more information on basic and advanced TEI encoding.

If you would like to view a marked-up sample of an individually encoded document that is available on the site, refer to Appendix A.   To view the transformed files in the VM, click here for "There Are Two Ripenings."

Using Transcription Tags

Because VM 3.2 is designed to aid editors creating editions with multiple witnesses, the VM supports special styling of two TEI core tags that are used frequently when dealing with manuscript and typescript drafts, <add> and <del>. Each <add> will display in green, courier-font typeface; each <del> will display in red typeface with a strikethrough. Additionally, the VM supports <space/> (one of the elements of the TEI.transcr, the tagset for transcription of primary sources). To use <space/>, enter either horizontal or vertical as the value of the DIM attribute, and then a number in the N attribute that represents the desired number of nonbreaking spaces, or line breaks, respectively. To edit these default styles, see the CUSTOMIZING THE VM section.

Other TEI tags for transcription of primary sources (including <sic>, <corr>, <gap>, <damage>, <unclear>, <supplied>, <restore>, <space/>, <handShift/>) are assigned a class by the VM but currently have no special styling; if you wish the data in these elements to render in a certain way, you may edit the cascading stylesheet file (see the CUSTOMIZING THE VM section for more information).

Encoding Notes

The VM displays information in <note>s, either in the Bibliographic Info (if the tag occurs in the <teiHeader>) or as user-manipulated pop-up notes, marked by icons within the text itself (if the tag is embedded in the <text>). The default display for the <note> within the <text> is a small superscript N; however, if you wish to customize the icon display, you may draw from a short list of VM note types. By using the <note> attribute TYPE, you can alter the icon display to indicate what type of note is presented.

The same support of note typology is available to notes in the header. Notes from the header will display on the Bibliographic Information popup, preceded by the appropriate label (e.g., Biographical, Gloss, etc.).

Please note one exception: a <note type="image"> in your document is reserved for image data only and will not be displayed (see section on Encoding Images).

Encoding Images

The representation of images is optional. If you wish to display image facsimiles with your texts, however, the VM enables that functionality. Note that because XSLT has difficulty referencing external files, catalogs are not supported; thus, image entity declarations must be included in the document itself.

The VM image viewer will support the following image types: jpeg, gif, and tiff. Images larger than 600 pixels high and 600 pixels wide will be scaled to that size for display purposes.

The current version of the VM requires that references to images be tagged within a <note> of attribute TYPE with the value of image (i.e., <note type="image">). The best place to encode this is in the header's <notesStmt>; if you wish to encode this somewhere other than the <notesStmt>, you will still need to follow the instructions below in regard to the contents of <note type="image">. Here is an example of an encoded <notesStmt> for images:

<notesStmt>
<note type="image">
<figure entity="imagea1">
</figure>
</note>
</notesStmt>

Let's go through it step by step. If your document does not already contain a <notesStmt>, you will need to enter one within your document's <fileDesc> (typically, after the <publicationStmt> and before the <sourceDesc>). Within <notesStmt>, add a <note>. Enter image as the TYPE attribute value of <note>.

Then, within that <note> add a <figure>. Enter into the ENTITY attribute of <figure> an abbreviated, unique alphanumeric string that identifies it.

Now, the entity declaration needs to be added to the DOCTYPE declaration in order to direct the machine where to find the image file. If your DOCTYPE declaration already contains data in square brackets, skip ahead to the next paragraph. If not, within the DOCTYPE declaration, locate the DTD path within quotation marks. Between the last quotation mark (i.e., ") and the closing angle bracket (i.e., >), insert one space and two square brackets (i.e., [ ]). At this point, your DOCTYPE should look like this:

<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
]>

Between the square brackets, you will enter the entity declaration as follows:

<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
<!ENTITY imagea1 SYSTEM "man533.jpg" NDATA JPEG>
]>

This defines the entity "imagea1" (the value you assigned to the ENTITY attributes of the <figure> tag) as a JPEG file and identifies the file name of the image file that corresponds to that entity. (Note that if you use your own DTD, rather than the default DTD provided, the path for the DTD file will not be "../src/teixtstc.dtd" but will identify your own DTD.)

Attaching the Stylesheet

Next, you will need to add the stylesheet path to your XML document, just below the <?xml> tag and just before the DOCTYPE declaration. The top of your document should now look like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../src/parallel.xsl" type="text/xsl"?>
<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd">

Creating the Holder File

In order for the VM to recognize that the individually encoded files are all versions of the same text, you must create another XML file called a "holder" file, detailing which files are related and in what order they should appear. The "holder" file should be uploaded along with the XML files, and the link from your index should go to the "holder" file instead of the individual witness files.

Using one of our Dickinson examples, its "holder" file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../src/discrete.xsl" type="text/xsl" ?>
<files>
<file sigil="a456" filename="a456.xml" />
<file sigil="aTr60a" filename="aTr60a.xml" />
<file sigil="h47" filename="h47.xml" />
</files>

Let's go through this step-by-step. The first declaration is common to all XML files; the second is the same stylesheet declaration you added to your documents in the preceding instruction (see Attaching the Stylesheet). The remainder of the file is contained within the <files> tag. Within <files>, you will include a <file> for each of your XML documents. The value of the attribute SIGIL will appear at the head of that version in the VM display; the value of the attribute FILENAME is the file name of the document. The ordering of the <file>s in the "holder" file corresponds to the ordering of the versions in the VM.

Encoding: Using Critical Apparatus

The Text Encoding Initiative (TEI) makes available a set of tags referred to as the "critical apparatus tagset" (TEI.textcrit) designed to provide editors with a structured way to record differences or variations between multiple witnesses of the same text. Using this tagset allows an editor to encode in one document multiple versions of that text; VM 3.2 is able to reconstruct multiple witnesses from the single XML-encoded document and display them, side-by-side, as individual documents. The critical apparatus tagset supports three different types of encoding variation: location-referenced, double-end-point, and parallel-segmentation; however, only parallel-segmentation is currently supported by VM 3.2.

The advantages of using this encoding methodology are these: (1) eliminates time-consuming repetition in data entry; and (2) allows for support of all of VM's features. The disadvantage of using this method is the difficulty of the powerful but rather unwieldy critical apparatus tagging. Because of the complex nature of this type of tagging, step-by-step basic instructions on its use are provided here to supplement the TEI's documentation.

If you are already familiar with using parallel segmentation, you may not need to read all of this section, but it will be helpful to skim it as it contains important information about how the VM interacts with certain strategies of tagging; note also sections on Recording Variant Encoding Methodology (<variantEncoding/>) and Recording a List of Witnesses (<witList>) as these two tags are required by the VM, as well as the section on Encoding Images if you wish to utilize the VM's image functionality.

Displaying Header Information

The VM supports the display of many TEI header tags. Header information is displayed on the Bibliographic Info page.

From the <fileDesc>, the following are supported in the display:

From the <encodingDesc>, the following are supported in the display:

Recording Variant Encoding Methodology

The VM requires that the choice to encode by parallel segmentation be recorded in the document header (<teiHeader>). Within the header's <encodingDesc>, enter the <variantEncoding/>; tag. It is an empty tag and thus does not wrap around any textual content (or PCDATA); instead, information pertaining to methodology is entered into attributes. The tag possesses two required attributes, METHOD and LOCATION, and each is restricted to certain prescribed values. Choose parallel-segmentation for METHOD, and internal for LOCATION. Your statement of variant encoding methodology should look like the following:

<variantEncoding method="parallel-segmentation" location="internal"/>

Recording a List of Witnesses

The VM utilizes <witList> tagging to produce multiple versions, so it is required that your document contain a <witList>; TEI recommends that this be added to the front matter. If you do not already have front matter in your document, enter a <front> within <text> and before <body>. Within <front>, enter a <witList>. This is where you will record bibliographic or descriptive information pertaining to each individual witness encoded and assign each witness a unique identifier. VM uses this information to reconstruct the multiple versions, and it will display the descriptions on the Bibliographic Info page so that users will be able to identify individual witnesses.

The <witList> holds this information within individual <witness>es. The SIGIL attribute contains the unique identifier you assign to each version. For instance, to encode four different versions of the Thomas MacGreevy poem "Nocturne," one might construct the <witList> as follows:

<front>
<div>
<witList>
<witness sigil="a1">'Nocturne, Saint Eloi, 1918' (TCD 878/1/2)</witness>
<witness sigil="a2">'Nocturne of St. Eloi, 1918' (TCD MS 7989/1/3)</witness>
<witness sigil="a3">'Nocturne, Saint Eloi' (TCD MS 79891/1/1)</witness>
<witness sigil="pub">This poem was published in <title>Poems</title> as 'Nocturne'</witness>
</witList>
</div>
</front>

The SIGIL attribute on each <witness> assigns an abbreviation unique to that witness. You may devise your own system of naming witnesses (as is the case in the example above), or you may wish to borrow from some recognized catalogue or authority. When recording variations within the text, the value entered in the SIGIL attribute will identify the text from which each variation derives; this value will also appear inside the dropdown menu above the displayed version.

ss01

Between each set of <witness> tags, a prose statement identifies the version by whatever bibliographic or descriptive data is appropriate; this prose statement will display in the Bibliographic Info window alongside its unique identifier so that users can ascertain the identity of each version.

ss02

The SIGIL value may contain any alphanumeric string. The prose description for each <witness> may be as long or as short as you like, and it may, for instance, contain structured data through the use of TEI's bibliographic tagging (e.g., <bibl> see TEI Guidelines for information on bibliographic tagging, section 6.10.1 http://www.tei-c.org/P4X/CO.html#COBITY).

The ordering of the individual <witness>es within the <witList> corresponds to the ordering of versions in the VM display.

Using Transcription Tags

Because VM 3.2 is designed to aid editors creating editions with multiple witnesses, the VM supports special styling of two TEI core tags that are used frequently when dealing with manuscript and typescript drafts, <add> and <del>. Each <add> will display in green, courier-font typeface; each <del> will display in red typeface with a strikethrough. Additionally, the VM supports <space/> (one of the elements of the TEI.transcr, the tagset for transcription of primary sources). To use <space/>, enter either horizontal or vertical as the value of the DIM attribute, and then a number in the N attribute that represents the desired number of nonbreaking spaces, or line breaks, respectively. To edit these default styles, see the CUSTOMIZING THE VM section.

Other TEI tags for transcription of primary sources (including <sic>, <corr>, <gap>, <damage>, <unclear>, <supplied>, <restore>, <space/>, <handShift/>) are assigned a class by the VM but currently have no special styling; if you wish the data in these elements to render in a certain way, you may edit the cascading stylesheet file (see the CUSTOMIZING THE VM section for more information).

Using Parallel-Segmentation

Parallel-segmentation embeds variants inline and does not privilege structurally one witness over another; the other two methods require a base text with variants from other versions attached by various linking mechanisms. A basic introduction to encoding with TEI's parallel segmentation for use in the VM follows; users are advised to consult Chapter 19 of the TEI guidelines for more information about critical apparatus tagging.

The Fundamentals of Parallel Segmentation

(Note: The instructions below rely on samples available to you on the site and in the ZIP file. If you wish to view the full XML files, with encoding, refer to Appendix B [for "Nocturne"] or Appendix C [for "Autumn, 1922]. To view the transformed files in the VM, click here for "Nocturne" and here for "Autumn, 1922.")

For both verse and prose, the TEI critical apparatus tagging utilizes the apparatus tag (<app>), within which multiple readings (<rdg>) can be encoded. Entering an <app> into the text signifies that multiple variations are present and will be encoded at that point; each individual variant constitutes a unique <rdg>.

In parallel-segmentation, all variants are recorded inline. The VM will support two different methods of encoding: by a "scalar" model of repetition, or by a procedure that embeds the variant at the exact point of variation. So, for instance, if a line in one version of a poem (let's call it witness "A") reads "I saw a dog today" and in another version (witness "B") reads "I saw a rhinoceros today" you may encode it either of these two ways:

method 1:
<l>
<app>
<rdg wit="A">I saw a dog today</rdg>
<rdg wit="B">I saw a rhinoceros today</rdg>
</app>
</l>
method 2:
<l alt="B"> I saw a
<app>
<rdg wit="A">dog</rdg>
<rdg wit="B">rhinoceros</rdg>
</app>
today
</l>

Both methods clearly show which variant belongs to which witness. In the first method, the line is repeated intact for each version. In the second method, the line tag (<l>) directly holds only those parts of the line that are common to both variants; the critical apparatus tagging is inserted only where the actual variation occurs. The VM is able to reconstruct versions from either method. The latter method, however, is recommended, particularly in prose, for two reasons: (1) it avoids needless repetition; and (2) it tags the exact point of variation, so readers do not have to locate for themselves the variant part of the line. That said, if the encoding is particularly complicated, you may wish to use the first method.

Let's look at an example from an actual poem. In this Thomas MacGreevy poem, "Nocturne," the third line varies in two versions by one word. Here is line 3 from versions a3 and the published version ("pub"):

ss03

The two versions differ in that version a3 begins "Far above," while the version pub begins "Far away."

To encode this variation using parallel segmentation, the <app> is inserted after the space following the word "Far."  Two <rdg>s are enclosed within the <app>, one for each version: one <rdg> will contain the word "above" and the other the word "away."  Immediately after the second </rdg>, close the apparatus tag (i.e., </app>). In order to denote which witness contains which variant, you will need to use the attribute WIT on <rdg>. The WIT value of each <rdg> will correspond to its SIGIL value entered into the <witList>'s <witness>. For instance, the <rdg> containing the word "above" has an attribute WIT value of a3, and the <rdg> containing the word "away" has an attribute WIT value of pub. The result will look like this:

<l n="3">Far
<app>
<rdg wit="a3">above</rdg>
<rdg wit="pub">away</rdg>
</app>
, stars wheeling in space,</l>

Note that the WIT attribute is required by the VM, which will not display a reading that does not have a WIT value.

You may encode several variants within a line, and you may group together within the WIT attribute versions that agree. For instance, the same line in another manuscript version of the poem (version "a1") looks like this:

ss04

While this line agrees with the published version in the choice of the word "away," it departs from both versions in two places: (1) its use of the phrase "on through" for "in"; and (2) its end punctuation. Taking into account this version, our variant encoding now looks like this:

<l n="3">Far
<app>
<rdg wit="a3">above</rdg>
<rdg wit="a1 pub">away</rdg>
</app>
, stars wheeling
<app>
<rdg wit="a1">on through</rdg>
<rdg wit="a3 pub">in</rdg>
</app>
space
<app>
<rdg wit="a1">.</rdg>
<rdg wit="a3 pub">,</rdg>
</app>
</l>

Just as in the previous example, variants are tagged with <app> and <rdg> at the point of variation and identified through the <rdg> WIT attribute. However, when considering three witnesses, two witnesses may agree but diverge from the third. While it is valid to enter three <rdg>s for each <app>, it is not necessary. To avoid repetition of the same information, you may enter two values within the WIT attribute to denote that those two witnesses agree.

The <app> tags may nest hierarchically, with a <rdg> containing an <app>, which in turn contains more <rdg>s. As this nesting can get quite complicated in practice, let's look at a simple example first, before turning back to our MacGreevy poem. Let's imagine that we are looking at a line from three different versions: witness A reads "I saw a dog today," witness B reads "I saw a rhinoceros today," and witness C reads "I heard birds singing."  We can encode this with nested apparatus like so:

<l> I
<app>
<rdg wit="C"> heard birds singing </rdg>
<rdg wit="A B"> saw a
<app>
<rdg wit="A"> dog </rdg>
<rdg wit="B"> rhinoceros </rdg>
</app>
today </rdg>
</app>
</l>

Except for the initial word of the line, witnesses A and B disagree with witness C entirely. So following "I," which they all share in common, an apparatus is inserted to distinguish witnesses A and B from witness C. Witnesses A and B, however, contain one variant word ("dog" or "rhinoceros"); thus, within the first level of apparatus, there is a second level inserted (after "saw a," which they have in common, and before "today," which they share) to encode this variant.

Back to MacGreevy. In line 3 of yet another manuscript version (version "a2") of our MacGreevy poem, there is more variation still:

ss05

Tagging it would render the following:

<l n="3"><del>Above me</del>, <add>Far away</add> stars wheeling in space,</l>

If we incorporate this fourth version into our variant encoding, we will have to embed one apparatus within another. Since only version "a2" contains the <del> and <add> tags, it must be separated from the other three versions. In the highest level of apparatus, the first <rdg> contains version "a2," and the second contains the other three; within the second <rdg>, however, there is further variation in the word following "Far," and another <app> entry is required. It might look something like this:

<l n="3">
<app>
<rdg wit="a2"><del>Above me</del>, <add>Far away</add></rdg>
<rdg wit="a3 a1 pub">Far
<app>
<rdg wit="a3">above</rdg>
<rdg wit="a1 pub">away</rdg>
</app>
</rdg>
</app>
stars wheeling
<app>
<rdg wit="a1">on through</rdg>
<rdg wit="a2 a3 pub">in</rdg>
</app>
space
<app>
<rdg wit="a1">.</rdg>
<rdg wit="a2 a3 pub">,</rdg>
</app>
</l>

As you can see, the tagging can get quite complex. But because the <add> and <del> tags are present in just one witness, we need to separate this witness from the rest; by doing so, we can take advantage of VM's rendering of the <add> and <del> tags.

Let's consider another Macgreevy poem, "Autumn, 1922." There are four drafts and a published version, most of which have different titles. The title of version a1 is "A Short History of Our Own Times"; the second (a2) has the title "CIVIL WAR" crossed out with "Ireland, Autumn 1922" written in to take its place; the third (a3) and fourth (a4) bear the title "IRELAND, AUTUMN, 1922"; and the published version (pub) is entitled "AUTUMN, 1922" but the word "IRELAND" is written in before it.

The encoding of the title might look something like this:

<title>
<app>
<rdg wit="a1">A Short History of Our Own Times.</rdg>
<rdg wit="a2"><del>CIVIL WAR</del> <add>Ireland, Autumn 1922</add></rdg>
<rdg wit="a3 a4">IRELAND, AUTUMN, 1922</rdg>
<rdg wit="pub"><add>IRELAND</add> AUTUMN, 1922</rdg>
</app>
</title>

This is simple enough, as it uses principles explored in the previous poem as well. However, "Autumn, 1922" presents at least three challenges for the VM not present in our earlier example: (1) one witness contains a third line that is omitted in the other witnesses; (2) one witness comprises one stanza, while the others comprise two; and (3) one witness splits into two lines what appears as one line in the other witnesses.

To address the first two items, let's first compare versions a1 and a2:

Version a1
ss06ab
Version a2
ss06b

Line three of version a1 is missing in version a2. The VM will support two different ways of encoding this missing line. The first inserts a line with an apparatus with only one reading:

<l>
<app>
<rdg wit="a1">Poets sing no more,</rdg>
</app>
</l>

The second method inserts two readings, one that has no content:

<l>
<app>
<rdg wit="a1">Poets sing no more,</rdg>
<rdg wit="a2"></rdg>
</app>
</l>

There is a further complication here, however; two stanzas make up version a2, while version a1 contains only one. TEI's critical apparatus tagging has well-known difficulties in dealing with encoding variants at a larger scale than the unit of the line; to get around this challenge in the case of a stanza break, the VM has built in the ability to read the <milestone/> tag with its UNIT attribute value equal to stanza. We insert the <milestone/> tag at the point of the stanza break in version a2 like so:

<l>
<app>
<rdg wit="a1">The world withers,</rdg>
<rdg wit="a2">The world withers<milestone unit="stanza"/></rdg>
</app>
</l>

The third challenge concerns version a3, which contains a line broken into two that other versions represent as a single line:

Version a3
ss07b

The VM can handle this variation in one of two ways. First, we might utilize a strategy similar to the <milestone/> method above by inserting a line break (<lb/>) at the appropriate point in version a3:

<l>
<app>
<rdg wit="a1 a2">And time grows afraid of the triumph of time.</rdg>
<rdg wit="a3">And time grows afraid <lb />Of the triumph of time.</rdg>
</app>
</l>

The second method is to tag version a3's "Of the triumph of time" as a line which has no corresponding lines in the other two versions:

<l>
<app>
<rdg wit="a1 a2">And time grows afraid of the triumph of time.</rdg>
<rdg wit="a3">And time grows afraid</rdg>
</app>
</l>
<l>
<app>
<rdg wit="a1 a2"></rdg>
<rdg wit="a3">Of the triumph of time.</rdg>
</app>
</l>

The Notion of a Base Text

Parallel segmentation does not require a base text, and structurally it does not privilege one witness over another; it does, however, allow for a base text. Should you wish to denote that one text be considered the base text from which other versions vary, you would encode those variations contained in the base text as the lemma (<lem>) instead of as a reading <rdg>. Moreover, you might use the <lem> to single out one version from the rest, whether or not it should be considered a base text. Note, however, that VM 3.2 will not display the <lem> any differently from the <rdg> without modifying the XSLT.

If, for instance, in the MacGreevy example above, you wanted version "a1" to be considered the base text, you would encode it as follows:

<l n="3">Far
<app>
<rdg wit="a3">above</rdg>
<rdg wit="pub">away</rdg>
<lem wit="a1">away</rdg>
</app>
, stars wheeling
<app>
<lem wit="a1">on through</rdg>
<rdg wit="a3 pub">in</rdg>
</app>
space
<app>
<lem wit="a1">.</rdg>
<rdg wit="a3 pub">,</rdg>
</app>
</l>

Line Numbering

The VM has the ability to display line numbers encoded into the TEI document. When available, they are activated by default. They can be deactivated by deselecting the "Show Line Numbers" checkbox in the VM interface.

Line Numbers

To make use of this feature, you would encode the text as follows:

<lg n="1">
<l n="1">
<app>
<rdg wit="a1 a2 a3 a4 pub">The sun burns out,</rdg>
</app>
</l>
<l n="2">
<app>
<rdg wit="a1">The world withers,</rdg>
<rdg wit="a3 a4">The world withers,<milestone unit="stanza"/></rdg>
<rdg wit="a2 pub">The world withers<milestone unit="stanza"/></rdg>
</app>
</l>
<l n="3">
<app>
<rdg wit="a1">Poets sing no more,</rdg>
</app>
</l>
<l n="4">
<app>
<rdg wit="a1 a2 a4 pub">And time grows afraid of the triumph of time.</rdg>
<rdg wit="a3">And time grows afraid</rdg>
</app>
</l>
<l n="5">
<app>
<rdg wit="a3">Of the triumph of time.</rdg>
</app>
</l>
</lg>

Encoding Notes

The VM displays information in both <note>s and <witDetail>s. If either of these tags occurs in the <teiHeader>, the information is displayed in the Bibliographic Information; if either of these tags is embedded in the <text>, the information is displayed as user-manipulated pop-up notes, marked by icons within the text itself.

Witness Detail

The <witDetail> records notes pertaining only to a specific witness (or witnesses); it contains the functionality of the <note> but is customized to treat witnesses. Like a <note>, a <witDetail> can occur almost anywhere within the document header or text. Because <witDetail> requires a TARGET attribute for linking, it is typically used to refer to one particular <rdg>.


The <witDetail> contains two required attributes, WIT and TARGET. just as in the text encoding examples above, the WIT attribute records the SIGIL value (or values) corresponding to the appropriate witness (or witnesses). Thus, to return to our MacGreevy example, a <witDetail> with a WIT value of "pub" would contain information pertaining only to the published version of the poem and not to the manuscript versions. Likewise, a <witDetail> with a WIT value of "a1 pub" would contain information pertaining to one of the manuscripts and the published version, but not to the other two manuscripts.

The TARGET attribute is a linking mechanism, used in much the same as TEI's other linking mechanisms: by linking two parts of the document through a matching of the ID attribute on one with the TARGET attribute on the other. So, for instance, if you wanted to annotate a particular variant, you would first assign a unique identifier to the <rdg> by entering an alphanumeric string in its ID attribute. (Note that TEI mandates that all ID attribute values begin with a letter; however, any combination of letters and numbers may follow.) Then, in the corresponding <witDetail> TARGET attribute, enter this same value. The information to which the note is attached might look something like this:

        <l>I saw a
                <app>
                   <rdg wit="A">dog</rdg>
                   <rdg wit="B" id="n1">rhinoceros</rdg>
                </app>
            today
        </l>

Elsewhere in the document, then, your corresponding <witDetail> might look like this:

    <witDetail wit="B" target="n1">The author had lost his glasses that day
        and mistakenly imagined the very large dog to be a rhinoceros.
    </witDetail>

Note Types

The VM displays all <note>s and <witDetail>s within the <text> with a small superscript N; however, if you wish to customize the icon display, you may draw from a short list of VM note types. By using the <note> or <witDetail> attribute TYPE, you can alter the icon display to indicate what type of note is presented.

The same support of note typology is available to notes in the header. Notes and witness details from the header will display on the Bibliographic Info page, preceded by the appropriate label (e.g., Biographical, Gloss, etc.).

Please note one exception: a <note type="image"> in your document will be ignored by the VM unless it contains a <witDetail>. This is because that note type is used by the VM to hold image data only (see section on Encoding Images).

Encoding Images

The representation of images is optional. If you wish to display image facsimiles with your texts, however, the VM enables that functionality. Note that because XSLT has difficulty referencing external files, catalogs are not supported; thus, image entity declarations must be included in the document itself.

The VM image applet will support the following image types: jpeg, gif, and tiff. Images should be no more than 600 pixels high and 600 pixels wide.

The current version of the VM requires that references to images be tagged within a <note> of attribute TYPE with the value of image (i.e., <note type="image">). The best place to encode this is in the header's <notesStmt>; if you wish to encode this somewhere other than the <notesStmt>, you will still need to follow the instructions below in regard to the contents of <note type="image">. Here is an example of an encoded <notesStmt> for images:

    <notesStmt>
        <note type="image">
            <witDetail wit="a1" target="va1">
                <figure entity="imagea1">
                </figure>
            </witDetail>
            <witDetail wit="pub" target="vpub">
                <figure entity="imagepub">
                </figure>
            </witDetail>
        </note>
    </notesStmt>

Let's go through it step by step. If your document does not already contain a <notesStmt>, you will need to enter one within your document's <fileDesc> (typically, after the <publicationStmt> and before the <sourceDesc>). Within <notesStmt>, add a <note>. Enter image as the TYPE attribute value of <note>.

Then, within that <note> add a <witDetail>; within the <witDetail> add a <figure>. Each version will have a different image; thus, you will enter a <witDetail> for each image of each version you wish to display.

As explained in the subsection Encoding Notes, the <witDetail> has two required attributes: WIT and TARGET. In WIT enter the SIGIL value of the corresponding image. In TARGET enter a unique identifier (see above subsection Encoding Notes for more information on the TARGET attribute). Enter into the ENTITY attribute of <figure> an abbreviated, unique alphanumeric string that identifies it.

TARGET values must match a corresponding ID attribute elsewhere in the document. So, the next step is to return to the <witList> and assign each <witness>'s ID attribute value the same unique identifier used with the TARGET of the corresponding <witDetail>. Your <witList> for the example immediately above will now look something like this:

    <witList>
        <witness sigil="a1" id="va1">'Nocturne, Saint Eloi, 1918' (TCD
            878/1/2)</witness>
        <witness sigil="pub" id="vpub">This poem was published in
            <title>Poems</title> as 'Nocturne'</witness>
    </witList>

Now, the entity declarations need to be added to the DOCTYPE declaration in order to direct the machine where to find the image files; you will enter one entity declaration for each image file. If your DOCTYPE declaration already contains data in square brackets, skip ahead to the next paragraph. If not, within the DOCTYPE declaration, locate the DTD path within quotation marks. Between the last quotation mark (i.e., ") and the closing angle bracket (i.e., >), insert one space and two square brackets (i.e., [ ]). At this point, your DOCTYPE should look like this:

   <!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
   ]>

Between the square brackets, you will enter the entity declaration as follows:

    <!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
        <!ENTITY imagea1 SYSTEM "man533.jpg" NDATA JPEG>
        <!ENTITY imagepub SYSTEM "autumn.jpg" NDATA JPEG>
    ]>

This defines the entities "imagea1" and "imagepub" (the values you assigned to the ENTITY attributes of the <figure> tags) as JPEG files and identifies the file names of the image files that correspond to the entities. (Note that if you use your own DTD, rather than the default DTD provided, the path for the DTD file will not be "../src/teixtstc.dtd" but will identify your own DTD.)

Attaching the Stylesheet

The last step is to add the stylesheet path to your XML document, just below the <?xml> tag and just before the DOCTYPE declaration. The top of your document should now look like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../src/engine.xsl" type="text/xsl"?>
<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd">

VIEWING WITH MANUAL FILE TRANSFORMATIONS

Manually transforming your XML files to HTML has many advantages over relying on native browser XSLT support, including increased compatibility and fewer browser-specific bugs. We recommend the free XSLT processor Saxon (see section INSTALLATION & REQUISITES above for information on how to get this software). Please note that Saxon requires a Java runtime environment to work.

  1. If you are not using the default DTD provided, place your DTD file in the folder entitled src. (See section CUSTOMIZING THE VM below for restrictions on using your own DTD.)
  2. If you are using the critical apparatus tagset to create one file of several versions, convert that file into HTML with Saxon or another XSLT processor. Place the file "saxon.jar" into your src directory and enter the following command within a command-line terminal: java -jar saxon.jar -o desired html filename.html XML file to be transformed.xml engine.xsl. Please note that the HTML/XML filenames must include the full path (for example, C:\v-machine\samples\faith.html).
  3. If you have encoded your versions in individual files, make sure that the "holder" file and the individual files are all in the same directory and convert the "holder" file only into HTML with Saxon or another XSLT processor (this will create one HTML file with all of your versions within it). Follow the command listed above, but replace engine.xsl with discrete.xsl.
  4. Place your HTML documents in the folder entitled samples if you did not tell Saxon to output the files there already.
  5. Place your images in the subdirectory of samples entitled images.
  6. Open the HTML file in your browser. Refer to the Help section of the VM to navigate the product.

VIEWING YOUR XML FILES WITH NATIVE BROWSER SUPPORT

The Versioning Machine can utilize browser transformation engines found in Internet Explorer 6.0+, Firefox 1.5+, Safari 1.2+, and Netscape 7.1+. Please note that certain VM features are not fully supported across all browsers when relying on native browser support. Once you have encoded your documents, you can view them by following these steps:

  1. If you are not using the default DTD provided, place your DTD file in the folder entitled src. (See section CUSTOMIZING THE VM below for restrictions on using your own DTD.)
  2. Place your XML documents in the folder entitled samples. If you have encoded your documents separately, also place the "holder" file in the samples folder.
  3. Place your images in the subdirectory of samples entitled images.
  4. Open the file (or, for separately encoded documents, the "holder" file) in your browser. Refer to the Help section of the VM to navigate the product.

NOTE: Browsers running the Mozilla engine (i.e. Mozilla, Netscape, and Firefox) are much stricter than Internet Explorer in requiring that file types match the declared mime-types of a server. While the instructions above will allow you to view transformed files on your local machine, you may need to modify the mime-type configuration file on your server if you plan to deliver your documents on the web. Specifically, these browsers require that the server declare files ending in .xml and .xsl as being of either type text/xml or application/xml. If you do not have permission to change your server's configuration, contact the server administrator or consider manually transforming your files (see below).

TECHNICAL INFORMATION

Files and Directory Structure

VM 3.2 resides in a folder entitled v-machine. The root directory of the folder contains several HTML files: index.html, a brief introduction to the Versioning Machine; terms.html, containing the GNU General Public Licensed under which the VM is made available; documentation.html, containing the documentation for the VM (which you are currently reading); and samples.html, a table of contents listing the sample files provided with the VM. In addition, the root directory also houses these five folders:

  1. The src folder contains the following:
    • The javascript and xslt files that run the product (engine.js, engine.xsl, and discrete.xsl). The files engine.xsl and discrete.xsl drive the VM for parallel segmentation and discrete witness files, respectively, by transforming the XML and calling the requisite JavaScript contained in engine.js.
    • vmachine.css, the cascading stylesheet file that defines features of display.
    • An XML TEI DTD (teixtstc.dtd). This default DTD was created using the TEI "pizza chef" from a prose base with tagsets added for linking, figures, analysis, transcription, and critical apparatus.
  2. The vm-images folder contains images associated with the VM's user interface display.
  3. The images folder contains images associated with the site surrounding the VM.
  4. The includes folder contains the cascading stylesheet for the site surrounding the VM.
  5. The samples folder contains sample encoded files that are included for demonstration purposes. The samples folder also contains an images subdirectory that holds JPEGs of some of the sample encoded files.

Customizing the VM

Colors of the main or pop-up note backgrounds, text, or links, as well as the styling of <add>, <del>, and other elements used for transcription of primary sources, are handled with a cascading stylesheet located within the src directory: vmachine.css. You may edit it if you wish to alter any of the default choices or add special rendering to particular tags. Elements used in transcription are tagged post-transformation with a font tag that assigns an appropriate class attribute (e.g., <span class="sic">); you may alter the stylesheet to specify special rendering of the various classes.

If you want to use your own DTD, you should place it in the src folder. While the VM does not require that you have a DTD at all, it will not work unless your documents are (1) well-formed and (2) conform to TEI's parallel segmentation tagging as laid out above. Since the XSL file is based in the tags and hierarchies of a TEI-conformant DTD with critical apparatus tagset, the VM will not work with other kinds of DTDs. Thus, if you wish to use your own DTD, we strongly recommend that it be a TEI-conformant DTD that incorporates the critical apparatus tagset.

You may wish to preserve the look of the VM or create your own design. If you wish to create your own, simply re-do the index.html file within the samples folder to your liking. If you wish to preserve the look of the VM, however, simply replace the links to our sample files in the samples.html file with links to your own files, which should be placed within the samples folder; in this case, you may wish to also remove the link to the "Documentation" icon. To do this, simply erase this link from the index.html page: <span><a href="../documentation.html">Documentation</a></span>.

APPENDIX A

Sample of "Nocturne" Encoded Using Critical Apparatus Tagging

<?xml version="1.0"?>
<?xml-stylesheet href="../src/engine.xsl" type="text/xsl" ?>
<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
  <!ENTITY imagea1 SYSTEM "images/man103.jpg" NDATA JPEG>
  <!ENTITY imagea2 SYSTEM "images/man105.jpg" NDATA JPEG>
  <!ENTITY imagea3 SYSTEM "images/man535.jpg" NDATA JPEG>
  <!ENTITY imagepub SYSTEM "images/nocturne.jpg" NDATA JPEG>
]>

<TEI.2>
  <teiHeader>
     <fileDesc>
        <titleStmt>
          <title>Nocturne</title>
          <author>Thomas MacGreevy</author>
          <respStmt>
             <resp>Text Encoding by Susan Schreibman and Jarom McDonald.</resp>
             <resp>Proofing and additional Encoding by Lara Vetter</resp>
             <resp>Annotations by Susan Schreibman</resp>
          </respStmt>
        </titleStmt>
        <publicationStmt>
          <publisher>Susan Schreibman</publisher>
          <address>
             <addrLine>Maryland Institute for Technology in the Humanities (MITH), University of Maryland, College Park, MD 20742</addrLine>
          </address>
          <availability>
             <p>Thomas MacGreevy's poetry is reprinted here with the kind permission of Margaret Farrington and Elizabeth Ryan. Permission to reproduce images of Thomas MacGreevy's manuscripts has been generously granted by The Board of Trinity College Dublin.</p>
             <p>This poem and manuscript drafts are available from this site for demonstration purposes only. They may not be reproduced without explicit permission from the copyright holder. For copyright information, please contact Susan Schreibman at ss423@umail.umd.edu</p>
          </availability>
        </publicationStmt>
        <notesStmt>
          <note type="critical">There are three TS versions of this poem entitled 'Nocturne, Saint Eloi, 1918'. It was published as 'Nocturne, Saint Eloi, 1929' in The Irish Statesman, II:4 (28 September 1929) 69, under the pseudonym L. Saint Senan (See 'Saint Senan's Well'). 'Nocturne' was written in late 1928 or early 1929. To the editor's knowledge, it has not been reprinted.</note>
          <note type="biographical">During World War I, MacGreevy served for twenty-two months as a second lieutenant in the Royal Field Artillery, spending most of that time in the front line of the Somme (after the war he was promoted to the rank of lieutenant). In France he was wounded twice, the second time (September 1918) more seriously at Commines, where he received a shoulder wound. </note>
          <note type="image">
             <witDetail wit="a1" target="va1">
                <figure entity="imagea1">
                </figure></witDetail>
             <witDetail wit="a2" target="va2">
                <figure entity="imagea2">
                </figure></witDetail>
             <witDetail wit="a3" target="va3">
                <figure entity="imagea3">
                </figure></witDetail>
             <witDetail wit="pub" target="vpub">
                <figure entity="imagepub">
                </figure></witDetail></note>
        </notesStmt>
        <sourceDesc>
          <p>Diplomatic editions of MacGreevy's poetry were created from <title rend="italic">Collected Poems of Thomas MacGreevy: An Annotated Edition</title>, edited by Susan Schreibman (Anna Livia Press and The Catholic University of America Press, 1991). Images of MacGreevy's published poems were taken from MacGreevy's own copy of <title rend="italic">Poems</title> (Heinemann, 1934). Manuscript copies are from MacGreevy's papers at Trinity College, Dublin (individual manuscript numbers appear in the Witness Details below).</p>
        </sourceDesc>
     </fileDesc>
     <encodingDesc>
        <projectDesc>
          <p>Test document for versioning machine project. Marked-up collation of Nocturne.</p>
          <p>DTD constructed from TEI poetry base with tagsets for linking, figures, analysis, transcr, textcrit.</p>
        </projectDesc>
        <variantEncoding location="internal" method="parallel-segmentation"/>
     </encodingDesc>
     <profileDesc>
        <handList>
        </handList>
     </profileDesc>
  </teiHeader>
  <text>
     <front>
        <div>
          <witList>
             <witness sigil="a1" id="va1">'Nocturne, Saint Eloi, 1918' (TCD 7878/1/2)</witness>
             <witness sigil="a2" id="va2">'Nocturne of St. Eloi, 1918' (TCD MS 7989/1/3)</witness>
             <witness sigil="a3" id="va3">'Nocturne, Saint Eloi' (TCD MS 79891/1)</witness>
             <witness sigil="pub" id="vpub">This poem was published in Poems as 'Nocturne'</witness>
          </witList>
        </div>
     </front>
     <body>
        <div0>
          <head>
             <title>
                <app>
                  <rdg wit="a1">Nocturne, St. Eloi, 1918.</rdg>
                  <rdg wit="a2">NOCTURNE OF ST. ELOI, 1918</rdg>
                  <rdg wit="a2"> <del type="hand">Weeds of virtue</del></rdg>
                  <rdg wit="a2"> <del type="hand">The</del> Widowed Virtue</rdg>
                  <rdg wit="a3">NOCTURNE, SAINT ELOI</rdg>
                  <rdg wit="pub">NOCTURNE</rdg>
                </app> </title>
             <note type="critical">
                <p>Saint Eloi, one of the most popular Saints of the Middle Ages, founded a monastery near the present village of Mont St. Eloi, five miles northwest of the city of Arras in northern France. The ruins of the monastery remain, and in 1917-18 were close to the Western Front. There is also a British Military Cemetery nearby.</p>
                <p>Eloi may also be a reference to the words of Christ on the cross: 'Eloi, Eloi, lamma sabacthani? . . . My God, my God, why hast thou forsaken me?' (Mark 15:34-5).</p></note> </head>
          <div1 type="dedication">
             <p>
                <app>
                  <rdg wit="a3"><hi rend="underline">To the memory of
                     <del type="hand">[?]</del> Geoffrey<lb/> England Taylor, 2nd Lieutenant, R.F.A.,<lb/> died of wounds received in action, in<lb/> France, September, 26, 1918.</hi>
                     <note type="biographical">
                        <p>Geoffrey England Taylor, a fellow cadet at the training academy at Bloomsbury in London, was MacGreevy's closest friend during the war. Both men were drafted to the same division in France. MacGreevy was assigned to guns, Taylor to trench mortars: 'the greatest misfortune that could befall a gunner-officer. Trench mortars were regarded with horror . . . [they were] a suicide club.' </p>
                        <p>While MacGreevy was recovering from his shoulder wound in Manchester, he found Taylor's name in the Died of Wounds section of the Casualty List. The death of Geoffrey Taylor, 'one of the most sensitively gentle' of men, represented to MacGreevy the worst horror of war: the destruction of 'life's hopes and dreams'; 'intelligence and beauty'.
                        <title rend="italic">Memoirs</title>, pp. 318-19. </p>
             </note></rdg>
             <rdg wit="pub"><hi rend="italic">To Geoffrey England Taylor, 2nd Lieutenant, R.F.A.,<lb/> "Died of wounds"</hi>.
                <note type="biographical">
                  <p>Geoffrey England Taylor, a fellow cadet at the training academy at Bloomsbury in London, was MacGreevy's closest friend during the war. Both men were drafted to the same division in France. MacGreevy was assigned to guns, Taylor to trench mortars: 'the greatest misfortune that could befall a gunner-officer. Trench mortars were regarded with horror . . . [they were] a suicide club.' </p>
                  <p>While MacGreevy was recovering from his shoulder wound in Manchester, he found Taylor's name in the Died of Wounds section of the Casualty List. The death of Geoffrey Taylor, 'one of the most sensitively gentle' of men, represented to MacGreevy the worst horror of war: the destruction of 'life's hopes and dreams'; 'intelligence and beauty'.
                  <title rend="italic">Memoirs</title>, pp. 318-19. </p>
                  </note></rdg>
             </app> </p>
          </div1>
          <div1>
             <lg>
                <l n="1">
                  <app>
                     <rdg wit="a1 a2 a3 pub">I labour in a barren place,</rdg>
                  </app> </l>
                <l n="2">
                  <app>
                     <rdg wit="a1">Afraid, aware, <del type="hand">little</del>
                        <add rend="hand">blundering</add>, lonely thing:</rdg>
                     <rdg wit="a2 a3 pub">Alone, self-conscious, frightened, blundering;</rdg>
                  </app> </l>
                <l n="3">
                  <app>
                     <rdg wit="a1">Far away, stars wheeling on through space.</rdg>
                     <rdg wit="a2"> <del type="hand">Above me</del>,
                        <add rend="hand">Far away</add> stars wheeling in space,</rdg>
                     <rdg wit="a3">Far above, stars wheeling in space,</rdg>
                     <rdg wit="pub">Far away, stars wheeling in space,</rdg>
                  </app> </l>
                <l n="4">
                  <app>
                     <rdg wit="a1 pub">About my feet, earth voices whispering.</rdg>
                    
                     <rdg wit="a2 a3">About my feet, earth voices whispering. . .
                        .</rdg>
                  </app> </l>
             </lg>
          </div1>
        </div0>
     </body>
  </text>
</TEI.2> 

APPENDIX B

Sample of "Autumn, 1922" Encoded Using Critical Apparatus Tagging

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../src/engine.xsl" type="text/xsl" ?>
<!DOCTYPE TEI.2 SYSTEM "../src/teixtstc.dtd" [
<!ENTITY imagea1 SYSTEM "man533.jpg" NDATA JPEG>
<!ENTITY imagea2 SYSTEM "man111.jpg" NDATA JPEG>
<!ENTITY imagea3 SYSTEM "man109.jpg" NDATA JPEG>
<!ENTITY imagea4 SYSTEM "man534.jpg" NDATA JPEG>
<!ENTITY imagepub SYSTEM "autumn.jpg" NDATA JPEG>
]>

<TEI.2>
  <teiHeader>
     <fileDesc>
        <titleStmt>
          <title>Autumn, 1922</title>
          <author>Thomas MacGreevy</author>
          <respStmt>
             <resp>Text Encoding  by <name>Susan Schreibman</name> and <name>Jarom McDonald</name></resp>
          </respStmt>
        <respStmt><resp>Proofing and Additional Encoding by  <name>Lara Vetter</name></resp><resp>Annotations by  <name>Susan Schreibman</name></resp></respStmt></titleStmt>
        <publicationStmt>
          <publisher>Susan Schreibman</publisher>
          <address>
             <addrLine>Maryland Institute for Technology in the Humanities (MITH), University of Maryland, College Park, MD 20742</addrLine>
          </address>
          <availability>
             <p>Thomas MacGreevy's poetry is reprinted here with the kind permission of Margaret Farrington and Elizabeth Ryan. Permission to reproduce images of Thomas MacGreevy's manuscripts has been generously granted by The Board of Trinity College Dublin.</p><p>This poem and manuscript drafts are available  from this site for demonstration purposes only. They may not be reproduced without explicit permission from the copyright holder. For copyright information, please contact Susan Schreibman at ss423@umail.umd.edu</p>
          </availability>
        </publicationStmt>
        <notesStmt>
          <note type="image">
             <witDetail wit="a1" target="va1">
                <figure entity="imagea1">
                </figure></witDetail>
             <witDetail wit="a2" target="va2">
                <figure entity="imagea2">
                </figure></witDetail>
             <witDetail wit="a3" target="va3">
                <figure entity="imagea3">
                </figure></witDetail>
             <witDetail wit="a4" target="va4">
                <figure entity="imagea4">
                </figure></witDetail>
             <witDetail wit="pub" target="vpub">
                <figure entity="imagepub">
                </figure></witDetail></note>
          <note>There are four TS versions of this poem entitled 'Ireland Autumn, 1922', 'Civil War', and 'A Short History of Our Own Time'. The poem was most probably written between 1924 and 1926. To the editor's knowledge, it has not been reprinted </note>
        </notesStmt>
        <sourceDesc>
          <p>Diplomatic editions of MacGreevy's poetry were created from <title rend="italic">Collected Poems of Thomas MacGreevy: An Annotated Edition</title>, edited by Susan Schreibman (Anna Livia Press and The Catholic University of America Press, 1991). Images of MacGreevy's published poems were taken from MacGreevy's own copy of <title rend="italic">Poems</title> (Heinemann, 1934). Manuscript copies are from MacGreevy's papers at Trinity College, Dublin (individual manuscript numbers appear in the Witness Details below).</p>
        </sourceDesc>
     </fileDesc>
     <encodingDesc>
        <editorialDecl>
          <p>Test document for versioningmachine project. Marked-up collation of Autumn.</p>
          <p>DTD constructed from TEI poetry base with tagsets for linking, figures, analysis, transcr, textcrit.</p></editorialDecl>
        <variantEncoding method="parallel-segmentation" location="internal"/>
     </encodingDesc>
  </teiHeader>
  <text>
     <front>
        <div>
          <witList>
             <witness sigil="a1" id="va1">'A Short History of Our Own Time' (7989/1/10)</witness>
             <witness sigil="a2" id="va2">'Civil War', which was deleted and replaced with 'Ireland, Autumn 1922'</witness>
             <witness sigil="a3" id="va3">'Ireland Autumn, 1922' (7989/1/7)</witness>
             <witness sigil="a4" id="va4">(7989/1/8)</witness>
             <witness sigil="pub" id="vpub">The poem was published in
                <title type="italic">Poems</title> under the title 'Autumn, 1922'</witness>
          </witList>
        </div>
     </front>
     <body>
     <head>
        <title>
          <app>
             <rdg wit="a1">A Short History of Our Own Times.</rdg>
             <rdg wit="a2"> <del rend="typed">CIVIL WAR</del> <add rend="hand">
                Ireland, Autumn 1922</add> </rdg>
             <rdg wit="a3 a4">IRELAND, AUTUMN, 1922</rdg>
             <rdg wit="pub"><add rend="hand">IRELAND</add> AUTUMN, 1922</rdg>
          </app>
          <note type="critical"><p>The alternative titles MacGreevy experimented with  provide the key to this very short poem. By the autumn of 1922 over six years had passed since Patrick Pearse had proclaimed the Irish Republic in Dublin's General Post Office. The country had seen the heart of its capital destroyed by the fires of Easter 1916, and this was followed after the Seinn Fein victory in the 1918 election by an extended campaign of guerilla warfare against the British with its reprisals and counter-reprisals.</p>
             <p>In the end, nationalist Ireland was divided into bitterly opposing camps, and engaged in civil war over the terms of the agreement reached in London in December 1921. The new national institutions that emerged did so more through the passage of time than as the expression of any national ideal or vision. MacGreevy's poem captures the despair and weariness of a nation torn apart by war and bitter political divisions.</p></note> </title> </head>
     <lg n="1">
        <l n="1">
          <app>
             <rdg wit="a1 a2 a3 a4 pub">The sun burns out,</rdg>
          </app> </l>
        <l n="2">
          <app>
             <rdg wit="a1">The world withers,</rdg>
             <rdg wit="a3 a4">The world withers,<milestone unit="stanza"/></rdg>
             <rdg wit="a2 pub">The world withers<milestone unit="stanza"/></rdg>
          </app> </l>
        <l n="3">
          <app>
             <rdg wit="a1">Poets sing no more,</rdg>
          </app> </l>
        <l n="4">
          <app>
             <rdg wit="a1 a2 a4 pub">And time grows afraid of the triumph of time.
                
                <note type="gloss"><p>The fifth of six allegorical triumphs in Petrarch's Trionfi is <emph rend="italic">the Triumph of Time</emph>.
                  Petrarch's Triumphs, often depicted as Father Time in his chariot surrounded by symbolic devices such as the scythe and hourglass, were frequently represented by Baroque and Renaissance artists.</p> <p>MacGreevy, however, may be thinking of one or more of the paintings that he saw during his visit to the Prado in Madrid in 1924. One is Goya's Saturn [Time] Devouring His Son, and the other is Pieter Brueghel the Elder's The Triumph of Death, which depicts a whole society visited by death riding a pale horse (using imagery from the Apocalypse) against a background of barren landscape and a darkened sky.</p></note> </rdg>
             <rdg wit="a3">And time grows afraid</rdg>
          </app> </l>
        <l n="5">
          <app>
             <rdg wit="a3">Of the triumph of time.
                <note type="gloss">The fifth of six allegorical triumphs in Petrarch's Trionfi is <emph rend="italic">the Triumph of Time</emph>.
                  Petrarch's Triumphs, often depicted as Father Time in his chariot surrounded by symbolic devices such as the scythe and hourglass, were frequently represented by Baroque and Renaissance artists. MacGreevy, however, may be thinking of one or more of the paintings that he saw during his visit to the Prado in Madrid in 1924. One is Goya's Saturn [Time] Devouring His Son, and the other is Pieter Brueghel the Elder's The Triumph of Death, which depicts a whole society visited by death riding a pale horse (using imagery from the Apocalypse) against a background of barren landscape and a darkened sky.</note> </rdg>
          </app> </l>
     </lg>
     <closer>
        <app>
          <rdg wit="a1">
             <lb/><name>Thomas Mc Greevy,</name>
             <address>
                <lb/><addrLine>19 Lincoln Chambers,</addrLine>
                <lb/><addrLine>Lincoln Place,</addrLine>
                <lb/><addrLine>DUBLIN.</addrLine>
             </address> </rdg>
          <rdg wit="a4">
             <lb/><name rend="hand">L. St. Senan </name><note type="biographical">    MacGreevy published several poems and reviews under the pseudonym L. St. Senan in the early-mid 1920s.
Saint Senan (d.560) founded several monasteries in MacGreevyâ..s  native Ireland. Senan's last settlement was on Scattery Island in the estuary of the Shannon, near MacGreevy's birthplace.
</note>  
             <lb/><name rend="type"> (L. St. Senan)</name>
             <lb/><name>Thomas McGreevy,</name>
             <address>
                <lb/><addrLine>15 Cheyne Gardens, London, S.W.3</addrLine>
             </address> </rdg>
        </app> </closer>
     </body>
  </text>
</TEI.2>