TEI Technical Council F2F Meeting in Würzburg

10–13 March 2026

Objectives

Daily notes

Discussion topics

From P5 to P6

Tuesday 3/10

Meeting started @ 09:46 local time

1. Setting the stage for P6

See TCW 09 and what Council thought in 2006/2007 when P5 began.

Discussion:
MH: That statement at the end of TCW09 has held us back from P6.
HBS: We have frustrations with P5 that we need to confront.
JT: We are, arguably, in the presence of new technologies (AI), but even if that doesn't change the use of XML, there's nothing being said in TCW09 that prevents us from moving to P6.
SB: Can we address our frustrations within P5?
RV: We need to be comfortable / confident about breaking things in the P5 class system, even if we don't call it P6. We can decide on the name of it later.
Discussion: there will be distress with breaking backward compatibility, so probably best to call it P6.
RV: P5 to P6 may be like Python 2. 6 vs. Python 3. Those who are ready will move to P6, but a robust community of practice can stick to P5 until ready.
MH: We don't have to do this quickly.
SB: P5 itself took several years.
MH: ATOP group hobbled by underspecification of ODD, yet another reason to start over w/ P6.
RV: It would be great to do ODD processing in more than just XSLT (e.g. XQuery, Typescript, Rust, Java).
TR: Consider graph database modeling for schema modeling?
MS: Invite people who think XML is not the only solution to consider for modeling TEI.
Discussion: mixed content
RV: Our use of XML is creating a certain kind of model that can be frustrating for those who don’t want to use it (e.g. an XML-specific way of breaking hierarchy may require more nodes in a graph than a simpler graph solution). But mixed content is central to TEI and XML excels at it.
UHK: If we were trying to describe the modeling without direct reference to XML it would need to be more general/abstract (as a model of text(s)?) in the Guidelines - that would change teaching and learning TEI a lot (just stating this without saying it would be a good or a bad thing)

Discussion of JSON/JSON Query vs. XPath/XQuery which works just fine with it. These are just methods of addressing maps and trees.

We don't really imagine people want to do text encoding in JSON.
People are interested in graph technologies for showing relationships across documents / annotations. Serializations always resolve to TEI XML. Can we envision a different kind of serialization that's more neutral / friendly to graph representation?

SB: We should back up and consider: What's the point of TEI now? Allow different projects to encode and share data.

TR: Can we write it by hand? (This is important to keep). Important to be able to learn encoding in relation to humanities projects: "to see what I mean". Editability threshold may collapse if things become too abstracted.

MH: If we put HTML on the table: We can express the TEI abstract model in HTML.
RV: HTML also handles mixed content, and there's good reason why it hasn't died.
Making TEI work in the browser immediately, without CETEIcean, would be wonderful.

2. TEI community views on P6:

Over the course of P5 and especially in recent years, what has Council and TEI community said of "P6" in GitHub tickets? Small group "warm-up" activity for one hour: Read the ticket and don't try to solve it, but rather describe the gist of its perspective on P6.

See Appendices: Table from Small Group Actvities: A. GitHub Guidelines and Stylesheets Tickets Marked or Mentioning P6

3. Do we need a P6 now, or had we better continue with P5?

Working in groups, Council freewrites and later summarizes points in favor of continuing P5 vs. why we need to start P6. See Appendices: Table from Small Group Actvities: B. Why not P6 yet? Vs. Why P6 now?

Wednesday 3/11

ODD processing without @module

#2840: When @module attribute is missing what should a processor do?

TEI modeling challenges discussion

This discussion was sparked by issues with where <addrLine> is permitted to be encoded, and the encoding of personography/placeography in transcriptional contexts.

Group P6 modeling activity

Working with cards (on which we printed the names of each current TEI P5 element) or whiteboards / marker/paper: Take a handful of ~20 elements from P5 and remodel them in terms of abstract classes. To become familiar with the complexity of how to group elements and attributes and abstract classes. To find criteria for organising elements.

Summary discussion / representative examples of experimental classifications based on random "scoops" of elements:

Discussion:

For details on more experiments see Appendix C. Element SubGroup Classification Exercise

Discussion following the group activity on redefining class structure for P6

Discussion of class structure on the element level

In the beginning was <element>. Everything is an <element>.

<catRef> as special kind of note and a pointer.
<anchor/> is a locus but <ptr/> points to somewhere else

Term for grouping of elements in P6: “scope” instead of "zone".

Structural fundamentals

<ab> -----> <div>, <p>, <note>
<seg> ----> <ref>, <name>, <hi>
<anchor/> ----> <ptr/>, <witEnd/>, etc.

OR

