Many encoding practices are common to all types of LEMDO XML files. Subsequent chapters deal with particular types of files (modern texts, annotations, etc), but you will want to come back to this chapter on a regular basis to remind yourself of general encoding principles and practices.

Word files from any era and especially from the early days of word processing contain hidden characters that will break the LEMDO build. Do not copy and paste directly from a Word file (a file with a .doc or a .docx extension) into an XML file. If you must copy content, put it in a text editor first. All PCs have a text editor already installed. There are many text editors available. Commons ones are Notepad (Windows OS), Text Editor (Linux Ubuntu OS), Atom, BBEdit, and SimpleText (Mac OS). Check the file extension of the file from which are copying. It must be .txt.

It is imperative that you begin every work session by opening the lemdo-all.xpr project file. This file contains important scripts that control the behaviour of Oxygen and give you access to tools that we have built especially for LEMDO users. The XPR file also ensures that you are validating your XML files against the schema and Schematron that determine how you are supposed to encode your play; the schema and Schematron catch your mistakes and prompt you to correct them. See LEMDO Oxygen Project.

Any file that you commit to the repository must be valid. It must follow the rules that are embodied in the schema and Schematron. An invalid file can break the build process. If you open the lemdo-all.xpr file first before you open any other file, you can be sure that you are validating against the LEMDO schema and Schematron. See Validate Files.

Infrastructure IDs

Texts and Anthologies

Facsimiles and Performances

Infrastructure IDs refer to IDs belonging in the following files, including the files themselves: PERS1, BIBL1, ORGS1, TAXO1, and LOCA1. The convention that we follow requires you to use unique IDs. These IDs must be structured as follows: XXXX#, where X is a letter and # is a number consisting of one or more digits. The letters and numbers are not arbitrary: use the first four meaningful letters of the title of the file; if the file you are naming uses a particular 4-letter combination for the first time in our database, the number will be 1. Otherwise, check the A–Z Index for the next available number for this particular 4-letter combination. For example, when you create a personography file, the first four letters are PERS. Given that this file was the first instance of this letter combination, the number was 1: PERS1.xml. Always check your ID against the A–Z Index, before finalizing it and committing. The A–Z Index text file is available from the Resources menu on the lemdo-dev site.

When you add a new text to the repository, consult DREʼs list of play IDs, and look for the title of the play you are adding. You will notice that the convention for plays is different than that of infrastructure files. The difference is due to scholarly conventions for play naming. IDs for Shakespeare plays have been long standardized; they are even listed in the Chicago Manual of Style and the MLA Handbook. DRE extends the implied principles for naming Shakespeare plays to all other plays. If you cannot find the title you are looking for, consult with the LEMDO Director, who will in turn consult with the DRE Coordinating Editors.

The conventions for facsimiles and performances include the ID of the text to which they are connected. When you name a facsimile, follow this pattern: facs, followed by an underscore (_), followed by the document ID (xml:id), followed by an underscore (_), followed by the library acronym from which the facsimile is taken. If you are not sure about the latter, consult with the LEMDO Director. For example, the facsimile corresponding to The Honest Whore, Part 1, Quarto 1 is named facs_1HWQ_Q1_Folger.

When you name a performance file, follow this pattern: perf, followed by an underscore (_),followed by the document ID (xml:id) of the text to which the performance belongs, followed by an underscore (_), followed by the ID of the anthology to which the performance belongs. For example, the files pertaining to the QME production of Friar Bacon and Friar Bungay all begin with perf_FBFB_QME.

Never capitalize file extensions (i.e., .jpg, .png).

This section pertains mainly to LEMDO Team members at UVic: When you are creating an @xml:id value for an entity in one of the sitewide database files (PERS1, PROS1, GLOSS1, HAND1, BIBL1, PROD1, ORGS1, or TAXO1), you must check the complete list of LEMDO @xml:id values to ensure that you are creating a new value. These ids are generally four uppercase letters followed by a number (JENS1, SHAK1, ADAM1, LEMD3, and so on).

We have two ways of viewing all the @xml:id values in the project (except for the anchor, speech, and paragraph ids). Note that you must be on the Jenkins site looking at the most recent build. When you begin working for LEMDO, we will give you the links to these pages. Assign the next available id. If you want to create an id beginning with ADAM, search the page for the string ADAM. If your search shows that ADAM1, ADAM2, and ADAM3 have been used, then the next available id is ADAM4.

The status of a document determines a number of things: As a document moves through the stages of remediation, encoding, peer review, proofing, and publishing, we track its movement via dated <change> elements in the <revisionDesc> . This information is also useful to the LEMDO team for tracking our progress.

