LEMDO: Encode egXMLs

Encode egXMLs

We often include strings of XML in documentation as examples to illustrate processes or concepts. Use the


                                       <egXML>

element to tag sample XML code. Do not use


                                       <egXML>

to tag non-XML code; use the


                                       <eg>

element instead.

Use the


                                       <egXML>

element only to wrap sample XML outside of the context of a paragraph (running text). Do not wrap XML that appears in running text in the


                                       <egXML>

element; use the


                                       <gi>


                                       <att>

, and


                                       <val>

elements instead to tag the elements, attributes, and values mentioned in running text. The


                                       <egXML>

element is strictly used for examples that are separate from running text.

Namespace for egXMLs

The


                                          <egXML>

element has its own namespace. Give the


                                          <egXML>

element the


                                       @xmlns

attribute and the value "http://www.tei-c.org/ns/Examples". Typing


                                          <egXML>

in Oxygen will generate a drop-down menu from which you can select the element with the


                                       @xmlns

attribute and this value already added. This namespace ensures that the content of the example is validated by a special process (if the sample has the


                                       @valid

value of "true"; see Validity of Sample XML).

Validity of Sample XML

All


                                          <egXML>

elements must have the


                                       @valid

attribute. Allowed values are "true" and "false". Unlike the tei-all.rng schema, the LEMDO schema does not allow the "feasible" value. Examples are "true" if they are complete and valid. Examples are "false" if they are deliberately incomplete. Avoid creating counter-examples or negative examples.

Occasionally, our sample XML is left incomplete so that we can demonstrate an aspect of encoding procedure without cluttering up the example with other intersecting procedures. See the principle of Economy of Example. Such sample XML must be given the


                                       @valid

value of "false" to avoid misleading the user.

Use the value "true" only if you are absolutely sure that the sample XML is complete and valid according to the schema rules for the type of document in which it is meant to be used. See Validity of Example.

The LEMDO build process will validate code wrapped in the


                                          <egXML>

element if the


                                       @valid

attribute has the value "true". This system will extract sample XML into a separate file and validate it against our schema, breaking if an example that has the value of "true" is invalid. In order for the system to work, all deliberately incomplete code must be tagged as "false" so the system does not attempt to validate it. These values will also allow us to render incomplete code differently from complete, valid code on the LEMDO site. In order to be valid, an example must have a single root element which is a direct child of the


                                          <egXML>

element.

All


                                          <egXML>

s with the "true" value are validated during the build process. If they are not valid, they will break the build. They cannot be validated using our normal schema because they are in a different namespace.

If you want to check all your


                                          <egXML>

s before you commit a file, run the following command in your Terminal: ant validateEgXMLs. You will have to have ant commands installed if you are working on your own computer. Ant commands will work on all the HCMC workstations.

Omission of Material from Sample XML

In many cases, we want to indicate that the parent element in the sample XML would normally have additional child elements. For example, if


                                          <list>

is the parent, one would normally have multiple child


                                          <item>

elements. If


                                          <listPerson>

is the parent element, one would normally have multiple child


                                          <person>

elements. In these cases, we normally give just one sample child element but include a commented-out ellipsis before and after this child element:

An egXML element with http://www.tei-c.org/ns/Examples as the value on the xmlns attribute and true as the value on valid. In the egXML text node is a listPerson with one child person element that has the children name with child reg, forename, and surname elements and note with a child p element.

Showing Examples of `<egXML>` Elements

The


                                          <egXML>

element itself cannot be wrapped in another


                                          <egXML>

element. In this present documentation file, where we need to give examples of


                                          <egXML>

, we have had to do a screen capture from Oxygen and insert a .jpg in the file. (Yes, writing documentation about writing documentation gets very meta. The TEI Guidelines have the same problem, so we are not alone.) For guidelines on storing and linking images, see Add Images to the Repository.

Counter-Examples and Negative Examples

Do not wrap deliberately wrong examples in


                                          <egXML>

. Use the


                                          <eg>

element in those rare cases where you want to give an example of something that needs to be remediated after the conversion. Thus far (in 2021), we give negative examples mainly in the Appendix on Remediation.

Rendering Considerations

Anything tagged with


                                          <egXML>

is rendered as an indented block with the default colours that Oxygen uses for elements (blue), attributes (orange), values (brown), and text nodes (black). We have added a background colour (currently light grey) to make the sample XML highly distinct.

This rendering means that you will not want to use


                                          <egXML>

for short examples in running prose. It also means that you may want to include enough running prose from your sample to make the sample encoding make sense.

For example, if you wanted to demonstrate how to use the


                                          <quote>

element in a note, give enough of the note text for the example to make sense (the actual note by David Bevington is longer):

An egXML element with http://www.tei-c.org/ns/Examples as the value on the xmlns attribute and true as the value on valid. In the egXML text node is a note element with commentary as the value on the type attribute.

Note that white space and carriage returns within the text nodes of elements affect the rendering of the contents of


                                          <egXML>

elements, unlike most other elements. Delete extra white space or carriage returns in the text nodes of


                                          <egXML>

elements so the examples render correctly.

Examples of Sample XML

These examples of


                                          <egXML>

offer complete, valid XML:

Prosopography

Isabella Seales

Isabella Seales is a fourth year undergraduate completing her Bachelor of Arts in English at the University of Victoria. She has a special interest in Renaissance and Metaphysical Literature. She is assisting Dr. Jenstad with the MoEML Mayoral Shows anthology as part of the Undergraduate Student Research Award program.

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 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.

Nicole Vatcher

Technical Documentation Writer, 2020–2022. Nicole Vatcher completed her BA (Hons.) in English at the University of Victoria in 2021. Her primary research focus was women’s writing in the modernist period.

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

LEMDO Team (LEMD1)

The LEMDO Team is based at the University of Victoria and normally comprises the project director, the lead developer, project manager, junior developers(s), remediators, encoders, and remediating editors.

Metadata

Authority title	Encode egXMLs
Type of text	Documentation
Publisher	University of Victoria on the Linked Early Modern Drama Online Platform
Series	Linked Early Modern Drama Online
Source	TEI Customization created by Martin Holmes, Joey Takeda, and Janelle Jenstad; documentation written by members of the LEMDO Team
Editorial declaration	n/a
Edition	Released with Linked Early Modern Drama Online 1.0
Encoding description	Encoded in TEI P5 according to the LEMDO Customization and Encoding Guidelines
Document status	prgGenerated
Funder(s)	Social Sciences and Humanities Research Council of Canada
License/availability	This file is licensed under a CC BY-NC_ND 4.0 license, which means that it is freely downloadable without permission under the following conditions: (1) credit must be given to the author and LEMDO in any subsequent use of the files and/or data; (2) the content cannot be adapted or repurposed (except in quotations for the purposes of academic review and citation); and (3) commercial uses are not permitted without the knowledge and consent of the editor and LEMDO. This license allows for pedagogical use of the documentation in the classroom.