[ABSTRACT CLASS NAME] used just for naming / grouping; it has no real bearing on the hierarchy

scope in green with solid border

(==removedElement) in red with dashed border

[TEI]
│
├── [SEGMENTATION]
│   ├── div
│   │   ├── lg
│   ├── ab
│   │   ├── p
│   │   ├── seg
│   │   │   ├── [POINTER]
│   │   │   │   ├── ref
│   │   │   │   │   ├── ptr
│   │   │   │   │   ├── link
│   │   │   │   │   ├── rs
│   │   │   │   │   │   ├── biblRef
│   │   │   │   │   │   ├── name:referring
│   │   │   │   │   │   │   ├── placeName
│   │   │   ├── del(==delSpan)
│   │   │   ├── name:naming
│   │   │   │   ├── label?
│   │   │   │   ├── head
│   │   │   ├── note
│   │   │   │   ├── desc
│   │   │   │   ├── gloss
│   │   │   │   ├── label?
├── anchor
│   ├── witEnd
│   ├── milestone
│   │   ├── lb
│   │   ├── pb
│   │   ├── cb
│   │   ├── gb

NAUGHTY CORNER
bibl
gloss?

Undeveloped class tree:
EL
│
├── SEGMENT
├── DESCRIPTOR

Discussion of multiple hierarchies/ inheritance

Thursday 3/12

