One way to orient ourselves in the landscape of transformation is to think about how we use our own data. If we think of the life cycle of a TEI project, there are numerous places along the timeline where we want to express different views of our data, for internal or external viewing: proofreading and error catching formats that extract specific structures to let us catch inconsistencies in the encoding web publication print publication formats for contribution to collaborative projects (where we might want to simplify or alter our markup to match the target encoding of those projects) metadata formats (e.g. to expose to metadata harvesters) archival formats for committing to a repository

Another way to approach the topic of this workshop is to think about transformation and publishing as a variety of informational avenues that radiate out from our TEI data. Even though it's probably a familiar concept to many of you, it's worth noting an important assumption that underlies much of our work with XML: we're creating a single XML source from which we are going to generate many different kinds of output.

This is important because the XML source is an expensive and valuable information object: it represents a careful modeling of our research materials, we've put a lot of work into it (transcription, encoding, proofreading, correction, annotation, other kinds of enhancement) and we want to exploit it in many different ways, automatically, not by hand.

When we generate these different varieties of output, we are often losing information: erasing distinctions that are present in the source (but unnecessary in the output), or moving from a representationally rich language (like TEI) to a representationally impoverished language (like HTML)

But since these output formats are generated automatically, rather than by hand, this information loss doesn't matter: the source retains its informational richness: it represents the full set of possibilities from which any specific option can be generated.

A few examples: Charles Brockden Brown Mark Twain Project Paul the Simple

A third important aspect of our topic is the idea of data as a mutable, protean substance: as a kind of plastic informational model that we can reshape and manipulate as needed.

In the example here, all four of these examples represent pretty much the same pieces of data—any one of them could be generated from any of the others. And yet these differences might matter in the context of some particular tool or standard way of doing things.

The point is that our data is almost never trapped in its current format: when we understand it as transformable, we gain power over it and we can use it more flexibly. If a collaborator needs some information extracted from our data, or if they put their fields in a slightly different order, or whatever, it's not a problem.

The chief tool for doing all of these kinds of work is a programming language called XSLT, the Extensible Stylesheet Language for Transformations: it can be used on its own to generate different kinds of transformed and manipulated data (such as HTML, KML, JSON, other XML formats) and it also is built into many (most? all?) of the XML publication systems that we use, such as XTF, as the way that they take XML data and manipulate it as part of their publication activities Either way, what it does is give us a way of manipulating our XML data: to extract pieces of it, reshape them, change their format, generally do whatever we want to do with them.

The Extensible Stylesheet Language allows you to transform XML documents into other XML formats

Essentially XSLT allows you to map a given XML element onto another XML element: saying "take in the following construct, and put out this other construct"

It could be a construct in the same language, or in a different language such as XHTML, as in the example here