TEI Technical Council Short Virtual Face-to-Face Meetings, 18–19 May 2025

Meeting times

• American subgroup meets Sunday May 18: 20:00–23:00 ET | 17:00–20:00 PT
• European subgroup meets Monday May 19: 10:45–13:45 IST | 11:45–14:45 CET
• Full Council meets Monday May 19: 06:00–09:00 PDT | 09:00–12:00 ET | 14:00–17:00 IST | 15:00–18:00 CET

Attendance

	Sunday, North American Group	Monday, European Group	Monday, Full Council
Syd Bauman (SB)	x		x
Helena Bermúdez Sabel (HBS)		x	x
Elisa Beshe­ro- Bondar (EBB)	x		x
Elli Bleeker (EB)		x	x
Ulrike Henny-Krahmer (UHK)		x	x
Martin Holmes (MH)	x		x
Patricia O’Connor (TOC)		x	x
Torsten Roeder (TR)		x
Martina Scholger (MS)		x	x
Joey Takeda (JT)	x		x
Raff Viglianti (RV)	x		x

TEI 2025 Conference and Council F2F:

• Conference website: https://tei2025.confer.uj.edu.pl/en_GB/
• Conference dates: 16–20 Sep 2025
• Magdalena Turska is chair of programme committee and requested volunteers for reviewing submissions
• Council meeting slated: Sun 14, Mon 15, and Tue 16 Sep 25.
• Action on EBB by 10 June: Confirm Council meeting F2F dates with local organising committee. Also find out information for planning SIG meetings to limit conflict with poster/paper sessions.

Schedule next release

• Refridge: week of Balisage (4–8 Aug)
• Freeze: starts Mon 11 Aug
• Release: Fri 15 Aug
• Release Techs: EB, TOC, HBS, JT as Pacific Rim Monitor
• EBB set Guidelines 4.10.0 milestone to 11 August 2025

Request about simplePrint

• Request from Martin Mueller sent to EBB, who shared with Council
• NA Subgroup: thinks perhaps we should represent these (simplePrint? TEIPublisher?) in https://tei-c.org/guidelines/customization/
• JT: simplePrint has historical value, lineage of authorship / ownership is blurry—how much is Council responsibility now?
• We would not want to remove this from the “Customizations provided by the TEI Consortium” table without buy-in from some of the other original authors.
• We don't want to put TEI Publisher's ODD in that position either.
• We should reframe the Preface / description of simplePrint to indicate its historical significance, that it's not updated / current.
• Does “Customizations provided by the TEI Consortium” imply that these customizations are maintained by the TEI Council? Council needs to make this transparent in documentation.
• JT: More accurate to state that these customizations are published by the TEI-C (that properly uses @source to pin it to the TEI version it derives from) rather than ‘provided’, so there’s no implication that the TEI-C is responsible for maintaining the customizations?
• Currently provided as exemplars; they may have two roles in the sense that some (like jTEI) are intended for use as-is, and others might be more intended to exemplify how to get started writing your own customizations. We might distinguish these two purposes.
• We should clarify to ourselves and community the purpose / function of these exemplars: see https://journals.openedition.org/jtei/2573#tocto1n2 : categorize these as:
  • Exemplars
  • template customizations
• Council decision: Keep simplePrint and create tickets out of points raised by Mueller, adding the respective authors to the tickets to get their input on the revisions Council makes.
• Action on EBB to write to Mueller about Council decision and tell him that Council will create tickets out of his email requests.
• Task Force for hosting, promoting, maintaining, and updating customizations (and other materials like the TEI By Example)
  • Volunteers: MH, JT, SB
  • We also need volunteers to represent different languages in the exemplars). Invite Board members?

oXygen version compatibility for TEI plugin

• Council decided we will support version 24 for backwards-compatibility.
• MH is working on this, but it's not working yet. The question may be whether or not SyncRO will give us permission to take old .jar files and put them in our repo or some such. We may need to provide some new instructions.
• Need other Council members to learn about this. EBB and MS joining.

Partnerships with other organizations

• ISO: TEI liaison update
  1. TR has expressed interest and is following up with the ISO people
