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

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

Meeting in 25 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 14 Jan '21

14 Jan '21

Von: Scholger, Martina (martina.scholger(a)uni-graz.at) Gesendet: Montag, 11. Jänner 2021 23:25 An: tei-council(a)lists.tei-c.org Betreff: Next Council meeting: Jan 14 Dear all, This is the agenda for our next meeting on Thursday, Jan 14 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET (please double check the meeting times in the google calendar): https://docs.google.com/document/d/1ofn0oIgmP5yyuCCfu4NF0Jw8lmNRMN44FN8gwsc…<https://docs.google.com/document/d/1ofn0oIgmP5yyuCCfu4NF0Jw8lmNRMN44FN8gwsc…> Please add topic that you would like to discuss. The zoom link is in the google doc. Best, Martina

3 2

Next Council meeting: Jan 14
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Jan '21

11 Jan '21

Dear all, This is the agenda for our next meeting on Thursday, Jan 14 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET (please double check the meeting times in the google calendar): https://docs.google.com/document/d/1ofn0oIgmP5yyuCCfu4NF0Jw8lmNRMN44FN8gwsc… Please add topic that you would like to discuss. The zoom link is in the google doc. Best, Martina

1 0

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

04 Jan '21

Dear all, The cooperative Stylesheets meeting takes place every fourth Thursday of the month (two weeks after the regular Council meeting) from 11am-12:30pm PST/2pm-3:30pm EST/8pm-9:30pm CET. The first meeting will be on Thursday, January 28. Please cross-check the meeting times in the Google Calendar. With best wishes for 2021! Martina

1 0