TEI

• —concentrates on data modelling aspects and ideological agnosticism
• —avoids standardization constraining individual projects
• —avoids any recommendation for processing & publishing
• —TEI stylesheets often too complicated to customize
• —only concerned with TEI

TEI Simple

• —concentrates on eliminating the ambiguity for the encoder
• —aims at interoperability
• —provides out-of-the-box mechanism for default processing
• —allows for [relatively] easy customization and extension
• —TEI Simple processing model can be applied to other vocabularies

TEI Simple ODD

=

a schema

+

processing instructions for all elements

Text

Processing Model

Editor

manages the text integrity,
makes the high-level output decisions:

• structural descriptions ‘ should the original or corrected version be displayed by default‘,         or ‘ is this a block level or inline component‘
• indications of  appearance  ‘ titles are in italics‘

Programmer

takes the editor’s specification, and the TEI text(s), and creates the input for the designer to make the output

Rahtz Rationale

workflow with three distinct roles

Designer

creates the output envelope ( for example book layout using InDesign, or a web site using Drupal), making decisions about the appearance in conjunction with the editor 

‘ use Garamond font throughout’

‘every page must show the departmental logo’

Default

—editorial decisions recommended by teiSimple fit project’s needs perfectly:

just use teisimple.odd

scenarios

Custom

—project requires customization: overwrite teisimple.odd

with custom processing and rendition instructions

ODD stores as much information as possible

for each element there are potentially numerous <model> instructions that specify intended processing and rendering for different outputs and in various contexts

Turska Tenet

maximum expressivity to the editor

• —identify elements that require individual treatment
• —if treatment differs depending on context, identify all possible situations via XPath expressions (eg. div type=“act” headings treated differently than all other head elements)
• —decide which behaviour is required under given circumstances, specify parameters (eg. use only lem child as visible by default in app entries)
• —if treatment differs depending on output type create additional models with @output as necessary
• —specify rendition as CSS where required

editor’s tasks

(apart from editing)

TEI Simple function library

• handful of functions that achieve > 80% tasks
• functions based on commonly used terms
• if no content parameter specified, all functions use current element as default content

model syntax

ODD extensions for TEI Simple Processing Model (PM)

• model
• param
• rendition
• modelGrp
• modelSeq

• —@output specifies output in which model applies
• —@predicate specifies context in which model applies
• —@behaviour specifies function from teiSimple function library to apply
• —@useSourceRendition indication to preserve @rendition value from the source
• —<param> elements specify parameters for behaviour
• —<rendition> elements specify CSS instructions to indicate outline appearance

model

• —there can be as many <model> statements as required, each of which can have multiple <rendition> children
• —set of multiple <model> statements is regarded as an alternation and only the first <model> with @predicate matching current context is applied
• —@behaviour specifies which one from TEI Simple function library should be applied and function parameters are specified as <param> children
• —within each <model> there can be set of <rendition> elements
• —<desc> allows for initial textual description of required processing

model

TEI Simple

in a broader context

• —familiarity with source files and XML encoding used
• —ability to identify different use scenarios
• —relative XPath fluency to specify model parameters*
• —relative CSS fluency*

—

—

* possibly assisted by project’s IT support

editor's necessary skills