• Kiyonori Nagasaki: question about TEI collaborating with CODATA
  1. https://codata.org/about-codata/
  2. https://codata.org/about-codata/our-mission/
  3. EBB has advised Kiyonori to write to the Board. If it costs money, now may not be the best time.
  4. Council recognizes that affiliation might be useful for us, but we would need to find out more.
  5. May be useful to the extent that TEI benefits from scientific association.

Rahtz Prize

• EBB to convene with RV and Kiyonori Nagasaki before mid-June.
• Should we revive the Community Prize? [Post-meeting Update: This is up to the Rahtz Prize Committee. Hugh Cayless reports that we have a total of $1000 USD to award, so multiple prize-winners would simply share this amount between them.]
• https://tei-c.org/activities/rahtz-prize-for-tei-ingenuity/

Recent action items

• Action on TOC by 2025-06-30: to take on the general updating of TCWs to bring into alignment with Google Docs or alternative versions.
• Action on TR by 2025-06: fix link to Computable Text and Media SIG and make sure people know how to join.

TEI By Example

• TBE linked on TEI-C website
• Plans: EBB, James Cummings, JT, and Sabine Seifert to try to organize a meeting with Ed Mackenzie, Melissa Terras, and the Edinburgh group and all others interested.
• JT: may be related to the TEI Customizations question about resources developed by the community.
• Call the meeting and discuss ways active TEI pedagogy people can contribute without Council taking on management role.
• Revival of the Pedagogy SIG in relation to this?

Pull Requests

• Documentation PR: https://github.com/TEIC/Documentation/pull/18 (for TCW 22 re checking Jenkins release artifacts) Reviewed and approved.

TEI PRs

