February 2021 - Tei-council

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) 12 Feb '21

12 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