Every encoded file should have a <revisionDesc> . This element should contain an @status attribute that documents the current stage of the fileʼs encoding process.

LEMDO’s predefined document status values are listed in the table below.

Note: Files in /main/ should not have the status “empty” or “draft”. They all contain converted text. Eventually, these files might have the status published or deprecated.

We use the <change> element to track our work because it gives credit where credit is due and allows future encoders to see what has been done to the file before they continue work on it.

When you begin encoding a file, add a <change> element as a child of the <revisionDesc> . Put the @who attribute, the @when attribute, and the @status attribute on the <change> element. These indicate who you are, the date you started remediating, and the status of the file. Add a statement for what you are doing in the file in the text node (e.g., began remediating file). For example:

When you have completed working on your file, add a <change> element. Put important and relevant information about your file in the text node of this <change> element, such as what you have completed and what must still be done in it. This protocol ensures that another encoder will be able to efficiently continue work on your file if there is any further work that must be done on it. For example:

You may add other <change> elements during the encoding process to indicate when you complete significant writing or encoding tasks. For example, you may want to make note of when you finished numbering <lb> elements in semi-diplomatic transcriptions. While it is optional to add <change> elements for completing significant writing or encoding tasks, it is good encoding practice to do so. You should always add a <change> element when you begin work on a file and when you finish work on it.

For example:

TEI allows the <title> element to appear in both the <teiHeader> (the metadata) and the <text> which might seem redundant, but actually allows you to make a helpful distinction between the title of your XML file and the title of the text that you want to give to the text captured in the XML file.

For primary texts, LEMDO aims to standardize filenaming practice while still allowing some editorial flexibility in play titles.

For born-digital texts, the title in the <titleStmt> is the title that will show up on the webpage.

Note that the title of the XML file, captured in the <titleStmt> section of the metadata, is distinct from the filename, which is generally truncated and must exactly match the xml:id of the file.

LEMDO uses the <title> element in several ways. Many types of files have titles:

You will find more information about titles for the various components of your edition in the relevant chapter for each component.

Because of the hierarchical organization of elements, it is sometimes impossible to capture fragmented parts of a text within a single element. Thus, we need a way to connect these parts even when they are wrapped in separate elements. The linking attributes @next and @prev attributes are one way to point to discontinuous segments. Combined with the @xml:id attribute, they can be used to connect parts of the text that are separated because of the need to maintain the hierarchy of TEI elements.

You will most commonly use the @next and @prev attributes to connect quotations that span multiple lines and letters that are interrupted by dialogue, but they are not limited to these usages.

When adding the @next and @prev attributes to a series of elements, you must give each element a value on the @xml:id attribute that is unique to the file it is in. The @xml:id value for each element includes the prefix emd, which stands for “early modern drama”; the abbreviation of the play; the name of the element that the @xml:id attribute is on; and a number unique to the file, all connected by underscores. By making each element in a series unique, we can assign them a place in the sequence in relation to the other unique elements.

After assigning @xml:id values to each element in the series of fragments you want to connect, add the @next and @prev attributes to the elements. We use the @next attribute to indicate, by assigning it a unique number, which element follows the one that the @next attribute is on. Similarly, the @prev attribute includes the unique number of the preceding line to indicate which element comes before the one that the @prev attribute is on.

Note that the first fragment in the sequence that you assign a @next attribute to will not have a @prev attribute because there is no previous fragment in the series to point to. Likewise, the last fragment in the series will have no @next attribute. All fragments between the first and last must have both the @next and @prev attributes.

See also Chapter 16: Linking, Segmentation, and Alignment in the TEI Guidelines.

This is a list of elements which most commonly need the @next and @prev attributes, with some scenarios in which they will be required:

See also Encode Letters and Songs in Modern Texts to learn how to encode fragmented sequences in letters and songs.

See also the Shared Verse Lines.

Although split lines are also cases of fragmented pieces of the text being linked together through encoding, we do not use @next and @prev to link split lines. Since split lines are so common, we developed a unique encoding practice for them.

For split lines, we add the @part attribute and one of three values, I, M, or F, to the <l> element wrapping the split line. The I, M, and F values stand for initial, medial, and final respectively and indicate the lineʼs position in the sequence of split lines:

Sometimes a characterʼs quotation spans more than one line of verse, however, the hierarchical structure of XML means that quotation elements cannot span multiple <l> elements. In this case, you must use the @next and @prev attributes to connect the fragments of the quotation: