jTEI input customization
author: Ron Van den Branden ron.vandenbranden@kantl.be; Martin Holmes mholmes@uvic.ca
language: en

Journal of the Text-Encoding Initiative Article Schema
Schema and guidelines for encoding an article for the journal

Ron Van den Branden
Martin Holmes
2014

Introduction

This document introduces and documents the content and use of the schemas provided by the Journal of the Text Encoding Initiative, as part of the TEI P5 distribution, for the use of authors who want to submit their articles to the journal in TEI. The schema described in this document is highly constrained and restrictive, consisting only of some 80 elements, compared with the complete TEI schema which contains nearly six hundred. In addition to general structural constraints, the ODD file also embeds fine-grained Schematron rules, severely limiting your options as you encode your file.

It is very likely that, as an experienced and confident TEI encoder with a broad knowledge of the TEI schema, you will find this at least a little frustrating. Where the TEI typically provides several ways of encoding the same phenomenon, we usually support only one. Where larger TEI schemas will allow you to describe rendering features (<hi rend="italic">) we do not allow that; we force you to choose a conceptual tag such as <emph> or <title level="j">.

The reasons for this are fairly obvious. From the XML document you submit, we need to generate a range of different outputs—ODT for reviewers and copyeditors to read and annotate, and OpenEdition XML for submission to the revues.org publication engine that supports the journal website. We must enforce a degree of conformity across all submissions, not only in order to maintain consistency when we publish, but also to ensure that contributions are assessed by reviewers in as fair a manner as possible, without possible influences due to divergence from the expected style rules or formatting conventions.

However, this constraint and conformity has advantages for you too, as an author. Our schemas will enforce a number of constraints which, we believe, may assist you in improving the quality of your article; these are a few of them:

- All quotations should be linked to references in the text.
- All references must be linked to bibliography items.
- All bibliography items must be cited somewhere in the text.
- All text styles such as italicization or quotation marks appear as a result of conceptual tags.

In what follows, we aim to provide a readable guide to encoding your article (or perhaps even composing it) according to the journal schemas, beginning with the template we provide, and viewing your results as you work through the use of CSS (in Author Mode in Oxygen) or by transforming it into ODT for examination in your word-processor.

This document is a work-in-progress (always), and we welcome your feedback at either mholmes@uvic.ca (Martin Holmes) or ron.vandenbranden@kantl.be (Ron Van den Branden).

Encoding for jTEI in Oxygen

Using the Template

Starting with version 16.2, the default distribution of Oxygen should include the jTEI components as part of its built-in TEI P5 framework. If you are using an older version of Oxygen, you can subscribe to the TEI-built version of the framework, by following these instructions.

In Oxygen, you can start a new article based on the jTEI template by selecting File → New, and selecting JTEI Article [TEI P5] under Framework templates → TEI P5.

Selecting the jTEI article template in Oxygen.

You will see that the root <TEI> element in the new file has an attribute @rend="jTEI". This tells Oxygen that it's a jTEI file, so that it can apply standard jTEI rendering and validation scenarios to it. If you don't want to keep this attribute value, you can achieve the same effect by saving the file with a filename matching this format: “jtei-*-source.xml” (where the asterisk stands for anything you like); Oxygen will also recognize files with names in this format as jTEI files.

Testing Your Document

The Oxygen framework provides one output rendering scenario, which allows you to transform your jTEI article to the ODT format. Open the ODT file you create in a recent version of LibreOffice or OpenOffice; Microsoft Office does not support the current ODT specification. If you see any problems with the rendering, don't worry, and please don't change good TEI XML to bad TEI in an attempt to make it render more successfully; report the problem to us and we'll look into it.

Basic Text Structure

A jTEI journal article is a relatively simple TEI document consisting of a <teiHeader> and a <text>.

The Header and Metadata

This is an example <teiHeader>:

<teiHeader>
  <fileDesc>
    <titleStmt>
      <title type="main">Learning the TEI in a Digital Environment</title>
      <author>
        <name><forename>Stella</forename> <surname>Dee</surname></name>
        <affiliation>Stella Dee is currently a <roleName>Research Associate</roleName>
          working to develop e-learning resources for historical languages with the
          Open Philology Project at the <orgName>University of Leipzig</orgName>.
          The research of this article was conducted while studying for a Masters
          degree in digital humanities at King’s College, London.</affiliation>
        <email>dee@informatik.uni-leipzig.de</email>
      </author>
    </titleStmt>
    <publicationStmt>
      <publisher>TEI Consortium</publisher>
      <date>2014</date>
      <idno>Issue 7</idno>
      <availability>
        <p>TEI Consortium 2014 (Creative Commons Attribution-NoDerivs 3.0 Unported License)</p>
      </availability>
    </publicationStmt>
    <sourceDesc>
      <p>No source, born digital.</p>
    </sourceDesc>
  </fileDesc>
  <encodingDesc>
    <projectDesc>
      <p>Revues.org -centre for open electronic publishing- is the platform for journals in the
        humanities and social sciences, open to quality periodicals looking to publish full-text
        articles online.</p>
    </projectDesc>
  </encodingDesc>
  <profileDesc>
    <langUsage>
      <language ident="en"/>
    </langUsage>
    <textClass>
      <keywords xml:lang="en">
        <term>pedagogy</term>
        <term>student resources</term>
        <term>survey</term>
        <term>file publication</term>
      </keywords>
    </textClass>
  </profileDesc>
</teiHeader>

Some of the content is boilerplate material provided by the template. These are the parts that you must supply:

- The title of your article (in fileDesc/titleStmt/title[@type='main']).
- Author information for each author (in fileDesc/titleStmt/author). Provide one <author> element for each author. Encode the names as shown, using <forename> and <surname>, inside <name>. Then provide a brief biographical paragraph for each author in <affiliation>, and an email address.
- Keywords (in profileDesc/textClass/keywords). Provide a handful of general categories under which you feel your article fits. There is (currently) no formal ontology of article categories to choose from. You may consult the list of keywords from previous articles on the journal website, but if you don't see what you need, feel free to use new ones. The editors may formalize these categories in future.

Front Matter

The front matter must consist of an abstract, encoded in <div type="abstract">. This should consist of one or two short paragraphs, covering the purpose and content of the article.

The only other thing that may appear in the front matter is a brief acknowledgements section. If you need to include this to acknowledge contributors, funding agencies etc., insert it after the abstract, encoded as <div type="acknowledgements">. It should be no longer than one short paragraph.

The Body

The content of the article appears in the body. It should be divided into sections using <div> elements. Each <div> element should have an @xml:id attribute, and its first child should be a <head> element with a suitable heading (in title case). <div> elements may be nested to provide subsections.

Do not provide section numbering in explicitly in the <head>s of your <div>s. These will be provided automatically by the rendering tools.

Back Matter: the Bibliography and Appendices

The back matter consists of a bibliography (required), which is encoded in <div type="bibliography">, and optional appendices, each of which if present must be encoded using <div type="appendix">. Appendices must appear after the bibliography.

The bibliography consists of a <listBibl> element containing a series of <bibl> elements. Each <bibl> element should contain a reference formatted as required by the Chicago Manual of Style (16th edition), including all required punctuation, with a couple of exceptions:

- Do not provide quotation marks around article titles. Instead, tag them with <title level="a"> (for chapters or contributions in a monograph, or journal articles) or <title level="u"> (for unpublished materials). The rendering tools will then provide the quotation marks.
- Tag titles that would normally be in italics using <title level="j"> (for journal titles) or <title level="m"> (for monographs).

Give each <bibl> element a unique @xml:id attribute, so that you can link to it from the quotations in the body of your text. In your bibliography entries, put the appropriate tags around the following components:

- titles: <title>, with an appropriate value for @level (see above)
- editions: <edition>
- dates: <date>
- authors: <author>
- editors: <editor>
- publishers: <publisher>
- publication places: <pubPlace>
- name of series: <series>
- scope of a bibliographic reference: <biblScope>, with an appropriate value for @unit ("volume", "issue", "page", "chapter", "part")
- id numbers such as DOIs: <idno>, with an appropriate value for @type
- web urls (use <ref>)

Note: if you have both a formal identification number such as a DOI code and a hyperlink to an online version, the DOI code should be placed last in the bibliographic description.

Here is a short example:

<div xml:id="bibliography" type="bibliography">
  <listBibl>
    <bibl xml:id="aoki07">
      <author>Aoki, Paul M.</author> <date>2007</date>.
      <title level="a">Back Stage on the Front Lines: Perspectives and
        Performance in the Combat Information Center</title>. In
      <title level="m">Proceedings of the SIGCHI Conference on
        Human Factors in Computing Systems</title>,
      <biblScope unit="page">717–26</biblScope>. CHI ’07.
      <pubPlace>New York</pubPlace>: <publisher>ACM</publisher>. <ref target="http://doi.acm.org.ezproxy.lib.utexas.edu/10.1145/1240624.1240735">
        http://doi.acm.org.ezproxy.lib.utexas.edu/10.1145/1240624.1240735
      </ref>. doi:<idno type="doi">10.1145/1240624.1240735</idno>.
    </bibl>
    <bibl xml:id="banski10">
      <author>Bański, Piotr</author>. <date>2010</date>.
      <title level="a">Why TEI Stand-off Annotation Doesn’t Quite Work and
        Why You Might Want to Use It Nevertheless</title>. In
      <title level="m">Proceedings of Balisage: The Markup Conference 2010</title>.
      <series>Balisage Series on Markup Technologies</series>,
      <biblScope unit="volume">vol. 5</biblScope>.
      doi:<idno type="doi">10.4242/BalisageVol5.Banski01</idno>.
    </bibl>
    <bibl xml:id="bowers12">
      <author>Bowers, John</author>. <date>2012</date>.
      <title level="a">The Logic of Annotated Portfolios: Communicating the
        Value of <soCalled>Research through Design.</soCalled></title> In
      <title level="j">Proceedings of the Designing Interactive Systems
        Conference</title>, <biblScope unit="page">68–77</biblScope>.
      <title level="s">DIS ’12</title>. <pubPlace>New York</pubPlace>:
      <publisher>ACM</publisher>. doi:<idno type="doi">10.1145/2317956.2317968</idno>.
    </bibl>

  </listBibl>
</div>

Divisions, Paragraphs, Lists and Other Block Elements

Divisions

Text divisions are encoded in <div>. Each division must have a <head> containing the heading for this division. Headings should just contain the bare heading, without numbering or other labels; those are added automatically when the TEI source file is rendered.

Divisions typically consist of a number of paragraphs, inside <p> elements. Apart from paragraphs, they can contain following text structures:

- subdivisions
- lists
- quotations
- figures and graphics
- tables
- code examples

Divisions can nest, by simply including a new <div> element with an @xml:id attribute and a <head> in a parent division. There's no need to indicate the nesting level for subdivisions: this is determined from the structural encoding by the rendering scripts. Please note that the general TEI limitations hold: divisions may not be followed by bare paragraphs. In order to facilitate cross-referencing, you are encouraged to provide a unique identification code in an @xml:id attribute for each <div>.

Following example illustrates a text division in which two introductory paragraphs are being followed by two more subdivisions.

<body>
  <div xml:id="notodd">
    <head>What’s not ODD?</head>
    <p>In the current source of TEI P5, there is extensive use of several different
      XML vocabularies: <list rend="bulleted">
        <item>Examples in TEI P5 are presented as if they belonged to some other
            <soCalled>TEI Example Namespace</soCalled>;</item>
        <item>Element content models are expressed using a subset of RELAX NG, as
          discussed in the previous section;</item>
        <item>Datatypes are expressed in a variety of ways, mapping either to built-in
          W3C datatypes (as defined in the W3C Schema Language) or to RELAX NG
          constructs;</item>
        <item>Additional semantic constraints (for example, co-dependence of
          attributes and element content) are expressed using ISO Schematron
          rules.</item>
      </list>
    </p>
    <p>Everything else in a TEI-conformant ODD specification uses only constructs from
      the TEI namespace. In this paper, we will argue for a further extension of the
      ODD language to replace several of the cases listed above.</p>
    <div xml:id="elementcontentmodels">
      <head>Element Content Models</head>
      <p>ODD was originally intended to support the <emph>intersection</emph> of the
        content models definable using three different schema languages. In practice,
        this reduced our modeling requirements quite significantly. </p>

    </div>
    <div xml:id="datatyping">
      <head>Datatyping and Other Forms of Validation</head>
      <p>Validation of an element’s content model is but one of many different layers
        of validation that a TEI user may wish to express in their ODD specification.
        </p>

    </div>
  </div>
</body>

Paragraphs

Paragraphs are encoded with <p> elements. They are the main building blocks of a division. They can contain plain text, mixed with other structural elements:

<p>Thus we introduce the <gi>transferGrp</gi> element, a grouping element somewhat
  like <gi>surfaceGrp</gi> but, like <gi>altGrp</gi> or <gi>attList</gi>, with
  the ability to assert the relationship among its children rather than just common
  features. This is accomplished with an <att>org</att> attribute whose suggested
  values include:
  <list type="gloss">
    <label><val>group</val></label>
    <item>an unordered set</item>
    <label><val>sequence</val></label>
    <item>a (chronologically) ordered set</item>
    <label><val>choice</val></label>
    <item>only one of the child <gi>transfer</gi>s
      obtained</item>
  </list>
</p>
<p>The following example demonstrates the use of <gi>transferGrp</gi> to indicate a
  transaction which is attested in (at least) two source documents which disagree as to
  the amount of money involved.</p>

Lists

Lists in jTEI are relatively simple. They are encoded in a <list> element and differentiated by the @type attribute, which may have only one value, "gloss". <list type="gloss"> is (as you might expect) a glossary list, and must consist of a sequence of <label>s and <item>s, like this:

