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.
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).
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.
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:
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.
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.
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):
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.
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.
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
Project manager 2022–present. Textual remediator 2021–present. Navarra Houldin (they/them)
completed their BA in History and Spanish at the University of Victoria in 2022. During
their degree, they worked as a teaching assistant with the University of Victoriaʼs
Department of Hispanic and Italian Studies. Their primary research was on gender and
sexuality in early modern Europe and Latin America.
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
Short title
Publisher
University of Victoria on the Linked Early Modern Drama Online Platform
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.
