This document offers some instructions on how to convert an old IML file into TEI. Note that this does not give a full explanation of how these processes work; instead, this file gives a summary of how a file can be converted into TEI. However, since the encoding of the source files can differ, the conversion is, in a sense, non-deterministic: each file, edition, or set of files may require editing—either in the source file itself or in the transformation files—in order to get the desired results. Note, as well, that the conversion is not meant to make perfect output TEI; instead, it is meant to give a workable copy of the file that is valid against the full TEI schema and must then be evaluated by a (human) XML editor to check for any inconsistencies or problems.

There are four different types of documents that are converted from their respective formats into TEI:

However, it often necessary to convert more than one of these documents at a time (e.g. the IML file and its associated critical paratexts). The instructions below detail how to convert an individual file, an edition (a set of files associated with a work), and a set of files or a collection.

The IML to TEI conversion is set up in modules, which call each other. It can be represented like so:

What this means is that you can convert the following to TEI: Each step of this process is described in detail below.

¶ Oxygen

¶ Terminal

¶ Apparatus

¶ XWiki

In the IML, documents were organized by work, which referred to the abstract idea of a text. For example, the work Hamlet refers to the material books of Hamlet, the scanned facsimiles, the edited texts, a production of the work, source materials, and adaptations. For the purposes of the conversion, the concept of a work helps to provide a set of files for conversion. For example, converting the IML for the work of As You Like It means to convert all of the IML files related to As You Like It (e.g. the folio, quarto, and modern files).

Note that converting a work requires the files to exist in the pre-existing ISE Subversion repository, and for that repository to be checked out on your computer. If the files for that work do not exist in the repository (i.e. it is a work whose files were not added to the ISE repository before the move to TEI), then you will need to convert each file individually.²

¶ Oxygen

¶ Terminal

¶ Oxygen

¶ Terminal

If everything goes okay, then the result files should be placed in the location code/out/{$thisWork}/main/emd{$thisWork}_M.xml. The files should be valid TEI, but they are not necessarily valid LEMDO TEI. Since the IML is differently structured than standard TEI, there are often errors in the document that need to be resolved by hand before they can go into the LEMDO repository.

Open the file in Oxygen and check the fileʼs validity. If the file is valid, then you can move the file into its proper place within data/texts/ (remember to svn add it to the LEMDO repository). If it is invalid, then you will need to resolve the invalidities. In all cases, if you are unsure as to how best to fix the file, consult with the Coordinating Editor. Mostly, the invalidities are as follows:

Schematron Error	Cause	Possible Solutions
Modern verse lines should be capitalized	This is an issue with how the flat structure of lineation in the IML is converted to the TEI. Occasionally, editor line beginnings (the IMLʼs <ln> element) were added to the middle of lines accidently.	This usually involves moving words into the preceding or following line, so it must be done with caution.
Do not use square brackets for editorially supplied segments	The practice in the IML files was to place editorial additions in square brackets; this error should only be raised in Modern texts almost exclusively within act or scene headings as well as stage directions.	Any text that is contained with a square bracket should be replaced with a TEI <supplied> tag.
Do not tag stage directions as verse lines	This occurs when stage directions are tagged as a <l> element, usually with no surrounding context.	In most cases, the wrapping <l> can be removed.
Donʼt use explicit angle brackets in text. If you want to reference an element, use the gi element or the code element.	Angle brackets (i.e. < and >) primarily occur only in instances where an IML file had incorrectly added an additional angle bracket to a tag (something like <</L>).	These can almost certainly be removed in the texts; however, it might also indicate that an element was incorrectly typed in the source and has thus been dropped from the TEI encoding. Instances where these symbols occur must be checked against the original IML file to ensure that nothing has been lost in the conversion.
Use the em-dash character (—), not double hyphens or en-dashes.	The IML Editorial Guidelines allowed for the use of double-hyphens or en-dashes in modern texts.	As per the DRE Editorial Guidelines, all double dashes should be converted to em-dashes in modern texts.
This <l> has part value I but no following M or F.3	This happens when part verse lines have been tagged as an initial line, but has no medial or final line. Usually, this is a case where the medial or final line (i.e. @part= "F" ) has been erroneously omitted in the encoding.	Usually the next line is a medial or final line, and thus you can add a @part="F" to the following line, but you may need to consult with the Coordinating Editor to determine the proper solution.

While the IML to TEI conversion is fairly robust, IML files can differ in subtle ways that may cause the build to fail. Below are some common errors that might occur and the steps that a programmer or encoder can take to resolve any issues.