<list type="gloss">
  <label>compressor</label>
  <item>a device which reduces the peaks of volume in an audio signal</item>
  <label>equalizer</label>
  <item>a device which allows different frequency bands in an audio signal
  to be cut or boosted</item>
</list>

All other types of list (numbered, bulleted etc.) do not have the @type attribute. Their appearance is controlled by the @rend attribute: Lists may be nested:

<list rend="bulleted">
  <item>compressor:
    <list rend="ordered">
      <item>limiter</item>
      <item>multiband compressor</item>
    </list>
  </item>
  <item>equalizer:
    <list rend="ordered">
      <item>graphic equalizer</item>
      <item>parametric equalizer</item>
    </list>
  </item>
</list>

For processing reasongs, jTEI puts one restriction on what can appear inside lists: you can't use <table> anywhere inside <item>.

Quotations, Inline and Block

The main components of a quotation are the quoted text itself, and a reference to the source it was quoted from. The quoted text is encoded with a <quote> element, without quotation marks. Quotations marks are added automatically by the rendering scripts. The jTEI schema requires that each quotation is linked to a bibliographic reference, identifying the source from where the text has been quoted. Typically, the source of a quotation is listed in the bibliography at the end of the article. References to such sources are encoded in a <ref> element, with a @type attribute of value "bibl", whose @target attribute must point to the @xml:id value of a <bibl> element in the article's bibliography. You must provide an @xml:id attribute for the <ref> element itself. This makes it possible to connect the quotation with its specific reference via the @source attribute on the <quote> element:

  <p>In his blog post, <title level="a">Text: A Massively Addressable Object</title>,
  published in the 2012 anthology <title level="m">Debates in the Digital
    Humanities</title>, Michael Witmore defines texts as objects that are
    <quote source="#quoteref3">massively addressable at different levels of scale</quote>
    (<ref type="bibl" xml:id="quoteref3" target="#witmore12">Witmore 2012, 325</ref>).
</p>

Here, we see how the value "#quoteref3" for the @source attribute expresses the correspondence with the bibliographic reference in
<ref type="bibl"
            xml:id="quoteref3" target="#witmore12">Witmore 2012, 325</ref>
.

In some cases, quotations are taken from less bibliographic sources, such as email conversations and other non-published texts. Such sources are not listed in the bibliography, so you can't refer to them with a <ref type="bibl"> reference. Instead, you should include the description of the source in the text. The description should be encoded in a <bibl> element with an @xml:id attribute. You should link the quotation to this bibliographic description by pointing to this @xml:id attribute with the @source attribute of the <quote> element:

<p>An exchange on the TEI electronic mailing list sparked the research published
  in this article, when a community expert wrote that given
  <quote source="#quoteref1">a graduate student in English who has heard about TEI
    and wants to dip her toes into it because she thinks it may be a better way of
    putting on the Web some 17th century poems<gap/> Where does she go for help?
    Where in the TEI universe is the level of ubiquitous Grade I support?</quote>
  (<bibl xml:id="quoteref1">Martin Mueller, pers. comm, Jan. 18, 2013</bibl>).</p>

Here, the "#quoteref1" value for the @source attribute on <quote> points to the <bibl> element in the text, describing the less bibliographic source for the quotation in a footnote.

Note how the examples above were inline quotations, which will be rendered inside the running text of the paragraph they appear in. It is also possible to encode block quotations, by wrapping the <quote> and its <ref> inside a <cit> container. A <cit> element can occur either in or between paragraphs, but is always rendered as a blockquote:

<p>In <title level="a">Wampum as Hypertext</title>, Angela Haas complicates the
  distinction between technology and high technology by discussing the way wampum
  belts function the same as Western hypertexts. Haas contends that while there are
  many similarities, they differ when we understand the way wampum is reliant on
  cultural practices and memory:
  <cit>
    <quote source="#quoteref8">Consequently one could argue that wampum is limited
      in relation to contemporary Western hypertexts in that it requires human
      intervention to remember the intent and content of the original message; however,
      one could also posit that such interaction encourages continuous civic involvement
      instead of an over-reliance on technology.</quote>
    <ref type="bibl" xml:id="quoteref8" target="#haas07">Haas 2007, 93</ref>
  </cit>
</p>

The <cit> element has been constrained in jTEI so it can only contain <quote>, <ref>, and <bibl>.

Inside quotations, inline rhetorical elements can be used (see Inline Rhetorical Elements). Two of such elements are quite specific to quotations, in the context of a jTEI article, however, namely omissions and supplied text. Omissions are encoded with <gap>, which at rendering time is transformed to the typographic omission symbol: …[^1]. If you supply text that wasn't present in the original quotation, you should wrap the supplied text in a <supplied> element. At rendering time, the <supplied> start and end tags are replaced with the [ and ] characters, respectively.