Summation of yesterday's discussion

  1. Although we see no reason to consider moving away from XML as our serialization/editing format, we would like to express the abstract model in such a way that it is not dependent on the distinction between elements and attributes in XML, reflecting expression in “objects” and “properties”, for example. Properties could be expressed as attributes, for instance, or as child elements. That way, transitioning to another format that is not XML will be facilitated.

  2. We would like, if it proves practical, to build our abstract model on a real class inheritance system under which any given class could be resolved back to a more generic class. This would in theory enable automated simplification of documents for the purpose of interchange, because a processor should be able to take a specific element/object/attribute/property and walk up the inheritance tree in order to find the most generic equivalent that a receiving system understands. There may be abstract classes in that tree, and it’s not yet clear how this would work. In addition: if multiple inheritance is allowed for, a strategy (precedence rules? depending on scopes?) is needed to decide on which path to take up the hierarchy.
    (An alternative would be to describe objects/properties in terms of common features instead of a strict classification system (e.g., using feature structures), with the advantage that it would make grouping easier and the disadvantage that there would probably not be an easy way for automated simplification and it might not be directly compatible with the establishment of content models)

  3. We will ensure that it is straightforward to provide different content models for the same object/element in different contexts, and will adopt that practice in all the “blueprints” (see below). The suggested mechanism for this is that affected objects/elements will declare different content models, each assigned to different “scopes”; then objects/elements will also declare their active “scopes”, and any object/element included in their content model will appear with the appropriate content model from their collection of available content models. The details of this are still not fully worked out.

    • For instance: scope definition (who defines the scopes? Are scopes fixed by us (the TEI, e.g., in council maintained blueprints) or can they be defined by the community/individual projects?)
    • scope compatibility (can we ensure scope compatibility across blueprints?
      • RV: This is a good question because if scope is beyond the abstract model, it's bound to be less compatible outside of subscription to / reuse of someone else's (including the Council's) blueprints
    • Should we make scope-declaration required?)
      • EB: For example: if an element appears in a context where no matching scope is declared, does it fall back to a/its default content model, raise a validation error, or accept anything?
    • Scope inheritance? If a subclass inherits its parent’s scope declarations, does it also inherit its content models, or should these be “redeclared”?.
    • The "scope-ability" of objects/elements would be part of the abstract model, but the actual scoping would not be generalized. Scoping should be built into the abstract model, to an extent.
    • Scopes would have to be defined within projects, but we might have some recommended / broadly accessible scopes that seem useful in many projects.
    • Can these be easily translated into a schema language? If we get too abstract, it may be difficult. Counterpoint: Perhaps a better definition of the abstract model will make it easier to develop a good schema. EB: That would include inheritance rules, scope-definition rules, and subclassing-mechanisms. Having strong "first principles" makes for better schemas.
    • Underspecification is a serious blockage for the atop group now. So knowing what the problems are with current P5 ODD processing will help. Out of this work we will probably make a much better ODD.
    • However, the difficulty will be in expressing schemas for the new approaches to customization. Can we make this less of a technological load for customizers and Council?
    • Much of our technological burden is about "why isn't this element allowed ___?" Our work will shift.
    • Core blueprint and starting point for users should have stronger, clearer guidance for decision making.

  4. Rather than providing a tei_all which becomes the yardstick for compliance and which many projects inevitably adopt despite our warnings, we will make an effort to provide a larger and better array of "blueprints" to replace the current exemplars. We want to emphasize customization as a core principle for using TEI. To encourage customization, users should be enabled to generate a schema bottom-up that can be refined/expanded further, starting from instances of encoded text (e.g., through ODDbyExample.xsl).

  5. Blueprints would be complete working customizations with full documentation (consisting of a template TEI file for encoding, a schema and an ODD), organized into a blueprint repository (ideally persistent and versioned) along the lines of a package management system (e.g. PyPI or NPM), with a front-end that enables you to use a questionnaire approach to find the blueprint(s) most appropriate as starting points for your project.

  6. A repository would provide a central place for the community to locate helpful blueprints for customization. Projects and scholarly communities would be encouraged to submit their own blueprints to the repository, which would be accepted provided they meet certain criteria (documentation etc.) and have appropriate descriptors enabling them to be found via the questionnaire. Some blueprints would have the Council’s mark of approval. Blueprints should be citable with DOIs. Blueprints/ODDs are treated as first-class research output and their circulation within the scholarly ecosystem is encouraged.

    • Review and acceptance can be facilitated by requiring push to a branch with actions/tests.
    • But some classification and organization will be required.
    • Responsibility for schemas involves the community. Perhaps a "TEI-approved" blueprint needs to involve a scholarly peer review infrastructure we develop (not limited to Council).
    • Maybe we don't have to make this a requirement to allow people to contribute to the repository.
    • Perhaps there's a free area that's a bit chaotic but could be a pre-peer review open resource.
    • “Council recommended” blueprints might conflict. Might not be a problem.
    • If limited community participation, perhaps limit our expectations. But we should promote this as Open Science. Council members can launch this and there will probably be interest in organizers of large projects. Could be integrated into graduate program work for peer review experience.
    • Possibly "Council recommended" is distinct from other forms of review/approval.

  7. Customizations would start from an existing blueprint, and extensions would be created by sub-classing an existing item in the tree; for example, a project wanting a <sarcasm> element could subclass the <seg> element, enabling automated resolution back to something like <seg subclass=”sarcasm”> for interchange.
    * EB: Will subclassing inherit the parent’s scope-sensitive content models? E.g., will <sarcasm> inherit the scope-sensitive content model of <seg> per scope?

  8. Distinguish between (1) working on a formal specification of the abstract model vs. (2) working on the processing pipeline. We need a clear definition of inheritance rules, scope resolution rules, and subclassing semantics, before working on the implementation.

TEI becomes two different things: the abstract model AND the scoping / blueprints. Both are to be maintained and versioned. We may need to develop new community infrastructure.

Council activity: Reduction and splitting exercise

Start with our Miro board of TEI elements (as well as classes and macros). (This was made a couple of years ago, but we have just added the new <post> element and macro.specialPara.cmc so that it is up to date.

Discussion of elements under "Destroy"

Council activity: Create a blueprint

Template: Council selects a Tom Hanks Letter Typewritten on a 1934 Smith Corona typewriter as a basis for constructing a simple experimental blueprint Source: https://flashbak.com/tom-hanks-writes-great-letter-1934-smith-corona-typerwriter-58609/

Working all together, with EBB encoding, guided by the group, we began by modeling the document in XML potentially possible for TEI P6 but incompatible wtih TEI P5

First encoding

<?xml version="1.0" encoding="UTF-8"?>
<tei6>
   <metadata> </metadata>
   <text>
       <dateline>
           <date when="2012-07-13">13 July 2012</date>
       </dateline>
       <formeWork>
           <formeWork rend="underline">PLAYTONE</formeWork>
           <formeWork>
               <seg>Film</seg>
               <seg>Television</seg>
               <seg>Music</seg>
               <seg>Typewriters</seg>
           </formeWork>
       </formeWork>
       <salute>Dear <persName>Chris</persName>, <persName>Ashley</persName>, and <rs ref="#dg"
               what="person" quantity="multiple">all the<lb/> diabolical
                       <options><sic>genuies</sic><corr n="1">geniuses</corr><corr n="2"
                       >geniis</corr><corr n="3">ingenues</corr></options>
               <!--   An alternate encoding <w>gen<choice><sic>ui</sic><corr>ius</corr></choice>es</w>-->
               at <orgName>Nerdist<lb/> Industries</orgName></rs>.</salute>
  
       <p>Just who do you think you are to try<lb/> to briibe me into an apperance on your<lb/> ‘thing’ with
           this gift of the most<lb/> fantastic Cornona Silent typewriter made in 1934?</p>

       <p>You are out of your minds if you <lb/>think… that I… wow, this thing <lb/>has great action… and
           this deep <lb/>crimson color… Wait! I’m not so <lb/>shallow as to… and it types nearly
           <lb/>silently…</p>
  
       <p>Oh, OKAY!</p>
       <p>I will have my people contact yours <lb/>and work out some kind of interview <lb/>process…</p>
       <closer>Damn you all to hell, <signature><lb/>Tom Hanks</signature></closer>
   </text>
</tei6>

Discussion

Same data with potential classes and "traits"

RV next experimented with preparing a more abstract modeling of the document encoding.

<?xml version="1.0" encoding="UTF-8"?>
<tei6>
   <metadata>
      
   </metadata>
   <text>
       <!-- Capitalized terms are abstract classes; they may or may not resolve into new elements -->
       <!-- ab is a placeholder to be replaced by either an abstract class or new element. <textualComponent> <contentObject> <thing> á la schema.org? -->
       <dateline--ab>
           <date--measure--Measuring when="2012-07-13">13 July 2012</date--measure--Measuring>
           <time--date--measure--Measuring>13 July 2012</time--date--measure--Measuring>
           <measure--Measuring/> <!-- time–Temporal–measure–Measuring & date–Temporal–measure–Measuring is under consideration as well -->


<!-- “texty” is inspired by truthy/falsy in JS: a value that is considered true/false when encountered in a Boolean. In practice it means that elements with this property will be able to contain text nodes. -->


           Thing?:texty
           ├── Measuring:quantifiable
               ├── measure
                   ├── Temporal:datable
                       ├── date
                       ├── time


       </dateline--ab>


       Thing?:texty
           ├── Peritext
               ├── formWork
                   ├── letterHead


       rdg:transparent (a property that indicates that the content is determined by the closest texty ancestor)


       <letterhead--formWork--Peritext--ab> <!-- form(e)Work to be renamed -->
           <letterhead--formWork--Peritext--ab rend="underline">PLAYTONE</letterhead--formWork--Peritext--ab>
           <letterhead--formWork--Peritext--ab>
               <seg>Film</seg>
               <seg>Television</seg>
               <seg>Music</seg>
               <seg>Typewriters</seg>
           </letterhead--formWork--Peritext--ab>
       </letterhead--formWork--Peritext--ab>


       <salute>Dear
           <persName--name>Chris</persName--name>,
           <persName--name>Ashley</persName--name>, and
           <rs what="person" ref="#" quantity="many">all the
           <lb/>diabolical
               <choice--Options> <!-- also app -->
                   <sic>genuies</sic> <!-- also orig, reg -->
                   <corr>geniuses</corr>
               </choice--Options> at Nerdist
               <lb/>Industries
           </rs>.
       </salute>
      
       <p>
           Just who do you think you are to try
           <lb/>to briibe me into an apperance on your
           <lb/>'thing' with this gift of the most
           <lb/>fantastic Cornona Silent typewriter
           <lb/>made in 1934?
       </p>


       <p>
           You are out of your minds if you
           <lb/>think… that I… wow, this thing
           <lb/>has great action… and this deep
           <lb/>crimson color… Wait! I'm not so
           <lb/>shallow as to… and it types nearly
           <lb/>silently…
       </p>


       <p>Oh, OKAY!</p>
      
       <p>
           I will have my people contact yours
           <lb/>ad work out some kind of interview
           <lb/>process…
       </p>
      
       <closer>
           Damn you all to hell,
           <signature><lb/>Tom Hanks</signature>
       </closer>
   </text>
</tei6>

Taking the example above and trying to model it from an Aspect-Oriented Programming perspective:

In a UML visualisation (generated with PlantUML):

PlantUML visual diagram based on the encoding provided in this section
PlantUML diagram representing our blueprint model. "C" indicates class, "A" indicates aspect, and "I" indicates specific inheritance from a class.

The visual diagram is based on the following PlantUML code:

interface Texty {
 +can contain text nodes
}

interface Quantifiable {
 +value
 +unit
}

interface Documentary {
 +records physical features  
}

abstract class Temporal {
 +@when
 +@notBefore
 +@notAfter
 +@...?
}

abstract class NamedEntity {
   +xml:id
}

class persName {
   +@role
}

class date {
 +@calendar
}

class peritext {
 +@type
}

class letterhead

class p

class name

Temporal ..|> Texty
Temporal ..|> Quantifiable
date --|> Temporal
time --|> Temporal
persName --|> NamedEntity
peritext ..|> Texty
peritext ..|> Documentary
letterhead --|> peritext

p ..|> Texty

name ..|> Texty

persName ..|> Texty

Friday 3/13

Proposed adjustments to Thursday's example abstract model and blueprints

This continues discussion of the modeling and blueprints we developed at the end of the day on Thursday.

Proposal for defining trait: Abstract model: classDef TRAIT:texty(:meta|:transc)

Blueprint:

Developing abstract models for P6

Discussion of the Guidelines prose and the schema

USE chapter now says:

Planning our next steps

Let's set some manageable tasks in motion for the near future.

Establish a workspace

Council homework assignment after this F2F

  1. Thinking which languages would be appropriate for P6, how to build?

    • HBS: Modelling exercise will result in us quickly realising that meta and content become a class
      • MS: We have to make clear and describe what we want and summarise what we know we want now. The tools don't matter until we achieve this consensus and clarity.
      • JT: Reach a shared vocabulary of what we're doing.

  2. Review the TEI Guidelines
    * Flag what sections can be kept for P6
    * Identify what sections need to be rewritten and to what extent (some will need to be rewritten from scratch).

  3. Regular reporting / review in Council meetings

Explore funding options for P6

Engage the TEI community

Continued support of P5 while developing P6

Proposed principles for P6

  1. We are the TEI: the TEI is a community standard that underscores openness and community involvement
    • We locate development and customization of schemas at the center of the TEI’s approach
  2. We do not re-invent the wheel. We value expertise and remain responsive to shifting needs and concerns.
    • However, we do not tie ourselves to a single technology.
  3. We provide core infrastructure for expressing scholarly knowledge for texts, enabling robust systems for scholarly communities to express, share, review, validate, collaborate, extend, and challenge expertise
  4. We consider interchangeability of texts, knowledge, and expertise as the key purpose of the TEI, its infrastructure, and its design

Appendices

Tables from small group activities

A. GitHub Guidelines and Stylesheets Tickets Marked or Mentioning P6

Group Ticket # What is the idea about P6, or what's relevant to P6 here?
A #2843 Attributes need a more flexible class system, too. In P6, attributes need to be treated as “first class citizens” just like elements. Council discussion: How about datatypes, too? In Relax NG, attributes were already "first class citizens" but we lost track of that in P5. Sometimes we're not clear on what should be an attribute vs. an element. Perhaps we can define elements and attributes according to the same system and allow a thing to be either element or attribute. Starting from an idea in principle can help express in multiple serializations. MH: "Makes the transition to P7 even easier!"
B #2090 Argues for per-document default attribute values. Should definitely be included in P6 but not relevant for today’s discussion. Council discussion: Idea is to allow for setting a declaration mechanism in the teiHeader: is this good explicit context modeling, and good idea for P6? Relation / difference to ODD chaining Raises question of relation between the document and the ODD. JT: Taxonomies are often wrapped into ODDs in the form of e.g. valLists; perhaps valLists should be taxonomies? Dropping ODD entirely and chain Relax NG instead? What are the advantages of ODD over RelaxNG (Documentation?)? A resource for generating Relax NG TEI can't be only about its schema. Raises arguments for a TEI schema and validator Relax NG provides speed/ease of validation What if TEI schema language were totally expressed in XPath? It would be slow to do Schematron for ALL of it. "Not invented here": If there's a good standard that works we should use it. Would the TEI still exist even if we didn't have validating engines? Yes. If we can generate complicated Schematron from a simpler source... “Vibe-coding a TEI schema”.
C #2000 Shows difficulties arising from over-policing content models in P5. Also shows the need for context-sensitive content models. (app use in tables) Council discussion: Is there a mechanism that we could use in RELAX NG In the context of critical apparatus, it means teasing apart and validating the individual versions (“horizontally”) as well as the apparatus (“vertically”). JT: Do we have to constrain it all, or can we rely on scholarly peer review. A lot of the TEI can be automated, but what cannot be automated are the prior decisions, e.g., why are you encoding the text, what’s your theoretical model? Need to review the 24.4.6 and update accordingly: What do we now want to define as TEI conformance?
D #1923 Technically complex change to resolve relative small inconsistency in ODD processing (attRef using @key and not @name) that would break backwards compatibility
A #1744 Content models need to be context-dependent – this seems to be a must-have for P6. The ticket includes suggestions on how to do this, including allowing <elementSpec> to define multiple contexts based on a @predicate containing an XPath – which we think should instead be abstracted as much as possible. Council discussion of "zones" or “interface” or "behaviors" or "grouping mechanism" or "purpose" or "context" or "mode"(?): related to object-oriented programming. "Context" problematic b/c of its association with document structure--that's not what this is about. seg.meta seg.ling seg.hi *** A class structure with inheritance: rs name persName
B #1400 P6 should not have numbered divs. Group D: We think this is where the marking of tickets explicitly for P6 begins. Council discussion: Given what we've been discussing so far: we can imagine including numbered elements in a specific abstract class by users. <q> vs. <quote> vs. <cit> begin to appear as distinct purposes of handling quotation marking, depending on the choice of abstract class. Content model might look simple but compile into something more complex in Relax NG. Discussion of inheritance: If we want the specific subclass (persName but not name), we get the subclass by pointing to it, and we lose access to name. But what if we want rs and persName? The user can define their own class to include what they need. How does multiple inheritance work? <note> How are modules participating in this? They could be properties (private?) of classes. *** We can express all the previous versions of TEI as profiles in P6. P3 can be expressed as a distinct profile of P6. Discussion of abstraction in the Guidelines: Feature structures as the most abstract of all the models? Can everything in TEI be expressed in this way? What is <rs>? Not really a feature structure We may not want to define what's "inline" or "block" anymore. But we could define "text-bearing"? <app> is an interesting complexity: not appropriate to call it a "block". And <list> can go in a <p> now in the TEI. It's the editorial and semantic function that should define these classes.
C #1175 Provides one of the principles we should[?] articulate at the outset of working on P6: what do we mean by modal verbs and terms such as “mandatory”?
D #2744 We need guidance to clarify and simplify the use of attributes as pointers. P5 has too many ways to do things that mean the same thing with different attributes (e.g. @ed vs @edRef ). Attributes for pointing and referencing are generally not well specified in P5. What do we use for single strings vs. multiple pointers? Broad principle: How much does the TEI grow in order to specify different use-cases and how much is up to the user to document and define? Does the TEI proliferate attributes or allow for refinement of a single attribute?
A #367 For the most part this is additional evidence that we need to rethink the class system. The ticket focuses on the content model discrepancies between place, org, and person.
B St #235 How to process an ODD into Relax NG. Having 1 repo for P6.
C St #569 Superficially relevant in that if we keep <altIdent> or something like it, it would be as an attribute. AND WE WILL DROP DTDs, so this particular issue would not arise.
D #2001 Our prefixDef is the same as privateURIScheme in the rest of the world. TEI has reinvented the wheel without consulting a more standard / universal definition.
A #2779 This ticket is about problems with Debian packages and their interdependencies. It highlights how P6 will need its own infrastructure that may look different from what we have now.
B #1921 <schemaSpec> restricted to a small group of elements. Done, issue closed. Relevance for P6: Yes, <schemaSpec> should be a member of model.resourceLike, but that is a small detail unimportant to this weeks’ discussions.
C #2157 Supports the idea of many good model ODDs for people to start from (so that not everyone is starting with TEI all) – but we should also consider something like ODDbyExample to go along with this. (idea of a questionnaire for people to build a starting point ODD suited to their texts/projects; potentially further customising this with a tool like ROMA 2.0; have a tool to check schema against actual encoded documents later in the workflow to suggest updates to the ODD)
D #1964 Not a big deal. Just a bad example and closed. One thing to note though is the LB notes that deprecation of teiCorpus would be a P6 change.
A #1841 This ticket is a specific example of how it can be complicated to work across classes to move elements around. This is relevant to P6 because of the need to rework the class system but also, in MH’s words: “[I] dream of [a] P6 [where] there's none of this nonsense. Things can appear wherever they want.”
B #1626 Request to accept the xml namespace for Standoff proposal. Also closed. Main query: “If validation under egXML can be divorced from validation in general” Relevance for P6: “Does the lack of widely available tools for handling NVDL make this a P6 proposal?”
C #1519 Reminds us that we need to be clear on how version labelling and numbering should work in P6. Issue can remain closed.
D #1323 Gist: This is a ticket recognizing that Council had introduced an ODD-breaking change but didn't announce it to the community. We're stagnating in P5 if we can't accommodate backwards compatibility as soon as we make a class change. MH in 2015: "We're in a situation, then, in which no-one wants to talk about P6 because that has to wait for a game-changing platform shift such as moving away from XML; but neither are we allowed to make improvements to the current P5 which affect backward compatibility even slightly. A better recipe for moribundity and stagnation could hardly be devised." SR in reply: "As regards P6, the TEI needs an infrastructure to support non-backwards-compatible releases, using a forking mechanism. Its going to be quite tedious to set up a complete parallel working setup, but i would suggest its worthwhile to get the mechanism in place."
A #1273 More evidence of a broken class system, but this has to do more with modules than classes, e.g. what determines whether an element goes to core or transcr, why not both? Quote: “there is no useful way to change this without module fragmentation which we've postponed until P6.”
B #516 <tagsDecl> needs to be explicit if it documents all tags in a document. No consideration for P6. Also closed.
C #481 Related to #2685. hand and handShift can be considered two ways of expressing the same phenomenon. Prompts the question: are there clear advantages of encoding a hand/handShift in two different ways? In the context of P6, the question becomes: what are our principles about allowing multiple elements/attributes/encoding ways (e.g., wrapper vs. milestone vs. stand-off markup) for a more or less similar thing?
D #1099 Does this wiki, especially the part about the object inheritance model, contain most of what we've been discussing about P6 this morning? https://wiki.tei-c.org/index.php/P6-dev EBB: note concept of "module fragmentation" (re splitting date/time from names/places/etc)
A #375 The ticket is about adding new types for <list>, which isn’t inherently P6-related, but it also points to an old P6 desiderata page worth looking at https://wiki.tei-c.org/index.php/P6-dev Some highlights: * rename msDesc elements towards a more generalized use * an “object inheritance model” * context-based definitions * apparently drop @type from list for some reason
B #346 Also closed. Proposal to split date and times and names and places into a new TEI chapter. (Probably a good idea to do in P6 — one chapter for names & entities, another for dates & times.) EBB: note concept of "module fragmentation"
C #314 The topic was mostly about backward compatibility when restricting a previously-lax content model; reminder that P6 will also have to have clear rules and principles about backward compatibility.
D #275 Speaks to the problems of understanding bibliographic citation: confusions of <biblFull>, <biblStruct>. Ticket wanted to deprecate <biblFull>, but we (subgroup) are recognizing this as expressing a certain kind of citation suitable for digital projects. Ticket expresses frustration about too many different elements but "can't do anything about it now." What kinds of bibliographic citation should we be supporting in P6 and can we do this without proliferating elements.
A #140 Concerns around backwards compatibility for iso* attributes. In 2008 it was thought that moving to P6 would be the only time to do this, though we have had deprecation mechanisms since, so this may not be a very P6-specific issue. However this brings up how new attribute classes may need be determined based on their datatype even if they are expressing the same concept (e.g. time as a concept but rendered as iso, custom, tei-defined, etc)
B #56 <del> to be added to macro:specialPara like <add>. Issue is closed. Relevance for P6, users sometimes need to delete things larger than phrases and this leads to hierarchical issues. Is <delSpan> sufficient for achieving this in P5. For P6, we need to think of a different method(s)
C #20 Not relevant.
The following is an AI-generated summary based on the table above. What ideas are emerging about P6? (Claude AI Sonnet 4.6).

Class & Attribute System

  • Rework the class system entirely — attributes should be "first class citizens" like elements
  • Allow things to be defined as either elements or attributes, with possible serialization of any attribute as an element
  • Context-dependent content models (using @predicate with XPath or similar abstraction)
  • Object-oriented inheritance model for classes, with descending hierarchies
  • Multiple inheritance support, with user-defined classes combining what they need

Schema & Validation

  • Drop DTDs entirely
  • Explore expressing TEI schema logic fully in XPath/Schematron, potentially generated from a simpler source
  • Keep Relax NG for speed/ease of validation, possibly chain it directly instead of ODD
  • Clarify what TEI conformance actually means (update section 24.4.6)

Simplification & Consolidation

  • No numbered divs (e.g. div1, div2)
  • Reduce redundant attributes and encoding options (e.g. @ed vs @edRef)
  • Reconsider bibliographic elements (biblFull, biblStruct) to avoid proliferation
  • Revisit hand/handShift as example of duplicate encoding paths
  • Drop or rethink "block" vs. "inline" distinctions in favor of semantic/functional categories

Backwards Compatibility & Versioning

  • P6 needs clear rules and infrastructure for non-backwards-compatible releases, possibly a forking mechanism
  • Previous TEI versions (e.g. P3) could be expressed as profiles within P6
  • Clear version labeling and numbering principles needed

ODD & Tooling

  • Consider model ODDs as starting points rather than requiring everyone to start from TEI All
  • Revisit ODD chaining; consider whether valLists should become taxonomies
  • Build better tooling (e.g. updated ROMA, ODDbyExample questionnaire)
  • One unified repo for P6

Philosophical/Structural Principles

  • Define clear use of modal verbs and terms like "mandatory" in the Guidelines
  • Decide how much TEI should specify vs. leaving to users to document
  • Address "module fragmentation" — reorganize chapters (e.g. names/entities, dates/times as separate chapters)
  • Peer review vs. automated validation: acknowledge limits of what schemas can enforce

B. Why not P6 yet? Vs. Why P6 now?

In this column, write reasons why we should not bother with P6. In this column, write reasons why we need P6 now?
It will be painful and time-consuming. The P5 schema has become unmanageable.
Confusion over multiple standards; fracturing of community P5 should be historicized.
People could be attracted to TEI through P6 (in the sense of: “it’s a straightforward and intelligently designed entry point into text encoding” instead of “it’s an overwhelmingly huge collection of different elements you can use with several ways to encode similar things”).
End users might be used to P5 and not willing to change at first (even just out of practical reasons), but the moment they run into its limitations or constraints, or notice that there are different ways of encoding the same thing, the need for P6 becomes more evident.
(From subgroup D discussion): The P5 is like an old house with a crammed attic and some mold problems. We should be taking things from the old house to a new house with bigger windows and more doors. (Cf. Emily Dickinson, "I dwell in Possibility.")
Developing P6 may help us to find new users of the TEI. We are not outdated.
TEI should not be about policing textual practice and interpretation; overly constrained schemas that rely on ossified “common sense” understanding of text alienates users, requires significant continuous updates to maintain currency (and be responsive to shifting understanding of text), and will always be insufficient

AI-generated summary based on notes above (Setting the stage for P6) (Claude AI Sonnet 4.6).

Reasons not to bother with P6 yet Reasons to develop P6 now
Frustrations with P5 could potentially be addressed within P5 itself (SB) The TCW09 closing statement has actively held back progress toward P6 (MH)
P6 doesn't need to happen quickly — P5 itself took several years to develop (MH, SB) The class system in P5 needs to be broken in ways that are incompatible with backward compatibility, making a new version name necessary
Those not ready for P6 can maintain a robust community of practice around P5, as with Python 2 vs. Python 3 (RV) ODD is underspecified, hobbling groups like ATOP — a fresh start would allow better ODD processing in languages beyond XSLT (MH, RV)
Mixed content is central to TEI and XML handles it well — no compelling technical reason to abandon the current approach (RV) New technologies (AI, graph databases) and the desire for multiple serialization formats create pressure to rethink TEI's foundations (JT, TR)
Abstraction away from XML would significantly change how TEI is taught and learned, with uncertain results (UHK) Context-dependent element definitions are currently possible but require deep expertise in a complex class system — P6 could make this tractable (RV, JT)
Over-abstraction risks collapsing the "editability threshold," making hand-encoding and humanities learning harder (TR) HTML and RDFa offer a path to making TEI work natively in the browser without tools like CETEIcean (MH, RV)
The current class system makes it hard to distinguish specialization from abstraction, and a cleaner formalization is needed (HBS)
TEI should support multiple serializations (XML, JSON, graph-friendly formats) more cleanly — something P5's architecture wasn't designed for (MS, JT)

C. Element SubGroup Classification Exercise

1. SubGroup Classification Exercise (MS, HBS, RV)

List
│
├── Pointer group
│   ├── listRef
│   ├── (listRelation)
│   ├── (specGrp)
│   ├── (linkGrp)

Resource
│
├── facsimile
├── (text)
├── (standOff)
├── (TEI)
│
├── Resource Part
│   ├── floatingText
│   ├── lg
│   ├── (div)
│   ├── (sp)

Named Entity
│
├── org
├── (person)
├── (place)

Statement
│
├── recordingStmt
├── publicationStmt
├── (change)

Feature (or Detail)
│
├── pubPLace
├── seal
├── publisher
├── terrain
├── region
├── support
├── floruit
├── affiliation
├── msContent
├── addrLine
├── colloc

Encoder Operation
│
├── revisionDesc
├── (fileDesc)
├── (encodingDesc)
│
├── Encoding Declaration
│   ├── fsDecl
│   ├── fsConstraint
│   ├── fDecl
│   │
│   ├── Verbose
│   │   ├── variantEncoding
│   │   ├── transcriptionDesc
│   │   ├── prefixDef

Analysis
│
├── s
├── gloss
├── (phr)
├── (seg)
├── (w)

2. SubGroup classification exercise (SB, EBB, TR, TOC)

Interpretation

Classification
│
├── usage
├── trait
├── per

Referential
│
├── mapping
├── bibl

Naming
│
├── ident
├── geogName
├── actor

Segmentation
│
├── text
├── div
├── entryFree
├── castItem

Markers
│
├── milestone
├── anchor
├── watermark
├── witEnd
├── gb
├── cb
├── g
├── pb
├── lb
├── handShift

Medium/a
│
├── notatedMusic
├── facsimile
├── pause
├── sound
├── set

Transcriptional
│
├── interaction

Bridgework
│
├── app