August 2020 - Tei-council - lists.tei-c.org

Stylesheets meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 01 Sep '20

01 Sep '20

Dear all, This is the Zoom-Link for our Stylesheets Meeting tomorrow: https://us02web.zoom.us/j/88599847406?pwd=WGZJUkQ4RGhYQXplcnNyc1RWQU4xdz09 Best, Martina

4 3

proposal for encoding ruby glosses
by Scholger, Martina (martina.scholger＠uni-graz.at) 28 Aug '20

28 Aug '20

Dear all, I'd like to share with you the proposal from Kiyonori Nagasaki and his colleagues from the East Asian / Japanese SIG on encoding ruby glosses in TEI https://docs.google.com/document/d/1rRgBRYpxUlsnMEHbOPW-92u_AIMNwq9axGtpI1U… Please have a look at it. Best, Martina

1 0

oXygen TEI plugin and debian packages
by Scholger, Martina (martina.scholger＠uni-graz.at) 21 Aug '20

21 Aug '20

Dear TEI Community, The oXygen TEI plugin has been updated with the latest version of the TEI Guidelines 4.1.0 and Stylesheets 7.50.0. A description on "How to automatically update your TEI framework in oXygen" can be found here: https://github.com/TEIC/oxygen-tei/blob/master/oxygen-tei-plugin.md Furthermore, the Debian packages are available at https://packages.tei-c.org/deb/. Best, Martina Martina Scholger Centre for Information Modeling Austrian Centre for Digital Humanities University of Graz A-8010 Graz | Elisabethstraße 59/III +43 316 380 2291 martina.scholger(a)uni-graz.at<mailto:martina.semlak@uni-graz.at> http://informationsmodellierung.uni-graz.at<http://informationsmodellierung.uni-graz.at/> | http://gams.uni-graz.at<http://gams.uni-graz.at/> Chair of the TEI Technical Council | http://www.tei-c.org/ Institut für Dokumentologie und Editorik e.V. | https://www.i-d-e.de/

1 0

No masters
by Hugh Cayless 20 Aug '20

20 Aug '20

Hi All, I have deleted the master branches for TEI and Stylesheets, and plan to gradually work through the remainder. My inclination on most of them is probably to wait until there's an automated migration tool, as I understand pull requests may break, etc. Hugh

2 2

Release 4.1.0 complete
by Hugh Cayless 19 Aug '20

19 Aug '20

Dear All, especially Martina who can now announce it, We (Jessica, Nick, and I) have completed the release. You are free to commit to dev again. Thanks to all who dropped in on Slack to help out. The only remaining bits are the Oxygen plugin, which I can't build, and the Debian packages, because I was a bad release technician and forgot to ask Peter for the passphrase. All the best, Hugh

4 7

release minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 Aug '20

19 Aug '20

Dear release technicians, here is a document were you can take notes during the release (in case this is necessary). It also contains the email to the TEI-L https://docs.google.com/document/d/1PJryKNeKIzUEpdFlaQaJAhO9F3XM23IU66lB3QR… Best, Martina

2 1

release notes
by Syd Bauman 19 Aug '20

19 Aug '20

