I’m going to take some time today to talk about CETEIcean, a new library that Raff Viglianti of MITH and I have been working on. We just pushed out the latest release this morning. CETEIcean grows out of work I’ve been doing for the Digital Latin Library to enable the online presentation of critical editions of Latin texts. Instead of transforming TEI XML into HTML for rendering in a browser, it does a 1::1 conversion of the XML into HTML Custom Elements. In practice what that means is that TEI tags, e.g.
<text>, get turned into tags that look like
<ref> element can be displayed as an HTML link, and when it’s clicked, the browser goes to the URL in its @target attribute.
<app> tags in the source, for example. But XSLT makes rearranging the source so simple that it’s almost the default behavior—you don’t really need to care about how things are laid out in the source because your transformation will just rewrite them for you. I’m coming to the conclusion though that this is not always a good thing, and that some of TEI’s constraints, the impact of which were smoothed over by XSLT’s transformative power, may lead you to model your texts in ways that are overly complicated. The other perhaps useful constraint CETEIcean provides is that it doesn’t let you throw away any of your text model. You can easily hide bits of your document using
display: none in a CSS selector. But it will still be there and available, whereas with XSLT you tend to throw away the stuff you aren’t going to display. In DLL texts, we don’t display alternate witness readings in the main text, for example, but they’re still right there, and if you want to show an alternate reading instead of the base text, all you need do is turn the
<rdg> into a
<lem> and vice-versa. Having the full text model available in the browser means we can have functions that manipulate it in useful ways. The isomorphism of CETEIcean documents also means it should be possible to have things like robust annotation (since annotation targets should be able to be trivially mapped to the source documents) and in-browser editing (because we can easily turn the HTML back into TEI). In sum, it seems like this approach has a great deal of potential and starts to get us out of the cul-de-sac our XSLT dependency had put us in.