https://github.com/TEIC/TEI
Tip revision: 347c64fac3fa1a64ade0d8d1842813d4b8f7acec authored by Hugh Cayless on 12 May 2017, 16:57:59 UTC
Updates.
Updates.
Tip revision: 347c64f
AB.html
<!DOCTYPE html
SYSTEM "about:legacy-compat">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><!--THIS FILE IS GENERATED FROM AN XML MASTER. DO NOT EDIT (4)--><title>iv. About These Guidelines - The TEI Guidelines</title><meta property="Language" content="en" /><meta property="DC.Title" content="iv. About These Guidelines - The TEI Guidelines" /><meta property="DC.Language" content="SCHEME=iso639 en" /><meta property="DC.Creator.Address" content="tei@oucs.ox.ac.uk" /><meta charset="utf-8" /><link href="guidelines.css" rel="stylesheet" type="text/css" /><link href="odd.css" rel="stylesheet" type="text/css" /><link rel="stylesheet" media="print" type="text/css" href="guidelines-print.css" /><script type="text/javascript" src="jquery-1.2.6.min.js"></script><script type="text/javascript" src="columnlist.js"></script><script type="text/javascript" src="popupFootnotes.js"></script><script type="text/javascript">
$(function() {
$('ul.attrefs-class').columnizeList({cols:3,width:30,unit:'%'});
$('ul.attrefs-element').columnizeList({cols:3,width:30,unit:'%'});
$(".displayRelaxButton").click(function() {
$(this).parent().find('.RNG_XML').toggle();
$(this).parent().find('.RNG_Compact').toggle();
});
$(".tocTree .showhide").click(function() {
$(this).find(".tocShow,.tocHide").toggle();
$(this).parent().find("ul.continuedtoc").toggle();
});
})
</script><script type="text/javascript"><!--
var displayXML=0;
states=new Array()
states[0]="element-a"
states[1]="element-b"
states[2]="element-c"
states[3]="element-d"
states[4]="element-e"
states[5]="element-f"
states[6]="element-g"
states[7]="element-h"
states[8]="element-i"
states[9]="element-j"
states[10]="element-k"
states[11]="element-l"
states[12]="element-m"
states[13]="element-n"
states[14]="element-o"
states[15]="element-p"
states[16]="element-q"
states[17]="element-r"
states[18]="element-s"
states[19]="element-t"
states[20]="element-u"
states[21]="element-v"
states[22]="element-w"
states[23]="element-x"
states[24]="element-y"
states[25]="element-z"
function startUp() {
}
function hideallExcept(elm) {
for (var i = 0; i < states.length; i++) {
var layer;
if (layer = document.getElementById(states[i]) ) {
if (states[i] != elm) {
layer.style.display = "none";
}
else {
layer.style.display = "block";
}
}
}
var mod;
if ( mod = document.getElementById('byMod') ) {
mod.style.display = "none";
}
}
function showall() {
for (var i = 0; i < states.length; i++) {
var layer;
if (layer = document.getElementById(states[i]) ) {
layer.style.display = "block";
}
}
}
function showByMod() {
hideallExcept('');
var mod;
if (mod = document.getElementById('byMod') ) {
mod.style.display = "block";
}
}
--></script></head><body><div id="container"><div id="banner"><img src="Images/banner.jpg" alt="Text Encoding Initiative logo and banner" /></div></div><div class="mainhead"><h1>P5:
Guidelines for Electronic Text Encoding and Interchange</h1><p>Version 3.1.1a. Last updated on
10th May 2017, revision bd8dda3</p></div><div id="onecol" class="main-content"><h2><span class="headingNumber">iv. </span>About These Guidelines</h2><div class="div1" id="AB"><div class="miniTOC miniTOC_left"><p><span class="subtochead">Table of contents</span></p><div class="subtoc"><ul class="subtoc"><li class="subtoc"><a class="subtoc" href="AB.html#ABSTRUNC" title="Structure and Notational Conventions of this Document">iv.1. Structure and Notational Conventions of this Document</a></li><li class="subtoc"><a class="subtoc" href="AB.html#ABTEI" title="Historical Background">iv.2. Historical Background</a></li><li class="subtoc"><a class="subtoc" href="AB.html#ABTEI4" title="Future Developments and Version Numbers">iv.3. Future Developments and Version Numbers</a></li></ul></div><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="FM1.html"><span class="headingNumber">iii. </span>Preface and Acknowledgments</a></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="SG.html"><span class="headingNumber">v. </span>A Gentle Introduction to XML</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><p>These Guidelines have been developed and are maintained by the Text Encoding Initiative Consortium (TEI); see <a class="link_ptr" href="AB.html#ABTEI" title="Historical Background"><span class="headingNumber">iv.2. </span>Historical Background</a>. They are addressed to anyone who works with any kind of textual resource in digital form.</p><p>They make recommendations about suitable ways of representing those features of textual resources which need to be identified explicitly in order to facilitate processing by computer programs. In particular, they specify a set of markers (or <span class="term">tags</span>) which may be inserted in the electronic representation of the text, in order to mark the text structure and other features of interest. Many, or most, computer programs depend on the presence of such explicit markers for their functionality, since without them a digitized text appears to be nothing but a sequence of undifferentiated bits. The success of the World Wide Web, for example, is partly a consequence of its use of such markup to indicate such features as headings and lists on individual pages, and to indicate links between pages. The process of inserting such explicit markers for implicit textual features is often called ‘markup’, or equivalently within this work ‘encoding’; the term ‘tagging’ is also used informally. We use the term <span class="term">encoding scheme</span> or <span class="term">markup language</span> to denote the complete set of rules associated with the use of markup in a given context; we use the term <span class="term">markup vocabulary</span> for the specific set of markers or named distinctions employed by a given encoding scheme. Thus, this work both describes the TEI encoding scheme, and documents the TEI markup vocabulary.</p><p>The TEI encoding scheme is of particular usefulness in facilitating the loss-free interchange of data amongst individuals and research groups using different programs, computer systems, or application software. Since they contain an inventory of the features most often deployed for computer-based text processing, these Guidelines are also useful as a starting point for those designing new systems and creating new materials, even where interchange of information is not a primary objective. </p><p>These Guidelines apply to texts in any natural language, of any date, in any literary genre or text type, without restriction on form or content. They treat both continuous materials (‘running text’) and discontinuous materials such as dictionaries and linguistic corpora. Though principally directed to the needs of the scholarly research community, these Guidelines are not restricted to esoteric academic applications. They are also useful for librarians maintaining and documenting electronic materials, and for publishers and others creating or distributing electronic texts. Although they focus on problems of representing in electronic form texts which already exist in traditional media, these Guidelines are also applicable to textual material which is ‘born digital’. We believe them to be adequate to the widest variety of currently existing practices in using digital textual data, but by no means limited to them.</p><p>The rules and recommendations made in these Guidelines are expressed in terms of what is currently the most widely-used markup language for digital resources of all kinds: the Extensible Markup Language (XML), as defined by the World Wide Web Consortium's XML Recommendation. However, the TEI encoding scheme itself does not depend on this language; it was originally formulated in terms of SGML (the ISO Standard Generalized Markup Language), a predecessor of XML, and may in future years be re-expressed in other ways as the field of markup develops and matures. For more information on markup languages see chapter <a class="link_ptr" href="SG.html" title="A Gentle Introduction to XML"><span class="headingNumber">v. </span>A Gentle Introduction to XML</a>; for more information on the associated character encoding issues see chapter <a class="link_ptr" href="CH.html" title="4"><span class="headingNumber">vi. </span>Languages and Character Sets</a>.</p><p>This document provides the authoritative and complete statement of the requirements and usage of the TEI encoding scheme. As such, although it includes numerous small examples, it must be stressed that this work is intended to be a reference manual rather than a tutorial guide. </p><p>The remainder of this chapter comprises three sections. The first gives an overview of the structure and notational conventions used throughout these Guidelines. The second enumerates the design principles underlying the TEI scheme and the application environments in which it may be found useful. Finally, the third section gives a brief account of the origins and development of the Text Encoding Initiative itself.</p><div class="div2" id="ABSTRUNC"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABTEI"><span class="headingNumber">iv.2. </span>Historical Background</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h3><span class="bookmarklink"><a class="bookmarklink" href="#ABSTRUNC" title="link to this section "><span class="invisible">TEI: Structure and Notational
Conventions of this Document</span><span class="pilcrow">¶</span></a></span><span class="headingNumber">iv.1. </span><span class="head">Structure and Notational Conventions of this Document</span></h3><p>The remaining two sections of the front matter to these Guidelines provide background tutorial material for those unfamiliar with basic markup technologies. Following the present introductory section, we present a detailed introduction to XML itself, intended to cover in a relatively painless manner as much as the novice user of the TEI scheme needs to know about markup languages in general and XML in particular. This is followed by a discussion of the general principles underlying current practice in the representation of different languages and writing systems in digital form. This chapter is largely intended for the user unfamiliar with the Unicode encoding systems, though the expert may also find its historical overview of interest.</p><p>The body of this edition of these Guidelines proper contains 23 chapters arranged in increasing order of specialist interest. The first five chapters discuss in depth matters likely to be of importance to anyone intending to apply the TEI scheme to virtually any kind of text. The next seven focus on particular kinds of text: verse, drama, spoken text, dictionaries, and manuscript materials. The next nine chapters deal with a wide range of topics, one or more of which are likely to be of interest in specialist applications of various kinds. The last two chapters deal with the XML encoding used to represent the TEI scheme itself, and provide technical information about its implementation. The last chapter also defines the notion of TEI conformance and its implications for interchange of materials produced according to these Guidelines.</p><p>As noted above, this is a reference work, and is not intended to be read through from beginning to end. However, the reader wishing to understand the full potential of the TEI scheme will need a thorough grasp of the material covered by the first four chapters and the last two. Beyond that, the reader is recommended to select according to their specific interests: one of the strengths of the TEI architecture is its modular nature. </p><p>As far as possible, extensive cross referencing is provided wherever related topics are dealt with; these are particularly effective in the online version of these Guidelines. In addition, a series of technical appendixes provide detailed formal definitions for every element, every class, and every macro discussed in the body of the work; these are also cross linked as appropriate. Finally, a detailed bibliography is provided, which identifies the source of many examples cited in the text as well as documenting works referred to, and listing other relevant publications.</p><p>As an aid to the reader, most chapters of these Guidelines follow the same basic organization. The chapter begins with an overview of the subjects treated within it, linked to the following subsections. Within each section where new elements are described, a summary table is first given, which provides their names and a brief description of their intended usage. This is then followed where appropriate by further discussion of each element, including wherever possible usage examples taken somewhat eclectically from a variety of real sources. These examples are not intended to be exhaustive, but rather to suggest typical ways in which the elements concerned may usefully be applied. Where appropriate, a link to a statement of the source for most examples is provided in the online version. Within the examples, use of whitespace such as newlines or indentation is simply intended to aid legibility, and is not prescriptive or normative. </p><p>Wherever TEI elements or classes are mentioned in the text, they are linked in the online version to the relevant reference specification for the element or class concerned. Element names are always given in the form <a class="gi" title="(name, proper noun) contains a proper noun or noun phrase." href="ref-name.html">name</a>, where <span class="q">‘name’</span> is the <span class="term">generic identifier</span> of the element; empty elements such as <a class="gi" title="(page break) marks the start of a new page in a paginated document." href="ref-pb.html">pb</a> or <a class="gi" title="(anchor point) attaches an identifier to a point within a text, whether or not it corresponds with a textual element." href="ref-anchor.html">anchor</a> include a closing slash to distinguish them wherever they are discussed. References to attributes take the form <span class="att">attname</span>, where <span class="q">‘attname’</span> is the name of the attribute. References to classes are also presented as links, for example <a class="link_odd" title="groups elements used to represent un-numbered generic structural divisions." href="ref-model.divLike.html">model.divLike</a> for a model class, and <a class="link_odd" title="provides attributes common to all elements in the TEI encoding scheme." href="ref-att.global.html">att.global</a> for an attribute class.</p><div class="teidiv2" id="AB-namecon"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#index-front.1_div.4_div.1_div.2"><span class="headingNumber"></span>Class, Macro, and Datatype Names</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h4><span class="bookmarklink"><a class="bookmarklink" href="#AB-namecon" title="link to this section "><span class="invisible">TEI: TEI Naming Conventions</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">TEI Naming Conventions</span></h4><p>These Guidelines use a more or less consistent set of conventions in the naming of XML elements and classes. This section summarizes those conventions.</p><div class="teidiv3" id="index-front.1_div.4_div.1_div.1_div.1"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"></li><li class="subtoc"></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h5><span class="bookmarklink"><a class="bookmarklink" href="#index-front.1_div.4_div.1_div.1_div.1" title="link to this section "><span class="invisible">TEI: Element and Attribute Names</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Element and Attribute Names</span></h5><p>An unadorned name such as <span class="q">‘blort’</span> is the name of a TEI element or attribute. <span id="Note3_return"><a class="notelink" title="During generation of TEI RELAX NG schema fragments, the patterns corresponding with these TEI names are given a prefix tei to allow them to co-exist w…" href="#Note3"><sup>1</sup></a></span>.</p><p>The following conventions apply to the choice of names: </p><ul><li class="item">Elements are given generic identifiers as far as possible consisting of one or more <span class="term">tokens</span>, by which we mean whole words or recognisable abbreviations of them, taken from the English language.</li><li class="item">Where an element name contains more than one token, the first letter of the second token, and of any subsequent ones, is capitalized, as in for example <a class="gi" title="(structured bibliographic citation) contains a structured bibliographic citation, in which only bibliographic sub-elements appear and in a specified order." href="ref-biblStruct.html">biblStruct</a>, <a class="gi" title="(list of persons) contains a list of descriptions, each of which provides information about an identifiable person or a group of people, for example the participants in a language interaction, or the people referred to in a historical source." href="ref-listPerson.html">listPerson</a>. This ‘camelCasing’ is used also for attribute names and symbolic values.</li><li class="item">Module names also use whole words, for the most part, but are always all lower case. </li><li class="item">The specification for an element or attribute whose name contains abbreviations generally also includes a <a class="gi" title="identifies a phrase or word used to provide a gloss or definition for some other word or phrase." href="ref-gloss.html">gloss</a> element providing the expanded sense of the name.</li><li class="item">An element specification may also contain approved translations for element or attribute names in one or more other languages using the <a class="gi" title="(alternate identifier) supplies the recommended XML name for an element, class, attribute, etc. in some language." href="ref-altIdent.html">altIdent</a> element; this is not however generally done in TEI P5.</li></ul><p>Whole words are generally preferred for clarity. The following abbreviations are however commonly used within generic identifiers: </p><dl><dt><span>att</span></dt><dd>attribute</dd><dt><span>bibl</span></dt><dd>bibliographic description or reference in a bibliography</dd><dt><span>cat</span></dt><dd>category, especially as used in text classification </dd><dt><span>char</span></dt><dd>character, typically a Unicode character</dd><dt><span>doc</span></dt><dd>document: this usually refers to the original source document which is being encoded,</dd><dt><span>decl</span></dt><dd>declaration: has a specific sense in the TEI Header, as discussed in <a class="link_ptr" href="HD.html#HD12" title="Types of Content in the TEI Header"><span class="headingNumber">2.1.2 </span>Types of Content in the TEI Header</a></dd><dt><span>desc</span></dt><dd>description: has a specific sense in the TEI header, as discussed in <a class="link_ptr" href="HD.html#HD12" title="Types of Content in the TEI Header"><span class="headingNumber">2.1.2 </span>Types of Content in the TEI Header</a></dd><dt><span>grp</span></dt><dd>group. In TEI usage, a group is distinguished from a list in that the former associates several objects which act as a single entity, while the latter does not. For example, a <a class="gi" title="(link group) defines a collection of associations or hypertextual links." href="ref-linkGrp.html">linkGrp</a> combines several <a class="gi" title="defines an association or hypertextual link among elements or passages, of some type not more precisely specifiable by other elements." href="ref-link.html">link</a> elements which have certain properties in common, whereas a <a class="gi" title="(citation list) contains a list of bibliographic citations of any kind." href="ref-listBibl.html">listBibl</a> simply lists a number of otherwise unrelated <a class="gi" title="(bibliographic citation) contains a loosely-structured bibliographic citation of which the sub-components may or may not be explicitly tagged." href="ref-bibl.html">bibl</a> elements.</dd><dt><span>interp</span></dt><dd>interpretation or analysis</dd><dt><span>lang</span></dt><dd>(natural) language</dd><dt><span>ms</span></dt><dd>manuscript</dd><dt><span>org</span></dt><dd>organization, that is, a named group of people or legal entity</dd><dt><span>rdg</span></dt><dd>reading or version found in a specific witness</dd><dt><span>ref</span></dt><dd>reference or link</dd><dt><span>spec</span></dt><dd>technical specification or definition</dd><dt><span>stmt</span></dt><dd>statement: used in a specific sense in the TEI header, as discussed in <a class="link_ptr" href="HD.html#HD12" title="Types of Content in the TEI Header"><span class="headingNumber">2.1.2 </span>Types of Content in the TEI Header</a></dd><dt><span>struct</span></dt><dd>structured: that is, containing a specific set of named elements rather than ‘mixed content’</dd><dt><span>val</span></dt><dd>value, for example of a variable or an attribute</dd><dt><span>wit</span></dt><dd>witness: that is, a specific document which attests specific readings in a textual tradition or apparatus</dd></dl><p>Some abbreviations are used inconsistently: for example, <a class="gi" title="(addition) contains letters, words, or phrases inserted in the source text by an author, scribe, or a previous annotator or corrector." href="ref-add.html">add</a> is an addition, and <a class="gi" title="(added span of text) marks the beginning of a longer sequence of text added by an author, scribe, annotator or corrector (see also <add>)." href="ref-addSpan.html">addSpan</a> is a spanning addition, but <a class="gi" title="(additional name) contains an additional name component, such as a nickname, epithet, or alias, or any other descriptive phrase used within a personal name." href="ref-addName.html">addName</a> is an additional name, not the name of an addition. Such inconsistencies are relatively few in number, and it is hoped to remove them in subsequent revisions of these Guidelines.</p><p>Some elements have very short abbreviated names: these are for the most part elements which are likely to be used very frequently in a marked up text, for example <a class="gi" title="(paragraph) marks paragraphs in prose." href="ref-p.html">p</a> (paragraph), <a class="gi" title="(s-unit) contains a sentence-like division of a text." href="ref-s.html">s</a> (segment) <a class="gi" title="(highlighted) marks a word or phrase as graphically distinct from the surrounding text, for reasons concerning which no claim is made." href="ref-hi.html">hi</a> (highlighted phrase), <a class="gi" title="(pointer) defines a pointer to another location." href="ref-ptr.html">ptr</a> (pointer), <a class="gi" title="(text division) contains a subdivision of the front, body, or back of a text." href="ref-div.html">div</a> (division) etc. We do not specifically list such elements here: as noted above, an expansion of each such abbreviated name is provided within the documentation using the <a class="gi" title="identifies a phrase or word used to provide a gloss or definition for some other word or phrase." href="ref-gloss.html">gloss</a> element .</p></div></div><div class="teidiv2" id="index-front.1_div.4_div.1_div.2"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#AB-namecon"><span class="headingNumber"></span>TEI Naming Conventions</a></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABTEI2"><span class="headingNumber"></span>Design Principles</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h4><span class="bookmarklink"><a class="bookmarklink" href="#index-front.1_div.4_div.1_div.2" title="link to this section "><span class="invisible">TEI: Class, Macro, and Datatype Names</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Class, Macro, and Datatype Names</span></h4><p>All named objects other than elements and attributes have one of the following prefixes, which indicate whether the object is a module, an attribute class, a model class, a datatype, or a macro: </p><div class="table"><table><thead><tr class="label"><th>Component</th><th>Name</th><th>Example</th></tr></thead><tbody><tr><td>Attribute Classes</td><td>att.*</td><td>att.global</td></tr><tr><td>Model Classes</td><td>model.*</td><td>model.biblPart</td></tr><tr><td>Macros</td><td>macro.*</td><td>macro.paraContent</td></tr><tr><td>Datatypes</td><td>data.*</td><td>data.pointer</td></tr></tbody></table></div><p>The concepts of model class, attribute class, etc. are defined in <a class="link_ptr" href="ST.html" title="3"><span class="headingNumber">1 </span>The TEI Infrastructure</a>. Here we simply note some conventions about their naming.</p><p>The following rules apply to attribute class names: </p><ul><li class="item">Attribute class names take the form <code>att.xxx</code>, where <code>xxx</code> is typically an adjective, or a series of adjectives separated by dots, describing a property common to the attributes which make up the class.</li><li class="item">Attributes with the same name are considered to have the same semantics, whether the attribute is inherited from a class, or locally defined.</li></ul><p>The following rules apply to model class names: </p><ul><li class="item">Model classes have names beginning <code>model.</code> followed by a <span class="term">root name</span>, and zero or more suffixes as described below.</li><li class="item">A root name may be the name of an element, generally the prototypical parent or sibling for elements which are members of the class.</li><li class="item">The first suffix should be <code>Part</code>, if the class members are all children of the element named rootname; or <code>Like</code>, if the class members are all siblings of the element named <code>rootname</code>.</li><li class="item">The rootname <code>global</code> is used to indicate that class members are permitted anywhere in a TEI document.</li><li class="item">Additional suffixes may be added, prefixed by a dot, to distinguish subclasses, semantic or structural.</li></ul><p>For example, the class of elements which can form part of a <a class="gi" title="(text division) contains a subdivision of the front, body, or back of a text." href="ref-div.html">div</a> is called <a class="link_odd" title="groups paragraph-level elements appearing directly within divisions." href="ref-model.divPart.html">model.divPart</a>. This class includes as a subclass the elements which can form part of a <a class="gi" title="(text division) contains a subdivision of the front, body, or back of a text." href="ref-div.html">div</a> in a spoken text, which is named <a class="link_odd" title="groups elements structurally analogous to paragraphs within spoken texts." href="ref-model.divPart.spoken.html">model.divPart.spoken</a></p></div><div class="div3" id="ABTEI2"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#index-front.1_div.4_div.1_div.2"><span class="headingNumber"></span>Class, Macro, and Datatype Names</a></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABAPP"><span class="headingNumber"></span>Intended Use</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h4><span class="bookmarklink"><a class="bookmarklink" href="#ABTEI2" title="link to this section "><span class="invisible">TEI: Design Principles</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Design Principles</span></h4><p>Because of its roots in the humanities research community, the TEI scheme is driven by its original goal of serving the needs of research, and is therefore committed to providing a maximum of comprehensibility, flexibility, and extensibility. More specific design goals of the TEI have been that these Guidelines should: </p><ul class="simple"><li class="item">provide a standard format for data interchange</li><li class="item">provide guidance for the encoding of texts in this format</li><li class="item">support the encoding of all kinds of features of all kinds of texts studied by researchers</li><li class="item">be application independent</li></ul><p> This has led to a number of important design decisions, such as: </p><ul class="simple"><li class="item">the choice of XML and Unicode</li><li class="item">the provision of a large predefined tag set</li><li class="item">encodings for different views of text</li><li class="item">alternative encodings for the same textual features</li><li class="item">mechanisms for user-defined modification of the scheme</li></ul><p> We discuss some of these goals in more detail below.</p><p>The goal of creating a common interchange format which is application independent requires the definition of a specific markup syntax as well as the definition of a large set of elements or concepts. The syntax of the recommendations made in this document conforms to the World Wide Web Consortium's XML Recommendation (<a class="link_ptr" href="BIB.html#XMLREC" title="Tim Bray Jean Paoli C. M. SperbergMcQueen Eve Maler François Yergau Extensible Markup Language (XML) Version 1.0 (Fourth editio...">Bray et al. (eds.) (2006)</a>) but their definition is as far as possible independent of any particular schema language.</p><p>The goal of providing guidance for text encoding suggests that recommendations be made as to what textual features should be recorded in various situations. However, when selecting certain features for encoding in preference to others, these Guidelines have tended to prefer generic solutions to specific ones, and to avoid areas where no consensus exists, while attempting to accommodate as many diverse views as feasible. Consequently, the TEI Guidelines make (with relatively rare exceptions) no suggestions or restrictions as to the relative importance of textual features. The philosophy of these Guidelines is <span class="q">‘if you want to encode this feature, do it this way’</span>—but very few features are mandatory. In the same spirit, while these Guidelines very rarely require you to encode any particular feature, they do require you to be honest about which features you have encoded, that is, to respect the meanings and usage rules they recommend for specific elements and attributes proposed.</p><p>The requirement to support all kinds of materials likely to be of interest in research has largely conditioned the development of the TEI into a very flexible and modular system. The development of other XML vocabularies or standards is typically motivated by the desire to create a single fully specified encoding scheme for use in a well-defined application domain. By contrast, the TEI is intended for use in a large number of rather ill-defined and often overlapping domains. It achieves its generality by means of the modular architecture described in <a class="link_ptr" href="ST.html" title="3"><span class="headingNumber">1 </span>The TEI Infrastructure</a> which enables each user to create a schema appropriate to their needs without compromising the interoperability of their data.</p><p>The Guidelines have been written largely with a focus on text capture (i.e. the representation in electronic form of an already existing copy text in another medium) rather than text creation (where no such copy text exists). Hence the frequent use of terms like ‘transcription’, ‘original’, ‘copy text’, etc. However, these Guidelines are equally applicable to text creation, although certain elements, such as <a class="gi" title="(source description) describes the source from which an electronic text was derived or generated, typically a bibliographic description in the case of a digitized text, or a phrase such as "born digital" for a text which has no previous existence." href="ref-sourceDesc.html">sourceDesc</a>, and certain attributes, such as <a class="link_ref" href="ST.html#STGAre" title="Rendition Indicators">the rendition indicators</a>, will not be relevant in this case.</p><p>Concerning text capture the TEI Guidelines do not specify a particular approach to the problem of fidelity to the source text and recoverability of the original; such a choice is the responsibility of the text encoder. The current version of these Guidelines, however, provides a more fully elaborated set of tags for markup of rhetorical, linguistic, and simple typographic characteristics of the text than for detailed markup of page layout or for fine distinctions among type fonts or manuscript hands. It should be noted also that, with the present version of these Guidelines, it is no longer necessarily the case that an unmediated version of the source text can be recovered from an encoded text simply by removing the markup. </p><p>In these Guidelines, no hard and fast distinction is drawn between ‘objective’ and ‘subjective’ information or between ‘representation’ and ‘interpretation’. These distinctions, though widely made and often useful in narrow, well-defined contexts, are perhaps best interpreted as distinctions between issues on which there is a scholarly consensus and issues where no such consensus exists. Such consensus has been, and no doubt will be, subject to change. The TEI Guidelines do not make suggestions or restrictions as to which of these features should be encoded. The use of the terms <span class="term">descriptive</span> and <span class="term">interpretive</span> about different types of encoding in these Guidelines is not intended to support any particular view on these theoretical issues. Historically, it reflects a purely practical division of responsibility amongst the original working committees (see further <a class="link_ptr" href="AB.html#ABTEI" title="Historical Background"><span class="headingNumber">iv.2. </span>Historical Background</a>).</p><p>In general, the accuracy and the reliability of the encoding and the appropriateness of the interpretation is for the individual user of the text to determine. The Guidelines provide a means of documenting the encoding in such a way that a user of the text can know the reasoning behind that encoding, and the general interpretive decisions on which it is based. The TEI header may be used to document and justify many such aspects of the encoding, but the choice of TEI elements for a particular feature is in itself a statement about the interpretation reached by the encoder.</p><p>In many situations more than one view of a text is needed since no absolute recommendation to embody one specific view of text can apply to all texts and all approaches to them. Within limits, the syntax of XML ensures that some encodings can be ignored for some purposes. To enable encoding multiple views, these Guidelines not only treat a variety of textual features, but sometimes provide several alternative encodings for what appear to be identical textual phenomena. These Guidelines offer the possibility of encoding many different views of the text, simultaneously if necessary. Where different views of the formal structure of a text are required, as opposed to different annotations on a single structural view, however, the formal syntax of XML (which requires a single hierarchical view of text structure) poses some problems; recommendations concerning ways of overcoming or circumventing that restriction are discussed in chapter <a class="link_ptr" href="NH.html" title="31"><span class="headingNumber">20 </span>Non-hierarchical Structures</a>.</p><p>In brief, the TEI Guidelines define a general-purpose encoding scheme which makes it possible to encode different views of text, possibly intended for different applications, serving the majority of scholarly purposes of text studies in the humanities. Because no predefined encoding scheme can possibly serve all research purposes, the TEI scheme is designed to facilitate both selection from a wide range of predefined markup choices, and the addition of new (non-TEI) markup options. By providing a formally verifiable means of extending the TEI recommendations, the TEI makes it simple for such user-identified modifications to be incorporated into future releases of these Guidelines as they evolve. The underlying mechanisms which support these aspects of the scheme are introduced in chapter <a class="link_ptr" href="ST.html" title="3"><span class="headingNumber">1 </span>The TEI Infrastructure</a>, and detailed discussions of their use provided in chapter <a class="link_ptr" href="USE.html" title="Using the TEI"><span class="headingNumber">23 </span>Using the TEI</a>.</p></div><div class="div3" id="ABAPP"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#ABTEI2"><span class="headingNumber"></span>Design Principles</a></li><li class="subtoc"></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h4><span class="bookmarklink"><a class="bookmarklink" href="#ABAPP" title="link to this section "><span class="invisible">TEI: Intended Use</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Intended Use</span></h4><p>We envisage three primary functions for these Guidelines: </p><ul class="simple"><li class="item">guidance for individual or local practice in text creation and data capture;</li><li class="item">support of data interchange;</li><li class="item">support of application-independent local processing.</li></ul><p> These three functions are so thoroughly interwoven in practice that it is hardly possible to address any one without addressing the others. However, the distinction provides a useful framework for discussing the possible role of these Guidelines in work with electronic texts.</p><div class="div4" id="ABAPP1"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABAPP2"><span class="headingNumber"></span>Use for Interchange</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h5><span class="bookmarklink"><a class="bookmarklink" href="#ABAPP1" title="link to this section "><span class="invisible">TEI: Use in Text Capture and Text Creation</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Use in Text Capture and Text Creation</span></h5><p>The description of textual features found in the chapters which follow should provide a useful checklist from which scholars planning to create electronic texts should select the subset of features suitable for their project. </p><p>Problems specific to text creation or text ‘capture’ have not been considered explicitly in this document. These Guidelines are not concerned with the process by which a digital text comes into being: it can be typed by hand, scanned from a printed book or typescript, read from a typesetter's tape, or acquired from another researcher who may have used another markup scheme (or no explicit markup at all).</p><p>We include here only some general points which are often raised about markup and the process of data capture.</p><p>XML can appear distressingly verbose, particularly when (as in these Guidelines) the names of tags and attributes are chosen for clarity and not for brevity. Editor macros and keyboard shortcuts can allow a typist to enter frequently used tags with single keystrokes. It is often possible to transform word-processed or scanned text automatically. Markup-aware software can help with maintaining the hierarchical structure of the document, and display the document with visual formatting rather than raw tags.</p><p>The techniques described in chapter <a class="link_ptr" href="USE.html#MD" title="Customization"><span class="headingNumber">23.3 </span>Customization</a> may be used to develop simpler data capture TEI-conformant schemas, for example with limited numbers of elements, or with shorter names for the tags being used most often. Documents created with such schemas may then be automatically converted to a more elaborated TEI form.</p></div><div class="div4" id="ABAPP2"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#ABAPP1"><span class="headingNumber"></span>Use in Text Capture and Text Creation</a></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABAPP3"><span class="headingNumber"></span>Use for Local Processing</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h5><span class="bookmarklink"><a class="bookmarklink" href="#ABAPP2" title="link to this section "><span class="invisible">TEI: Use for Interchange</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Use for Interchange</span></h5><p>The TEI format may simply be used as an interchange format, permitting projects to share resources even when their local encoding schemes differ. If there are n different encoding formats, to provide mappings between each possible pair of formats requires n×(n-1) translations; with an interchange format, only 2×n such mappings are needed. However, for such translations to be carried out without loss of information, the interchange format chosen must be as expressive (in a formal sense) as any of the target formats; this is a further reason for the TEI's provision of both highly abstract or generic encodings and highly specific ones.</p><p>To translate between any pair of encoding schemes implies: </p><ol class="ordered"><li class="item">identifying the sets of textual features distinguished by the two schemes;</li><li class="item">determining where the two sets of features correspond;</li><li class="item">creating a suitable set of mappings.</li></ol><p>For example, to translate from encoding scheme X into the TEI scheme: </p><ol class="ordered"><li class="item">Make a list of all the textual features distinguished in X. </li><li class="item">Identify the corresponding feature in the TEI scheme. There are three possibilities for each feature: <ol class="ordered"><li class="item">the feature exists in both X and the TEI scheme;</li><li class="item">X has a feature which is absent from the TEI scheme;</li><li class="item">X has a feature which corresponds with more than one feature in the TEI scheme.</li></ol> The first case is a trivial renaming. The second will require an extension to the TEI scheme, as described in chapter <a class="link_ptr" href="USE.html#MD" title="Customization"><span class="headingNumber">23.3 </span>Customization</a>. The third is more problematic, but not impossible, provided that a consistent choice can be made (and documented) amongst the alternatives.</li></ol><p>The ease with which this translation can be defined will of course depend on the clarity with which scheme X represents the features it encodes.</p><p>Translating from the TEI into scheme X follows the same pattern, except that if a TEI feature has no equivalent in X, and X cannot be extended, information must be lost in translation.</p><p>The rules defining conformance to these Guidelines are given in some detail in chapter <a class="link_ptr" href="USE.html#CF" title="Conformance"><span class="headingNumber">23.4 </span>Conformance</a>. The basic principles informing those rules may be summarized as follows: </p><ol class="ordered"><li class="item">The TEI <span class="term">abstract model</span> (that is, the set of categorical distinctions which it defines) must be respected. The correspondence between a tag X and the semantic function assigned to it by these Guidelines may not be changed; such changes are known as <span class="term">tag abuse</span> and strongly deprecated.</li><li class="item">A TEI document must be expressed as a valid XML-conformant document which uses the TEI namespace appropriately. If, for example, the document encodes features not provided by these Guidelines, such extensions may not be associated with the TEI namespace. </li><li class="item">It must be possible to validate a TEI document against a schema derived from these Guidelines, possibly with extensions provided in the recommended manner.</li></ol></div><div class="div4" id="ABAPP3"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#ABAPP2"><span class="headingNumber"></span>Use for Interchange</a></li><li class="subtoc"></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h5><span class="bookmarklink"><a class="bookmarklink" href="#ABAPP3" title="link to this section "><span class="invisible">TEI: Use for Local Processing</span><span class="pilcrow">¶</span></a></span><span class="headingNumber"></span><span class="head">Use for Local Processing</span></h5><p>Machine-readable text can be manipulated in many ways; some users: </p><ul class="simple"><li class="item">edit texts (e.g. word processors, syntax-directed editors) </li><li class="item">edit, display, and link texts in hypertext systems</li><li class="item">format and print texts using desktop publishing systems, or batch-oriented formatting programs </li><li class="item">load texts into free-text retrieval databases or conventional databases </li><li class="item">unload texts from databases as search results or for export to other software </li><li class="item">search texts for words or phrases </li><li class="item">perform content analysis on texts </li><li class="item">collate texts for critical editions </li><li class="item">scan texts for automatic indexing or similar purposes</li><li class="item">parse texts linguistically </li><li class="item">analyze texts stylistically </li><li class="item">scan verse texts metrically </li><li class="item">link text and images </li></ul><p>These applications cover a wide range of likely uses but are by no means exhaustive. The aim has been to make the TEI Guidelines useful for encoding the same texts for different purposes. We have avoided anything which would restrict the use of the text for other applications. We have also tried not to omit anything essential to any single application.</p><p>Because the TEI format is expressed using XML, almost any modern text processing system is able to process it, and new TEI-aware software systems are able to build on a solid base of existing software libraries. </p></div></div></div><div class="div2" id="ABTEI"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#ABSTRUNC"><span class="headingNumber">iv.1. </span>Structure and Notational Conventions of this Document</a></li><li class="subtoc"><span class="nextLink"> » </span><a class="navigation" href="AB.html#ABTEI4"><span class="headingNumber">iv.3. </span>Future Developments and Version Numbers</a></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h3><span class="bookmarklink"><a class="bookmarklink" href="#ABTEI" title="link to this section "><span class="invisible">TEI: Historical Background</span><span class="pilcrow">¶</span></a></span><span class="headingNumber">iv.2. </span><span class="head">Historical Background</span></h3><p>The Text Encoding Initiative grew out of a planning conference sponsored by the Association for Computers and the Humanities (ACH) and funded by the U.S. National Endowment for the Humanities (NEH), which was held at Vassar College in November 1987. At this conference some thirty representatives of text archives, scholarly societies, and research projects met to discuss the feasibility of a standard encoding scheme and to make recommendations for its scope, structure, content, and drafting. During the conference, the Association for Computational Linguistics and the Association for Literary and Linguistic Computing agreed to join ACH as sponsors of a project to develop these Guidelines. The outcome of the conference was a set of principles (the ‘Poughkeepsie Principles’, <a class="link_ptr" href="BIB.html#AB-eg-01" title="Lou Burnard Report of Workshop on Text Encoding GuidelinesLiterary Linguistic Computing31988">Burnard (1988)</a>), which determined the further course of the project.</p><p>The Text Encoding Initiative project began in June 1988 with funding from the NEH, soon followed by further funding from the Commission of the European Communities, the Andrew W. Mellon Foundation, and the Social Science and Humanities Research Council of Canada. Four working committees, composed of distinguished scholars and researchers from both Europe and North America, were named to deal with problems of text documentation, text representation, text analysis and interpretation, and metalanguage and syntax issues. Each committee was charged with the task of identifying ‘significant particularities’ in a range of texts, and two editors appointed to harmonize the resulting recommendations.</p><p>A first draft version (P1, with the <span class="q">‘P’</span> here and subsequently standing for <span class="q">‘Proposal’</span>) of the Guidelines was distributed in July 1990 under the title <span class="titlem">Guidelines for the Encoding and Interchange of Machine-Readable Texts</span>. Extensive public comment and further work on areas not covered in this version resulted in the drafting of a revised version, TEI P2, distribution of which began in April 1992. This version included substantial amounts of new material, resulting from work carried out by several specialist working groups, set up in 1990 and 1991 to propose extensions and revisions to the text of P1. The overall organization, both of the draft itself and of the scheme it describes, was entirely revised and reorganized in response to public comment on the first draft.</p><p>In June 1993 an Advisory Board met to review the current state of the TEI Guidelines, and recommended the formal publication of the work done to that time. That version of the TEI Guidelines, TEI P3, consolidated the work published as parts of TEI P2, along with some additional new material and was finally published in May of 1994 without the label <span class="mentioned">draft</span>, thus marking the conclusion of the initial development work.</p><p>In February of 1998 the World Wide Web Consortium issued a final Recommendation for the Extensible Markup Language, XML.<span id="Note4_return"><a class="notelink" title="XML was originally developed as a way of publishing on the World Wide Web richly encoded documents such as those for which the TEI was designed. Sever…" href="#Note4"><sup>2</sup></a></span> Following the rapid take-up of this new standard metalanguage, it became evident that the TEI Guidelines (which had been published originally as an SGML application) needed to be re-expressed in this new formalism if they were to survive. The TEI editors, with abundant assistance from others who had developed and used TEI, developed an update plan, and made tentative decisions on relevant syntactic issues.</p><p>In January of 1999, the University of Virginia and the University of Bergen formally proposed the creation of an international membership organization, to be known as the TEI Consortium, which would maintain, develop, and promote the TEI. Shortly thereafter, two further institutions with longstanding ties to the TEI (Brown University and Oxford University) joined them in formulating an Agreement to Establish a Consortium for the Maintenance of the Text Encoding Initiative (<a class="link_ptr" href="BIB.html#AB-eg-02" title="An Agreement to Establish a Consortium for the Maintenance of the Text Encoding InitiativeMarch 1999">An Agreement to Establish a Consortium for the Maintenance of the Text Encoding Initiative (March 1999)</a>), on which basis the TEI Consortium was eventually established and incorporated as a not-for-profit legal entity at the end of the year 2000. The first members of the new TEI Board took office during January of 2001.</p><p>The TEI Consortium was established in order to maintain a permanent home for the TEI as a democratically constituted, academically and economically independent, self-sustaining, non-profit organization. In addition, the TEI Consortium was intended to foster a broad-based user community with sustained involvement in the future development and widespread use of the TEI Guidelines (<a class="link_ptr" href="BIB.html#AB-eg-03" title="Lou Burnard Text Encoding for Interchange A New Consortium2000">Burnard (2000)</a>).</p><p>To oversee and manage the revision process in collaboration with the TEI Editors, the TEI Board formed a Technical Council, with a membership elected from the TEI user community. The Council met for the first time in January 2002 at King's College London. Its first task was to oversee production of an XML version of the TEI Guidelines, updating P3 to enable users to work with the emerging XML toolset. This, the P4 version of the Guidelines, was published in June 2002. It was essentially an XML version of P3, making no substantive changes to the constraints expressed in the schemas apart from those necessitated by the shift to XML, and changing only corrigible errors identified in the prose of the P3 Guidelines. However, given that P3 had by this time been in steady use since 1994, it was clear that a substantial revision of its content was necessary, and work began immediately on the P5 version of the Guidelines. This was planned as a thorough overhaul, involving a public call for features and new development in a number of important areas not previously addressed including character encoding, graphics, manuscript description, biographical and geographical data, and the encoding language in which the TEI Guidelines themselves are written. </p><p>The members of the TEI Council and its associated workgroups are listed in <a class="link_ptr" href="FM1.html" title="Preface and Acknowledgments"><span class="headingNumber">iii. </span>Preface and Acknowledgments</a>. In preparing this edition, they have been attentive to the requirements and practice of the widest possible range of TEI users, who are now to be found in many different research communities across the world, and have been largely instrumental in transforming the TEI from a grant-supported international research project into a self-sustaining community-based effort. One effect of the incorporation of the TEI has been the legal requirement to hold an annual meeting of the Consortium members; these meetings have emerged as an invaluable opportunity to sustain and reinforce that sense of community.</p><p>The present work is therefore the result of a sustained period of consultation, drafting, and revision, with input from many different experts. Whatever merits it may have are to be attributed to them; the Editors accept responsibility only for the errors remaining. </p></div><div class="div3" id="ABTEI4"><div class="miniTOC miniTOC_right"><ul class="subtoc"><li class="subtoc"><span class="previousLink"> « </span><a class="navigation" href="AB.html#ABTEI"><span class="headingNumber">iv.2. </span>Historical Background</a></li><li class="subtoc"></li><li class="subtoc"><a class="navigation" href="index.html">Home</a></li></ul></div><h3><span class="bookmarklink"><a class="bookmarklink" href="#ABTEI4" title="link to this section "><span class="invisible">TEI: Future Developments and Version Numbers</span><span class="pilcrow">¶</span></a></span><span class="headingNumber">iv.3. </span><span class="head">Future Developments and Version Numbers</span></h3><p>The encoding recommended by this document may be used without fear that future versions of the TEI scheme will be inconsistent with it in fundamental ways. The TEI will be sensitive, in revising these Guidelines, to the possible problems which revision might pose for those who are already using this version of these Guidelines. </p><p>With TEI P5, a version numbering system is introduced following <a class="link_ref" href="http://unicode.org/versions/">the pattern specified by the Unicode Consortium</a>: the first digit identifies a major version number, the second digit a minor version number, and the third digit a sub-minor version number. The TEI undertakes that no change will be made to the formal expression of these Guidelines (that is, a TEI schema, as defined in <a class="link_ptr" href="USE.html#CF" title="Conformance"><span class="headingNumber">23.4 </span>Conformance</a>) such that documents conformant to a given major numbered release cease to be compatible with a subsequent release of the same major number. Moreover, as far as possible, new minor releases will be made only for the purpose of adding new compatible features, or of correcting errors in existing features.</p><p>The Guidelines are currently maintained as an open source project on the Github site <a class="link_ptr" href="https://github.com/TEIC/TEI"><span>https://github.com/TEIC/TEI</span></a>, from which released and development versions may be freely downloaded. See <a class="link_ref" href="http://www.tei-c.org/Guidelines/P5/#previous">Previous Releases of P5</a> for information on how to find specific versions of TEI releases (Guidelines, schemas etc.). Notice of errors detected and enhancements requested may be submitted at <a class="link_ptr" href="https://github.com/TEIC/TEI/issues"><span>https://github.com/TEIC/TEI/issues</span></a>.</p></div></div><nav class="left"><span class="upLink"> ↑ </span><a class="navigation" href="index.html">TEI P5 Guidelines</a><span class="previousLink"> « </span><a class="navigation" href="FM1.html"><span class="headingNumber">iii. </span>Preface and Acknowledgments</a><span class="nextLink"> » </span><a class="navigation" href="SG.html"><span class="headingNumber">v. </span>A Gentle Introduction to XML</a></nav><!--Notes in [div]--><div class="notes"><div class="noteHeading">Notes</div><div class="note" id="Note3"><span class="noteLabel">1 </span><div class="noteBody">During generation of TEI RELAX NG schema fragments, the patterns corresponding with these TEI names are given a prefix <code>tei</code> to allow them to co-exist with names from other XML namespace. This prefix is not visible to the end user, and is not used in TEI documentation. When generating multi-namespace schemas, however, the user needs to be aware of them.</div> <a class="link_return" title="Go back to text" href="#Note3_return">↵</a></div><div class="note" id="Note4"><span class="noteLabel">2 </span><div class="noteBody">XML was originally developed as a way of publishing on the World Wide Web richly encoded documents such as those for which the TEI was designed. Several TEI participants contributed heavily to the development of XML, most notably XML's senior co-editor C. M. Sperberg-McQueen, who served as the North American editor for the TEI Guidelines from their inception until 1999. </div> <a class="link_return" title="Go back to text" href="#Note4_return">↵</a></div></div><div class="stdfooter autogenerated"><p>
[<a href="../../en/html/AB.html">English</a>]
[<a href="../../de/html/AB.html">Deutsch</a>]
[<a href="../../es/html/AB.html">Español</a>]
[<a href="../../it/html/AB.html">Italiano</a>]
[<a href="../../fr/html/AB.html">Français</a>]
[<a href="../../ja/html/AB.html">日本語</a>]
[<a href="../../ko/html/AB.html">한국어</a>]
[<a href="../../zh-TW/html/AB.html">中文</a>]
</p><hr /><div class="footer"><a class="plain" href="http://www.tei-c.org/About/">TEI Consortium</a> | <a class="plain" href="http://www.tei-c.org/About/contact.xml">Feedback</a></div><hr /><address><br />TEI Guidelines <a class="link_ref" href="AB.html#ABTEI4">Version</a> <a class="link_ref" href="../../readme-3.1.1.html">3.1.1a</a>. Last updated on <span class="date">10th May 2017</span>, revision <a class="link_ref" href="https://github.com/TEIC/TEI/commit/bd8dda3">bd8dda3</a>. This page generated on 2017-05-12T12:30:09Z.</address></div></div></body></html>