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

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

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 10 Feb '21

10 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

Re: [Tei-council] Next Stylesheets meeting
by BERMUDEZ SABEL Helena 09 Feb '21

09 Feb '21

Hello! No issues with the proposed date. Best, H. Helena Bermúdez Sabel Chercheuse FNS senior Institut des sciences du langage Université de Neuchâtel ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 08 February 2021 18:08:07 To: tei-council(a)lists.tei-c.org; Martin Holmes; Nicholas Cole Subject: [Tei-council] Next Stylesheets meeting Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

6 5

PDF build with Japanese
by Martin Holmes 08 Feb '21

08 Feb '21

Hi all, The ruby stuff is now merged into the repo, and I've spent a good few hours now trying to get the PDF to build properly. It dies with this error: ! LaTeX3 Error: The key 'fontspec-opentype/...' is unknown and is being (LaTeX3) ignored. which is something to do with xml:lang='ja' appearing in the source. At one point I got it to build, but without the Japanese language attributes, the characters just come out as square boxes. Can anyone who knows more about LaTeX than me suggest anything? I don't really want to go round removing xml:lang attributes just to get past the PDF problem, but I don't know what else to do at this point. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

4 8

Next Council call: Feb 11
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, This is the preliminary agenda for our next Council call on February 11 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

2 1

Next Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

1 0