I updated the release notes *in the release-4.1.0 branch* (because that's what Martina did). While there are always improvements to be made, I think they are mostly good to go. Still need a release code name (why do we have those -- they are fun for us, but since we do not actually use them ...?). And I think we should consider deleting the prhase "to represent primary source materials" from the 1st bullet point.

2 1

Deb build warning
by Martin Holmes 17 Aug '20

17 Aug '20

Hi all, I'm still getting this warning on the release branch of the Stylesheets: dh_clean: warning: Compatibility levels before 9 are deprecated (level 5 in use) Didn't we decide to push that compat value up to 9? Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Release branches
by Hugh Cayless 17 Aug '20

17 Aug '20

Dear All, I've created release branches "release-4.1.0" for the Guidelines, and "release-7.50.0" for the Stylesheets. All the best, Hugh

3 3

Annotations and impasses
by Hugh Cayless 17 Aug '20

17 Aug '20

Hi All, Since we essentially have today to make the go/no-go decision for getting Annotations into this release. We seem to be deadlocked in a couple of ways, and I would like to see if we can un-jam things. Syd and I are arguing over whether annotations should look like: <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <respStmt xml:id="HAC"> <resp>creator</resp> <persName>Hugh Cayless</persName> </respStmt> <ptr target="http://example.org/description1"/> <note>tag1</note> </annotation> or <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <annMeta> <respStmt xml:id="SB"> <resp>creator</resp> <persName>Syd Bauman</persName> </respStmt> </annMeta> <annBody> <ptr target="http://example.org/description1"/> <note>tag1</note> </annBody> </annotation> Syd's argument (and you should correct me if I'm misrepresenting your opinion, Syd) is that it's cleaner to partition things this way and we might want in the future to say virtually any TEI element could be an annotation body. My counter to this is that we set out here to implement the Web Annotation Data Model (or parts of it at least) in TEI, and that WADM doesn't have extra containers for annotation metadata or bodies. Further, WADM doesn't do specialized body types. They have text and they have URIs. I'm certainly in favor of adding useful features to TEI annotations, but if we want to do that in the next round of work on annotations, we'll have to do it by adding new TEI functionality (probably via new elements), and I don't think partitioning the content of annotation will buy us anything. It might make it worse, because the extra-sparkly new TEI functionality won't be compatible with WADM:body and therefore probably shouldn't go in an <annBody> element. To compound this, Laurent seems to say that WADM was only ever meant to be an inspiration and actual interoperability with Web Annotation wasn't a goal they had in mind in requesting this feature. I'm just going to go cry for a bit...excuse me. Ok. I will sum up: I would really like to have WADM compatibility this year because I have things I want to do with it. My proposal is that we proceed with WADM-compatible annotations and then begin work on more powerful TEI annotations. I would like to keep the content model of <annotation> as simple and as close to WADM as possible, but I won't pout if I'm voted down on that. What do you all think? Hugh

7 12

Freeze
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 Aug '20

16 Aug '20

Dear all, I would like to remind you that we had agreed to freeze starting tonight. Please keep that in mind and check with the release technicians in case of late changes. Best, Martina Von meinem Huawei-Mobiltelefon gesendet

2 1

Stylesheets 454 and thus TEI 1848
by Syd Bauman 16 Aug '20

16 Aug '20

I have put multiple days of debugging work into Stylesheets 454, the release-blocking error that means a <classRef>, or at least a <classRef> with an @except, is ignored when processing an ODD. While I have made serious progress (some of which is in the sydb-454 branch), it is looking like I will not have a viable solution by the end of the day. Thus I think we need an alternate solution, which would be to back out [1] and either leave title page stuff out of <lem> and <rdg> for this release, or use some other ODD mechanism to put them in there. Possibilities (listed in my order of preference) include: 1. Use a bunch of <elementRef>s 2. Use <classRef> w/o @except, and add a <constraint> to flag <binaryObject>, <graphic>, and <castList> as invalid 3. Make a new class "model.frontPart.apparatusable" and put the needed elements in it. 4. Use <classRef> w/ @include (but I am highly suspicious that this will fail in exactly the same way). We can change any of the above back to <classRef> w/ @except after 454 is fixed. The other possibility, of course, is that someone else will take a look at this and fix the bug in the next few hours. If anyone wants to join my for a screen-sharing debugging session, speak up. That said, I really have other things I need to do today, too. :-| Notes ----- [1] TEI repo commit 193e6283321aeeb68b9a93b0d95b10a82148ef74

1 0

OxGarage release
by Peter Stadler 13 Aug '20

13 Aug '20