[^1: Note, if you're omitting text at the end of a sentence, the sentence punctuation should precede the <gap> element.]

Apart from <quote> for attributed quotations, you can also use <q> for short anonymous inline quotations, whose source is not known or irrelevant. This is discussed in more detail in Inline Rhetorical Elements.

Figures and Graphics

Illustrative figures are encoded using the<figure> element, along with a mandatory <head type="legend"> element providing the caption for the figure, as in this example:

<figure xml:id="titlePage">
  <graphic url="img/titlePage.png" width="620px" height="980px"/>
  <head type="legend">The title page of the 1598 edition</head>
</figure>

The graphics file should be in PNG or JPEG format, and should be stored in a directory called img which is a sibling of the article XML file. Graphics file names should not contain spaces or punctuation. The <graphic> element must include the @width and @height attributes containing the image size in pixels. A second <head type="license"> may also be provided in cases where an explicit statement of licensing, copyright or accreditation is required.

The caption in the <head type="legend"> element should not begin with “Figure 1” or any similar prefix; this will be provided by the rendering code at output time. To link to the figure, all you need to do is to provide a pointer targeting its @xml:id attribute, like this:

<p>As you can see from <ptr target="#titlePage" type="crossref"/>,
  the title page is damaged...</p>

This will be expanded at rendering time into “Figure X”, where X is the appropriate figure number.

Example Code, XML and non-XML

Example computer code in jTEI falls into two categories. XML code appears in the <egXML xmlns="http://www.tei-c.org/ns/Examples"> element. When you use this element, make sure you get the namespace right; all elements appearing in the <egXML> element are also in the Examples namespace, to distinguish them from regular TEI elements that are part of the encoding of the document. Code from non-XML languages appears in the <eg> element.

In many cases, example code will appear inline as part of the prose of your article[^2]:

<p>Links between authors and books are encoded using <gi>link</gi> elements: &lt;egXML
  xmlns="http://www.tei-c.org/ns/Examples"&gt; <link target="#middlemarch #eliot"/>
  &lt;/egXML&gt; </p>

[^2: Note, however, that <eg> and <egXML> examples are always rendered as blocks, regardless of their appearance as inline or block-level elements in the article encoding. If you want to include a short code fragment that should be rendered inline, you can use the <code> element as discussed in Inline Technical Elements.]

You might want to provide a caption for code examples. In these cases, the <eg> or <egXML> element should be enclosed in a <figure>:

<figure xml:id="example_code_1">
  <eg>
  declare function local:getTitles($source as element(div)) as xs:string*{
      for $t in $source//title
        return xs:string($t)
  };
</eg>
  <head type="legend">A simple XQuery function</head>
</figure>

At rendering time, captions of examples will be supplied with a leading “Example X”, where X is the number of the example. You can link to and refer to block examples like this using <ref> and <ptr>. In order to do so, you should provide a unique identification code to the <figure> in an @xml:id attribute.

Tables

Tables can be encoded with the <table> element. Tables consist of a number of rows (<row>) that contain a number of cells (<cell>). Header rows and cells can be distinguished by different values for the @type attribute:

"label"
- The row or cell contains a header, not actual data.
data
- (default) The row or cell contains data.

Cells and rows can be merged. In order to indicate how many columns a row or cell spans, a number can be provided for a @cols attribute; the number of rows spanned can be given as value for a @rows attribute.

<table xml:id="table1">
  <head>Elements in <ident>tei_corset</ident> customization</head>
  <row role="label">
    <cell>Module</cell>
    <cell>Elements in <ident>tei_corset</ident></cell>
  </row>
  <row>
    <cell role="label"><ident>textstructure</ident></cell>
    <cell><gi>body</gi> <gi>div</gi> <gi>TEI</gi></cell>
  </row>
  <row>
    <cell role="label"><ident>figures</ident></cell>
    <cell><gi>cell</gi> <gi>row</gi> <gi>table</gi></cell>
  </row>
  <row>
    <cell cols="2">a sample cell spanning two columns (this was not in the original)</cell>
  </row>
</table>

The example above illustrates how the first row is marked as a header row with <row role="label">, and how the left column is marked as a header column by specifying each first cell in a row as <cell role="label">. The last cell illustrates how column spanning can be indicated with <cell cols="2">.

Note how the example also illustrates how tables can have headings, in a <head> element. The text of this heading should not begin with “Table 1” or any similar prefix; this will be provided when the article is rendered. To link to the table, all you need to do is to provide a pointer targeting its @xml:id attribute:

<p>As you can see from <ptr target="#table1" type="crossref"/>, the elements included...</p>

This will be expanded at rendering time into “Table X”, where X is the appropriate table number.

Inline Rhetorical Elements

The jTEI schema prompts you to encode information as much as possible with conceptual tags. Therefore, the general-purpose <hi> tag has been removed from the jTEI schema. Instead, you should use more semantically expressive elements for identifying the rhetorical phenomenon you want to encode. If you want to stress a word in a sentence, you can do so with the <emph> element, which is rendered as italicized text. Foreign terms can be tagged with <foreign>, with a proper language identification code for the @xml:lang attribute. Technical terms, or terms in general, can be encoded with <term>, and appear as italicized text in the rendered article.

<p><term>Interoperability</term> may be defined as the property of data that allows
  it to be loaded <emph>unmodified</emph> and fully used in a <emph>variety</emph>
  of software applications. <term>Interchange</term> is basically the same property
  that applies after a preliminary conversion of the data (<ref type="bibl" target="#bauman11">Bauman
    2011</ref>; <ref type="bibl" target="#unsworth11">Unsworth 2011</ref>), and
  implies some loss of information in the process. Interchange can thus be seen as
  an easier, less stringent or less useful kind of information exchange than pure interoperability.</p>

<p>Unicode is a <emph>character</emph> encoding standard, and is not intended to
  standardize ligatures or other presentation forms
  (<ref type="bibl" xml:id="quoteref16" target="#unicode14">Unicode 2014</ref>).
  For example, there is no Unicode character for old Latin <foreign xml:lang="la">sescuncia</foreign>
  (like a pound-sign, = one eighth), since it can be composed from <foreign xml:lang="la">semuncia</foreign>
  (character 10192) and an EN-dash (<ref type="bibl" target="#unicode06">Unicode 2006, 4</ref>)</p>

Another category of inline rhetorical elements are those that are used for text that is somehow quoted. When a word is mentioned to illustrate its form or usage, without its actual meaning, it should be encoded as <mentioned>. At rendering time, it will be displayed in italics. When you use a word while at the same time distancing yourself from it, you should encode it with <soCalled>. At rendering time, the start and end tag will be replaced with double quotation marks. Finally, if you want to quote a word or passage without attributing it to an external source, you can use the <q> element. Such anonymous quotations are rendered in double quotation marks.[^3]

[^3: The actual form of the quotation marks depends on the nesting level of quotation marks, so that double and single quotation marks alternate when they nest. For example, if a word tagged as <soCalled> appears inside a <q> element, then the quoted text will be wrapped in double quotation marks, while the text inside <soCalled> will be rendered with single quotation marks.]

<p>The standard definition of metadata as <q>data about data</q> seems to pose more
  questions than it answers.</p>

<p>There are possible ways (<soCalled>hacks</soCalled>) around some of these problems
  even without rewriting the software, and some software is open source. For example,
  some software may permit dates in the <emph>future</emph>, in which case a project
  might record eighteenth-century dates using values from the twenty-eighth century.
  Pounds, shillings, and pence could be converted to a modern standard unit (for
  example, US dollars; <ref target="http://www.measuringworth.com/">Measuring Worth</ref>
  provides calculators for determining values in some historical currencies). A
  project could consistently use the <mentioned>comments</mentioned>, <mentioned>memo</mentioned>,
  or <mentioned>notes</mentioned> field to record pointers into the attesting document.</p>

If you mention titles in paragraph text, you should encode them as such, with the <title> element and a proper type for the @level attribute. Titles of journals (level="j" for @level) and monographs ("m") are rendered in italics. Titles of book chapters or journal articles ("a"), or unpublished materials ("u") are enclosed in quotation marks at rendering time (so you mustn't provide them yourself).

Inline Technical Elements

Due to the nature of this journal, a discussion of technical XML or TEI elements is a common feature in jTEI articles. When elements from an XML vocabulary are discussed, they should be identified in a <gi> element, with an optional @scheme attribute in which the XML vocabulary can be named. The default value for this attribute is "TEI" for TEI elements; others could be "HTML", "Schematron", "DBK" (Docbook), etc. At rendering time, the <gi> start and end tags are replaced with the < and > characters, respectively. The element name is always presented in this form: <p> in the output rendering, even if it is an empty element which in actual usage is almost always self-closing, such as <lb> or <pb>.

Attribute names should be tagged in an <att> element, which at rendering time will be preceded with a @ character. Attribute values should be tagged in <val>. At rendering time, the <val> start and end tags are replaced with straight quotation marks, so there is no need to quote the values yourself.

<p>For example, the extension of credit can be represented in a transactionography
  by the transfer of a commodity of indebtedness. We have been using the keyword
  <val>iou</val> as the value of <att>commodity</att> of <gi>measure</gi> for this purpose.</p>

When you want to quote an instance of a single start or end tag, you should use the <tag> element. If you want to specify the XML vocabulary this tag belongs to, this can be done in the @scheme attribute (see above). In the @type attribute, you can specify the kind of tag: "start" (start tag), "end" (end tag), "empty" (an empty tag), "pi" (processing instruction), "comment" (an XML comment), or "ms" (a CDATA marked section). For all these types of tags, the proper delimiters (starting with the < and ending with the > characters) are inserted when the article is rendered. Note, for full-fledged XML examples, the <egXML> element should be used (see Example Code, XML and non-XML).

<p>A range like <code>#range(left(//lb[@n='3']),left(//lb[@n='4']))</code>, however,
  could unambiguously address the sequence of nodes comprising line 3, even if the
  <gi>lb</gi> happened to be a child of another element that began in the previous line.</p>

<p>For example, <tag type="empty">rng:ref name="model.pLike"</tag> becomes <tag type="empty">classRef key="model.pLike"</tag>.</p>

If you want to cite a brief inline code fragment from a formal programming language, you can use the <code> element. With the @lang attribute, you can identify the language of the code:

<p>Most of the time, pointing from one part of a TEI document to another, it is easy
  to use IDs. Simply wrap the thing in an element, give that element an <att>xml:id</att>
  attribute (say, <code>xml:id="foo"</code>), and point at the ID using either a
  URI with an appended fragment identifier (<val>#foo</val>) or using an attribute
  whose type is IDREF.</p>

The <ident> element should be used to encode identifiers in a formal language, such as variable, class, and function names in a programming language. When discussing the TEI encoding scheme or customizations, the names of model and attribute classes, datatypes, macros, and TEI customizations should be encoded with <ident>:

<p>For example <ident>data.duration.iso</ident>, <ident>data.outputMeasurement</ident>,
  <ident>data.pattern</ident>, <ident>data.point</ident>, <ident>data.version</ident>,
  and <ident>data.word</ident> all map to the same datatype CDATA in XML DTD, and to
  various TEI-defined regular expressions in RELAX NG or W3C Schema.</p>

Footnotes

jTEI articles can have footnotes. Since no other notes are supported, the encoding is fairly simple: just add a <note> element at the place where you want to insert the footnote in the text. No further attributes are required: numbering is catered for at rendering time. Notes can contain plain text or paragraphs. No block-level elements are allowed:

<p>There are essentially two pointing mechanisms TEI employs to implement its graph
  data structure: XPath, used in the <att>match</att> attribute,
  <note><p>See <ptr target="http://www.tei-c.org/Vault/P5/2.2.0/doc/tei-p5-doc/en/html/ref-att.scoping.html"/></p>
</note> and URIs, which can indicate documents, or (using fragment identifiers)
elements in the current document which have <att>xml:id</att> attributes.</p>

Internal Linking

Internal links are cross-links within the article. In jTEI, you can point to other text structures that can have labels, namely <div>, <figure> (containing either graphics or code examples), or <table>. You can link to those structures either with an unlabeled cross-reference in <ptr>, or with a labeled link in <ref>. Both must have a @type attribute with value "crossref", and a @target attribute, whose value should start with the “#” sign, followed by the @xml:id value of the element it addresses:

    <p><ref type="crossref" target="#figure2">The following figure</ref> shows a typical example of such a tag document.
<figure xml:id="figure2">
  <graphic url="img/tagdoc-p2.png" width="642px" height="716px"/>
  <head type="legend">Tagdoc for <gi>resp</gi> element in P2.</head>
</figure>
    </p>

For unlabeled cross-links, the <ptr type="crossref" xml:id="#link-target"/> is replaced with an appropriate label for the link target at rendering time:

<p><ptr target="#table2" type="crossref"/> shows allowable <att>rend</att> values and
  their equivalent meanings.</p>
<table xml:id="table2">
  <head>Allowable <att>rend</att> attribute values in <ident>tei_corset</ident>
    customization</head>
  <row role="label">
    <cell><att>rend</att>
      <lb/>(renamed <att>r</att>) <lb/>attribute value</cell>
    <cell>Meaning</cell>
  </row>

</table>

In the generated ODT and OpenEdition version, the cross-reference is is rendered as: “Table X shows allowable @rend values and their equivalent meanings.”

Note how internal links are rendered as plain text instead of hyperlinks in the ODT version and the final version in revues.org.

Another type of internal linking consists of bibliographic references, pointing to entries in the bibliography. This should be done with a specific type of <ref> element, with value "bibl" for the @type attribute. The value of the @target attribute for bibliographic references must point to a <bibl> element in the bibliography:

<p>Thomas notes numerous additional developments in the use of computers in historical
  study, both in the United States and elsewhere between the 1940s and the early
  twenty-first century (<ref type="bibl" target="#thomas04">Thomas 2004</ref>).</p>

<back>
  <div type="bibliography">
    <listBibl>
      <bibl xml:id="thomas04"><author>Thomas, William G., III</author>. <date>2004</date>.
        <title level="a">Computing and the Historical Imagination</title>:
        <title level="m">A Companion to Digital Humanities</title>, edited by
        <editor>Susan Schreibman</editor>, <editor>Ray Siemens</editor>, and
        <editor>John Unsworth</editor>. <pubPlace>Oxford</pubPlace>:
        <publisher>Blackwell Publishing</publisher>.</bibl>
    </listBibl>
  </div>
</back>

Note, how all characters surrounding bibliographic references have to be hard-coded in the text; they are not generated automatically at rendering time. For linking bibliographic references with quotations, see Quotations, Inline and Block.

External Linking

Links to external destinations can be encoded with <ptr> (unlabeled) or <ref> (labeled). They must have a @target attribute whose value is the URI of the link's destination: <item>addresses the range between two points (<ref target="http://www.tei-c.org/Vault/P5/2.2.0/doc/tei-p5-doc/en/html/SA.html#SATSRN">16.2.5.4 range()</ref>)</item> <p>More detailed information can be found at <ptr target="http://www.tei-c.org/Vault/P5/2.5.0/doc/tei-p5-doc/en/html/ref-elementSpec.html"/>.</p>At rendering time, both types of links are transformed to clickable hyperlinks, and for <ptr> the value of the @target attribute is used as the link label.

One caveat for external links to the TEI Guidelines: since the web version at is unstable and will be updated at each new release, you must point to the archived versions in the Vault section of the TEI website. There, you can find an archive of all previous TEI releases and their documentation. Follow the links to the exact version you're referencing in your article (even if it's the current version), and use them for your external hyperlinks. In the examples above, the first link points to the documentation of version 2.2.0 of the TEI Guidelines, while the second link points to version 2.5.0.

Frequently-asked Questions

- Where did <hi> go? How do I do italics?

We're trying to avoid <hi> because it's so widely used in so many different ways. We would also prefer that all styling be applied for semantic reasons, so rather than italics, think journal title or emphasis or foreign word. Also, what you believe should be in italics might in our style guide be rendered in quotation marks, or not styled at all; that's why it's easier if you identify things and let the system style them.

- Why can't I use quotation marks?

Literal quotation marks can be straight double, straight single, curly double, curly single, or (if you happen to be on a non-English keyboard) a range of other symbols. All copyeditors are familiar with the tedium of checking that they're all the right form, and that all the inital ones are opening ones and the closing ones are the matching closing ones. It's much simpler if you tag your text as <quote>, <soCalled> or whatever, and let the XSLT provide the quotation marks in a reliable way.

- Why is this so restrictive?

The TEI is a huge standard; there are lots of available approaches to encoding any given phenomenon, and every TEI user has their own habits and preferences, arising out of their history and the projects they've worked on. If we accept submissions in any valid TEI (tei_all), we inevitably spend many hours re-encoding them to get something that will work with our system. It's much simpler if we let the schema do the work for us.

Summary of Elements and their Rendition

Element/Tag	Usage	Example	Rendition
<att>	attribute name	<att>place</att>	@place
<cit>	blockquote with bibliographic reference	<cit> <quote source="quoteref7"><supplied>A</supplied>ccount books are among the most common but least accessible primary sources for historians<gap/></quote> <ref type="bibl" xml:id="quoteref7" target="#mcgaw85">McGaw 1985</ref> </cit>	“[A]ccount books are among the most common but least accessible primary sources for historians … (McGaw 1985)”
<code>	short inline code example	<p>A mixed content model such as <code>(#PCDATA | a | model.b)*</code> might be expressed as follows</p>	A mixed content model such as (#PCDATA | a | model.b)* might be expressed as follows
<eg>	non-XML code example	<eg> $('#teiHolder').data('modVers', { xmlFile: 'data/teiFile.xml' annotations: 'data/annotations.json', fixFirst: false, fullscreen: false, height: 300, ids: 'a,b,c', witnesses: 'v1,v2' }); </eg>	$('#teiHolder').data('modVers', { xmlFile: 'data/teiFile.xml' annotations: 'data/annotations.json', fixFirst: false, fullscreen: false, height: 300, ids: 'a,b,c', witnesses: 'v1,v2' });
<egXML>	XML example code	&lt;egXML xmlns="http://www.tei-c.org/ns/Examples"&gt; &lt;content&gt; &lt;classRef key="model.ab" maxOccurs="unlimited"/&gt; &lt;/content&gt; &lt;/egXML&gt;	<content> <classRef key="model.ab" maxOccurs="unlimited"/> </content>
<emph>	emphasized text (italics)	The TEI began as a conscious attempt to <emph>model</emph> existing and future markup systems.	The TEI began as a conscious attempt to model existing and future markup systems.
<figure>	a block figure or example code, with a mandatory heading	<figure xml:id="figure1"> <graphic url="img/ives_img_01.png" width="768px" height="1004px"/> <head type="legend">Page-image from Ingelow’s <title level="m">Poems</title></head> </figure>	Figure 1: Page-image from Ingelow’s Poems
<foreign>	a foreign text fragment	Nowhere is this more obvious than in the weight accorded the single author monograph, which remains the standard <foreign xml:lang="fr">par excellence</foreign> of scholarship in the humanities.	Nowhere is this more obvious than in the weight accorded the single author monograph, which remains the standard par excellence of scholarship in the humanities.
<gap>	an omission in quoted text	<quote source="#quoteref7">Leisure moments only <gap/> available for its execution</quote>	“Leisure moments only … available for its execution”
<gi>	the name of an XML element	<gi>quote</gi>	<quote>
<graphic>	a digital image	<graphic url="img/ives_img_01.png" width="768px" height="1004px"/>	
<head>	a heading for a text division, figure, table, or list	<div xml:id="futuredirections"> <head>Future Directions</head> </div>	4. Future Directions
<ident>	identifier in a formal language	the new <ident>range()</ident> and <ident>string-range()</ident> pointers	the new range() and string-range() pointers
<list>	a list	<list rend="ordered"> <item>The first misconception is this: digital texts and digital archives merely replicate physical texts and physical archives in a non-material environment.</item> <item>The second misconception is that all possible digital representations of a text are created equal.</item> </list>	- The first misconception is this: digital texts and digital archives merely replicate physical texts and physical archives in a non-material environment. - The second misconception is that all possible digital representations of a text are created equal.
<mentioned>	a word that is mentioned	conversations on the multi-dimensional understanding of <mentioned>text</mentioned> and <mentioned>representation</mentioned>	conversations on the multi-dimensional understanding of text and representation
<note>	a footnote	A similar suggestion is made in Eric Van der Vlist’s <title level="m">RELAX NG</title><note><p><ref target="http://relaxng/">http://relaxng/</ref>. </p></note> (<ref type="bibl" target="#vlist04">2004</ref>)	A similar suggestion is made in Eric Van der Vlist’s RELAX NG1 (2004) Notes 1 http://relaxng/.
<ptr>	a pointer to another location (internal or external)	The rest of this paper treats each of these points in more detail. <ptr type="crossref" target="#interoperability"/> describes the nature of the interoperability problem.	The rest of this paper treats each of these points in more detail. Section 2 describes the nature of the interoperability problem.
<q>	a short, unattributed inline quotation	(student survey responses included words such as <q>apprehensive</q>, <q>intimidated</q>, and even <q>terrified</q>), which explains why one student commented that TEI training <q>was not something I would have sought out on my own.</q>	(student survey responses included words such as “apprehensive,” “intimidated,” and even “terrified”), which explains why one student commented that TEI training “was not something I would have sought out on my own.”
<quote>	an attributed quotation	<quote source="#quoteref4">Names of authors</quote> appear in <quote source="#quoteref4">Italic Capitals</quote> (<ref type="bibl" xml:id="quoteref4" target="#arber1875">Arber 1875–95, 1:29</ref>).	“Names of authors” appear in “Italic Capitals” (Arber 1875–95, 1:29).
<ref>	a reference to another location (with custom label text)	<ref target="http://www.tei-c.org/#SATSRN">16.2.5.4 range()</ref>)	16.2.5.4 range())
<soCalled>	a word from which the author distances herself	There are possible ways (<soCalled>hacks</soCalled>) around some of these problems	There are possible ways (“hacks”) around some of these problems
<supplied>	text that has been added by the jTEI author (in a quotation)	<q>Finding what you need can be problematic. Lack of links to chapters that describe elements next <supplied>to</supplied> some element definitions</q>	“Finding what you need can be problematic. Lack of links to chapters that describe elements next [to] some element definitions”
<table>	a table	<table xml:id="table3"> <head>Allowable <att>rend</att> attribute values in <ident>tei_corset</ident> customization</head> <row role="label"> <cell><att>rend</att> <lb/>(renamed <att>r</att>) <lb/>attribute value</cell> <cell>Meaning</cell> </row> <row> <cell role="label"><val>ab</val></cell> <cell>rendered above the line</cell> </row> <row> <cell role="label"><val>al</val></cell> <cell>rendered aligned to the left</cell> </row> </table>	Table 4: Allowable @rend attribute values in tei_corset customization @rend (renamed @r) attribute value Meaning ab rendered above the line al rendered aligned to the left
<tag>	a full XML tag	<tag type="empty">rng:ref name="model.pLike"</tag>	<rng:ref name="model.pLike"/>
<term>	a technical term	Annotations are stored in <term>triple stores</term> or graph databases like Neo4J	Annotations are stored in triple stores or graph databases like Neo4J
<title>	the title of a bibliographic work	<title level="a">Where Did All the Document Kids Go? Open-source, Markup, and the Casual Developer.</title> Presented at Balisage: The Markup Conference 2013, Montréal, Canada, August 6–9, 2013. In <title level="m">Proceedings of Balisage: The Markup Conference 2013</title>.	“Where Did All the Document Kids Go? Open-source, Markup, and the Casual Developer.” Presented at Balisage: The Markup Conference 2013, Montréal, Canada, August 6–9, 2013. In Proceedings of Balisage: The Markup Conference 2013.
<val>	an attribute value	an attribute <att>preserveOrder</att> taking values <val>true</val> or <val>false</val>	an attribute @preserveOrder taking values "true" or "false"

<TEI>
@version

<titleStmt>
title statement
groups information about the title of a work and those responsible for its content. In jTEI, this must include a title and an <author> element for each author of the paper, which in turn must include <name>, <affiliation> and <email>.

<textClass>

<affiliation>
@notAfter
@role

<application>
@type
@notAfter

<att>
Attribute delimiters are not allowed for : they are completed at processing time via XSLT.
@scheme

att.breaking

att.cReferencing

att.canonical

att.citing
@from
@to

att.combinable
@mode

att.coordinated

att.damaged
@hand
@agent
@degree
@group

att.datable
@calendar
@period

att.datable.custom

att.datable.iso

att.datcat

att.declarable

att.declaring

att.deprecated

att.dimensions
@unit
@quantity
@extent
@precision
@scope

att.divLike
@org
@sample

att.docStatus

att.duration.iso

att.duration.w3c

att.editLike
@evidence
@instant

att.edition

att.fragmentable

att.global.rendition
@style

att.global.change

att.global.facs

att.handFeatures

att.identified
@predeclare
@module
@status

att.internetMedia

att.interpLike
@type
@inst

att.measurement

att.media
@scale

att.milestoneUnit

att.naming
@nymRef

att.patternReplacement

att.personal
@full
@sort

att.pointing
@targetLang
@evaluate

att.pointing.group
@domains
@targFunc

att.ranging

att.readFrom

att.repeatable

att.responsibility
@cert
@resp

att.scoping

att.segLike
@function

att.sortable

att.spanning

att.styleDef
@schemeVersion

att.tableDecoration
@role
"data"
"label"

att.timed

att.transcriptional
@hand
@status
@cause
@seq

att.translatable

att.typed
@subtype

<author>
Author information in the <titleStmt> must include <name>, <affiliation> and <email>.
@role

<availability>
@status

<bibl>
A bibliographic entry should have a unique value for @xml:id. This bibliographic entry is an orphan: no ref[@type="bibl"] references to it occur in the text.
@type

<biblScope>
@type
@unit
"chapter"
"issue"
"page"
"part"
"volume"

<cit>
cited block quotation
contains a quotation from some other document, together with a bibliographic reference to its source. In jTEI, this is used only for block quotations, and it will be rendered as a block. For inline quotations, use the <quote> element and link it to a reference using @source.
is normally expected to have a bibliographic reference (ref[@type="bibl"]). Please make sure you intended not to add one here.
@type

<date>
@type

<desc>
@type

<div>
Abstracts ([@type="abstract"]) and acknowledgements ([@type="acknowledgements"]) may only occur inside front. Only abstracts (div[@type="abstract"]) and acknowledgements (div[@type="acknowledgements"]) may appear in the <front>. Bibliography ([@type="bibliography"]) and appendices ([@type="appendix"]) may only occur inside back. An editorial introduction ([@type="editorialIntroduction"]) may only occur inside body. A must contain a head.
@type
"abstract"
Abstract for the article, appearing inside <front>.
Every article must include an abstract, consisting of one or two paragraphs. This appears in the <front> element and may not appear anywhere else.
"acknowledgements"
Acknowledgements for the article, appearing inside <front>.
If an article includes a section for acknowledgements (for funders, supporters, etc.), it should be as brief as possible, and must appear in the <front> element and nowhere else.
"appendix"
Appendix to the article, appearing inside <back>.
Any appendices must appear in the <back> of the article, following the bibliography.
"bibliography"
Bibliography, appearing inside <back>.
Every article must include a bibliography, which appears as the first component of the <back> element, followed by any appendices.
"editorialIntroduction"
Editorial introduction, appearing inside <body>.
An editorial introduction to an issue must contain a <div type="editorialIntroduction">, which must appear in the <body> element and may not appear anywhere else.

<editor>
@role
"translator"

<emph>
Emphasis (italicization)
The <emph> element is used for emphasized text, and will be rendered in italics.

<figure>
figure
groups elements representing or containing graphic information such as a graphic illustration, or a block of example code. Figure must contain either <graphic>, <egXML> (for example XML code) or <eg> (for non-XML code), and a mandatory <head> element containing the caption for the figure. Inline code examples may be provided through <egXML> and <eg> without the <figure> wrapper.
@place
@type

<figure>
  <graphic url="http://www.example.org/fig1.png" width="100px" height="750px"/>
  <head type="legend">The View from the Bridge</head>
  <head type="license">Used with permission</head>
</figure>

<figure>
  <eg>if ((err = SSLHashSHA1.update(&amp;hashCtx, &amp;serverRandom)) != 0)
    goto fail;
    if ((err = SSLHashSHA1.update(&amp;hashCtx, &amp;signedParams)) != 0)
    goto fail;
    goto fail;
    if ((err = SSLHashSHA1.final(&amp;hashCtx, &amp;hashOut)) != 0)
    goto fail;
  </eg>
  <head type="legend">An embarrassing error for Apple</head>
</figure>

<figure>
  &lt;egXML xmlns="http://www.tei-c.org/ns/Examples"&gt;
  &lt;list rend="bulleted"&gt;
  &lt;item&gt;Life&lt;/item&gt;
  &lt;item&gt;The Universe&lt;/item&gt;
  &lt;item&gt;Everything&lt;/item&gt;
  &lt;/list&gt;
  &lt;/egXML&gt;
  <head type="legend">A book title rendered as a list</head>
</figure>

<forename>
@role
@type

<ident>
@type

<label>
@type
@place

<language>
@usage

<lb>
@type

<list>
@type
"gloss"
@rend
describes the way the list should be rendered.
"bulleted"
A bulleted list
Bulleted lists will appear with each item preceded by a leading dot.
"inline"
An inline list
Inline lists appear within a paragraph of ordinary text; list items do not start on a new line, but follow immediately from the preceding text or item. The value "inline" may be combined with another value; for example, "ordered inline" means that the list will be rendered inline, but each item will be preceded by a number in parentheses: (1) first item (2) second item, and so on.
"ordered"
A numbered list
Items in a numbered list will be preceded by a number. If the list is inline, then the number will be enclosed in parentheses, but if it is a block-level list (the default), the number will be followed by a period.
"simple"
A simple list (no bullets or numbers)
Items in a simple list will be rendered with no bullet or preceding number at all.

<list rend="bulleted">
  <item>Bacon</item>
  <item>Eggs</item>
  <item>Mushrooms</item>
  <item>Spam</item>
  <item>Spam</item>
  <item>Spam</item>
  <item>Spam</item>
</list>

<p>
  There are three kinds of list: <list rend="inline ordered">
    <item>simple, </item><item>bulleted</item> and
    <item>ordered</item></list>.
</p>

<listBibl>
@type

<name>
@role
@notAfter
@type

<note>
Footnotes should follow punctuation marks, not precede them. Place your <note> element after the punctuation mark. No block-level elements are allowed inside note.
@anchored
@targetEnd
@place
@target
@type

<head>
Headings are numbered and labeled automatically, please remove the hard-coded label from the text. Figure titles must have a type 'legend' or 'license'.
@type
indicates the type of heading. In jTEI, we only use this attribute in the context of a <head> element in <figure>, where it must have one of two values.
"legend"
the caption for a figure.
"license"
licensing information that must be shown alongside the figure.

<num>
@type
indicates the type of numeric value. In jTEI, we particularly use num[@type='ordinal'] for e.g. “21st” or “2nd”; in rendering, this results in the non-numeric suffix to the number being output as superscript. Note, however, that ordinals for centuries should be spelled out, not written using digits (“nineteenth century”, not “19th century”).
"cardinal"
absolute number, e.g. 21, 21.5
"ordinal"
ordinal number, e.g. 21st. This will be rendered with the non-numeric component superscripted.
"fraction"
fraction, e.g. one half or three-quarters
"percentage"
a percentage

<orgName>
@notAfter
@role
@type

<pubPlace>
@role

<ptr>
Multiple targets are only allowed for [@type='crossref'].
@target
@type
"crossref"
A cross-reference (reference to another part of the article).
To link to another part of your article, use <ptr type="crossref">, and point to the @xml:id value of the target location: <ptr type="crossref" target="#intro">. The <ptr> element will be expanded to create an appropriate link to the target location.

<q>
@type

<quote>
must be accompanied by a bibliographic reference (ref[@type="bibl"]) or a bibliographic description in the running text.
@type

<ref>
with multiple targets is not supported. Parentheses are not part of bibliographic references. Please move them out of . A bibliographic reference must point to an entry in the bibliography. A bibliographic reference must be typed as @type="bibl".
@target
@type
"crossref"
A cross-reference (reference to another part of the article).
To link to another part of your article, use <ref type="crossref">, and point to the @xml:id value of the target location: <ref type="crossref" target="#intro">.
"bibl"
A bibliographic reference (reference to an entry in the bibliography).
To link to a bibliographic description in the bibliography, use <ref type="bibl">, and point to the @xml:id value of the target location: <ref type="bibl" target="#ide88">.

<rendition>
Please remove all definitions that aren't actually being used in the article.
@scope
@scheme
"css"

<roleName>
@role
@type

<surname>
@role
@type

<teiHeader>
@type

<term>
@target
@type

<text>
text
contains the complete text of the article. Must include a <front> containing an abstract, a <body> containing the main text, and a <back> containing the bibliography and any appendices.
An article must have a keyword list in the header. An article must have a front section with an abstract. An article must have a back section with a bibliography.
@type

<text>
  <front>
    <div type="abstract" xml:id="abstract">
      <p>This article is about...</p>
    </div>
  </front>
  <body>
    <div xml:id="intro">
      <head>Introduction</head>
      <p>A great deal of previous research...</p>
    </div>
    <div xml:id="method">
      <head>Method</head>
      <p>This project was undertaken...</p>
    </div>
  </body>
  <back>
    <div type="bibliography">
      <listBibl>
        <bibl>[...]</bibl>
      </listBibl>
    </div>
  </back>
</text>

<title>
@type
"main"
The main title of your article.
Academic articles often have a main title followed by a subtitle (sometimes with a colon separating them). If you have two such components in your article title, then in the <titleStmt>, use <title type="main"> and <title type="sub"> to encode the two components of your title.
"sub"
The subtitle of your article.
Academic articles often have a main title followed by a subtitle (sometimes with a colon separating them). If you have two such components in your article title, then in the <titleStmt>, use <title type="main"> and <title type="sub"> to encode the two components of your title.

<body>

If contains a div, and that div is not an editorial introduction, then there should be more than one div. Rather than using only a single div, you may place the content directly in the element.

<back>
must have a bibliography (div[@type="bibliography"]), which must be organized inside a listBibl element.

<tag>
Tag delimiters are not allowed for : they are completed at processing time via XSLT.

<val>
Attribute value delimiters are not allowed for : they are completed at processing time via XSLT.

<supplied>
Please remove square brackets from : they are completed at processing time via XSLT.

<idno>
If a bibliographic entry has a formal DOI code, it should be placed at the very end of the bibliographic description.

<graphic>
Width and height in pixels must be specified for any . may only occur inside figure.

<front>
must have an abstract (div[@type='abstract']).

<table>
No tables are are allowed inside lists.

<gap>
A element should follow a period rather than precede it when an ellipsis follows the end of a sentence. A should follow a period directly, without preceding whitespace.

"Straight apostrophe" characters are not permitted. Please use the Right Single Quotation Mark (U+2019 or ’) character instead. On the other hand, if the straight apostrophe characters function as quotation marks, please replace them with appropriate mark-up that will ensure the appropriate quotation marks will be generated consistently. Left and Right Single Quotation Marks should be used in the right place. Quotation marks are not permitted in plain text. Please use appropriate mark-up that will ensure the appropriate quotation marks will be generated consistently. Double hyphens should not be used for dashes. Please use the EM Dash (U+2014 or —) instead. Numeric ranges should not be indicated with a hyphen. Please use the EN Dash (U+2013 or –) character instead. You should put a comma after "i.e." and "e.g.". There's no local target for this link. Please make sure you use an existing @xml:id value. Quotation mark delimiters are not allowed for : they are completed at processing time via XSLT. You're strongly advised to add an @xml:id attribute to to ease formal cross-referencing with (ptr|ref)[@type='crossref'] Please replace literal references to tables, figures, examples, and sections with a formal crosslink: (ptr|ref)[@type="crossref"] Cross-links ([@type="crossref"]) should be targeted at div, figure, or table elements. Please type internal cross-references as 'crossref' ([@type="crossref"]). Centuries such as "the nineteenth century" should be spelled out, not written with digits. Please refer to the exact version of the TEI Guidelines, and link to the version that can be found in the Vault section. For an overview of all archived versions, see http://www.tei-c.org/Vault/P5/. If you're referring to the English version, the correct URL will likely take the form of http://www.tei-c.org/Vault/P5/{$version-number}/doc/tei-p5-doc/en/html/.