Refrigeration
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, We are close to refrigeration, starting on Friday, February 12. After this date we should not commit major changes to the schema. Minor changes like improvements in wording, correction of typos etc. are fine. Please have a look at the open milestone 4.2.0 Guidelines issues (https://github.com/TEIC/TEI/issues?q=is%3Aissue+milestone%3A%22Guidelines+4…) and 7.51.0 Stylesheets issues https://github.com/TEIC/Stylesheets/issues?q=is%3Aopen+is%3Aissue+milestone…. Please remove issues that you will not tackle before the next release. Best, Martina

1 0

positioning of examples vis-a-vis prose
by Bauman, Syd 08 Feb '21

08 Feb '21

Working on ruby glosses, I think it is quite useful to say in the prose of CO things like “the following example” or “the example above”. I note that the “Examples” subsection of the “Style Notes” section of TCW 20<https://teic.github.io/TCW/tcw20.html> (why don’t these <div>s have IDs?) says in the very first paragraph not to do that. However, it is clear to me that the rest of that paragraph is about examples in tagdocs, not examples in the prose of the Guidelines. Furthermore, I think the logic (someone might come along later and add an example) at best does not really apply here in the prose (where being able to differentiate examples is useful), and at worst is basically silly. (I very vaguely remember the argument in favor of this restriction, and begrudgingly agreeing to it; but I cannot find the reasoning that led me to that agreement now, nor can I recall if it was intended for only tagdocs or for examples in the prose, too :-) That said, why don’t we have a mechanism for referring to specific examples?

4 3

Re: [Tei-council] More NVDL issues: Spec files not validating
by Bauman, Syd 05 Feb '21

05 Feb '21

Trying to validate which schema file against which schema? ________________________________ Just trying to validate the schema itself in oXygen.

3 10

Thanks for Ruby feedback
by Martin Holmes 04 Feb '21

04 Feb '21

Hi all, Thanks for the feedback on the location for the Ruby prose. The consensus is clear -- it should be in core -- and the comments suggest that the most appropriate approach will be to integrated it with the content relating to glosses, which is currently in 3.3.4, "Terms, Glosses, Equivalents, and Descriptions". That sub-subsection is already quite long, so what I propose to attempt is this: Take 3.3.4 "Terms, Glosses, Equivalents, and Descriptions" and 3.3.5 "Some Further Examples" and make them into a new subsection (i.e. one level higher), which will become 3.4. Title the new section "Terms, Glosses, Equivalents, Descriptions, and Ruby". (JJ suggests that terms belongs elsewhere, but that would be a major reorg, and I don't think we have time for that right now.) Create subsections: 3.4.1 "Terms and Glosses" covering the first part of what is now 3.3.4. This would also include the "Further Examples" bit, which is really an extension of this. 3.4.2 "Ruby Annotations" containing the new prose already proposed. 3.4.3 "Equivalents and Descriptions" containing the part of what is now 3.3.4 which discusses altIdent, desc, and equiv; I think this is a different topic, really, from glossing terms. I'm doing this work in a separate branch: <https://github.com/TEIC/TEI/tree/issue-2054-ruby> which I'll merge dev into steadily as I go, to minimize later merge conflicts. I'll also set up a build job for this branch on my Jenkins when the initial work is done. The time is relatively short, but I think we can get there before the freeze. I'll post the meat of this on the ticket too, for the record. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

3 10

More NVDL issues: Spec files not validating
by Martin Holmes 03 Feb '21

03 Feb '21

Hi all, Our Spec files (P5/Source/Specs/*.xml) all link to the NVDL schema here: <http://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rele…> That generates an error in itself, because the Jenkins server gives a 308 Permanent Redirect to https. But if you do retrieve the schema and try to validate with it in Oxygen, you get (or at least, I get) the error: IllegalStateException - getSchemaProperties requires a schema I'm not sure why that is -- anybody know? It makes it a bit difficult to work on Spec files. What are people doing to validate their Spec files at the moment? Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

4 3

Next short VF2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 03 Feb '21

03 Feb '21

Dear all, During the VF2F meeting this weekend, we agreed to do more short virtual F2F meetings as long as we can't do in-person meetings. Please fill in the doodle for our next short VF2F meeting (end of March / April): https://doodle.com/poll/dc68qph9py96w39f?utm_source=poll&utm_medium=link. The procedure is the same as last time: the North American Group starts on Friday, the European Group continues on Saturday morning and the full Council meets in the "afternoon" (morning for PST and EST). Best, Martina

1 0

issue 2010: <persPronoun>
by Bauman, Syd 02 Feb '21

02 Feb '21

Meg and I plan to finish up work on ticket #2010 on Mon evening 08 Feb (ET), and create a PR at that time. We are hoping it can be reviewed before the Council meeting on Thu 11 Feb. (If you don’t want to wait, see branch megjbrownIssue2010.)

1 0

Jenkins builds failing and not failing
by Martin Holmes 01 Feb '21

01 Feb '21

Hi all, If you look at Peter's Jenkins, you'll see that the TEI-P5-Test-dev job appears to succeed (it's green). However, the console log for the latest build (653) shows 14 errors: <https://jenkins.tei-c.org/job/TEIP5-Test-dev/653/parsed_console/> On my Jenkins, the latest build (547) also fails, but differently: <https://jenkins2.tei-c.org/job/TEIP5-Test-dev/547/parsed_console/> I'm going to try to figure out why my build is failing, but I'm even more puzzled by the main Jenkins, which seems to be giving the impression that all is well. Peter, do you know what's happening here? NVDL errors seem to be ignored. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

4 12

Council votes on Ruby in the Guidelines
by Martin Holmes 01 Feb '21

01 Feb '21

HI all, As Elisa points out, Council can't vote on the original ticket because it's not on the main TEI repo, so I've reposted it here: <https://github.com/TEIC/TEI/issues/2054#issuecomment-770934282> Please record your preferences for the location of the Ruby introductory prose and other mentions/pointers to it. I'll also check Slack where there's another poll under way. Doesn't matter which one you use. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Will miss the afternoon meeting
by Peter Stadler 30 Jan '21

30 Jan '21

Friends, I’m sorry but I have to apologise for the afternoon meeting. My wife got an appointment she can’t miss and I have to look after the kids. Just wanted to let you know that I’ll miss your (virtual) company and to wish you a productive discussion! Best Peter

1 0

TEI Council VF2F North America
by Hugh Cayless 29 Jan '21

29 Jan '21

Hugh Cayless, Ph.D. is inviting you to a scheduled Zoom meeting. Topic: TEI Council VF2F North America Time: Jan 29, 2021 03:00 PM Eastern Time (US and Canada) Join Zoom Meeting https://duke.zoom.us/j/8407352885 Meeting ID: 840 735 2885 One tap mobile +13126266799,,8407352885# US (Chicago) +16468769923,,8407352885# US (New York) Dial by your location +1 312 626 6799 US (Chicago) +1 646 876 9923 US (New York) +1 301 715 8592 US (Washington DC) +1 669 900 6833 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 408 638 0968 US (San Jose) Meeting ID: 840 735 2885 Find your local number: https://duke.zoom.us/u/abQMVai96I Join by SIP 8407352885(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada) 207.226.132.110 (Japan) Meeting ID: 840 735 2885

1 0