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

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

VF2F meeting: Jan 29 and 30
by Scholger, Martina (martina.scholger＠uni-graz.at) 28 Jan '21

28 Jan '21

Dear all, This is the agenda for our VF2F meeting: https://docs.google.com/document/d/1ditQHz4VXEitKZ7IeWO41tgzKZq_LwF0zclXHJF… I think that we first should work on pull requests (with milestone 4.2.0) and Guidelines issues with the milestone "Guidelines 4.2.0" which are still labeled with "Needs Discussion+Go" or do not have a status yet. For the North American Group - please start with whatever you like and fix issues from either or both of the tables. On Saturday the European group will continue. In the full Council session on Saturday we start with the discussion on ruby glosses. Please have a look at the issue and Martin's proposal on prose. Please feel free to add topics that you would like to discuss. Hugh will send a zoom link for tomorrow's meeting. Best, Martina

1 0

Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 28 Jan '21

28 Jan '21

Dear all, This is the zoom link for our Stylesheets meeting which starts in an hour https://us02web.zoom.us/j/88017340213?pwd=T3NTWmpFUWNrUWFaeU4zWHBBQUVqZz09 Best, Martina

2 1

Stylesheets meeting in 1 week
by Bauman, Syd 28 Jan '21

28 Jan '21

We are scheduled to hold a Stylesheets meeting on Thu 28 Jan 21 from 19:00Z to 20:30Z. That’s * 11:00–12:30 PST * 14:00–15:30 EST * 19:00–20:30 GMT * 20:00–21:30 CET We have not decided yet on a platform (although it seems to be Zoom vs Google Meet), or who will be hosting. Per last week’s Council meeting, our main topic will be Stylesheets #237<https://github.com/TEIC/Stylesheets/issues/237>. I hope to post a bit of a summary and some thoughts on this issue by the beginning of next week, but not guarantees.

4 4

Question on progress with the ruby work
by Martin Holmes 26 Jan '21

26 Jan '21

Hi all, I'm writing to Council because I need to get some clarity on what Council is aiming at with regard to the ruby markup proposal and the upcoming release. My initial understanding, and the work Syd and I have been doing, was based on the idea that we would really like to get a basic implementation of the new elements into the schema, along with a simple section for the prose chapter, in time for this release; that would allow the Japanese users in particular, who initiated the work, to get started with the markup and begin to work out some of the edge cases. However, the work on the ticket and the repo has become increasingly complexified; Duncan has submitted a set of cases that would stretch the initial implementation considerably and require a much-expanded prose section with many more examples, and this could not be ready for the upcoming release. My personal view is that these cases could be submitted as feature requests for further exemplification and expansion of the chapter prose, which we will need to do anyway, after the initial release, but Duncan is quite determined that he doesn't want to do that. There are also various discussions about multiple methods for doing stand-off ruby markup, some of which look quite flaky to me, and which I wouldn't really want to recommend in the Guidelines; but I'm not a content expert and don't have much authority to wield. As always, there is a lot of tension between the need for the Guidelines to provide straightforward, generic recommendations and the desire for people to see their own preferred approaches sanctioned and exemplified. I need to have something ready for the Council meeting on Saturday, so I'd like to get Council's view on what we're aiming to do right now. I think our options are: 1. Add only the new elements to the schema, with full Spec files and basic examples in them, but without any prose section in the Guidelines. 2. Add to #1 a relative short and straightforward introduction in the prose, with some basic worked examples, but no complicated edge cases, at the same time soliciting feature requests for further work. 3. Give up on getting anything into this release, and instead adopt a working-group approach to build a complete solution before we put anything into a release. My personal preference is for #2, but I don't think it's a decision I can make without Council's backing. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

3 2

Next Weekend's Council F2F: Timing Question
by Elisa Beshero-Bondar 25 Jan '21

25 Jan '21

Greetings, Council! Next Saturday, January 30, do we have any plans to meet after the times we posted in our minutes, namely: 06:00–10:00 PST 09:00–13:00 EST 15:00–19:00 CET ? I'm pretty sure not, but wanted to double-check as I'm trying to schedule something. Thanks, Elisa -- Elisa Beshero-Bondar, PhD Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities | Director of the Digital Humanities Lab at Penn State Erie, The Behrend College Development site: https://newtfire.org

2 1

GitHub PRs
by Bauman, Syd 22 Jan '21

22 Jan '21

Inspired by Nick’s tei_current_assignments.py<https://github.com/npcole/teiutils>, a program that leverages the gitHub API to summarize gitHub issue assignments, I have just spent the entire day trying to write an XSLT program to summarize pull requests. At this point, I have to (at least temporarily) give up. I simply cannot figure out how to get the list of reviewers (those who have been asked to be reviewers, those who have accepted the request to be a reviewer, and those who have submitted reviews) without, at least sometimes, including the OP in that list. (That is, I have yet to figure out an XPath that will select the reviewers without the OP from the JSON-converted-to-XML returned by the “reviews” API call.) If anybody feels like helping me out, I think we would find this a useful utility. To prove the point, I generated one possible useful output (an HTML table) using my current mildly broken code, and went through and fixed the output by hand. (Sigh.) See https://bauman.zapto.org/~syd/temp/4TEICouncil/GHPRs.html. Talk to y’all tomorrow.

3 4

shift of validation need deprecation?
by Bauman, Syd 19 Jan '21

19 Jan '21

I am hoping to close several tickets, including #2062<https://github.com/TEIC/TEI/issues/2062> very soon. This one “needs discussion”, IMHO, only on the issue of whether or not deprecation is required. Could folks weigh in on the ticket, please? Issue: the @key attribute of <specDesc> is optional in the schema, but required by the Stylesheets. The request is to require it in the schema, too. Decision (unilateral, by me): yes, we should make @key of <specDesc> required by the schema. Question: Do we have to provide deprecation for this change? Discussion 1: The <specDesc> element “indicates that a description of the specified element or class should be included at this point within a document”. The @key attribute is the only mechanism by which the element or class you want to be included can be indicated. Therefore a <specDesc> without a @key is not doing what it is supposed to do. Currently, a <specDesc> without a @key passes validation, but then when processed by the Stylesheets the message “ERROR: no key attribute on specDesc” is generated (by Stylesheets/common/common_tagdocs.xsl); processing continues, and the spot where the @keyless <specDesc> occurred is simply blank in the output HTML. Discussion 2: We have decided in the past that, in general, changes that break backward compatibility should be deprecated. (I.e., users should get a warning, not an error, for 6 months to 2 years before the feature is changed to an error.) My opinion (on the question “Do we have to provide deprecation for this change?”): Emphatically not, this is a corrigible error. The change only effects when the user gets an error message, not if. One of the main reasons to have schema validation is to catch errors before you get to the processing stage. Discussion 3: One (especially a new member of Council) may well ask, why did I even bother raising this question? The answer is an abundance of caution. The question of whether or not a change need be deprecated is often an issue with disagreement within Council. I have a (well deserved) reputation for having a high threshold for requiring deprecation; others (including Peter and Martin) have a reputation for a much lower threshold. Thus it makes sense to make sure that I am not the only one who thinks this does not need deprecation.

4 3

tei_customization the shunned step child
by Bauman, Syd 18 Jan '21

18 Jan '21

Is there a reason that tei_customization.rn[cg] are not showing up in https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rel… Am I looking in the wrong place? BTW, where in the lastSuccessfulBuild hierarchy does one look for the .isosch files?

2 3