More Info

Map of London: XML Encoding

Introduction

This document provides instructions for encoders and editors working on the XML documents in the MoEML project. It includes instructions on how to check out the XML files from the repository, and commit them back after making changes, as well as documentation of the XML elements and attributes used in the project, and our markup practices.
This document is currently only partially complete, and is subject to change. Over the next few months, it will become more extensive and detailed.

Accessing the files through Subversion

All of the files in the project, including the XML data files and all the programming logic (XQuery, XSLT, etc.) are stored in our Subversion (SVN) repository. This enables us to keep all versions of every file, so that if we need to, we can roll back to a previous version, and it helps to avoid versioning conflicts when more than one editor may work on the same file.
To access the data in Subversion, you need to use a Subversion command-line client. These exist for Windows, Mac and Linux. This document contains instructions for Windows users. Instructions for Mac will be added later, but OSX comes with a Subversion command-line client anyway, so there's no need to install one, and the rest of the instructions are very similar for Mac and Windows.
Obtain your command-line client from Collabnet. Note: you have to register in order to download the program, but it's free. Make sure you download the correct version for your architecture; there are versions for 32-bit and 64-bit Windows, so you'll need to know whether your Windows OS is 32-bit or 64-bit in order to get the correct one. When you have downloaded the program, install it by double-clicking the downloaded installer and following the instructions.

Checking out the XML files from the repository

Next, you need to create a directory for your XML files, and check out the files from Subversion. Here are some basic instructions, with screenshots, using Windows 7:
  • First, you need to "check out" the files from the Subversion repository. That means that you make a local copy of all of the files on your own hard drive. This is what we do:
    • Open a command window (a terminal), by clicking on the Windows Start Menu, then typing the letters "cmd" into the Run box, and pressing return. This should bring up a terminal window:

  • You'll notice that the terminal window opens in your home folder (on Windows 7, c:\Users\[username]). That's where we're going to store our copy of the data files. We need to create a folder for them, then we'll check them out into that folder. First we make a folder; then we "cd" (change directory) into that folder; then we check out the files. These are the commands:
    • mkdir london
    • cd london
    • svn checkout https://revision.hcmc.uvic.ca/svn/london/db/data .
    Type each command on one line (without returns), and press the return key after each command to make the terminal execute it. You should probably copy/paste the commands from here into your terminal window, to make sure you get them right. If you do type them, don't forget the "s" in "https", or the period at the end (after "data" there's a space then a period). This is what you should see:
  • Once you press the return key, you should see a lot of filenames scroll past, as all the files download to your computer:

    and at the end, you'll see something like this:

    This shows you which revision number you have checked out. A revision number represents the state of the repository. "Revision 17" means that 17 changes have been committed to the repository since it was set up. Every time you commit new changes to the repository, the revision number will go up.
  • Now you have a complete copy of the files on your hard drive. You can check this out by opening Windows Explorer and navigating to the location where you checked them out:

    Now you can edit your files in this location, using oXygen. Don't forget to keep validating your files! Invalid XML files won't work properly in the database.

Updating your local copy, and committing your changes

You have now "checked out" a copy of the code from the server. Once you've done that on a particular computer, you don't need to do it again. But other people will be working on the files, and you will need to get their changes on a regular basis. This is done with the svn update command. Normally, you will run svn update at the start of every session, to make sure you have the latest versions of the files before you start work. Try it now:

  • You'll see that a change has been made. In this case, a new file has been added (it has "A" next to it), and the revision number has been updated to 18. The new file has been downloaded to your computer. Files which have been changed will have a "U" next to them.
