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

Stylesheets meeting today, Thu 25 Mar
by Scholger, Martina (martina.scholger＠uni-graz.at) 25 Mar '21

25 Mar '21

Dear all, please find the google doc for our Stylesheets meeting here: https://docs.google.com/document/d/1Qolxk9yzIAtqofcu7szuPArOuv1koy6g-bjhM1r… Meeting times: * 12:00 PDT (Victoria, BC) * 15:00 EDT (New York) * 19:00 GMT (London) * 20:00 CET (Vienna) Zoom link: https://zoom.us/j/95354913465?pwd=ODZpVUxFVmJjWnlIZnBnaCtIVnFadz09 Best, Martina Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Bauman, Syd Gesendet: Mittwoch, 24. März 2021 04:09 An: tei-council(a)lists.tei-c.org Betreff: Re: [Tei-council] upcoming Stylesheets meeting, Thu 25 Mar Topics for discussion, in no particular order: * 2-minute update on Saxon 9 -> Saxon 10 (MH) * Did we have more to discuss or work on for PR #327<https://github.com/TEIC/Stylesheets/pull/327>? (I forget) * Close issue #272<https://github.com/TEIC/Stylesheets/issues/272> and create new ticket for @mode? * Didn't we fix #482<https://github.com/TEIC/Stylesheets/issues/482>? * Issues we have started delving into, but have not solved: * Issue #327<https://github.com/TEIC/Stylesheets/issues/237>, generating an element or attr that has the same local-name as a TEI element or attr * Issue #402<http://We%20need%20a%20volunteer%20to%20write%20a%20test%20ODD>, on @mode: we need a volunteer to write a test ODD * Issue #399<https://github.com/TEIC/Stylesheets/issues/399>, <code> being dropped from <desc> * Issues that have had a lot of work done, but still are not fixed: * Issue #444<https://github.com/TEIC/Stylesheets/issues/444>, <desc> getting dropped * Issue #102<https://github.com/TEIC/Stylesheets/issues/102>, for which we now have test output, and I finally sort of understand the problem * Issue #424<https://github.com/TEIC/Stylesheets/issues/424>,@ns causing pain ________________________________ We are scheduled to meet (on Zoom, right Martina?) this coming Thu 25 Mar 21 at 19:00Z for 1½ hours. Due to daylight saving time mis-match, this meeting time will be different for some people, most likely for this meeting only. Times are: * 12:00 PDT (Victoria, BC) * 15:00 EDT (New York) * 19:00 GMT (London) * 20:00 CET (Vienna) I plan to post a suggested agenda 24+ hours before the meeting starts. (So if you want something on the agenda, let me know now.)

2 1

upcoming Stylesheets meeting, Thu 25 Mar
by Bauman, Syd 23 Mar '21

23 Mar '21

We are scheduled to meet (on Zoom, right Martina?) this coming Thu 25 Mar 21 at 19:00Z for 1½ hours. Due to daylight saving time mis-match, this meeting time will be different for some people, most likely for this meeting only. Times are: * 12:00 PDT (Victoria, BC) * 15:00 EDT (New York) * 19:00 GMT (London) * 20:00 CET (Vienna) I plan to post a suggested agenda 24+ hours before the meeting starts. (So if you want something on the agenda, let me know now.)

2 2

git me this
by Bauman, Syd 23 Mar '21

23 Mar '21

I have on my local HD a copy of a fork one of our repos.[1] The interesting bit of this repo is in its dev branch. But sadly, its dev branch is somewhat behind our dev branch. So I would like to merge our dev branch in. How do I do that? I.e., how do I specify that I want the git merge command to use our repo’s dev branch (not the current repo’s dev branch, which would be silly, as I am on the current repo’s dev branch) as the upstream? Note [1] https://github.com/sanskrit-coders/Stylesheets.git to be precise, but that detail does not matter.

2 4

p5subset.xml and TCW22
by Martin Holmes 12 Mar '21

12 Mar '21

Hi all, Syd, Nick and I were looking at the Stylesheets repo this morning and we realized that the version of p5subset.xml in its source subfolder had not been updated for quite a long time. That means the Stylesheets tests were running against an old version of the Guidelines. When we decided to put p5subset.xml into the Stylesheets repo, the purpose was to avoid the circularity problem that causes an inability to build each repo against the other. That's been successful, but the corollary was that we should regularly update the p5subset.xml in the Stylesheets repo so that we caught new issues resulting from changes to the Guidelines in good time. That hasn't happened. We added an updated p5subset.xml this morning, and there were a LOT of test issues to fix, although none of them were significant. We've added two new steps to TCW22 so that at the beginning of the freeze or refrigeration period[1], an up-to-date p5subset.xml is added, meaning that almost everything will get fixed at that point; and then later, once the release-X.X.X branch of P5 is building, the p5subset.xml from that gets added into the release-X.X.X branch of the Stylesheets, so that our release is actually coordinated (the states of the two repos match), prior to the release. In the process, we also noticed that lots of the instructions about creating the release-X.X.X branch were written to apply ONLY to the TEI repo, but the same steps also have to happen for the Stylesheets repo, so we've made that more explicit. In our regular Friday meetings, the three of us are going to make a point of updating p5subset.xml so we don't get so far out of sync again. Anyone else is also free to update it any time of course. Cheers, Martin [1] TCW22 doesn't adequately distinguish these two phases; we should fix that. -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

1 0

minute assist
by Bauman, Syd 11 Mar '21

11 Mar '21

Janelle — The “minute assist” task is not about taking minutes during the meeting (in theory we all chip in on that), but rather is about helping the Chair whip the notes taken during the meeting into publishable minutes. Martina typically does this by transferring them to another GoogleDoc, making “suggestion” changes there, and then asking the minute assist person to review those changes and make any of her or his own. (Other Chairs have done it differently in the past, but that’s not important right now. :-) If that means you do not have time to do minute assist for this month, just say so. I spent much less time than expected last week on the minute assisting of the SVF2F, so would not mind doing this one.

1 0

call in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Mar '21

11 Mar '21

Dear all, Our call starts in 30 minutes: https://docs.google.com/document/d/1qcs0bVOjgm0ae7x7ZRMEMvlsipZ4FXzBNJXe5Oj… 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/

3 2

Next call: Thursday, March 11
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Mar '21

09 Mar '21

Dear all, Our next TEI Council meeting is scheduled for Thursday, March 11 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET. Please add discussion topics to the agenda: https://docs.google.com/document/d/1qcs0bVOjgm0ae7x7ZRMEMvlsipZ4FXzBNJXe5Oj… The zoom link is in the google doc. Best, Martina

1 0

Deb packages key signing broken?
by Martin Holmes 07 Mar '21

07 Mar '21

Hi all, My Jenkins server says: Err:9 https://packages.tei-c.org/deb/binary ./ Release.gpg The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> [...] W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.tei-c.org/deb/binary ./ Release: The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> W: Failed to fetch https://packages.tei-c.org/deb/binary/./Release.gpg The following signatures were invalid: EXPKEYSIG 19CF3E497B9824DC TEI Council (GPG key for signing Debian packages) <council(a)tei-c.org> Did the packages get signed correctly, or has the key expired? Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

3 3

what we’re up to
by Bauman, Syd 05 Mar '21

05 Mar '21

Martin, Nick, and I are halfway through updating the repos to use Saxon 10. We have finished the Stylesheets repo, which was probably the easier one. It has been checked in as the “saxon10” branch. We expect to do the TEI repo soon (unless someone else jumps on this interminable task). We expect to issue a PR for each repo, assigned to the same person (any volunteers?), at roughly the same time. Probably a good idea that each of the repos be merged at roughly the same time, too. (I think there shouldn’t be any circularity problem from this change, but just in case, having them both get to Mr. Jenkins in the same cycle sounds like a good defense.) I just realized there are no tickets for this, so I plan to create issues now.

1 0

Stylesheets meeting Thu 04 Mar
by Bauman, Syd 04 Mar '21

04 Mar '21

We have a Stylesheets meeting scheduled for tomorrow (likely today by the time you read this), Thu 04 Mar, 19:00Z to 20:30Z. That is * 11:00 PST * 14:00 EST * 19:00 GMT * 20:00 CET for 1½ hours. Agenda: 1. Update to 7.51.1, i.e. issue #488, PR #489 (Syd & Martin) 2. Issues surrounding yesterday’s release of TEI framework for oXygen (Hugh & Martin) 3. Detailed review of PR #327 (Peter) 4. Review of PR #462 (Syd)

3 2

TEI release directory structure
by Peter Stadler 01 Mar '21

01 Mar '21

Hi all, apologies for sending to both groups, but this issue is kind of between Council and infrastructure group, so I thought I’d be better to include both. The issue I see is about the „release“ directory structure, i.e. the stuff at https://tei-c.org/release/ Currently, on the Huma-Num server, „release“ is just a symlink pointing at "Vault/P5/current“ – this caused frequent errors with the Stylesheets release missing due to missing CSS files for building ePubs. It was hacked around by copying Stylesheets to P5 or symlinking Stylesheets into P5. Since the structure under „release“ seems to mimic the "/usr/share/doc“ and „/usr/share/xml“ structure known from Debian systems – and this is the place where the TEI Debian packages are installed by default – I think the *original* setup might have looked like an apache Webserver simply serving its local „/usr/share“ directory under „release“ to the outside. At the latest with the ADHO server crash, this setup got lost and we have a semi-functioning release directory now. IMHO, with our current infrastructure, the proper setup would be to (hard) create the directory „release/doc“ and „release/xml/tei“ and create symlinks within these directories to the respective directories in the Vault: release/doc * tei-p5-doc —> ../../Vault/P5/current/doc/tei-p5-doc * tei-p5-exemplars —> ../../Vault/P5/current/doc/tei-p5-exemplars * tei-xsl —> ../../Vault/Stylesheets/current/doc/tei-xsl release/xml/tei: * Exemplars —> ../../../Vault/P5/current/xml/tei/Exemplars * Test —> ../../../Vault/P5/current/xml/tei/Test * custom —> ../../../Vault/P5/current/xml/tei/custom * odd —> ../../../Vault/P5/current/xml/tei/odd * schema —> ../../../Vault/P5/current/xml/tei/schema * stylesheet —> ../../../Vault/Stylesheets/current/xml/tei/stylesheet * xquery —> ../../../Vault/P5/current/xml/tei/xquery release/oxygen —> Vault/P5/current/oxygen Does that make sense? Anything I’m missing? And of course, I’m curious about some more history that Lou(?) or James(?) might be able to share? Best Peter

3 2

Stylesheets meeting is scheduled for this Thu 04 Mar 19:00Z
by Bauman, Syd 01 Mar '21

01 Mar '21

If I understand correctly, we are scheduled to hold a Stylesheets meeting this coming Thursday, 04 March at 19:00Z to 20:30Z. That is * 11:00 PST * 14:00 EST * 19:00 GMT * 20:00 CET for 1½ hours. I am expecting we will spend a little time reviewing the fix for the 4.2.1 release, and intend to post here an actual agenda with a ticket or two to work on by at least 24 hours before the meeting. I am hoping Martina will also post the details of how to get to the meeting here at least a few hours before the meeting. Looking forward!

1 0

Slight borkitude in moduleRef content model display
by Martin Holmes 25 Feb '21

25 Feb '21

Hi all, Just clicking around in the various types of Guidelines outputs, and I noticed this: <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-moduleRef.html> Take a look at the content model. It's the same in the ebook; it's slightly different but I think also borked in the PDF (p. 1402). I don't think it's urgent, because it was the same in 4.1.0. I'll raise a ticket and start investigating. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

2 3

Version 4.2.0 released
by Nicholas Cole 25 Feb '21

25 Feb '21

Dear Council, The Release team is happy to report that with the exception of the Oxygen Plugin, the build and release of P5 4.2.0 and Stylesheets 7.51.0 has been done. The release notes need some moderately extensive updating, and I will be making some suggested changes and a pull request later today / tomorrow. Very best wishes, Nicholas, Meaghan, and Peter.

3 3

GPG Key
by Nicholas Cole 23 Feb '21

23 Feb '21

Dear Council, Just to note that the current expiration date for the TEI GPG key is the second of next month. This can be extended, of course, without problem, but I’m not sure whose task that is. Best wishes, Nicholas

2 3

release notes
by Scholger, Martina (martina.scholger＠uni-graz.at) 22 Feb '21

22 Feb '21