Hi all, the last release of OxGarage was done in June 2019 and since then not much development has happened, yet there are some minor changes that IMHO qualify for a new release. Most of all, the current master branch won’t build anymore on Travis nor on DockerHub – which is already fixed in dev. While at it, I already created a new main branch to eventually replace master starting with this release. (As a side note, Hugh was right about GitHub providing tools for doing this change later this year, see https://github.com/github/renaming#later-this-year. So I won’t touch other repos …) So, my proposal is to release OxGarage v3.1.0 next week and take care of the branch name switch with this release. If I hear no objections, I will take this as silent consent and do so :) Best Peter

1 1

REGENERATING, NOT!
by Syd Bauman 11 Aug '20

11 Aug '20

Re: Stylesheets meeting further info BTW, passing REGENERATING=1 to the Stylesheets/Test/Makefile tells the Makefile to not bother doing all those `diff` commands, but it does NOT actually regenerate the expected_results/. I.e., it just generates the output files (like test15.odd.rnc), but does not move them into expected_results/. One would have to do that by hand. (I think this was a purposeful change by Martin or someone just to avoid clobbering all the expected_results/.) Moreover, back on 2020-03-18 Martin commented out the diffs of test21.rnc, test30.rnc, and test30.dtd. I think we should probably put those back, yes, Martin?

3 2

Slightly Updated: Steps for updating p5subset.xml in Stylesheets repo
by Martin Holmes 11 Aug '20

11 Aug '20

This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets. The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release. This is how it goes: 1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5. 2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull. 3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch. 4. Replace the source/p5subset.xml in the subsetSetup branch with the fresh one. 5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch. 6. Fix any problems. At this point, if there are problems too difficult to fix in the time you have available, abandon the process and put in a ticket for the Stylesheets repo. If the error is serious, make it a release-blocking bug. 7. Commit changes to subsetSetup branch. git push. 8. Switch back to the dev branch, git pull, and merge changes from the subsetSetup branch. git push. 9. Watch Mr Jenkins to make sure all is well. -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

2 2

Fwd: Steps for updating p5subset.xml in Stylesheets repo
by Martin Holmes 11 Aug '20

11 Aug '20

-------- Forwarded Message -------- Subject: Steps for updating p5subset.xml in Stylesheets repo Date: Fri, 7 Aug 2020 08:41:32 -0700 From: Martin Holmes <mholmes(a)uvic.ca> To: Syd Bauman <s.bauman(a)neu.edu> CC: Martin Holmes <mholmes(a)uvic.ca> This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets. The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release. This is how it goes: 1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5. 2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull. 3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch. 4. Replace the p5subset.xml in the subsetSetup branch with the fresh one. 5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch. 6. Fix any problems. 7. Commit changes to subsetSetup branch. git push. 8. Switch back to the dev branch, git pull, and merge changes. git push. 9. Watch Mr Jenkins to make sure all is well. -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Stylesheets meeting Tue 11 Aug
by Syd Bauman 11 Aug '20

11 Aug '20

Time to get our heads spinning 'round circularity! We are planning a Stylesheets group meeting for this Tue 11 Aug at 13:00Z.[1] This is an important meeting, because we are going to step through the process of updating the p5subset.xml that the various build processes are using; i.e., we are implementing (for the first time) our planned "fix" for the circularity problem. (Not really so much a fix as a work-around, IMHO.) I expect we will be using Google Hangouts unless someone says otherwise. Notes ----- [1] 13:00 UTC is: 06:00 PDT 09:00 EDT 14:00 BST 15:00 CEST

3 2

Guidelines JQuery
by Hugh Cayless 06 Aug '20

06 Aug '20

Hi All, I've upgraded the Guidelines' copy of JQuery to 3.5.1 (the latest) and fixed a bug that followed on from that. Does anyone remember why we haven't nuked P5/Utilities-1 (which I believe was where old XSLT 1.0 Guidelines generation code got put, like over a decade ago). Can I get rid of it? Please? This is the sort of thing I was calling "cruft" in the meeting this morning :-). Hugh

4 5

WG: TEI and meeting the needs of most users most of the time
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Aug '20

04 Aug '20

Dear all, FYI - I would like to share with you an email from Martin Mueller. Best, Martina Von: Martin Mueller <martinmueller(a)northwestern.edu> Gesendet: Samstag, 18. Juli 2020 00:25 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Betreff: TEI and meeting the needs of most users most of the time Dear Martina, I have been working with TEI Publisher 6.0 (or rather trying to wrap my aging brain around its complexities), and in doing so I have spent the past two days looking at TEI documentation. This has confirmed my long-held conviction that TEI documentation is very good for folks who know what they are doing but need to look up this or that. It does not do much “newbies”. Luther’s “Kleiner Katechismus” (1529) has often been on my mind when thinking about TEI documentation. It badly needs its own Small Catechism in which everything that you need most of the time is clearly described then and there without reference to a very large document, which becomes useful only after weeks of using it. Within a few years of the first release of the TEI Lou and Michael published TEI-Lite with the goal of meeting 90% of the uses of 90% of the users—a classic and extremely successful implementation of the 80/20 rule. For quite a few years there was a very nice guide to it on an Oxford site. I think it was Sebastian’s work. It told you everything about the ~150 elements of that schema without distracting the users’ minds with stuff they did not (yet) need to know. In the years since then the TEI has spent a lot more time refining this and that but has spent hardly any time or energy on “preaching beyond the choir”. There are many reasons for the absolute and relative decline of the TEI as an institution, but the lack of attention to ordinary users has probably had a good deal to do with. One of my friends tells me that in Medical School he got the advice “When you hear hooves clattering behind you, think horses not zebras”. The TEI has been all about zebras. An almost funny example is the documentation for TEI Simple, the project that Sebastian and I worked on and that suffered greatly from his illness and death, although its Processing Model was eagerly picked up by Wolfgang Meier and Joe Wicentowski. In the final report to the Mellon Foundation I wrote the following paragraph about it: At an earlier stage the project was called TEI Nudge, and throughout it has taken inspiration from Richard Thaler's and Cass Sunstein's Nudge with its persuasive argument that in many walks of life people will make better choices if they are offered well-designed default solutions, as long as they are free to opt out of them. TEI Simple focuses on interoperability, machine generation, and low-cost integration. The TEI architecture facilitates customizations of many kinds; TEI Simple aims to produce a complete ‘out of the box’ customization that meets the needs of the many users for whom the task of creating a customization is daunting or seems irrelevant. TEI Simple in no way intends to constrain the expressive liberty of encoders who do not think that it is either possible or desirable to follow this path. It does, however, promise to make life easier for those who think there is some virtue in travelling that path as far as it will take you, which for quite a few projects will be far enough. Some users will never feel the need to move beyond it, others will outgrow it, and when they do they will have learned enough to do so. On the Customization page of the TEI site, TEI simplePrint is described as “An entry-level customization, focused primarily on the needs of those encoding Western European early modern printed material”. Instead of stressing what you can do with it, the description dwells on what you cannot do. This is plain wrong in several ways. You can encode the Iliad in Greek, the Torah in ancient Hebrew, Anna Karenina in the Cyrillic alphabet, the Koran in Arabic (I believe),and a lot of other stuff. It is neither “Western” nor “early modern” But the summary of TEI Lite is not much better, describing it as “basic elements for simple documents”. Its 150 elements are not particularly ‘basic’, and the documents encoded by it are anything but simple. I wrote an early draft of the documentation for TEI Simple, using (with their permission) Lou’s and Michael’s’ excellent TEI Lite documentation, but did not see the final version, and indeed until this morning never read the following paragraphs to which I would have strongly objected at the time: Like every other TEI customization, TEI simplePrint was designed for use with a particular type of material. If the material you are planning to encode matches the following criteria, then TEI simplePrint is for you. If it does not, it may not be. You are encoding print material, rather than manuscript: simplePrint provides no way of encoding manuscript features such as correction, deletion, or scribal variation. You are encoding material from the Early Modern period (i.e., up to the end of the nineteenth century): some of the features for which simplePrint provides encodings are rarely found in modern materials. You are encoding material written, broadly speaking, within the Western European tradition, using largely Western European characters. simplePrint does provide facilities for encoding short passages in non Western European languages, but many features needed to cope with Asian or ancient scripts are missing. Your intention is to provide a relatively simple encoding for a large amount of material, rather than a rich encoding of a small amount of material: simplePrint is intended to help libraries and archives wishing to go beyond basic digital facsimiles, rather than to support specialist research. It does not, for example, include features for detailed linguistic tagging beyond simple word-level tagging, nor for specialised text types such as dictionaries, historical or biographical databases, etc. These paragraphs are condescending in tone and inaccurate in substance . The term “Early Modern” is misused, the reference to “Western European characters” is grossly inaccurate, and the claim that texts encoded in this fashion do not “support specialist research” does not hold up to much examination. My mother, a pediatrician, did not care much for Dieter Borsche, especially in one of his films where as a doctor he proclaims that “Der ist kein wahrer Arzt der noch kein Serum hat erfunden.” Medicine most of the time is about horses, not zebras—a useful lesson right now when the daily Corona virus deaths in Florida (20 million people) are as many as in the European Union (400 million people). But the TEI is also about horses most of the time—a dangerous thing to forget. The language of the Simple documentation and of quite a few paragraphs in the Guidelines carries an undertone of indifference to encoding schemes that fall below some level of complexity, as if the interest of a TEI encoded document were only a function of the complexity of its encoding. But this is exactly the wrong way of looking at it. Most encounters of end users with TEI-encoded documents involve documents with moderately complex encoding. I can certainly appreciate the challenges of virtuoso encoding and the pleasures of a difficulté vaincue , but the thriving of the TEI depends primarily on providing quite mundane services to a growing community of readers and users. This is not a new topic for me: some years ago I warned that the TEI might become an Orchideenfach. https://sites.northwestern.edu/scalablereading/2016/09/20/whither-tei-the-n… Chapter 23 of the Guidelines has the sentence “it is almost impossible to use the TEI schema without customizing it in some way.” That is not true: a large majority of TEI encoded texts have been encoded encoded in schemas that are identical with or slight variants of TEI Lite, TEI Guidelines for Libraries, Level 4, the EEBO dtd, the DTA schema, the Clarin schema and perhaps a few others. “ Standardize where you can, customize where you must” might be good advice. It would not be difficult to derive from these schemas a new version of TEI Lite. I would call it TEI Vanilla because it does for encoding what Vanilla does for ice cream: it works most of the time in the sense of supporting moderately complex encodings of quite complex documents. If the TEI wants to thrive it needs to have some version of TEI Vanilla with a built-in Processing Model and a documentation that has the virtues of Luther’s Small Catechism: enough to give ordinary users a clear pathway to heaven. Feel free to share this letter with the Council or Board With best wishes MM Martin Mueller Professor emeritus of English and Classics Northwestern University

4 3

meeting starts in 15 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Aug '20

04 Aug '20

Dear all, our Council meeting starts in 15 minutes, this is the agenda with the zoom link: https://docs.google.com/document/d/1HhU-alLRORO-aHpNH07xXU0NugTsKWACrODIDib… Best, Martina

1 0

Next Council meeting - Tues, Aug 4
by Scholger, Martina (martina.scholger＠uni-graz.at) 03 Aug '20

03 Aug '20

Dear all, After receiving some feedback on my request to swap the Council and the Stylesheets meeting, the Council meeting will now be tomorrow (Tues, Aug 4) at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30. This is the agenda for the meeting: https://docs.google.com/document/d/1HhU-alLRORO-aHpNH07xXU0NugTsKWACrODIDib… Please find the zoom link in the agenda. Best, Martina

1 0

refrigeration & next meetings
by Scholger, Martina (martina.scholger＠uni-graz.at) 02 Aug '20

02 Aug '20

Dear all, I would like to remind us that we are already in the refrigeration period. There are still a lot of issues labeled with milestone 4.1.0 (https://github.com/TEIC/TEI/issues?q=is%3Aissue+milestone%3A%22Guidelines+4…). Please have a look at the list and remove those issues, that you will not tackle before the next release. Our next Stylesheets meeting is scheduled for Tuesday, August 4; the next Council meeting is scheduled for Tuesday, August 11 (one day before release on August 12). I would like to propose to switch these dates and have our Council meeting on Tuesday, August 4. This would give us the opportunity to prepare for the release and to clarify open questions. Let me know what you think. Best, Martina

5 4