Text only | Skip links
Skip links||IT Services, University of Oxford

Contents

1. Overall P4 to P5

There have been many changes from TEI P4 to TEI P5, and we can't hope to cover them all now. However, we think it is important to highlight some of the most important of these changes.

1.1. changes P4 to P5

  • Since we can't mention all the changes since TEI P4, we'll look at the main types of things that have changed
  • Conversion will always be a process of trial and error
  • Where possible the TEI has adopted external standards rather than reinvent the wheel
  • A long-term attempt to do things the 'better' way rather than the 'easier' way
  • As always the prose of the TEI P5 Guidelines is the final source for the current recommendations

1.2. Eight new things about P5

  1. One specification language for extensions and documentation
  2. Support for multiple schema languages
  3. Support for namespaces
  4. Reliance on XML, and hence on Unicode
  5. Validation of attributes and datatyping
  6. Use of W3C pointers and paths
  7. Verifiable conformance
  8. Some old annoyances removed and some new topics added

1.3. 1. One Specification Language

  • A set of TEI documents is described by an ODD, which is itself a TEI document that combines:
    • references to existing declarations
    • formal declarations for elements and attributes
    • documentation and usage notes
  • Underlying this:
    • a conceptual model which abstracts from specific elements to generic classes
    • a modular architecture for combining sets of definitions
  • specifications are chainable; modifications are written in ODD with ODD as input and output
  • Roma is one interface to this: there will be others

1.4. 2. Support for many schema languages

  • TEI schemas can be generated for
    • Traditional XML DTD language
    • ISO RELAX NG language
    • W3C Schema Language
  • Content models are defined using RELAX NG syntax
  • Datatypes are defined in terms of W3C datatypes
  • Some facilities (e.g. alternation, namespaces) cannot be expressed in DTD
  • Additional constraints can be expressed in Schematron

1.5. 3. Support for many namespaces

  • A key design goal for P5 was interoperability with other standards
  • By defining — and insisting on — a TEI namespace we facilitate that interoperability
  • Examples: embedding of MathML, SVG, KML, GML...
  • Not to mention: embedding of TEI within Docbook

User-defined extensions must use their own namespace

1.6. For example

Embedding SVG within TEI:
<figure><svg xmlns="http://www.w3.org/2000/svg" width="6cm" height="5cm" viewBox="6 3 6 5">
<ellipse style="fill: #ffffff"
cx="9.75" cy="6.35" rx="2.75" ry="2.35"/>
</svg>
</figure>
A user-defined extension:
<div   xmlns:my="http://www.example.org/ns/nonTEI">
<!-- ... -->
 <p n="12my:topic="rabbits">Flopsy, Mopsy, Cottontail, and
   Peter...</p>
</div>