Dear all, I've added a first draft of the release notes to the release branch (release-4.2.0): https://github.com/TEIC/TEI/commit/06af7ce77dae7d133c39da68cf0a179a579bca0a Please feel free to modify and please correct my spelling errors. Best, Martina

5 8

Release Number?
by Nicholas Cole 20 Feb '21

20 Feb '21

Dear Council, There is a lot in this release. Have we all agreed what the version number is? ;-) If there are any last pleas not to ‘freeze’ yet, make them now. As far as I can see, the Jenkins servers are reporting builds correctly. I’m going to ‘freeze’ at 15:00pm UK time, for Release 4.2.0, unless we think this is a ‘major’ version. (I actually think there’s quite a lot in this release, actually). Best wishes, N.

6 6

Freeze?
by Nicholas Cole 20 Feb '21

20 Feb '21

Dear Council, I suppose the Freeze starts at the end of today. Is that right? N

3 6

broken persPronouns
by Bauman, Syd 18 Feb '21

18 Feb '21

~10 hours ago PR 2014 was merged into dev. This broke the build because we (Meaghan and I) had examples that used <persPronouns> in running-prose-like places (inside <closer> and <docAuthor>, to be precise); but, because <persPronouns> was (as per the original FR) only a member of model.personPart, it was only allowed inside <person>, <personGrp>, and <persona>. We put our heads together on a brief telephone consultation, and concluded that we believe that the new <persPronouns> element is going to be desired for the encoding of signature blocks in email or blog posts as much or more than in personographies. Therefore we think the solution is to permit <persPronouns> in those sorts of places, not to remove the examples. Thus I have made <persPronouns> a member of model.persNamePart (in addition to model.personPart). This allows <persPronouns> in <closer> and <docAuthor>, and thus should fix the build. It also allows <persPronouns> in quite a few desirable places like inside an <s>, a <p>, or an <item>. It also allows it inside lots of somewhat screwy places like <tagUsage> and <unti>. However, <roleName> (for example) is allowed in precisely the same set of places, so even if screwy, at least it is consistently screwy. If anyone wants to object, please do so quickly (by Fri latest, preferably earlier). The commit that would need to be reverted is 1f874af07. Sorry everyone. The reason this got past me, BTW, is because oNVDL does not run on my system. (Martin is saying “I told you so” right now. :-)

4 3

semantic version conversation
by Bauman, Syd 15 Feb '21

15 Feb '21

