Appearance
To choose an edition publishing framework, score candidates against four criteria in priority order: does it consume standard TEI P5 unchanged, can you host and preserve it for a decade, does it support the features your edition actually needs (search, apparatus display, IIIF facsimiles), and how large is its maintainer community. The best default for most projects is a static framework (EVT or CETEIcean) because hosting and long-term preservation are trivial; reach for a server framework like TEI Publisher only when you genuinely need dynamic, full-text querying across the corpus.
What frameworks are actually in use?
The field has consolidated around a handful of mature options, each making a different trade between richness and maintenance.
| Framework | Type | Strengths | Watch out for |
|---|---|---|---|
| TEI Publisher | Server (eXist-db) | Powerful search, Processing Model, ODD-driven | You must run and patch eXist-db |
| EVT | Static site | No server, IIIF, image-text linking | Configuration over code; less flexible |
| CETEIcean | Browser JS library | Renders TEI client-side, ultra-light | You write the CSS/JS behaviour yourself |
| ediarum | Editing + publishing | Editorial workflow integration | Heavier setup, oXygen-centric |
How do I weight the selection criteria?
Standards compliance comes first, because it determines whether you are trapped. Then sustainability — who hosts this in 2035? Then features. Features come last deliberately: a feature-rich framework you cannot maintain is worse than a plain one you can.
text
score = 0.35 * standards_compliance # consumes plain TEI P5 + IIIF, clean exit
+ 0.30 * sustainability # community size, hosting simplicity
+ 0.25 * feature_fit # search, apparatus, facsimile views
+ 0.10 * developer_experience # how fast can your team shipTune the weights to your context, but keep standards and sustainability dominant. A framework scoring 9/10 on features and 2/10 on sustainability is a trap.
Static or server — which should I pick?
This is the decision with the largest long-term consequence. A static edition is a folder of HTML, JS, and IIIF manifests you can drop on any web host or into a preservation repository; it will still open in fifteen years. A server-based edition needs a running, patched database — a maintenance commitment that outlives most grants.
Pick static unless you need dynamic full-text search across a large corpus, faceted browsing the build cannot precompute, or live collaborative editing. For a single edition or a modest corpus, EVT or CETEIcean will do everything readers expect.
How do I test a framework before committing?
Build a real spike, not a demo. Take five of your hardest TEI pages — ones with apparatus, marginalia, and facsimile links — and publish them through each candidate. You learn more from one ugly page than from the framework's own showcase.
bash
# CETEIcean spike: render TEI in the browser, no pipeline
git clone https://github.com/TEIC/CETEIcean.git
cp my-hard-page.xml CETEIcean/
# open index.html, point it at my-hard-page.xml, check apparatus + facsimileTime how long it takes to make the apparatus render correctly. That number predicts your real build cost better than any feature list.
What keeps an edition portable across frameworks?
Discipline about separation. If your TEI carries no HTML classes, no presentational attributes, and no framework-specific hacks, then switching frameworks means writing new stylesheets — not re-encoding. Keep behaviour in an ODD-style Processing Model or a stylesheet, keep your images as IIIF, and keep a one-command build. Then the framework is a swappable component, not a lock-in.
What does a defensible checklist look like?
Before you commit, confirm: the framework reads your unmodified TEI P5; your IIIF manifests render; the apparatus and notes display correctly; the output is accessible (keyboard, alt text, headings); you can host it within your institution's means for ten years; and you can export your data and walk away. If any item fails, you are not done evaluating.
Key Takeaways
- Score frameworks on standards compliance, sustainability, feature fit, then developer experience.
- Default to static (EVT, CETEIcean); choose server (TEI Publisher) only for real dynamic search needs.
- Refuse any tool that requires modifying your TEI; your data must exit cleanly.
- Spike five hard pages through each candidate, not the framework's own demo.
- Keep presentation out of the source so frameworks stay swappable.
- Server frameworks add a decade-long database maintenance commitment.
- Finish with a defensible checklist covering accessibility, hosting, and exit.
Frequently Asked Questions
What are the main TEI publishing frameworks?
The widely used ones are TEI Publisher (eXist-db, TEI Processing Model), EVT (Edition Visualization Technology, static), edition-builder tools like ediarum (for editing), and CETEIcean for browser-side rendering. Each suits a different balance of features, server needs, and maintenance burden.
Should I prefer a static or a server-based framework?
Static frameworks (EVT, CETEIcean, custom XSLT-to-HTML) are far cheaper to host and preserve but limit dynamic search and faceting. Server frameworks (TEI Publisher on eXist-db) give rich querying at the cost of running and patching a database for years.
How important is standards compliance when choosing?
Critical. A framework that consumes plain TEI P5 and IIIF means your data stays portable if the framework dies. Avoid any tool that demands a proprietary export of your TEI; your edition should survive its publishing layer.
What is CETEIcean and when does it fit?
CETEIcean is a JavaScript library that renders TEI directly in the browser using custom elements and CSS, no transformation pipeline. It fits small to medium editions that want a lightweight, fully static deployment with behaviour driven by a TEI Processing Model-like spec.
How do I evaluate long-term sustainability of a framework?
Check the release cadence, the size of the maintainer community, whether it depends on one server product, and how cleanly your data exits. A framework backed by an active consortium and consuming standard TEI scores far higher than a clever one-person project.
Can I switch frameworks later?
Yes, if your data is clean TEI P5 and your images are IIIF. The framework only renders; migrating means writing new stylesheets, not re-encoding. This is the strongest argument for keeping presentation logic out of your source.