The documentation in this chapter is for all repo users. It is relevant for editors,
encoders, remediators, and anthology leads, containing foundational information about
ensuring your files are error-free and have functional links.
The LEMDO TEI schema is supported by a Schematron file that enforces project-specific
rules that are not governed by TEI. For example, LEMDO requires curly apostrophes.
If you type a straight apostrophe, you will get a Schematron error as you encode to
remind you to use the curly apostrophe.
We also have robust diagnostics that can generate reports and flag potential problems.
Between LEMDO’s constrained schema, the Schematron, and our Diagnostics, you have
plenty of checks to help you get the encoding right and finish all the parts of your
file.
The pages in this chapter describe the permanent diagnostics. We often add temporary
diagnostics to help us clear up a pattern of errors before we write Schematron to
prevent those errors in the future.
Learning Outcomes
This chapter is designed to support you throughout the process of encoding files and
preparing them for publication. By the time you have worked through this chapter,
you will:
Know how to fix Schematron errors.
Know where to find and how to use our general diagnostics.
Know how to check diagnostics for your specific edition or anthology.
Schematron is the language that LEMDO uses to write rules specific to LEMDO’s encoding. Schematron, alongside our schema, ensures that encoding is consistent and correct throughout the LEMDO project. If
your encoding does not follow one of the Schematron rules that we have written, then
you will get a validation error. This error will prompt you to go back and correct your encoding. Important: fix validation errors as soon as you see an error message or a red squiggly line;
if you ignore error messages, the errors will compound and become harder to correct.
If you commit an invalid file, it will break the build and prevent our Jenkins Continuous Integration Server from serving up a new version of the LEMDO-dev website. When the build is broken, nobody can see
their recently committed work rendered in HTML. If you inadvertently break the build,
a member of the LEMDO team will contact you to let you know that we are fixing the
error or to invite you to fix the error causing the build break.
If we see a frequently occurring error that is not currently prevented by Schematron,
we will write a new Schematron rule in the ODD file (lemdo.odd). You must svn up regularly to ensure that you get any new Schematron rules that we add.
Step-by-Step: Check Validity
Save your file. You always want to save your file before validating; if you save after
validating, you run the risk of introducing a new error if you press the wrong key
combination while trying to save.
Click the validation button at the top of your Oxygen window. (The icon resembles
a piece of paper with a red checkmark.)
Check for the validation message at the bottom of your Oxygen window. It will say
either Validation successful or Document contains errors.
If your validation is successful, you can either continue working or commit your file.
If your validation is not successful, you must fix the error. Never commit an invalid
file.
For more detailed instructions on validating a file, see Validate Files.
Practice: Fix Validation Errors
To fix a validation error, look at the error message at the bottom of your Oxygen
window. In most cases, we have written instructions for how to fix Schematron errors.
For example, if you have a straight apostrophe in your file, you will get an error
message that says: ERROR: Straight apostrophes are not allowed in text. Use curly apostrophes instead.
The shortcut to add a curly apostrophe is ctrl+shift+’ (on PC or Unix) and command+shift+’
(on iOS). The LEMDO team writes these error messages; the messages are not generated by Oxygen.
Please follow the guidance we have written for you in these error messages.
If you are unable to see the entire message because it is cut off, you can pull up
a window with the full message by double clicking on the message text.
If you are unable to fix the error yourself, contact the LEMDO team for help. Do not commit your file while it is invalid.
Although many errors can be caught by the Schema and by Schematron and flagged for
you in Oxygen, some errors cannot. Even when we can check an error via the Schema
or via Schematron, we sometimes choose not to break the build over the error, typically
because there are too many instances of the error to fix, such as old TLN links. Our normal workflow is to write a Diagnostic to catch and list these errors. Once
we have cleared the Diagnostic report, we will write Schematron to prevent such errors
occurring in the future and then retire the Diagnostic. In other cases, we use Diagnostics
as a mechanical copyeditor to catch and enforce decisions that cannot be enforced
by Schematron.
Practice: Check LEMDO Diagnostics
To navigate to LEMDO diagnostics from the LEMDO-dev site, click on the Resources tab in the top navigation bar and select Diagnostics. Your browser will open the LEMDO Diagnostics Web page.
Diagnostics are under the Consistency Checks tab of the LEMDO Diagnostics page; by default, the page opens with this tab expanded.
Each diagnostic has its own collapsable tab. Each diagnostic check that does not currently
find any errors across the LEMDO repository is coloured green and has the number zero
in brackets beside the diagnostic name. Each diagnostic check that does find errors
is coloured red and has the number of errors found by the diagnostic check in brackets
beside the diagnostic name.
You can filter the diagnostics to show errors from just one edition by typing emd followed by your edition abbreviation in the filter text box and clicking Filter. For example, if you were working on the Henry V edition, you would type emdH5 into the filter box. You can also search for diagnostics in a specific file by typing
the full file name into the filter box. For example, you can type emdHam_EM_collation to find errors in just that file.
For instructions for fixing errors flagged by the diagnostic checks, see the relevant
section below on the type of error that you wish to fix.
In addition to the consistency checks, there is a statistics tab on the diagnostics
Web page. This tab is closed by default, but you can click on the right-facing arrow
to expand the statistics tab. The statistics include counts of files in the LEMDO
repository, of total xml:ids across the repo, and of the number of facsimile files
that we have stored on our facsimile server. If other statistics would be useful to
you, please let us know. We will add them if we can.
Excluding a Portfolio or File from Diagnostics
Sometimes one portfolio or file can generate many errors in the diagnostics without
any prospect of their being fixed in the near future, and all of those results may
swamp and obscure important errors that need to be addressed quickly. In such cases,
a programmer or project administrator can add a file id or a partial file id to this
text file in the SVN repository: jenkins/diagnostics_exclusions.txt. Our diagnostics build process ignores files listed in this file and does not report
errors. The LEMDO team will review the diagnostics_exclusions.txt file periodically to check that it contains only inactive files.
Files Containing Bad Facsimile Links Diagnostic
LEMDO stores facsimile images on an HCMC server. They are too big and too numerous
to include in LEMDO’s Subversion repository. We create XML files in the facs folder the the LEMDO repo in order to encode the metadata for the images and to give
each image an xml:id. LEMDO editors and encoders can then point to facsimile images
from their semi-diplomatic transcription files. Because this linking process is relatively
complex, there are sometimes errors in linking from files in the LEMDO SVN repo to
the server containing the facsimile images. This diagnostic catches these errors by
finding links to images that do not exist.
If you are working on facsimile files in the facs folder, you should regularly check this diagnostic to ensure you do not introduce
any errors.
If there is an error in this diagnostic (i.e., a file has tried to link to a non-existant
facsimile file), you must correct the values for the
@url attributes on the
<graphic>
elements of your facsimile file. Follow the instructions in Encode Images in Facsimile Files.
If you cannot find the error, check the value of the
@url attribute against the URI of the facsimile images on the facsimile server. To navigate
to the facsimile server, click the Resources tab on the top navigation bar of the LEMDO-dev website and select Facsimiles. Click on the link for the copy that you are working with to be brought to a list
of the relevant URIs.
Bad Internal Links Diagnostics
LEMDO has two diagnostics for bad internal links: an urgent diagnostic and a non-urgent
diagnostic. Both find broken internal links (i.e., links from a LEMDO file to an entity
within the LEMDO repo). The urgent diagnostic highlights errors in files with status
values indicating they are close to publication. The non-urgent diagnostic finds internal
link errors in all other LEMDO files.
Under the bad internal link diagnostic, each file with one or more bad link is listed
along with the link that is broken. To fix the bad link, go to the file that contains
it and search for the bad link. Fix the link following the instructions for encoding
links as given in Chapter 5. Making Links.
Pointers to External Anchors Diagnostic
Using a pointer to link to an anchor in another edition is not forbidden (yet), but
it is not as stable as linking to structural entities.1 When you make a link from your edition to another edition, you should use
<ref>
elements to link to structural elements with xml:ids (such as acts, scenes, speeches,
or paragraphs).
To resolve this diagnostic, search in your file for the anchor ID that is linked to
and replace it with a link to a structural entity following the directions in Encode Reference Links.
Missing Speaker Elements Diagnostic
All speeches in modernized texts should have a speech prefix encoded with the
<speaker>
element. This diagnostic finds speeches in modernized texts that do not have speech
prefixes. (Note that some speeches in semi-diplomatic transcriptions do not have speech
prefixes.)
To resolve this diagnostic, add speech prefixes to your modernized text where they
are missing. See Encode Speakers in Modernized Texts. If you have a compelling reason not to add a speech prefix, discuss the matter with your anthology lead, who will in
turn take up the matter with the LEMDO team.
Texts Lacking Authors Diagnostic
All semi-diplomatic and modernized texts should have an author identified in their
metadata. This diagnostic identifies plays, shows, and poems that do not have a
<respStmt>
for an author in their
<titleStmt>
elements.
To add an author to the metadata for your file, follow the instructions in Encode Responsibility Statements. In cases where the work’s author is unknown, add a
<respStmt>
for the author and link to the Anonymous entry in PROS1 as follows:
Files that began as IML files that have not been completely remediated have links
to targets beginning with tln:. These correspond to the old through line numbers used by the Internet Shakespeare Editions. Old TLN links will be removed during the remediation process. Remediators should
delete links to TLNs once they have replaced them with functioning links to the LEMDO
edition.
Bad Documentation Resp Pointers Diagnostic
We give credit to the people who have worked on documentation using the
@resp attribute on the root
<div>
element of documentation files. All
@resp values in documentation must link to a
<respStmt>
element in the ODD file (lemdo.odd) and must prefixed by or: (e.g., or:odd_JENS1_wtm).
To fix this error, check that all
@resp values match a
<respStmt>
in the ODD file. If there is no
<respStmt>
for the person who needs credit for a particular role, ask a member of the LEMDO
team with read/write permissions over the ODD file to add the
<respStmt>
. For more information, see Give Credit for Documentation Files.
Unlinked Documentation Files Diagnostic
LEMDO’s many documentation files are included in our Encoding Guidelines only if they are listed in the ODD file (lemdo.odd). We do not want to have documentation files in the repo that are not listed in the
ODD file. If there is a documentation file in the repo that is not listed in the ODD
file, this diagnostic will flag it.
To clear this diagnostic, either list the documentation file in the ODD file or move
deprecated documentation files to the data/obsolete/oldDocumentation folder. To avoid this diagnostic error, we recommend writing content for new documentation
files as soon as you create them so that they are ready to add to the ODD file as
soon as they are added to the repo. Do not make XML files as placeholders for text
you have not yet written.
Links Using the Role: Prefix to Empty Roles Diagnostic
LEMDO allow you to make links from your collation, annotations, and critical paratexts
to characters in your character list(s). To make such links, encoders use a
<ref>
element with a
@target attribute. The value of the
@target attribute must be prefaced by role: and must link to a
<person>
element in a character list.
The intention of these links to characters in character lists is to provide additional
information or context about the character by linking to the location of their character
note. There is no point in linking to a
<person>
element that does not have a child
<note>
element because there will be no information about the character. In cases where
a
<person>
element does not have a child
<note>
element, the diagnostic will flag the redundant link.
To clear this diagnostic, simply remove the link to the cast list. Alternatively,
add a note to the character list.
Broken Link Chains Diagnostic
When we have split elements (e.g., a quote that spans multiple verse lines, so must
be split into multiple
<quote>
elements), we use the
@next and
@prev attributes to link to the other parts of the element. If the links do not correctly
go to an xml:id either before or after the element, the diagnostic will flag it. For
more information, see Encode Split Elements.
To resolve this diagnostic, check that the numbering is correct for each part of the
split element. Then, check that the value of each
@prev and
@next attribute links to an existing xml:id.
Tags with Bad
@xml:lang Values
LEMDO tags foreign languages using the
@xml:lang attribute and a set of allowed values listed in our ODD file. Each value corresponds
to an IANA value for a specific language. For more information on encoding foreign languages, see
Encode Foreign Languages.
To resolve this diagnostic, ensure that the value you give the
@xml:lang attribute is one of the ones listed in the dropdown when you add the
@xml:lang attribute in Oxygen. You can also view the language values in tabular form in IANA Values for Specific Languages. If you are encoding text in a language that is not included in our allowed languages
list, contact the LEMDO team to have the language added.
Duplicate Bibls Diagnostic
The LEMDO bibliography serves all the anthologies and editions therein. As a consquence,
there are thousands of entries spread across the 26 BIBL1 files (BIBL1_A, BIBL1_B, and so on), which are regularly updated and expanded by the LEMDO team. We have
occasionally created a duplicate entry. This diagnostic uses a similarity metric to
check the BIBL1 files and flag
<bibl>
entries that appear to be similar. If you are an RA checking the general diagnostics
report, you will want to clear this diagnostic regularly so that you catch duplicates
shortly after the second one has been created.
If two entries do refer to the same source, search the repository to see which xml:id
has been cited the most often in
<ref>
elements. If you are checking Diagnostics regularly, you will normally find that
the duplicate id has been used just once or twice. Standardize the
<ref>
elements so that they all point to the most-used xml:id. Delete the duplicate
<bibl>
entry.
If the diagnostic has flagged two similiar entries that are not duplicates, we have a mechanism for telling the similarity metric to ignore pairs
(or trios) of entries. Add a
@corresp attribute to the
<bibl>
element of each one. The value of the
@corresp attribute is not: followed by the xml:id of the entry: e.g., not:CONN2. Note that the
@corresp can have multiple space-separated values.
In the examples below, the similarity metric has flagged three editions contributed
by Francis X. Connor to the New Oxford Shakespeare. To each entry, we have added the
@corresp attribute to indicate that the entry is not a duplicate of either of the other two.
<bibl xml:id="CONN3" corresp="not:CONN2 not:CONN10"> <editor>Connor, Francis X.</editor>, ed. <title level="m">Lucrece</title>. By <author>William Shakespeare</author>. <title level="m">The New Oxford Shakespeare</title>. Ed. <editor>Gary Taylor</editor>, <editor>John Jowett</editor>, <editor>Terri Bourus</editor>, and <editor>Gabriel Egan</editor>. <pubPlace>Oxford</pubPlace>: <publisher>Oxford University Press</publisher>, <date>2016</date>. 673–721. WSB <idno type="WSB">aaag2304</idno>.</bibl>
<bibl xml:id="CONN10" corresp="not:CONN3 not:CONN2"> <editor>Connor, Francis X.</editor>, ed. <title level="m">The Tragedy of Coriolanus</title>. By <author>William Shakespeare</author>. <title level="m">The New Oxford Shakespeare</title>. Ed. <editor>Gary Taylor</editor>, <editor>John Jowett</editor>, <editor>Terri Bourus</editor>, and <editor>Gabriel Egan</editor>. <pubPlace>Oxford</pubPlace>: <publisher>Oxford University Press</publisher>, <date>2016</date>. 2723–2813. WSB <idno type="WSB">aaag2304</idno>.</bibl>
<bibl xml:id="CONN2" corresp="not:CONN3 not:CONN10"> <editor>Connor, Francis X.</editor>, ed. <title level="m">Venus and Adonis</title>. By <author>William Shakespeare</author>. <title level="m">The New Oxford Shakespeare</title>. Ed. <editor>Gary Taylor</editor>, <editor>John Jowett</editor>, <editor>Terri Bourus</editor>, and <editor>Gabriel Egan</editor>. <pubPlace>Oxford</pubPlace>: <publisher>Oxford University Press</publisher>, <date>2016</date>. 639–672. WSB <idno type="WSB">aaag2304</idno>.</bibl>
Unknown Old IML Characters Diagnostic
When files were converted from IML to TEI, some special characters were not transformed
into TEI. These characters were not recognized in the transformation, and so we wrote
a diagnostic to identify characters that need to be remediated manually.
To resolve this diagnostic, open the file containing the old IML character search
for it using Ctrl+F (Cmd+F on Mac). Check the transcription agains the facsimile of
the text and add the correct character. For information on encoding glyphs and ligatures
in TEI, see Encode Glyphs and Ligatures in Semi-Diplomatic Transcriptions.
In 2026, we still have over 20,000 characters to remediate. A glorious day is coming
when all IML files will be fully remediated, and then we will retire this diagnostic
with fanfare and relief.
Files Containing TEI
<persName>
Elements without
@ref Attributes Diagnostic
LEMDO uses the
<persName>
element to tag people’s names in metadata and primary texts. In order to identify
the person, we put a
@ref attribute on
<persName>
linking to either PERS1 (for contributors to LEMDO) or PROS1 (for historical people).
Our processor cannot do anything with a
<persName>
element that has no
@ref attribute. This diagnostic finds instances of
<persName>
elements with no
@ref attribute.
To resolve this diagnostic, add
@ref attributes to all
<persName>
elements. If the person is a LEMDO contributor, give
@ref a value of pers: followed by the person’s xml:id as given in PERS1. If the person is historical, give
@ref a value of pros: followed by the person’s xml:id as given in PROS1. If the person does not already
have an xml:id in PERS1 or PROS1, contact the LEMDO team to add one.
LocalCit Pointers to Divs without Heads Diagnostic
Within an edition, you may use the
<ptr>
element to link to
<div>
elements that have child
<head>
elements. The text node of the head element is used to create a linkable string of
text. This diagnostic checks that the
<div>
has a child
<head>
.
To resolve this diagnostic, ensure that you are using the
<ptr>
only as allowed in the LEMDO project: use it only to link within your edition and
only to link to acts, scenes, speeches, stage directions, or
<div>
elements that have a
<head>
. If you have linked to a
<div>
without a
<head>
, add a
<head>
element. Adding a
<head>
will not only clear the diagnostic, but will also add the
<div>
to the page’s table of contents.
<catRef>
Elements whose Target Does Not Match Their Scheme Diagnostic
LEMDO uses the
<catRef>
element to specify important information about the nature of a file so that that
our processor is able to treat the file according to its purpose, source, content,
and editorial treatment. There are two attributes on the
<catRef>
element:
@scheme and
@target. Each has a list of allowed values. Each of the
@target values belongs to one of the schemes. It is important for our processor that the
value of
@target belong to the scheme given as the value of the
@scheme attribute. This diagnostic finds instances where the
@target value does not belong to the scheme indicated in the value of the
@scheme attribute.
To resolve this diagnostic, ensure that the values of
@scheme and
@target match. The values for the
@target attribute each begin with the initialism for the associated scheme. For example,
the targets for the scheme emdBookFormats all begin with lbf (i.e., “LEMDO Book Formats”).
Backwards Annotation and Collation Spans Diagnostic
When linking annotations and collation to modernized texts, we link to anchors on
either side of the span that we are annotating or collating. It is important that
we link first to the anchor before the lemma and then to the anchor after the lemma. This diagnostic finds instances
where anchors are linked to in the wrong order.
To resolve this diagnostic, open the file for your modernized text. Run edition diagnostics
by clicking on the red play button at the top of the Oxygen window. Doing so will
open a diagnostics page in your Web browser that includes the diagnostic Annotations and collations whose Pointers are in the wrong order. If any are found, go into your annotations or collation file to find and correct
the order of links. LEMDO recommends running edition diagnostics regularly while you
work on annotations and collation to avoid this issue.
For detailed instructions about running edition diagnostics, see Edition Diagnostics.
Possible Missing Spaces Diagnostic
In most cases,
<anchor>
elements should have a space on one side when they are between two words. If there
is not a space on either side of an
<anchor>
between two words, the rendered page will run words together. This diagnostic flags
instances where there is no space on either side of an
<anchor>
element so that there are no missing spaces in your rendered edition.
To resolve this diagnostic, find the
<anchor>
element and add a space if needed.
Other Resources
Martin Holmes and Joseph Takeda, Beyond Validation: Using Programmed Diagnostics to Learn About, Monitor, and Successfully
Complete your DH Project,Digital Scholarship in the Humanities 34 (2019); DOI: 10.1093/llc/fqz011.
LEMDO has set up a number of diagnostic checks for your edition that you will find
useful as you prepare your edition. These diagnostics provide statistics about characters,
entrances and exits, and spoken lines. Diagnostics also help you to encode links correctly
to anchors from your collation and annotations. For that reason, we recommend that
editors regularly check their edition diagnostics. This documentation will guide you
through the process of checking your edition diagnostics and clearing any potential
errors therein.
Practice: Run Edition Diagnostics
To run edition diagnostics, first open the file for your modernized text. In the tool
bar at the top of your Oxygen window, click the red play button:
It typically takes some time to run the diagnostics. Once they are complete, a new
tab will automatically open in your default Web browser with an HTML page listing
diagnostics. At the top of the Web page will be the date that the diagnostics were
generated and the ID for your edition. Each set of diagnostics and statistics is available
through a drop-down on the HTML page.
Note that diagnostics that have no potential issues will have the number zero (0)
beside them, while those diagnostics that do find potential issues will give the number
of issues you need to resolve.
Edition Statistics
The first drop-down on your edition diagnostics page is for statistics. This section
includes counts for number of acts, scenes, speeches, stage directions, and speaking
characters in your edition. In addition, the length of your modernized text is given
in both characters and words. Finally, you can see the total number of elements and
attributes that you and the LEMDO team have added to your file.
The statistics section also offers statistics by character. In this table, each character
in your edition is listed along with the number of speeches they give, number of words
that they speak, their average speech length, the average length of words that they
speak, the number distinct words that they use, and how many of their total words
are distinct (given as a decimal between 0.0 and 1.0 with 1.0 meaning each word spoken
is distinct). This information may be helpful to you when you write your critical
introduction.
Unused Anchors Diagnostic
LEMDO uses anchors and pointers to link annotations and collations to modernized texts.
All
<anchor>
elements should be linked to from somewhere in your edition. This diagnostic finds
<anchor>
elements that are not linked to from anywhere within the edition.
To resolve this diagnostic, you will first check that the anchor is not being linked
to from another edition by searching the texts directory in the LEMDO repo. (Other editions should not be linking to anchors in your edition. They should be linking to the acts/scenes
and speeches in your modern text, speeches or WLNs in your semi-diplomatic text, and
<div>
s or paragraphs in your critical paratexts.) Follow these steps to check that no other
edition is linking to your anchors:
Copy the xml:id of the unused anchor. You can copy this directly from your edition
diagnostics.
Right click on the texts directory in Oxygen’s project pane.
Select Find/Replace in Files…
Paste the xml:id in the Text to find text box.
Click Find All.
If there are no files linking to the anchor (as is likely the case, given LEMDO’s
general diagnostic that looks for such links), only one result will come up (the anchor
itself). In those cases, you may delete the unused anchor. If there is another edition
linking to the anchor, leave the anchor in place but let the LEMDO team know that
someone is linking to your edition so that we can help the other editor link in the
LEMDO-allowed ways.
Pointers not Pointing at Anything Diagnostic
All pointers must link to an entity with an xml:id. This diagnostic finds
<ptr>
elements that are trying to link to non-existent xml:ids. If a file is committed
with a pointer not pointing at anything, the LEMDO build will break. Checking this
diagnostic before you commit files containing new
<ptr>
elements prevents the build breaking on this issue.
To resolve this diagnostic, search your edition for the pointer that is not pointing
at anything and correct the value of its
@target attribute so that it correctly links to an entity. These errors are almost always
typos (“3411” when you mean “341”.
Annotations and Collations Whose Pointers Are in the Wrong Order Diagnostic
When annotations and collation link to anchors in a modernized text, the first target
must link to the
<anchor>
element that comes first in the modernized text while the second target must link
to the
<anchor>
that comes second. If the anchors are invoked in the wrong order, our processor will
not be able to mark the span and the LEMDO build will break. Checking this diagnostic
before you commit your annotations or collation file prevents the build breaking on
this issue.
To resolve this diagnostic, search for the annotation or collation entry that links
to anchors in the wrong order and correct the order. Run your edition diagnostics
again to ensure that the issue is fixed.
facs Attributes that do not Follow a Consistent Expected Pattern Diagnostic
LEMDO allows you to make links from
<pb>
(page beginning) elements to facsimile images using the
@facs attribute. Because all facsimile images are associated with xml:ids that are consecutively
numbered and we link to facsimile images for all pages in semi-diplomatic transcriptions
(including blank pages), we expect the links to follow the pattern of consecutively
numbered xml:ids. This diagnostic finds any inconsistencies in the expected pattern.
All speeches in modernized texts should have speech prefixes encoded using the
<speaker>
element. This diagnostic finds
<sp>
elements (speeches) without a child
<speaker>
element. If you have a compelling reason not to give a speech prefix to a speech,
take up the matter with your anthology lead(s), who will in turn take the matter to
the LEMDO team.
To resolve this diagnostic, open your modernized text file and add
<speaker>
elements to speeches that do not yet have them. For more information on speech prefixes
in modernized texts, see Encode Speakers in Modernized Texts.
LEMDO lists all of the entrances and exits encoded in each scene of your modernized
texts in the entrances and exits section of the edition diagnostics page. This information is often helpful to editors
determining scene divisions. It is also useful information if you want to create a
doubling chart.
If the list seems to be missing an entrance or exit, check that your encoding is correct.
All entrances and exits should be encoded using the
<stage>
element. For entrances, ensure that the
@type attribute on the
<stage>
element has the entrance value on it. For exits, ensure that the
@type attribute has the exit value on it.
LEMDO has created a series of checks for the status of anthologies before they publish.
Before an anthology can be released, all checks must be successful for every file
slated for publication. This documentation will guide you through the process of checking
the status of your anthology and clearing diagnostics in the lead up to anthology
release.
Practice: Check Your Anthology Diagnostics
You will check your anthology diagnostics from the LEMDO-dev site. To access the anthology
diagnostics, click on the Anthologies tab in the top navigation bar, then select the option for your anthology’s pre-release
status. For example, anthology leads wanting to check the status of the DRE anthology
would select the option DRE Pre-Release Status. This will bring you to the Web page containing your anthology diagnostics.
Your anthology diagnostic Web page will contain a list of diagnostic checks for each
file included in your anthology. Checks that are passed are highlighted green and
say [Diagnostic check] is OK. Checks that do not pass are highlighted red and have a message containing PROBLEM. All diagnostic checks must pass for all files included in a release before the anthology
is published.
For all files being released (anthology pages and edition pages), there are two checks:
Publication status: the status of each file must be published. LEMDO will change the value of the
@status attribute on the
<revisionDesc>
element of files shortly before release. This only happens when all other work in
a file is complete.
Edition statement: LEMDO has an expected format for the
<editionStmt>
element that must be followed before a file is released. Checking the
<editionStmt>
should be done when the metadata for a file is updated.
For each file in the editions being included in a release, there is an additional
check for license status. This diagnostic checks that the
<licence>
element in the
<publicationStmt>
contains the necessary information. Each
<licence>
element must have a logical licensing date encoded using the
@from attribute, a person who licenses the file for publication (typically the editor)
encoded by linking to the person’s xml:id using the
@resp attribute, and the anthology that is being licensed to release the edition encoded
using the
@corresp attribute. The
<publicationStmt>
(including the
<licence>
element) should be updated when the metadata is checked in each file during the pre-freeze
phase of anthology release.
One of the key functions of any LEMDO edition or anthology is to make links—our name
is Linked Early Modern Drama Online for this reason! Because there are many types of links that LEMDO editors, encoders,
and anthology leads make, it is important that we have mechanisms to ensure the links
are functional. This documentation will guide you through the process of checking
link validity using edition diagnostics, general LEMDO diagnostics, and our anthology
link checker.
Step-by-Step: Check Pointer Links Using Edition Diagnostics
You can use your edition diagnostics to check that pointers from your annotations
and collation files are formatted correctly. To do so:
Run edition diagnostics by opening your modernized text file and clicking the red
play button at the top of the Oxygen window.
Once the diagnostic page has opened in your browser, navigate to the Annotations and collations whose pointers are in the wrong order diagnostic.
If there is a zero after the diagnostic title, there are no issues with the order
of pointers in your annotations or collation.
If there is a number other than zero after the diagnostic title, open the diagnostic
by clicking on the title.
Search your edition to find the bad pointer listed in the diagnostic.
Check your modernized text to ensure you are linking to anchors in the correct order.
You can also check that all of your pointers link to something using the Pointers not pointing at anything diagnostic. If the number following the diagnostic title is not zero, open the diagnostic
and search your edition for the bad pointer. Update the value of the
@target attribute so that the pointer successfully links to an entity.
Step-by-Step: Check Bad Internal Links Using LEMDO Diagnostics
LEMDO offers two internal link checks in our general diagnostics: urgent and non-urgent.
Urgency is based on the status of the file that the bad link is in; files that have
a status close to publication should have their links corrected more quickly than
those that are in early stages of encoding or remediation. To check bad internal links
in your files:
Open LEMDO diagnostics through the Resources tab in the top navigation bar of the LEMDO-dev site.
If you want to check links in one edition only, type the edition abbreviation in the
filter text box. Otherwise, leave it blank.
Navigate to the Bad Internal Links diagnostics and check if your files are listed under them.
If your files are listed under the bad internal links diagnostics, search your edition
for the links listed and correct the links.
Practice: Check External Links Using the Anthology External Links List
Before an anthology can be released, all of its external links must be checked. LEMDO
lists all of the external links for each anthology in the anthology’s Jenkins Web
page.
To check your anthology’s external links, ask LEMDO Director Janelle Jenstad (lemdo@uvic.ca) to have your anthology’s link check pages added to HCMC’s server. The pages must be uploaded to the HCMC server before external links can be
checked. Once they have uploaded the pages, either the LEMDO director or an HCMC developer
will tell you where to find your link check pages.
Your anthology’s link check index page on the HCMC server will provide you with instructions
to use the W3C Link Checker. Using this tool will allow you to find any 301 (permanently moved pages), 302 (redirected
pages), and 404 (dead link) errors.
If there are any link errors, search across your anthology and its editions for the
bad URL to and correct any instances of it.
1.We have a tool that sweeps an edition for unused anchors before publication. If the
tool does not find any pointers within the edition to a particular anchor, we will delete the anchor. A link to an anchor in another
edition is therefore fragile.↑
Prosopography
Anonymous
Janelle Jenstad
Janelle Jenstad is a Professor of English at the University of Victoria, Director
of The Map of Early Modern London, and Director of Linked Early Modern Drama Online. With Jennifer Roberts-Smith and Mark Beatrice Kaethler, she co-edited Shakespeare’s Language in Digital Media: Old Words, New Tools (Routledge). She has edited John Stow’s A Survey of London (1598 text) for MoEML and is currently editing The Merchant of Venice (with Stephen Wittek) and Heywood’s 2 If You Know Not Me You Know Nobody for DRE. Her articles have appeared in Digital Humanities Quarterly, Elizabethan Theatre, Early Modern Literary Studies, Shakespeare Bulletin, Renaissance and Reformation, and The Journal of Medieval and Early Modern Studies. She contributed chapters to Approaches to Teaching Othello (MLA); Teaching Early Modern Literature from the Archives (MLA); Institutional Culture in Early Modern England (Brill); Shakespeare, Language, and the Stage (Arden); Performing Maternity in Early Modern England (Ashgate); New Directions in the Geohumanities (Routledge); Early Modern Studies and the Digital Turn (Iter); Placing Names: Enriching and Integrating Gazetteers (Indiana); Making Things and Drawing Boundaries (Minnesota); Rethinking Shakespeare Source Study: Audiences, Authors, and Digital Technologies (Routledge); and Civic Performance: Pageantry and Entertainments in Early Modern London (Routledge). For more details, see janellejenstad.com.
Joey Takeda
Joey Takeda is LEMDO’s Consulting Programmer and Designer, a role he assumed in 2020
after three years as the Lead Developer on LEMDO.
Mahayla Galliford
Project manager, 2025-present; research assistant, 2021-present. Mahayla Galliford
(she/her) graduated with a BA (Hons with distinction) from the University of Victoria
in 2024. Mahayla’s undergraduate research explored early modern stage directions and
civic water pageantry. Mahayla continues her studies through UVic’s English MA program
and her SSHRC-funded thesis project focuses on editing and encoding girls’ manuscripts,
specifically Lady Rachel Fane’s dramatic entertainments, in collaboration with LEMDO.
Martin Holmes
Martin Holmes has worked as a developer in the UVic’s Humanities Computing and Media
Centre for over two decades, and has been involved with dozens of Digital Humanities
projects. He has served on the TEI Technical Council and as Managing Editor of the
Journal of the TEI. He took over from Joey Takeda as lead developer on LEMDO in 2020.
He is a collaborator on the SSHRC Partnership Grant led by Janelle Jenstad.
Navarra Houldin
Training and Documentation Lead 2025–present. LEMDO project manager 2022–2025. Textual
remediator 2021–present. Navarra Houldin (they/them) completed their BA with a major
in history and minor in Spanish at the University of Victoria in 2022. Their primary
research was on gender and sexuality in early modern Europe and Latin America. They
are continuing their education through an MA program in Gender and Social Justice
Studies at the University of Alberta where they will specialize in Digital Humanities.
Tracey El Hajj
Junior Programmer 2019–2020. Research Associate 2020–2021. Tracey received her PhD
from the Department of English at the University of Victoria in the field of Science
and Technology Studies. Her research focuses on the algorhythmics of networked communications. She was a 2019–2020 President’s Fellow in Research-Enriched
Teaching at UVic, where she taught an advanced course on Artificial Intelligence and Everyday Life. Tracey was also a member of the Map of Early Modern London team, between 2018 and 2021. Between 2020 and 2021, she was a fellow in residence
at the Praxis Studio for Comparative Media Studies, where she investigated the relationships
between artificial intelligence, creativity, health, and justice. As of July 2021,
Tracey has moved into the alt-ac world for a term position, while also teaching in
the English Department at the University of Victoria.
Orgography
Humanities Media and Computing Centre (HCMC1)
https://hcmc.uvic.ca
The Humanities Computing and Media Centre (HCMC)
at the University of Victoria has an international reputation developing projects
in
collaboration with researchers and instructors from UVic’s Faculty of Humanities,
with
particular expertise in the fields of digital humanities and language learning.
Glossary
schema
“A schema is a set of rules governing the use of TEI elements in a particular project.
XML languages are all governed by a small set of shared principles; any document that
follows these principles, even if it makes up its own elements, is well-formed XML.
TEI is a formal language that is designed to comply with the principles of XML. TEI
offers many elements and attributes in its XML-compliant language. But most projects
still need to customize the TEI for their own purposes, by prescribing how and where TEI elements and attributes
are to be used, precluding some elements and attributes, making other elements and
attributes optional, making child elements required or optional, and defining allowed
and required values for attributes. The schema captures the project’s requirements,
prohibitions, and standards. We use a RelaxiNG schema at LEMDO. The main schema for
LEMDO is lemdo-all.rng (where the .rng file extension indicates the schema type).
The schema is responsible for generating the error messages in Oxygen when encoders
break one or more of the rules associated with it. (Read more about schemas in the
TEI Guidelines.)”
Schematron
“Schematron is an open-source language for ensuring that certain patterns are present
in XML documents. For example, it can insist upon certain spellings, enforce curly
apostrophes, and limit the use of elements to specific contexts. It is the feather duster of an XML project. See An Overview of Schematron.”