At the VF2F we apparently discussed PR 1996 (which implements one point of the discussion on issue 1993). Does anyone remember what, if anything, I said about it? My suspicion is I was making tweaks for 2032 at the time, and did not realize y’all were accepting the idea that TEI/@version (et al.) is a “version number following the Semantic Versioning Specification”. Because it is not. This would have serious (albeit extremely rare) side-effects in processing, because it means we would be obligated to drop anything from a ‘+’ on (i.e., the build metadata) when ascertaining order of precedence. Much more importantly, it means that we would be obligated to change our system of changing the MAJOR and MINOR portions of the version number. (The PATCH bit would still be updated only for backwards-compatible bug fixes.) We currently update MINOR every new release (roughly every 6 months), and only update MAJOR if and when there is a significant change in functionality (e.g., switching to PureODD). If we adopt SemVer, we would be obligated to change MAJOR whenever any backwards-incompatible change occurred, no matter how small. Furthermore, we would have to define backwards-incompatible. Obviously a change (even a bug fix) that changes the schema such that a document that was valid before the change is invalid after it is a change that requires a bump in the MAJOR portion in the SemVer system. But what about the reverse, a change that allows a document that had been invalid to be considered valid? (E.g., adding "PostScript" to the value list of @scheme in att.styleDef.) Seems to me that is backwards-incompatible too, just in a different way. (The schema no longer catches the same “error” it used to.) Conversely, of course, we could use the idea that SemVer refers to the incompatibility of the API, not of the schema, to decide not to bump MAJOR for incompatible schema changes. But if the version number is about the API, what API is it about, and what does it have to do with our release system and schemas? I think all of this can be avoided by just saying “based on” rather than “following” the Semantic Versioning specification. (Note that in either case it should be capitalized and have a reference in the bibliography to the spec<https://semver.org/> that we don’t follow but maybe will say that we do.) If y’all really think we really should say we are following it, I will accept the majority opinion. That said, you should not vote in favor of “following” until you have actually read the SemVer<https://semver.org/> spec.

5 9

keep Subversion version # capability? On stupidity
by Bauman, Syd 13 Feb '21

13 Feb '21

Hey all. Two things. First just wanted to clarify that when I said “because it’s stupid” in reference to <text> as a direct child of <teiCorpus>, I was trying to express that it was inappropriate and careless of us to ever let <text> slip into the content model of <teiCorpus> in that position (which happened in 2016-02). I am (as y’all can probably tell) somewhat annoyed with myself for not noticing this as a problem when it came up then. I was not calling users (like Martin and Janelle, among others) who make use of this perfectly valid facility stupid. My current annoyance, though, is some horrible code. Thus I want input on what to do with P5/repodate.xml. This is an untracked file generated by the Makefile during the P5 build process and read by the P5/Utilities/expand.xsl program. That program changes the <?insert date?> PI found in P5/Source/guidelines-en.xml (and in P5/Source/guidelines-fr.xml) and thus in p5.xml into the date the GLs were built, and changes the <?insert revision?> PIs into the git commit number, etc. This whole system is made quite a bit more complicated by the fact that the code is designed to work whether the version control system we use is Subversion or git. My instinct is that it is no longer useful to maintain the code that worries we might be using Subversion rather than git. We have not been using Subversion for roughly 5 years,[1] and I do not see us ever going back to it. Sure, GitHub the service is a company and may fold, but git the command is not going away. Something better may come along, and we may switch in the future, but that means re-working all this code, anyway. The only reasonable concern that floats through my tiny brain is that maybe we need this code in case someone uses the current build system to try to generate a very old copy of the Guidelines that dates back to the pre-git days. But I do not have any reason to believe that either anyone would use the modern Makefile to build an ancient copy of the Guidelines (you would use the build system that came with that revision), or that there would be any hope of success even if this code for handling Subversion revision numbers was left in place. So does anyone think we should leave the Subversion code in there? Going once … P.S. Given that we are in the refrigeration period, I will be doing this in a separate branch and leave it to others whether to merge it before or after release. It should have absolutely no effect on the output at all. (And if anything goes wrong, would be very easy to spot by just checking the output of PIs.) Notes [1] My vague recollection is that the changeover from Subversion in Sourceforge to git in GitHub was masterfully handled by Peter Stadler in 2015 or 2016.

3 4

Next VF2F: May 7 and 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Feb '21

11 Feb '21

Dear all, Our next virtual F2F meeting is on May 7 and 8. As last time, the North American Group starts on Friday at 12am PST / 3pm EST (3 hours); the Europeans continue on Saturday morning at 9am BST/10am CET (3 hours); the full Council meets on Saturday 6am PST / 9am EST / 2pm BST / 3pm CET (4 hours). Please have a look at the google calendar to check the meeting times. Best, Martina

1 0

Council call in 40 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Feb '21

11 Feb '21

Dear all, Our call starts in 40 minutes. Agenda: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

1 0

Re: [Tei-council] Mr. Jenkins is ignoring me
by Bauman, Syd 10 Feb '21

10 Feb '21

Thank you, Peter! (Why did I not see it in the dashboard? Why did I miss the build failure locally? Hmmm...) ________________________________ seems it’s there at https://jenkins.tei-c.org/job/TEIP5-Test-dev/680/ The build has been kicked off due to your commit but failed, hence the subsequent jobs have not been started at all.

1 0

Mr. Jenkins is ignoring me
by Bauman, Syd 09 Feb '21

09 Feb '21

Attn: Peter & Martin I committed to dev branch at 20:50:00 localtime (± 6 sec), commit #9d8122417ee2ec8d05f979bf920f98069586817a. That was over 2 hours ago, and yet neither Jenkins[1] seems to have noticed. Worse, one of them seems to have kicked off a build at roughly halfway between then and now, but it does not list my commit as its reason for existing. Snif! What is going on? — Syd “I’ve been ghosted by a CI server!” Bauman [1] https://jenkins.tei-c.org/view/TEI%20dev/ https://jenkins2.tei-c.org/view/Dev%20branch%20jobs/

2 1