When you have made some changes to a file, you will need to "commit" (upload) those changes to the repository. Let's imagine that you have changed this very file, which is data/info/xml_encoding.xml. This is what you do:
  • Go back to your terminal again. If you've already closed it, then start it again from the Start Menu, then do cd london and press return to move into the london directory.
  • Type the following:
    svn commit -m "Added copyright info to the header of xml_encoding.xml."
    "-m" means "message", and it's followed by your message, in quotes, explaining what changes you made in your editing session. When you press return, Subversion should ask you for a password. This would be your netlink password; you can't commit changes to the repository without it. However, the first time you enter your password, it may fail because Subversion is trying your user name on your local computer, and that may not be the same as your netlink user name. If that happens, you will be asked for your user name for Subversion (that's your netlink id), and then your password (your netlink password). Once Subversion is happy that you have rights to commit to the repository, it will go ahead and send the changes. This is what it looks like in the terminal:

    The system has committed the changes you made, and the revision number is now 19.

Adding and deleting files in the repository

So far, you've set up a system where you can edit existing files, and commit the changes back to the repository. However, sometimes you will need to add a new file to the tree. This is how you do it:
  • First, create the file that you want to add. You can do this by creating a new file in oXygen, or you might save an existing file with a new name, and then modify it. Make sure you save it in the right folder on in the tree.
  • Once you have created the file, you need to add it to the Subversion system. If you don't do that, it will only remain on your hard drive, and never be copied to the server. To add the file, you need to use the svn add command. If, for instance, you have created a file called test.xml in the info folder, this is what you in the terminal:

    Subversion responds by echoing the folder and filename with an "A" in front of it.
  • Now you need to commit the change to the server. Nothing is sent to the server until you do svn commit:

    Now your file is safely in the repository.
You may also want to delete a file from the repository. If you do this, it can still be recovered later, but the process is a bit complicated, so don't do this unless you're sure it's the right thing to do. Here we'll delete the test.xml file we added above. It's a two-stage process, just like adding a file: svn delete, then svn commit.

  • As soon as you have done this, your own local copy of the file will be deleted from your hard drive, so be careful!

  • Now the file has been deleted from the repository as well as your hard drive. When anyone else working on the files does svn update, their local copy of the file will be deleted as well.

Why do we do this at the command line?

You may be wondering why we use the command-line in this apparently old-fashioned manner. There are several reasons for this:
  1. The command-line client works exactly the same way on all platforms, so if you move from Windows to Mac, for example, you won't have to learn a whole new way of working.
  2. The command line is the simplest approach, once you get used to it. The various GUI programs for interacting with SVN (such as Tortoise SVN for Windows) are all quite complicated to learn, and all differ from each other.
  3. The command-line client provides access to more functions and capabilities if you need them. For instance, try running svn log to see a list of all the changes made to the repository. Run svn log -r 21 -v to see the details of a specific revision.

Reprise: svn update, edit, svn commit

So, to review what we've covered above, the normal editing workflow goes like this:
  • svn update (to get all the latest changes from the database)
  • your editing work (including svn add or svn delete as necessary)
  • svn commit to write your changes back to the repository.
If you're editing for a long period, you might want to do an svn commit every hour or so. It's rather like saving a document. Every time you do svn commit, you're creating something analogous to a "restore point" on Windows: a point to which you can "roll back" a document (or the whole repository) if something goes wrong with it.

Database structure

The eXist database now contains the entire application, including data, XQuery, XSLT, JavaScript etc. This makes it very portable; it can be copied from one machine to another, and requires only Apache Tomcat to run. As a result, it is possible to take a working copy of the database on a laptop to a conference, rather than having to rely on an internet connection that might be slow, or a server that might be temporarily down.
The database is divided into three subcollections:
  • data
  • site
  • system
The data subcollection contains all the XML files that editors are working on. It is organized similarly to the london subcollection in the old database. Editors will have write permission on this subcollection.
The site subcollection contains all of the machinery for making the website work, including XQuery, XSLT, CSS, and JavaScript. Programmers will have write permission on this subcollection.
The system subcollection contains configuration of indexes for optimizing queries, and other housekeeping items. Programmers will have write permission on this subcollection.

Basic document structure

All data in the MoEML is in the form of TEI P5 XML documents. This includes all the write-ups about streets and churches, literary texts in the Library, and site information pages like this one. You can see the structure of any of these pages by clicking on the XML link at the top left of every document. These documents are all standard TEI P5 (they should all validate against a standard P5 schema), but they fall into three distinct categories: simple documents, location documents, and complex (multi-text) documents.

Simple documents

Most of the basic information pages on this site, such as the About page, fall into the category of simple documents. They consist of a <teiHeader> and a single <text> element. The basic structure of a document looks like this:
 <TEI version="5.0" xml:id="about">
  <teiHeader>
   <fileDesc>
    <titleStmt>
     <title>
      Map of London: About the Project
     </title>
    </titleStmt>
    <publicationStmt>
     <availability>
      <p>
[Information about copyright...]
      </p>
     </availability>
    </publicationStmt>
    <sourceDesc>
     <p>
[Information about the source document, if applicable...]
     </p>
    </sourceDesc>
   </fileDesc>
  </teiHeader>
  <text>
   <body>
    <div xml:id="content">
     <head>
      About the Project
     </head>
     <p>
[Paragraph content...]
     </p>
    </div>
   </body>
  </text>
 </TEI>
Some points to note:
  • The @xml:id attribute on the root <TEI> element is the same as the name of the file, except without its extension. So when the file is called about.xml, the @xml:id attribute should be "about".
  • There is only one <text> element.
  • The main content is contained in a <div> element with the @xml:id attribute "content". This is by convention, and makes it simpler to find and render key content during processing.
Tags and attributes used to mark up the content itself are covered in more detail below.
Some simple documents will have subsections and even sub-subsections. This is achieved by using nested <div> elements. Nesting can be as deep as required, but should be kept as simple as possible. For instance, this is a page which has an introduction and two subsections:
 <text>
  <body>
   <div xml:id="content">
    <head>
     Page title
    </head>
    <p>
Introduction
    </p>
    <div>
     <head>
      Subsection 1 title
     </head>
     <p>
Para one...
     </p>
     <p>
Para two...
     </p>
    </div>
    <div>
     <head>
      Subsection 2 title
     </head>
     <p>
Para one...
     </p>
     <p>
Para two...&amp; things.
     </p>
    </div>
   </div>
  </body>
 </text>

Location documents

Location documents are like simple documents in that they contain only one text element, and usually have a straightforward structure, but they typically have three elements which don't appear in simple documents. This is the basic outline of a location document:
 <TEI version="5.0" xml:id="ABCH1">
  <teiHeader>
   [...Normal teiHeader; more below...]
  </teiHeader>
  <facsimile>
   <surface>
    <graphic url="C6.jpg">
    </graphic>
    <zone xml:id="C6_ABCH1" points="266,233 256,232 254,186 274,112 283,115 264,183 266,233 266,233">
    </zone>
   </surface>
  </facsimile>
  <text>
   <body>
    <div type="placeInfo">
     <head>
      Abchurch Lane
     </head>
     <listPlace>
      <place type="street" corresp="#C6_ABCH1">
       <placeName>
        Abchurch Lane
       </placeName>
       <location>
        <geo>
         [Geographical coordinates will go here when available...]
        </geo>
       </location>
      </place>
     </listPlace>
    </div>
    <div>
     <p>
<ref target="mol:ABCH1">Abchurch Lane</ref> runs north-south from <ref target="mol:LOMB1">Lombard Street</ref> to <ref target="mol:CAND1">Candlewick (Cannon) Street</ref>. [More about Abchurch Lane...] 
     </p>
    </div>
   </body>
  </text>
 </TEI>
There are two key aspects to this file: the <facsimile> element, in which the location of the place on a specific tile of the map is specified, and the <div> element with a @type attribute of "placeInfo". These are both crucial.
 <facsimile>
  <surface>
   <graphic url="C6.jpg">
   </graphic>
   <zone xml:id="C6_ABCH1" points="266,233 256,232 254,186 274,112 283,115 264,183 266,233 266,233">
   </zone>
  </surface>
 </facsimile>
The <facsimile> element in the example specifies that there is one "surface" on which this place appears. The graphic for that surface is C6.jpg, the tile for C6; this is encoded in a simple TEI <graphic> tag. On that graphic, there is one <zone>. The <zone> is defined as a series of points on the graphic. Each point consists of a pair of coordinates, x and y, separated by a comma, and the points are separated by spaces. In this example, you can see that the final point is the same as the first point, thus closing the polygon to make a shape. This will almost always be the case.
The <zone> element has an @xml:id attribute, which enables us to point to it later in the file. The @xml:id attribute value, "C6_ABHC1", is constructed from the name of the tile (C6), an underscore, and the @xml:id of the file itself.
 <div type="placeInfo">
  <head>
   Abchurch Lane
  </head>
  <listPlace>
   <place type="street" corresp="#C6_ABCH1">
    <placeName>
     Abchurch Lane
    </placeName>
    <location>
     <geo>
      [Geographical coordinates will go here when available...]
     </geo>
    </location>
   </place>
  </listPlace>
 </div>
The <div> with @type="placeInfo" starts with a <head> element with an overall title for the place/page. Then there is a <listPlace> element. In this case, it contains only one <place> element, but in some cases there will be several; the same street may appear on multiple map tiles, and may be split by other features into separate sections. Each section might have a slightly different title (Main Street West, Main Street East), so there is a <placeName> tag inside each <place>.
The attribute @type="street", which defines the type of place (other values are "church", "ward" etc.). These determine which index page the location will appear on ("Streets", "Churches" etc.). The second attribute is @corresp="#C6_ABCH1". This points to the <zone> element in the <facsimile> section above. It specifies that this place element is located at the position specified by the <zone> with @xml:id="C6_ABCH1".
More complex locations will have multiple <surface> elements with multiple <zone> elements, and multiple <place> elements below. See /data/locations/THAM1.xml for a good example.
Each <place> element has a <location> element with an empty <geo> tag inside it. In the future, this will contain the GIS coordinates of the place, so that we can provide links to shapes on Google Maps or other GIS-based mapping systems.
Following the <div> with @type="placeInfo", the remainder of the document consists of regular <div> elements containing the content of the document. See below for more information on textual markup.

Complex documents

The final type of document is the much larger contribution which typically consists of a long essay divided into several sections. These are often found in the Topics or Library areas of the site. Sections in the same document may be written by different people, so we constitute them in the form of separate <text> elements. The typical document structure looks like this:
 <TEI version="5.0" xml:id="HENS2">
  <teiHeader>
   [...Normal teiHeader; more below...]
  </teiHeader>
  <text>
   <group>
    <text>
     [First text...]
    </text>
    <text>
     [Second text...]
    </text>
    <text>
     [Third text...]
    </text>
   </group>
  </text>
 </TEI>
Each <text> element will have its own <body> containing <div> elements, which may of course be nested. When a document like this is processed for display, a table of contents will automatically be created based on the hierarchy of <text> and nested <div> elements with their <head> children. See the /data/topics/HENS2.xml for an example of this kind of XML structure, and its HTML rendering to see the result.
One final note: when a table of contents is created for a complex file like this, XHTML @id attributes are generated automatically to support the links between the TOC and the various sections. However, these automatically-generated @ids may be different each time the page is rendered. If you want to create static internal ids to link to, add and @@xml:id attributes to each <text> element, or to each <div> element inside a <text>. The page you are currently reading provides an example of this; click on the XML link above to see the code.

The bibliography and the personography

There are two special files which act rather like centralized databases: the bibliography and the personography. They are, respectively, /data/BIBL1.xml and /data/PERS1.xml. The first contains all the bibliographical entries used throughout the site, and the other contains information on all the people (historical, mythical, and modern) who are mentioned on the site.

The bibliography

The bibliography file is structured like this:
 <TEI version="5.0" xml:id="BIBL1">
  <teiHeader>
   [...]
  </teiHeader>
  <text>
   <body>
    <div>
     <listBibl>
      <bibl>
[Bibliographical reference...]
      </bibl>
      <bibl>
[Bibliographical reference...]
      </bibl>
      <bibl>
[Bibliographical reference...]
      </bibl>
     </listBibl>
    </div>
   </body>
  </text>
 </TEI>
Individual bibliographical references look like this:
 <bibl xml:id="ARCH1">
<author>Archer, Ian W.</author><title level="m">The Pursuit of Stability: Social Relations in Elizabethan London.</title> Cambridge: Cambridge UP, 1991. Print.
 </bibl>
Every time you refer to a bibliographical reference when writing an article, first check in the bibliography file to see if it is already there. If it is, then all you have to do is to link to it, like this:
 <p>
[...] (<ref type="bibl" target="mol:ARCH1">Archer</ref>)
 </p>
Otherwise, create a new reference in the bibliography file, and then link to that. Don't forget to put @type="bibl" on your <ref> tag
In the long term, we plan to elaborate the markup of bibliographical entries, so that dates, publishers, and publication places are also marked up, like this:
 <bibl xml:id="ARCH1">
<author>Archer, Ian W.</author><title level="m">The Pursuit of Stability: Social Relations in Elizabethan London.</title><pubPlace>Cambridge</pubPlace>: <publisher>Cambridge UP</publisher>, <date when="1991">1991</date>. Print.
 </bibl>
It is sometimes necessary to construct an annotated bibliography, where items from the main bibliography are presented, but with additional information on each. This can be done using a mechanism that looks like this (this example is taken from Guidelines for Contributors, /data/info/guidelines_contributors.xml, which can be used as a model:
 <listBibl>
  <bibl type="replace">
<ref type="bibl" target="mol:SHER2"></ref><note>The subscription database is accessible through many major university and research libraries. Use the abbreviation ODNB in parenthetical references. See the <ref type="internal" target="#citationGuide">MoEML Citation Guide</ref> for examples of citations.</note>  </bibl>
  <bibl type="replace">
<ref type="bibl" target="mol:OED1"></ref><note>The subscription database is accessible through many major university and research libraries. Use the abbreviation OED in parenthetical references. See the <ref type="internal" target="#citationGuide">MoEML Citation Guide</ref> for examples of citations.</note>  </bibl>
 </listBibl>
Here the <bibl> with @type="replace" element causes the target <bibl> to be retrieved from BIBL1.xml, but the additional information in the <note> element is added to the reference when it is rendered.

The personography

The personography file is structured like this:
 <TEI version="5.0" xml:id="BIBL1">
  <teiHeader>
   [...]
  </teiHeader>
  <text>
   <body>
    <div>
     <listPerson>
      <person>
       [...]
      </person>
      <person>
       [...]
      </person>
      <person>
       [...]
      </person>
     </listPerson>
    </div>
   </body>
  </text>
 </TEI>
The file contains information on historical, fictional, and mythical characters, as well as contributors to the site, and technical assistants. An individual entry looks like this:
 <person xml:id="ABBO2">
  <persName type="hist">
   <reg>
    Abbot, George
   </reg>
   George Abbot
  </persName>
  <note>
   <p>
1562-1633; Vice-Chancellor of the University of Oxford, 1601-1606; Archbishop of Canterbury, 1611-1633.
   </p>
   <list type="links">
    <item>
<ref target="http://www.oxforddnb.com/index/101000004/">ODNB</ref>    </item>
   </list>
  </note>
 </person>
Note the @type attribute on the <persName> tag. This is used to distinguish the five types of person in the file:
  • hist = historical person
  • fict = fictional person
  • cont = content contributor
  • myth = mythological character
  • tech = technical assistant
Information about the person is included in a <note> tag containing one or more <p> tags, and a <list> if there are references.
To link a name in an article to their entry in the personography, use a <name> tag like this:
 <p>
[...] The transgressions against the Diary were committed mainly in pursuit of <name type="person" ref="mol:SHAK1">Shakespeare</name>. [...]
 </p>
The attribute @type="person" is optional.

Linking

Linking to locations inside and outside the project is very simple. This is how you link to an external location on the web:
 <p>
[...] Consult the <ref target="http://www.tei-c.org/release/doc/tei-p5-doc/en/html/">TEI Guidelines</ref> for more information. [...]
 </p>
Linking to a page, bibliographical item, or person inside the project is even easier. All you need to know is their @xml:id attribute. In the case of an article, that's the @xml:id attribute on the root <TEI> element of the document; in the case of people, it's the @xml:id attribute on their <person> element in the personography file, and in the case of bibliographical items it's the @xml:id attribute on the <bibl> element in the bibliography file. In all cases, we use the "mol:" prefix to specify that the item we're linking to is inside the MoEML project. Here are some examples:
  • Linking to an article: 
     <p>
<ref target="mol:BUDG1">Budge Row</ref> ran east-west through <ref target="mol:CORD1">Cordwainer Street ward</ref>. [...]
 </p>
  • Linking to a person: 
     <p>
The history of <name type="person" ref="mol:HENS1">Philip Henslowe</name>’s Diary (1592-1609) is in no way straightforward. [...]
 </p>
  • Linking to a bibliographical reference: 
     <p>
In Stow’s time the lane was “chiefly inhabited by Basketmakers, Turners and Butchers” (<ref type="bibl" target="mol:STOW1">Stow 1.211</ref>). [...]
 </p>
You can easily find items to link to by searching for them on the ids page.

Encoding notes

Notes are inserted into the text of articles or transcriptions using the <note> element, which can be placed wherever you want the note marker to appear. In other words, you should insert the <note> element at precisely the location to which it refers. Two types of note are distinguished in this project: editorial notes, and marginal notes. The former are notes by the modern editors and contributors working on this site; the latter are marginal notes appearing on the original documents which are being transcribed. They are distinguished by means of an @type attribute on the <note> element. Here are some examples:
 <p>
9. In <ref target="mol:BILL2">Blliinſgate ward</ref> 5.<note type="editorial">Obvious typographical error for Billinſgate.</note> [...]
 </p>

 <p>
Wee must haue no peace with it, if there be no grace in it.<note type="marginal">Psalme 1</note> [...]
 </p>

Text styles

The issue of text styling (italics, bold, etc.) falls into two distinct groups of issues:
  1. Text which is styled because of what it is (such as book titles which are in italics).
  2. Text in a transcription of an original text which has some distinctive style features, but without there necessarily being a clear reason for them. For instance, in a 16th-century text, some words may appear in italics; a modern transcriber may not be able to determine the reason for it, or may not feel confident in doing so.
The vast majority of such cases, especially in articles written by site contributors, will fall into the first category. In these cases, you do not need to apply styling; all you need to do is to use the appropriate tag to identify what type of thing you are dealing with. The system will then take care of applying the correct style for you. Here are some examples:
The following tags will be rendered with italics:
  •  <title level="m">
  War and Peace
 </title>
    (monograph/book titles)
  •  <title level="j">
  Notes and Queries
 </title>
    (journal/periodical titles)
  •  <emph>
  emphasized text
 </emph>

  •  <foreign>
  foreign text
 </foreign>
    (such as Latin phrases, etc.)
The following tags will normally be rendered with quotation marks:
  •  <title level="a">
  John Stow, Citizen and Historian.
 </title>
    (article or book chapter titles)
  •  <quote>
  Tomorrow and tomorrow and tomorrow
 </quote>
    (inline quotations; block quotations are discussed below)
There will be some circumstances in which you need to style text, and you know what the reason for the text styling is, but our current schema does not support the TEI tag you want to use, or when you use it, the correct styling does not appear. This is a programming issue, and you should contact HCMC staff (preferably Martin Holmes). It's very easy to add an existing TEI tag to our schema and to provide the appropriate formatting for it.
Finally, there will be situations in which you need to style text, but there is no clear or obvious reason for it that can be captured in a TEI tag. In this case, you can use the general-purpose <hi> element, and specify the styling using CSS code in its @rend attribute. CSS (Cascading Style Sheets) is a set of international standards which are supported by web browsers and many other rendering agents. It is relatively easy to learn CSS, and you will find it is very powerful. CSS code in the @rend attribute looks like this:
 <p>
 [...]<hi rend="font-style: italic;">italic text</hi> [...]
 </p>
Any text styling which is written in CSS code will be passed through automatically to the output web page, so it will just work (as long as it's correct CSS). If you need to apply a new kind of style that you've never used before, you can just look up the correct way to do it in CSS, and then use it. Multiple styling properties can be chained together using semicolons:
 <p>
[...] <hi rend="font-weight: bold; font-style: italic;">bold italic text</hi> [...]
 </p>
CSS is a very rich and powerful standard, and it also has the advantage that CSS code can be validated against the standard, so it's very easy to check whether mistakes have been made in @rend attributes. One point to be aware of is that some CSS styling properties apply only to block elements such as paragraphs or divisions; these are attributes such as alignment. These attributes will only "work" (i.e. have an effect) if they are assigned to block elements in the XML such as <div>, <head> and <p>. So this will work: 
 <head rend="text-align: center;">
  Centred heading
 </head>
but this will have no effect: 
 <p>
[...] <hi rend="text-align: center;">some text</hi> [...]
 </p>
because <hi> is an inline element rather than a block element, and is converted into an inline element (a <span>) in the HTML output.
Another useful CSS property is "display". This can be used to hide parts of the document if, for example, they aren't yet complete and shouldn't yet be seen by readers:
 <p rend="display: none">
This paragraph isn't yet finished...
 </p>
Note: at the present time, you will see a great deal of code on the site which does not conform with these guidelines; in particular, you will see styling which uses the <hi> element for many identifiable purposes, such as book titles or emphases. This is legacy code, and will be corrected over the next few months.

Main site pages

Main site pages such as the Home page or the About page are just XML files like any other. They live in the /data/info subcollection. They have a slightly different convention for file names and @xml:id attributes: they are named with lower-case filenames and @xml:ids, which are typically longer and more descriptive, with multiple-word names separated with underscores:
  • credits.xml
  • guidelines_contributors.xml
To create a new page on the site, simply create a new XML file in the /data/info subcollection. For instance, to create a page about Future Plans, create this XML file:
  • /data/info/future_plans.xml
with @xml:id="future_plans" on its root element: 
 <TEI version="5.0" xml:id="future_plans">
   [...] 
 </TEI>
You'll find the page here:

[map-of-london-domain]/future_plans.htm and you can link to it like this: 
 <p>
[...] <ref target="mol:future_plans">Future Plans for this site</ref> [...]
 </p>

Boilerplate text on the site

All of the text which appears on the site is editable by the editors. Most of it, of course, comes from the data documents themselves, but there is a lot of other text which appears in the form of captions and labels. This text is all stored in /data/boilerplate/boilerplate.xml. If you see a caption or heading that needs fixing, you should be able to edit it inside the boilerplate.xml file. This includes the main page menus. Most of the smaller captions appear inside a <div> with @xml:id="captions", and look like this: 
 <seg xml:id="clickToZoomCaption">
  Click on a square to zoom in.
 </seg>
You can change the text to make the caption change on the website. Don't change the @xml:id attribute, though; that's used to find the appropriate caption when processing pages. If you need to create a new caption for use somewhere on the site, you'll need to collaborate with the programmer(s) to make it work, but the process is quite simple.

This research was supported by the Social Sciences and Humanities Research Council.

Humanities Computing and Media Centre       University of Victoria
SSHRC
Share |