1.7. 4. Reliance on XML and Unicode

  • Getting rid of &squiggle; in favour of the actual character (or the unicode reference &#xxxx;) is highly recommended
  • If you really need to use non-Unicode characters...
    • wherever text is possible as content, <g> can be used, either as a pointer, or to hold any convenient representation
    • nonstandard characters and glyphs can now be defined in the header
  • we now use xml:lang (just as we now use xml:id and xml:base)

1.8. 5. Validation of attributes and datatyping

Attribute values at P5 cannot contain markup. Consequently, the <choice> element replaces ‘mirror’ tags
<reg orig="yeere">year</reg>
becomes
<choice>
 <reg>year</reg>
 <orig>yeere</orig>
</choice>
Text-like attributes become child elements:
<event desc="transcriber dozes off"/>
becomes
<incident>
 <desc xml:lang="en">transcriber dozes off</desc>
 <desc xml:lang="fr">transcripteur s'endort</desc>
</incident>

1.9. Datatype validation

At P4, attribute values were ID, IDREF, enumerated list, or CDATA (only)

At P5, we introduce greater precision and variety, relying on more sophisticated schema processors able to check
  • validity of dates (ISO or W3C)
  • URIs
  • predefined ISO standards e.g. for sex and language
  • data facets and patterns
  • Schematron rules

1.10. 6. Support for W3C pointer mechanisms

  • P4 vs P5
    • P4 had two different ways of linking:
      • internal: <ptr>: using ID/IDREF
      • external: <xptr>: using TEI-specific syntax
    • In P5, all pointing is done in the same way, using URIs
    • A URI may be absolute …
      <ptr
        target="http://www.tei-c.org/P5/Guidelines/SA.html"/>
    • … or relative
      <list>
       <item>
        <ref target="details/dogs.xml">Dogs</ref>
       </item>
       <item>
        <ref target="details/cats.xml">Cats</ref>
       </item>
      </list>
    • … or local identifiers can still be used
      <sp who="#Macbeth">
       <speaker>Mac.</speaker> ...
      </sp>
    • In addition, you can qualify a URI using an XPointer framework scheme such as xpath()

1.11. 7. Verifiable conformance

  • What might it mean to say that a document is ‘TEI conformant’?
    • conformance to the TEI abstract model
    • appropriate use of TEI namespace
    • appropriate use of a TEI ODD
    • ‘clean’ modifications only
    • compiled schemas not DTD subsets - a different way of thinking

Standardization does not mean ‘Do what I do’, but ‘Explain what you do’

1.12. 8: Other novelties at P5

P5 includes significant new material:
  • manuscript description
  • manuscript transcription
  • data about persons and places
  • floating and overlapping texts
  • integration of text and graphics
  • markup documentation
  • internationalization features

2. Converting from P4 to P5

There is no magic solution when converting from TEI P4 to P5. If you used plain vanilla TEI, then chances of pure mechanical conversion are better, but not assured! Most of the problems are because of attribute value datatypes whereas P4 just allowed text values.

2.1. Methods of converting

  • http://www.tei-c.org/P5/p4top5.xsl
  • http://www.tei-c.org.uk/wiki/index.php/Category:P4toP5
  • Roll your own
  • As with all data migration, small pipelined steps you can customize are generally a good idea
  • None of the available conversion methods, so far, is able to process earlier extension files (while ODD files are better documentation)
  • In highly extended schemas, consider reducing to standard TEI P4 before converting to P5

2.2. Some other conversion reminders

  • @id is now @xml:id (except when parent::lang) and @lang is @xml:lang
  • TEI.2 is TEI | teiCorpus.2 is teiCorpus
  • ODD means no need for @TEIform
  • Janus tags (corr/sic|abbr/expan, etc.) are inside <choice>
  • Most @url are now @target
  • @xptr/@xref are @ptr/@ref and uses xpointer schemes
  • date/@value and similar are @when (and W3C)
  • descriptive text attribute values are now child elements
  • lots of URI based pointers, start attribute value with '#'
  • everything has a namespace, and lots of values have datatypes

3. Names

In TEI P5 there are new ways to link names of people/places/organizations with information about the things themselves.

3.1. Linking Names and Their Referents

The name-related elements provided by the 'namesdates' module are members of the 'att.naming' class which provides ways to link the instance of a name with the entity (person, place, organization) being named. The 'att.naming' class provides the following attributes:
key
provides an external means of locating a full definition of the entity, e.g. a database key
nymRef
provides a means of locating the canonical form (<nym>) of the names associated with the object
ref
provides an explicit means of locating a full definition of the entity by means of a URI

3.2. Personal Names

  • <persName> (a proper noun or proper-noun phrase referring to a person)
  • <forename> (a forename, given or baptismal name)
  • <surname> (a family (inherited) name)
  • <roleName> (a name component indicating a particular role or position)
  • <addName> (an additional name, such as a nickname)
  • <nameLink> (a phrase used within a name, but not part of it, such as 'van der')
  • <genName> (a generational name component)

3.3. Organizational Names

  • <orgName> (contains an organizational name)
  • Any named collection of people regarded as a single unit
  • <orgName> can be used both to mark the instances of names, and also inside <org> (discussed later) which contains the description of that organization

3.4. Place Names

  • <placeName> (an absolute or relative place name)
  • <bloc> (a geo-political unit of two or more countries)
  • <country> (a nation / country)
  • <region> (administrative unit, such as a state, province or county)
  • <settlement> (a settlement, such as a city or town )
  • <district> (a subdivision ,such as a parish or ward)
  • <geogName> (a name of a geographical feature)
  • <geogFeat> (a common noun identifying a geographical feature such as valley or mount)
  • <offset> (direction of offset of a relative temporal/spatial expression between two place names / dates)

4. Biographical and Prosopographical Data

Once you have marked up names of people/places/organizations you might want to point from those names to stored biographical and prosopographical data concerning the people/places/organizations.

4.1. Reality vs text

  • In text we see references to persons, places, organizations, names
  • P5 (for the first time) complements these with structured data for <person>, <place>, <org> elements
  • states, traits, and events
  • applications in in prosopography, historical datasets, etc.
  • These may be linked using ref or key attributes
  • and we can also treat names as objects, using the <nym> element

4.2. Person

  • <listPerson> (a list of person descriptions)
  • <personGrp> (group of individuals)
  • <person> (information about an individual)
  • <relationGrp> (information about relationships identified amongst people, places, and organizations)

4.3. Personal data

Structured information about a person, distinct from their name/s
  • Three new model classes:
    • model.persTrait: traits, e.g. eye colour, ethnicity
    • model.persState: states, e.g. name, residence, occupation
    • model.persEvent: changes in state e.g. birth, marriage, death
  • in each class:
    • a small number of generally useful elements
    • one generic element, e.g. <persTrait>
  • attributes for dating (dateValue, notBefore, notAfter) and responsibility (resp)
  • relationships between people are represented by a stand-off <relation> element
  • <person> or <personGrp>, like <bibl>, can be regarded either as metadata or as content

4.4. Personal Characteristics

  • <trait> (some culturally-determined characteristic)
  • <faith> (faith or belief set of a person)
  • <langKnowledge> (summary of a person's linguistic competence)
    • <langKnown> (knowledge of a single language)
  • <nationality> (a person's present or past nationality or citizenship)
  • <sex> (the sex of a person)
  • <age> (the age of a person)
  • <socecStatus> (perceived social or economic status)

4.5. Personal States

  • <state> (a description of some ongoing status of a person/place/organization)
  • <occupation> (informal description of a trade or profession)
  • <residence> (a person's past or present place of residence)
  • <affiliation> (a person's past or present affiliation)
  • <education> (a description of a person's educational history)
  • <floruit> (information about a person's period of activity)

4.6. Personal Events

  • <birth> (information about a person's birth, such as its date and place)
  • <death> (information about a person's death, such as its date and place)
  • <event> (data relating to any kind of significant event associated with a person, place, or organization)

4.7. A simple person

<person age="18sex="1">
 <persName>
  <forename>Ichabod</forename>
  <surname>Crane</surname>
 </persName>
 <birth when="1756-03-17">
  <placeName>
   <settlement>New York</settlement>
   <country>USA</country>
  </placeName>
 </birth>
 <death when="1809-03-27">
  <placeName>
   <settlement>Washington, DC</settlement>
   <country>USA</country>
  </placeName>
 </death>
 <affiliation notBefore="1797-05notAfter="1798-10-31">Sleepy Hollow School</affiliation>
</person>

4.8. Relationships

  • <relationGrp> (information about relationships identified amongst people, places, and organizations)
  • <relation> (describes any kind of relationship or linkage amongst a specified group of participants)
  • The <relation> element also has four important attributes:
    name
    supplies a name for the kind of relationship of which this is an instance
    active
    identifies the 'active' participants in a non-mutual relationship, or all the participants in a mutual one
    mutual
    supplies a list of participants amongst all of whom the relationship holds equally
    passive
    identifies the ‘passive’ participants in a non-mutual relationship

4.9. Organizations

  • <listOrg> (a list of descriptions of organizations)
  • <org> (information about an identifiable organization such as a business, a tribe, or any other grouping of people)
  • <orgName> (an organization's name)

4.10. Places

  • <listPlace> (a list of places)
  • <place> (contains data about a geographic location)
  • <placeName> (an absolute or relative place name)
  • <location> (the location of a place as a set of geographical coordinates, in terms of a other named geo-political entities, or as an address)
  • <geo> (geographical coordinates)

4.11. Place states, traits and events

In addition to the generic <state>, <trait>, and <event> elements, there are a few predefined for places:
  • <population> (information about the population of a place)
  • <climate> (information about the physical climate of a place)
  • <terrain> (information about the physical terrain of a place)

4.12. Place Example

<place xml:id="SH1">
 <placeName>Sleepy Hollow</placeName>
 <settlement>Sleepy Hollow</settlement>
 <district>Tarrytown</district>
 <region>New York</region>
 <country>USA</country>
 <climate>
  <p>Sleepy</p>
 </climate>
 <population when="1798-10-30">
  <p>78</p>
 </population>
 <population when="1798-10-31">
  <p>77</p>
 </population>
 <terrain>
  <p>Woody, with rolling hills, with large sections cleared for peach farming.</p>
 </terrain>
 <state notBefore="1798-07-10notAfter="1798-11-01">
  <p>Haunted occasionally by a Headless Horseman</p>
 </state>
</place>

4.13. Place relationships

  • <place> and <listPlace> (and event, trait and state) can self-nest indicating to indicate relationship
  • Alternatively <relation> can be used, as with <person> elements to indicate relations in a stand-off method
  • If the data forms a convenient hierarchy then nesting is easiest, but if it changes frequently or places belong to more than one categorization, then using <relation> is more flexible

4.14. Names and Nyms

Names can be regarded as objects in their own right irrespective of the object to which they are attached, e.g. in onomastic studies
  • <listNym> (a list of canonical names)
  • <nym> (the definition for a canonical name or namepart)
  • A <nym> can be seen as a specialised dictionary entry for a name, which might have multiple forms

4.15. All Together Example

<place type="cityxml:id="LYON1">
 <placeName notBefore="1400">Lyon</placeName>
 <placeName notAfter="0056">Lugdunum</placeName>
 <location>
  <geo>41.687142 -74.870109</geo>
 </location>
</place>
<p>Don't tell <forename nymRef="#N123ref="#BLT"> Tony</forename>...</p>
<!-- ... -->
<person xml:id="BLT">
 <persName>Tony Blair</persName>
 <occupation>politician</occupation>
</person>
<!--...-->
<nym xml:id="N123">
 <form>Antony</form>
 <form xml:lang="la">Antonius</form>
<!-- ... -->
</nym>

5. Dates

The support for dates in TEI P5 has concentrated on enabling greater use of international standards (W3C and ISO).

5.1. Dating Attributes

att.datable.w3c provides attributes for normalization of elements that contain datable events using the W3C datatypes.
when
supplies the value of a date or time in a standard form
notBefore
specifies the earliest possible date for the event in standard form
notAfter
specifies the latest possible date for the event in standard form
from
indicates the starting point of the period in standard form
to
indicates the ending point of the period in standard form

The W3C standard form for dates is YYYY-MM-DD.

5.2. Other Normalizations

For some uses the subset of ISO 8601 which is used by the W3C might not be enough, so the TEI provides an optional att.datable.iso and att.duration.iso classes to give the following attributes if needed:
when-iso
the value of a date or time in a standard form
notBefore-iso
the earliest possible date for the event
notAfter-iso
the latest possible date for the event
from-iso
the starting point of the period
to-iso
the ending point of the period
dur-iso
the length of this element in time

5.3. Relative Dates

Dates may also be provided not in an absolute way, but relative to something else
  • <offset> (the 'offset' component of a relative temporal expression)
The dur attribute on the <date> and <time > elements can also be used to provide a period range. Though this is also available in ISO dateTime formulations.

5.4. Summary

Elements defined by namesdates module: addName affiliation age birth bloc climate country death district education event faith floruit forename genName geo geogFeat geogName langKnowledge langKnown listNym listOrg listPerson listPlace location nameLink nationality nym occupation offset org orgName persName person personGrp place placeName population region relation relationGrp residence roleName settlement sex socecStatus state surname terrain trait

6. Digital Facsimiles

Increasingly people want to do not just 'text' editions but text editions with facing page (or otherwise linked) facsimile images. Indeed, some people want to just have images and create and electronic facsimile (perhaps with a view to later eventual transcription). The <facsimile> element is new in TEI P5 and built to accommodate this desire.

6.1. Digital Facsimiles

  • <facsimile> contains a representation of some written source in the form of a set of images rather than as transcribed or encoded text
  • <surface> defines a written surface in terms of a rectangular coordinate space
    • start points to an element which encodes the starting position of the text
  • <zone> defines a rectangular area contained within a <surface> element
  • Global facs (facsimile) points directly to an image, or to a part of a facsimile element which corresponds with this element.

6.2. Simplest case: using facs for 1:1 mapping

If a digital text contains one image per page or column (or similar unit), and no more complex mapping between text and image is envisaged, then the facs attribute may be used to point directly to a graphic resource.
<TEI>
 <teiHeader>
<!--...-->
 </teiHeader>
 <text>
  <pb facs="LSH-416.pdfn="416"/>
  <head>THE LEGEND OF SLEEPY HOLLOW</head>
<!-- Page 416 continues -->
  <pb facs="LSH-417.pdfn="417"/>
  <lb n="1"/>of the quietest places in the whole world. A small brook
 
<!-- Page 417 continues -->
 </text>
</TEI>

6.3. Using facs in conjunction with <facsimile>, <surface>, and <zone>

Using these attributes and elements together enables an editor to
  • associate multiple images with each page
  • record arbitrary planar coordinates of textual elements on any kind of written surface and link such elements to digital facsimile images of them

6.4. <facsimile>

The facsimile element is used to represent a digital facsimile. It appears within a TEI document along with, or instead of, the text element introduced in section 5 Default Text Structure. When this module is selected therefore, a legal TEI document may thus comprise any of the following:
  • a TEI Header and a text element
  • a TEI Header and a facsimile element
  • a TEI Header, a facsimile element, and a text element

6.5. <facsimile> Example

<TEI>
 <teiHeader>
<!--...-->
 </teiHeader>
 <facsimile>
  <graphic url="LSH-416.pdf"/>
  <graphic url="LSH-417.pdf"/>
  <graphic url="LSH-418.pdf"/>
  <graphic url="LSH-419.pdf"/>
 </facsimile>
 <text>
<!-- -->
 </text>
</TEI>

6.6. <surface>

The <surface> element may be used to indicate that there are two image files corresponding with the same area of the work:
<facsimile>
 <surface>
  <graphic url="LSH-416.pdf"/>
  <graphic url="psnypl_berg_979.jpg"/>
 </surface>
</facsimile>

6.7. dimensions

The actual dimensions of the object represented are not documented by the surface element; instead, the surface is located within an abstract coordinate space, which is defined by the following attributes, supplied by the att.coordinated class:
  • ulx gives the x coordinate value for the upper left corner of a rectangular space
  • uly gives the y coordinate value for the upper left corner of a rectangular space.
  • lrx gives the x coordinate value for the lower right corner of a rectangular space.
  • lry gives the y coordinate value for the lower right corner of a rectangular space.

6.8. Example drawn rectangles

6.9. <surface> Example

<facsimile>
 <surface
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

<!-- ... -->
 </surface>
</facsimile>

6.10. <zone> in <surface>

To describe the whole image, we will also need to define a zone of interest which represents an area larger than this surface. This zone of interest can be defined by a <zone> element, within which we can place the uncropped <graphic>:

<facsimile>
 <surface
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <zone
    ulx="93"
    uly="681"
    lrx="967"
    lry="1568">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
 </surface>
</facsimile>

6.11. <desc>

The <desc> element may also be used within either <surface> or <zone> to provide some further information about the area being defined. In this case, each surface must specify a bounding box which encloses the appropriate page, as well as defining the zone for the graphic itself:

6.12. <desc> Example

6.13. <desc> Example

<facsimile>
 <surface
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>front matter</desc>
  <zone
    ulx="96"
    uly="89"
    lrx="950"
    lry="657">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
 </surface>
 <surface
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>main text</desc>
  <zone
    ulx="93"
    uly="681"
    lrx="967"
    lry="1568">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
 </surface>
</facsimile>

6.14. More uses for <zone>

In addition to acting as a container for <graphic> elements, <zone> elements may also be used to select parts of each surface for analytical purposes.

<facsimile>
 <surface
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>main text</desc>
  <zone
    ulx="93"
    uly="681"
    lrx="967"
    lry="1568">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
  <zone
    ulx="507"
    uly="1109"
    lrx="707"
    lry="1163">

   <desc>supralinear addition</desc>
  </zone>
 </surface>
</facsimile>

6.15. More uses for <zone>

6.16. Aligning the transcription with facsimile elements

  1. give each relevant part of the facsimile an identifier
  2. using the facs attribute, point from the transcription into the <facsimile>

6.17. Aligning the transcription with facsimile elements (example - facsimile)

<facsimile>
 <surface
   xml:id="SH-front-facs"
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>front matter</desc>
  <zone
    ulx="96"
    uly="89"
    lrx="950"
    lry="657">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
 </surface>
 <surface
   xml:id="SH-pg1-facs"
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>main text</desc>
  <zone
    ulx="93"
    uly="681"
    lrx="967"
    lry="1568">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
  <zone
    xml:id="SH-add1-facs"
    ulx="507"
    uly="1109"
    lrx="707"
    lry="1163">

   <desc>supralinear addition</desc>
  </zone>
<!-- ... -->
 </surface>
<!-- ... -->
</facsimile>

6.18. Aligning the transcription with facsimile elements (example - text)

<text>
 <front facs="#SH-front-facs">
  <div>
   <head>THE LEGEND OF SLEEPY HOLLOW.</head>
<!-- front matter -->
  </div>
 </front>
 <body>
  <div>
   <p>
    <pb facs="#SH-pg1-facs"/>IN the bosom of one of
       those spacious coves ... and where they
       always <add facs="#SH-add1-facs">prudently</add>
       shortened sail ...</p>
<!-- more body -->
  </div>
 </body>
</text>

6.19. Using start to link from <facsimile> to transcription

It is also possible to point in the other direction, from a <surface> or <zone> to the corresponding text. This is the function of the start attribute, which supplies the identifier of the element containing the transcribed text found within the <surface> or <zone> concerned.

6.20. Using start to link from <facsimile> to transcription (example - facsimile)

<facsimile>
 <surface
   start="#SH-front"
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>front matter</desc>
  <zone
    ulx="96"
    uly="89"
    lrx="950"
    lry="657">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
 </surface>
 <surface
   start="#SH-pg1"
   ulx="0"
   uly="0"
   lrx="993"
   lry="1639">

  <desc>main text</desc>
  <zone
    ulx="93"
    uly="681"
    lrx="967"
    lry="1568">

   <graphic url="psnypl_berg_979.jpg"/>
  </zone>
  <zone
    start="#SH-add1"
    ulx="507"
    uly="1109"
    lrx="707"
    lry="1163">

   <desc>supralinear addition</desc>
  </zone>
<!-- ... -->
 </surface>
<!-- ... -->
</facsimile>

6.21. Using start to link from <facsimile> to transcription (example - text)

<text>
 <front xml:id="SH-front">
  <div>
   <head>THE LEGEND OF SLEEPY HOLLOW.</head>
<!-- front matter -->
  </div>
 </front>
 <body>
  <div>
   <p>
    <pb n="1xml:id="SH-pg1"/>IN the bosom of one of
       those spacious coves ... and where they
       always <add xml:id="SH-add1">prudently</add>
       shortened sail ...</p>
<!-- more body -->
  </div>
 </body>
</text>

6.22. Live Example (facsimile)

<facsimile>
 <surface
   xml:id="grave"
   ulx="0"
   uly="0"
   lrx="355"
   lry="678">

  <graphic url="gravestone-cropped.jpg"/>
  <zone
    ulx="83"
    uly="223"
    lrx="272"
    lry="256"
    xml:id="line1"/>

  <zone
    ulx="92"
    uly="251"
    lrx="256"
    lry="282"
    xml:id="line2"/>

  <zone
    ulx="21"
    uly="281"
    lrx="330"
    lry="308"
    xml:id="line3"/>

  <zone
    ulx="36"
    uly="306"
    lrx="320"
    lry="332"
    xml:id="line4"/>

  <zone
    ulx="85"
    uly="535"
    lrx="249"
    lry="556"
    xml:id="line5"/>

  <zone
    ulx="97"
    uly="556"
    lrx="241"
    lry="576"
    xml:id="line6"/>

  <zone
    ulx="58"
    uly="577"
    lrx="281"
    lry="595"
    xml:id="line7"/>

  <zone
    ulx="68"
    uly="595"
    lrx="271"
    lry="613"
    xml:id="line8"/>

 </surface>
</facsimile>

6.23. Live Example (text)

<div facs="#grave">
 <p>Private Moulds' gravestone</p>
 <div>
  <ab>
   <s facs="#line1">12851 PRIVATE</s>
   <lb/>
   <s facs="#line2">H. MOULDS</s>
   <lb/>
   <s facs="#line3">NORTHAMPTONSHIRE REGT.</s>
   <lb/>
   <s facs="#line4">23RD JULY 1916 AGED 21</s>
  </ab>
  <ab>
   <s facs="#line5">LOVING SON OF </s>
   <lb/>
   <s facs="#line6">MRS MOULDS</s>
   <lb/>
   <s facs="#line7">PETERBORO, ENGLAND</s>
   <lb/>
   <s facs="#line8">FOR EVER WITH US</s>
   <lb/>
  </ab>
 </div>
</div>

6.24. Live Example (rendered)

http://users.ox.ac.uk/~rahtz/test4.html



Date: 2008-03-05
Copyright University of Oxford