http://mariage.uvic.ca/. This is an anthology of texts and images from around the 17th century in France.

http://mapoflondon.uvic.ca/. This project links a large historical map of London to a variety of information about streets, churches and other landmarks, with a focus on the literary history of the city.

http://pear.hcmc.uvic.ca:8080/ach/site/abstracts.htm. The ACH/ALLC 2005 Conference was held at UVic, and we created this system to produce the online schedule with abstracts in XML, XHTML, PDF and Text format, as well as the printed abstracts book.

http://web.uvic.ca/hrd/iallt2003/oldenglish/OEparagraph-1.html. This experimental project focuses on syntactic analysis of Old English sentence structure, giving readers access to very detailed linguistic information about the text they're reading.

We're concerned with the latter, but more broadly we're adding something to the text in order to provide profit for the reader.

Our historical textual conventions are very sophisticated, but they're not machine-readable. XML encoding enables us to identify very precisely the structure of a text, and its features. This can be a very painstaking and difficult. It can also force the elimination or resolution of inconsistencies and ambiguities which may be important to the overall effect of the text. Nevertheless, as Unsworth says, there can be "an enormous return on the exercise of foolish consistency". Marking up a text will often force us to articulate clearly our view of what the text is and how it works. This often makes humanists uncomfortable; they thrive on such ambiguities and tensions. However, we can think of markup as a way to make explicit a theory of the text. Any given markup expresses a theory or set of theories about the text. These need not be mutually exclusive -- multiple markups can be applied to the same text -- but within one markup version, we are forced into consistency.

Which edition or MS will you use? What representations of the text are available to you? How reliable are they?

What is their interest in the text? What standards and technologies are they used to working with? What can you provide for them that is not available elsewhere?

Rhyme/meter? Paleography? Physical structure? Thematic structure? Linguistic features? What will you change about the text, or add to it? In other words, what is the knowledge you're trying to represent?

Look at some sample documents and think about what features of those texts might be important for various audiences.

This is short for <pb></pb>

The order of attributes in a tag is not constrained in any way (in other words, we cannot depend on their being in a particular order, or make their order significant; processors will ignore the order of attributes).

This is a standard TEI tag; it's purpose is obvious.

This is apparently equivalent; humans can easily tell that it means basically the same thing.

This is the same information again, in a different format.

We must all agree on what tags and attributes we're going to use, what they mean, and how we're going to use them.

Schemas and DTDs formalize our agreement. They are also machine-readable, so (for instance) editor applications can use them to constrain our choices and help us to write conformant documents.

The TEI site (http://www.tei-c.org/) also provides extensive guidelines on how to mark up texts.

"Well-formed" means that the document is correctly hierarchical (all tags are closed, and the tag structure forms a correctly branching tree). "Valid" means that the document conforms to the schema (it uses the right tag names attributes, and attribute values in the right places).

Before the next session, try using the TEI <choice>, <orig> and <reg> tags to encode a modern regular form of the poem alongside the original text.

This is the simplest type of selector. It selects all elements with the tag name "div".

This selects all p elements which are descendants of div.

This selects all title elements which have an attribute level="m".

These pseudo-selectors are a little more complicated; they enable you to add content which will appear before or after the element. Using these selectors, for instance, you can opening and closing quotation marks before and after a quote.

The link above goes to the CSS 2.1 specification; CSS 3 defines many more selectors and pseudo-selectors, but only a few are currently supported by browsers.

Elements can be displayed as blocks (such as paragraphs, which are multi-line wrapping blocks of text), inline (words or phrases that occur within a block, such as italicized terms) or "none" (which means not displayed at all).

Width and height can be specified for any block elements, in percentages (relative to the containing block) or units such as pixels (400px) or inches (6in).

A margin setting does just what you would think: it puts a space between the element and anything contiguous to it. Margins can be set in percentages or units such as pixels, inches or ems (the height of the element's font). Margins can be set separately on all four sides of the element, or in a single setting (margin: 2%).

The font-family property takes a series of comma-separated values, in order of preference; the browser will use the first one which is available. Font names with spaces should be enclosed in quotes, and the series should end with one of the generic font families (serif, sans-serif, cursive, fantasy or monospace).

Some elements are not normally viewed in a document; one good example might be the teiHeader, which is often used only by metadata parsers or coders comfortable with reading XML. Such elements can be hidden by setting display: none.

By default, all elements are displayed as inline. The first step in organizing the layout is to determine which elements should be block elements. Typical examples in TEI would be head tags and p tags.

Space out the elements on your page by setting margin values. Other properties to consider at this stage are padding and border.

Some elements (such as headings) might be centred, others (such as paragraphs) will look best when justified.

The hierarchy of a text is often signalled through setting different font sizes for different levels of heading. Blockquotes are sometimes shown with a smaller font size than the surrounding paragraph text.

TEI emph tags will typically be italicized, acronyms or abbreviations might be bold, and monograph titles will typically be in italics.

Nothing is clickable, and nothing pops up when you mouse over things.

CSS allows us to specify a background image for an element or for the whole file, but it doesn't allow us to show images in the document, based on a filename or url in the document.

In order to do something more dynamic with our documents, we need to convert them into something else. In the next part of the session, we'll be converting our XML into HTML using XSLT.

XSLT code is expressed in XML format. That makes it a little different from other computer languages you might know.

The input to an XSLT transformation is always XML. The output may be one several formats.

XHTML is the most recent form of HTML. It is based on the old HTML many of us are familiar with, but it is expressed in well-formed and valid XML. In other words, it's simultaneously XML and HTML.

Version 2 also exists, but it's not supported in browsers yet. We're going to view the results of our transformation in a browser, so we need to stick to version 1.0. It should be good enough.

Don't ask why; it's too complicated to explain, and you'll wish you never asked. We just have to do it for this exercise.

You won't see anything right now, because our XSLT file is empty.

This tells the processor we want to create an HTML page. Other options are XML and text.

XSLT works by templates. It parses the XML tree of the input file, and every time it finds something that matches one of its templates, it carries out the instructions in that template. Here, we're matching the root of the document, which is signified by a slash character. We're telling the processor: "When you find the root of the document, output a basic HTML file". Then we're telling it to extract a specific piece of information from the teiHeader, and use that for the title of the HTML page. Finally, we're telling it to continue processing from the text/body level of the tree.

eXist is an open-source Java application that runs on the server. It can be integrated with a sophisticated web application server called Cocoon.

You can see that a number of different languages are actually involved. The query comes in to the system in the form of a URL. This is then passed to an XQuery processor, which creates a detailed query in the XQuery language. eXist deals with the XQuery, gets the data out of the db in XML format, and passes it back into the pipeline. Then the results are processed through XSLT, to produce XML, HTML, Text or XSL:FO. XSL:FO can be passed to our XEP processor to produce PDF. The results are sent back to the browser.