• Translation PRs, updating branches as needed (e.g. PR #2582).
  https://github.com/TEIC/TEI/labels/i18n
  NA subgroup merged #2582 (after updating and review), and closed.

• PR #2600 - Remove mobi from generated outputs!
  High priority.
  NA subgroup: MH found a few more references to Kindle / Kindlegen / mobi, so he’s removing these before we merge.
  JT would like us to add a note about removal of mobi format, probably here: https://github.com/TEIC/Stylesheets/tree/dev/profiles/teikindle
  Merged after the VF2F.

• PR #2534 - no duplicate <attDef>s allowed.
  SB merged dev into this branch before the meeting and added extensive comment on the ticket.
  NA Subgroup: Not merged yet, but we went for option 2 with this Stylesheets ticket
  EU Subgroup: Assigned the Stylesheets ticket so it gets tackled in the next Stylesheets Group meeting. We suggest to label the PR as “blocked”.

• PR #2698 - A fix for issue #2642
  NA subgroup thinks we should add documentation to TCW 20 that discusses SB’s intuition that ( a | b )* is preferable to ( a*, b* )* primarily because there are a lot of cases of the former in the Guidelines already. (Do we want Schematron that notices this particular construct?)
  EU subgroup has implemented the change proposed by SB; merging and closing the PR. EU subgroup created a new issue (2704) to add this to TCW 20.

• PR #2694 - Removed enumerated values in the attribute descriptions ‘Status Go’
  EU subgroup merged it.

• PR #2691 - Fix spelling in 16 files (but I18N/examples-fr/original.en needs discussion)

  EU Subgroup: will revert the changes in generated files, and re-generate them.

• PR #2692
  SB: Updated branch passes tests in the Docker.
  NA subgroup merged / closed.

• PR #2693 - Guidelines lists processing
  SB: updated and re-tested, all tests pass. Recommends merging, closing, and opening a new ticket for the <specList>.
  EU: We merge the PR, and we open two issues: one for the <specList> (#2706) and the other for suggested values of @rend in the <list> spec (#2705).

• PR #2638 - Make @rotate attribute on <zone> type teidata.numeric
  SB shares unpublished examples from a working project and indicates that in this project describing the 5+ angles needed more precisely than to the degree would be overkill.

  • NA subgroup notes that @rotate is currently defined only in relation to <surface>, but a) it’s defined to be “clockwise” only in the spec, and b) we now allow nesting of <zone>. Should @rotate be defined in relation to its container <zone>? Should we allow for expression of counterclockwise direction as a negative number? We don’t have examples of @rotate in the Guidelines, so maybe we need some examples. SVG <path> can express this better than TEI can. JT shares examples from ALTO: https://altoxml.github.io/documentation/use-cases/shape/ALTO_shape_usecases.html

  • EU subgroup notes that the current definition …”with respect to the normal orientation of the parent surface element” cannot be kept anyway because of nested <zone>s. We propose that @rotate is not calculated in relation to its parent but in relation to the origin of the coordinate system, following the same principles of the att.coordinated attributes.

  • Should other elements, like <line>, have the attribute @rotate?

  • Full Council discussion: JT, RV, EBB, HBS: seems not problematic to change the datatype as OP requests. Can simplify conversions from PageXML / Alto, relationship to IIIF (see https://iiif.io/api/image/2.0/#rotation). Action on EB to open new tickets for

    1. better defining `@rotate` with respect to nested zones and multiple surfaces (#2709)
    2. good examples (#2710).

• PR #2538 - Interleave
  How do we review this? SB: merged dev and made a few tweaks; all our tests pass. The bad news is that there are no tests that exercise <interleave> because the test procedure validates ODDs against p5odds, which is just wrong. (Note that p5odds, the schema against which the Guidelines themselves, i.e. p5.xml and p5subset.xml are supposed to be valid, does not allow <interleave>, precisely because we do not want to use it in P5. But we do want to be able to test it. So this will take some updating of the test Makefile, too.) SB hand-tested an <interleave> (using one of the examples in TD), and it worked just fine, so recommends merging this now and opening a new ticket to generate a good test.

  • NA subgroup thinks we should merge this in order to give people the possibility to apply <interleave> if they wish. We set the deprecation date for @preserveOrder to 2026-06-15.
  • JT opens a new ticket (#2703) about the need for testing interleave.

• PR #2509 - Should we close this and open a fresh branch with new Mausatron?
  SB: Maybe. Perhaps it could solve the NVDL problem?
  EU subgroup agrees with closing the PR and opening a fresh branch with the latest release of Mausatron in case this fixes some of the problems. If not, we need to review our decision from https://github.com/TEIC/TEI/pull/2509#issuecomment-2127923822

  • The problem is that oNVDL does not properly handle Schematron that has abstract patterns.
  • Can we remove NVDL? oNVDL processing helpful for validation of SVG (and other namespaced XML) within TEI.
  • MH: oXygen has the most up-to-date oNVDL. There’s a w3c web interface for oNVDL for validating HTML, CSS, and nested SVG in HTML.
  • Maybe we can update our processor?
  • Action on SB by 2025-07: Write to SyncroSoft people about to attend Markup UK about oNVDL to see if they will update it to match Schematron?
  • Council ultimately decides to keep this open in hopes of better oNVDL processing, and also for SB to add new Mausatron by time of next release.

Stylesheets tickets

• PR #710 - Fix #703: update link in README.md
  • Action on EBB by 2025-08 to deal with the TEI website update needed
  • Directing the community to set up TEI Docker environment seems the best way to update this.
  • Also tackle Stylesheets ticket: #720 - Rewrite the “Using the TEI Guidelines” page.

TEI tickets

• #2116: NA subgroup: Needs consultation with East Asian SIG.

• #1933: NA subgroup: Do we need another attribute other than @xml:lang that could have multiple values?

  • @targetlangs on <exemplum> would allow us to indicate specific languages or ”mul” in addition to the @xml:lang on <egXML>.
  • Processing could default to representing the targeted language first, rather than default with English first.
  • More sophisticated idea than just “mul” would be to recognize that a structure in classical Greek is especially relevant to Japanese documents. This could then be handled by an editor adding “ja” to the @targetlangs on the Greek example.
  • We think we don’t need the <exemplumGrp> proposed on the ticket in October 2021.

• #2335: NA subgroup wants to discuss with full Council: what mechanism(s) could we create to locate specs w/ not many languages in glosses/descs, or to invite community translation? [To be discussed in future Council meeting.]