- 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

Dec 20 ticket assignments
by Bauman, Syd 03 Jan '21

03 Jan '21

Finally got to it, sorry. Let me know if you are interested in my litany of excuses … 🙂 I left TEI #2073 and Stylesheets #480 unassigned, as they are blocked by another ticket. (They are the 2nd and 3rd parts of the 3 step sequence for the examples: change the content model (#2072), change the processing (#480), actually change the use of the element (#2073).) Number of tickets of current and recent Council members, loosely defined (TEI then Stylesheets): Syd Bauman = sydb 42 14 Elisa Beshero-Bondar = ebeshero 23 06 Vanessa Bigot_Juloux = vbigot-juloux 02 00 Meaghan Brown = MegJBrown 10 01 Loub Burnard = lb42 01 00 Hugh Cayless = hcayless 21 12 Nicholas Cole = npcole 13 07 James Cummings = jamescummings 05 03 Martin Holmes = martindholmes 08 13 Janelle Jenstad = JanelleJenstad 02 00 Jessica_H. Lu = lujessica 10 03 Elli Mylonas = emylonas 02 01 Helena Bermúdez_Sabel = HelanaSabel 02 00 Martina Scholger = martinascholger 18 03 Peter Stadler = peterstadler 17 09 Sarah Stanley = scstanley7 00 00 Magdalena Turska = tuurma 18 02 Raffaele Viglianti = raffazizzi 18 03 BTW, if you want to quickly see how many tickets are assigned to each GitHub user that has tickets assigned, try out Nick’s clever new tool. See https://github.com/npcole/teiutils. If you have Python 3.8 installed you can just issue python3.8 teiutils/bin/tei_current_assignments.py, and presto! P.S. HelenaSabel is now a member of TEIC on GitHub. I only auto-added her to the TEI Council group. Can she add herself to other teams as she wants, or does an owner or team member have to do that for her?

1 0

Martina for Chair!
by Bauman, Syd 03 Jan '21

03 Jan '21

Re: https://tei-c.org/activities/council/ So, first a question: who are you? I realize I am not sure who the webmaster is recently. Anyway, on the Council page the “Term January 2019 through December 2020” section should now be deleted, and the “Chair 2020” after Martina’s name should be changed to “Chair 2021” (or perhaps just “Chair”?). Thank you! P.S. Personally, I am still in favor of having a list of people who have served on the Council in the past, either on this page or pointed to by this page. But I have been saying that for years …

1 0

Reminder: Doodle: Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 29 Dec '20

29 Dec '20

Dear all, This is a reminder to fill in the doodle for the monthly Stylesheets meeting: https://doodle.com/poll/6nvai7q622sunhx5?utm_source=poll&utm_medium=link Options: * 1 week before the Council meeting* (same timeslot), * 1 week after the Council meeting* (same timeslot), * 2 weeks after the Council meeting* (same timeslot), or * some other time (please leave a comment if this is the case) * The regular Council meeting will be held every second Thursday of the month from 11am-12:30pm PST/2pm-3:30pm EST/8pm-9:30pm CET. Best, Martina

1 0

Happy holidays
by Scholger, Martina (martina.scholger＠uni-graz.at) 24 Dec '20

24 Dec '20

Dear Council, Thanks for a strange but still very productive year. Happy holidays and a good start into the new year in which we can hopefully meet face to face again at some point. Best, Martina

1 0

virtual short F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 22 Dec '20

22 Dec '20

Dear all, We have a date for the virtual short F2F meeting. It is January 29 to 30. This is how it works: The North Americans start on Friday afternoon at 12am PST / 3pm EST The Europeans continue on Saturday morning at 10am CET The full Council meets on Saturday morning for US/CA, afternoon for Europeans. The original plan would mean 6am PST / 9am EST / 3pm CET. I'd suggest moving this back an hour or two since that seems very early for Janelle. Let's discuss this during our next call on January 14. Unfortunately Meaghan will not be able to join us on those dates, but there was no doodle option which suited everyone. Best, Martina

1 0

Doodle: Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 18 Dec '20

18 Dec '20

Dear all, Here is another doodle for the monthly Stylesheets meeting: https://doodle.com/poll/6nvai7q622sunhx5?utm_source=poll&utm_medium=link Options: * 1 week before the Council meeting (same timeslot), * 1 week after the Council meeting (same timeslot), * 2 weeks after the Council meeting (same timeslot), or * some other time (please leave a comment if this is the case) Best, Martina

3 2

monthly call: new meeting times
by Scholger, Martina (martina.scholger＠uni-graz.at) 18 Dec '20

18 Dec '20

Dear all, We have a decision for the new meeting times for the monthly Council call in 2021. The meeting will be held every second Thursday of the month from 11am-12:30pm PST/2pm-3:30pm EST/8pm-9:30pm CET. The first meeting will be on Thursday, January 14. Please check the Google calendar for the meeting times (Janelle and Helena - you should have access to the calendar). As always I will send the agenda and the zoom link a few days in advance. Best, Martina

2 1

ticket assignments and mentors
by Bauman, Syd 15 Dec '20

15 Dec '20

[Janelle and Helena — every month 1 person from Council is the “ticket triage” person. This person pays attention to new or otherwise unassigned tickets (actually called “issues”) on GitHub, and assigns them to one or more Council members; might also assign labels and milestone to each. This month I am the ticket triager.] IIRC at our last meeting we did not decide on mentors for our new members, instead deferring that decision to January. Does that mean I should not assign tickets to Janelle and Helena, either? My instinct is that I should go ahead and assign tickets to our new members now (so as to avoid forgetting or having unassigned tickets; besides, one of them requires a native Spanish speaker :-), with the understanding that until they have each gone through some orientation with their mentor next month, there is no expectation of actually tackling the tickets yet. As soon as they are ready, the tickets would be waiting for them, though. Any objections?

4 4

new meeting times
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Dec '20

09 Dec '20

Dear all, I've set up a doodle to coordinate the meeting times for the monthly Council meetings in 2021. I suggest to stick with the second week of each month (2nd Mon/2nd Tue etc.). In the doodle I have put in the January dates as an example. Please fill in the doodle by 2020-12-14: https://doodle.com/poll/486ypeh2nkzgtp9v?utm_source=poll&utm_medium=link Best, Martina

1 0

Next meeting: Dec 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Dec '20

04 Dec '20

Dear all, This is the agenda for our next meeting on Tuesday, Dec 8 at 6:00-7:30 PST, EST 09:00-10:30, GMT 14:00-15:30, CET 15:00-16:30: https://docs.google.com/document/d/1sToQJklZ9ZdXSE5nMXpxN9P1yZho9IVYvXW--u1… Please find the zoom link in the google doc. Best, Martina

1 0

virtual short F2F meeting January/February
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Dec '20

04 Dec '20

Dear Council, During the three days virtual F2F meeting in October we agreed on a VSF2F (virtual short face-to-face meeting) in late January or early February: * US/CA meet Friday afternoon / evening (~3 hours) * Europeans meet Saturday morning (~3 hours) * Council convenes as a whole on Saturday (morning for US/CA, afternoon for Europeans) (~4 hours) Please fill in the doodle: https://doodle.com/poll/8958wr5fqecfqxne?utm_source=poll&utm_medium=link For our new members: In addition to the monthly meetings we have in person meetings twice a year for three days (one in spring and one before or after the TEI Conference). This year we had two very successful meetings, but it is not possible to meet online for full three days, also because of the time difference. Since we do not expect in person meetings in 2021 (at least not in the first half of the year) we agreed to hold an additional meeting in January/February. Best, Martina

1 0

Stylesheets meeting addendum
by Bauman, Syd 03 Dec '20

03 Dec '20

Attn: Meaghan Brown, Martin Holmes, Martina Scholger, Elisa Beshero-Bondar, and Raff Viglianti Please see 2nd page of today’s notes<https://docs.google.com/document/d/11aTpKoEaXfYuHTbtCd7Vh6rxdeM-QVxcCp8Ej7V…>; if in a rush skip down to last section, “Current State of Play”.

4 7

Stylesheets meeting, Tue 01 Dec
by Bauman, Syd 01 Dec '20

01 Dec '20

We are scheduled to hold a Stylesheets meeting this coming Tue 01 Dec 20, 14:00Z, which is: * 06:00 PST (Victoria) * 09:00 EST (New York) * 14:00 GMT (London) * 15:00 CET (Berlin) I do not know on which platform we will meet, or who will be hosting. (I suppose as chair of this group I am supposed to figure that out, but so far y’all have pretty cleverly kept me out of the communication technology end of things.) Is Google Hangouts still viable? Anyway, topics include (but are not limited to): * ticket #471<https://github.com/TEIC/Stylesheets/issues/471>: Add permalink for examples * language processing; see https://wiki.tei-c.org/index.php?title=Mapping_language_processing * and, if we have ample time left over, we could re-tackle ticket #399<https://github.com/TEIC/Stylesheets/issues/399>: <code> in <desc> gets dropped in rng

4 3

run XSLT 1 from ant?
by Bauman, Syd 29 Nov '20

29 Nov '20

How do we run XSLT 1 from ant? (In particular, from P5/antbuilder.xml. I tried "trax", but get a fatal “XSLT 1.0 compatibility mode is not available in this configuration”.)

3 5

Welcome to our new members!
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Nov '20

23 Nov '20

Dear all, Welcome to our new Council members Helena and Janelle! Our webmaster Luis Meneses added you to the Council's and Board-Council's mailing lists to give you an opportunity to keep up to date with what is going on before your term starts officially in January. You should also have received an invitation for the Google Drive folder "TEI-Technical-Council" were we collect our meeting minutes, the GitHub repository, the shared Google calendar, and the Slack channel. New Council members will be assigned a mentor to help you get started. If you have any questions please do not hesitate to contact me. 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/

1 0

Meeting in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 10 Nov '20

10 Nov '20

Hi all, our call starts in 30 minutes: https://docs.google.com/document/d/1P-DFu-mPB9Xhva2Up2oXTG7HY55l-QgR6zOZLKU… Best, Martina

1 0

Next Council meeting: Nov 10
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Nov '20

09 Nov '20

Dear all, This is the agenda for our meeting tomorrow at EST 09:00, GMT 14:00, CET 15:00 https://docs.google.com/document/d/1P-DFu-mPB9Xhva2Up2oXTG7HY55l-QgR6zOZLKU… The zoom is linked in the google doc. Best, Martina

1 0

Evaluating the "Copia" version of the Guidelines
by Elisa Beshero-Bondar 04 Nov '20

04 Nov '20

Dear Council, After I had to exit early from this morning's Stylesheets meeting I was eager to see how Syd's "Copia" output of the Guidelines turned out. (For those who missed it, Syd found a quick way to output the Guidelines in a way that would prevent suppression of examples in other languages, and this seems mainly to affect the way the Guidelines Spec pages turn out (not the Guidelines chapter examples). I saw in the minutes that we're asked to review Syd's interesting output, named "Copia" (for more copious examples) and report back to the Council list. So started exploring element spec pages a little this evening. Here's what I'm finding: The bibl element is much improved by the Copia output: the examples are far more diverse, but not bewildering in number. I think it is fascinating to see non-English variety: - Copia: https://bauman.zapto.org/~syd/temp/4TEICouncil/html_GLs_all_eg_en/ref-bibl.… - Current: https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-bibl.html The byline element is similarly a lot more interesting now: - Copia: https://bauman.zapto.org/~syd/temp/4TEICouncil/html_GLs_all_eg_en/ref-bylin… - Current: https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-byline.html The gap element seems similarly improved, though there's a little problem here: - Copia: https://bauman.zapto.org/~syd/temp/4TEICouncil/html_GLs_all_eg_en/ref-gap.h… - Current: https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html What I noticed right away was, the number of examples did not seem overwhelming, and the variety of languages evident before you had to click "Show All" reflects a good diversity with Asian languages rising to the fore. However(!) the duplicate example jumps out--duplicates in English. Turns out the French exemplum is identical to the English here, and I"m not really sure why. I think I've seen that in other specs as well. Meanwhile, the element p looks a bit more interesting now, and I think it improves on the current output: - Copia: https://bauman.zapto.org/~syd/temp/4TEICouncil/html_GLs_all_eg_en/ref-p.html - Current: https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-p.html How about ab? Completely boring: no change at all, and it's sadly evident that we don't have enough examples in the first place. (If that isn't a ticket yet, it should be!) - Copia: https://bauman.zapto.org/~syd/temp/4TEICouncil/html_GLs_all_eg_en/ref-ab.ht… - Current: https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-ab.html Okay-that's a start: a review of 5 out of 582 element specs (less than one percent...sigh). But so far I like the Copia version for what it illuminates about our range of exempla, both where it is diverse and where it is lacking. Looking forward to hearing what others think! 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

5 6

Stylesheets meeting Tue 03 Nov 20
by Bauman, Syd 01 Nov '20

01 Nov '20

We are scheduled to hold a Stylesheets meeting this coming Tue 03 Nov 22. Note the time may be different due to recent DST shift in north America: * 06:00 PST * 09:00 EST * 14:00 GMT (and UTC) * 15:00 CET The topic is pre-ordained from the VF2F Council meeting. The goal is to generate a version of the Stylesheets (in a branch, of course) that puts all examples in every language into the Guidelines outputs. Our fearless leader has prepared a GoogleDoc for us, which has the notes from the VF2F and can be used to take notes during the Stylesheets meeting.[1] Is Hangouts still OK for everyone? Note [1] https://docs.google.com/document/d/1uk_6CtLQIM9lrLPDWcFni48sfTqc9CtSk6SWcXl… [https://lh5.googleusercontent.com/oSVfkHOctyKLYcUfUFycQIkOu3kes8AUpXkCTuzR1…]<https://docs.google.com/document/d/1uk_6CtLQIM9lrLPDWcFni48sfTqc9CtSk6SWcXl…> 2020-11-03_StylesheetsGroup<https://docs.google.com/document/d/1uk_6CtLQIM9lrLPDWcFni48sfTqc9CtSk6SWcXl…> Stylesheets 2020-11-03 https://github.com/TEIC/TEI/issues/1934 Subgroup suggests this ticket for consideration by i18N SIG. 2020-10-24: HC: examples are on the agenda for future discussion of i8N group. RV: What would we be asking i18n? Shouldn't Council be doing the mechanism of this work... docs.google.com

1 0

TEI Customizations ODD issues?
by Hugh Cayless 29 Oct '20

29 Oct '20

Hi All, I guess this question is mostly for Syd, but since the customizations ODD is an exemplar, we're all kind of responsible for it. If I have bug reports, should I make GitHub issues for them? Issues I've run into: 1) @role="nonfatal" I think is not understood as a warning, and gets you the usual red underline/error presentation. I feel like warn and/or info might be better. Oxygen's supported role levels seem to be: "warn" or "warning" "error" "fatal" "info" or "information" 2) default values for required attributes are flagged. I can sort of see the logic there, but they're not *really* the same thing. 3) non-"tei:" schemes in @source are discouraged, but what if your source isn't a TEI release? I've got a couple of these, and I'd like to be able to put a URI in there without being yelled at. Hugh

2 2

VF2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Oct '20

23 Oct '20

Dear Council, our VF2F meeting starts tomorrow at 9 EDT, 14 BST, 15 CEST Please find the agenda here: https://docs.google.com/document/d/1nIk4x5SDB0_EqSJG-DynzLz-n9WbmR0tjzM7Aax… Best, Martina

1 0

VF2F -- time change in Europe
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 Oct '20

19 Oct '20

Dear all, I noticed today that Europe switches to standard time from Saturday to Sunday. Please find the updated meeting times (in red) in the google doc. I hope that one hour lunch break on Sunday is enough before we start with the full Council session. https://docs.google.com/document/d/1nIk4x5SDB0_EqSJG-DynzLz-n9WbmR0tjzM7Aax… Best, Martina

1 0

Stylesheets 7.50.1
by Syd Bauman 16 Oct '20

16 Oct '20

This morning Martin & I released Stylesheets 7.50.1 on GitHub, Sourcefoge, and as the Debian packages. We did not release a new oXygen plug-in, as the bug that was fixed was part of the commandline `transformtei` script, which oXygen does not use to run the stylesheets. We (actually, Martin gets the credit) realized that our previous concern about the `tei-install.sh` program with respect to the oXygen plug-in was incorrect, so closed that ticket. Worth noting it took us nearly an hour, even though we had all the pieces ready to rock-and-roll. If we were doing this every week, it could be done a whole lot faster. But infamiliarity and insecurity makes it a slow process. Martin -- are there any updates we would recommend to TCW 22?

3 2

Meeting, Oct 13
by Scholger, Martina (martina.scholger＠uni-graz.at) 12 Oct '20

12 Oct '20

Dear all, This is the agenda for our meeting tomorrow, October 13 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30´ https://docs.google.com/document/d/1F2hc2cVyS2UzxSILqrRtMnTQuy1DH18bTdJv6mz… Please do also have a look at the reminder section. The zoom link is in the google doc. Best, Martina

1 0

Stylesheets meeting Tue 06 Oct
by Syd Bauman 09 Oct '20

09 Oct '20

We have a Stylesheets meeting planned for Tue 06 Oct at 13:00Z; that's * 06:00 PDT * 09:00 EDT * 14:00 BST * 15:00 CEST Unless we get off our collective rear ends and do so before then, I'm thinking perhaps we should perform the release of 7.50.1 during the meeting. This is at the moment a tiny bug fix which waiting for someone other than its authors (me & Martin) to either approve and release or at least approve for release. One question this immediately raises, of course, is how do we do just a Stylesheets release? (I don't know -- I bet no one knows for sure, but I hope some of you have a good idea. :-) If folks don't like that idea, please let me know ASAP so I can have something else lined up.

5 8

Reminder: VF2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 29 Sep '20

29 Sep '20

Dear all, This is a reminder that our next virtual F2F meeting will take place from 24 to 26 October. Please add topics that we need to address during the meeting: https://docs.google.com/document/d/1nIk4x5SDB0_EqSJG-DynzLz-n9WbmR0tjzM7Aax… Best, Martina

2 1

new Stylesheets release needed
by Syd Bauman 24 Sep '20

24 Sep '20

With Martin's help, I have just fixed an egregious error in Stylesheets/bin/transformtei, which is a bad problem, but was an easy fix. (The problem was that it would always fail to find the default p5subset.xml if you started from a directory outside the Stylesheets/ tree.) I have pushed the change to the 'dev' branch. But this is a serious enough problem that the fix should be release, in Martin's humble opinion. (Mine, too.) We probably don't want to release the _other_ changes that have been made to dev since the last release. (At least, Martin doesn't. I kinda like them. :-) So we think the steps should be to cherry-pick that particular fix into the release branch. 1. git checkout released 2. git cherry-pick c615d52 3. change VERSION to 7.50.1 4. run tests, pray there are no errors 5. git commit # to get the new VERSION file 6. git push 7. Hope Stylesheets released branch build works on Jenkins 8. Read TCW 22 and figure out how to actually release the new package. 9. Read TCW 22 and figure out how to release the new oXygen package (may need to kick Jenkins to get it to build, but at least on Martin's Jenkins it should go on its own after the TEIP5-relased job completes successfully) 10. Update TCW 22 as needed to cover this process. (We don't think there has been a separate Stylesheets release for a long time.)

5 6

ISO liaison
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Sep '20

23 Sep '20

Dear all, Kathryn forwarded me some documents on Guidance for ISO liaisons. Please find them here: https://drive.google.com/drive/folders/10diuYAlKE_yYf_KwaGKiUGoHYXZZ2cf1?us… Best, Martina

1 0

Next meeting: September 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Sep '20

08 Sep '20

Dear all, This is the agenda for our meeting on Tuesday, September 8 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30: https://docs.google.com/document/d/1gRTkIgQe7WCKSXSjgGcpFsrwHDKiwB8jhczLaRO… If you find time, please have a look at the proposal on encoding ruby glosses. Best, Martina

1 1

not so-called
by Syd Bauman 07 Sep '20

07 Sep '20

In P5/Source/Guidelines/en/ND-NamesDates.xml in the 1st paragraph of section NDORG the (organization) names “Harvard College”, “the BBC”, “Apple”, “Google”, “the Scythians”, and “the Militant Tendency” appear. They are encoded as <soCalled>. I am not sure what they should be encoded as (<mentioned> jumps to mind), but, except perhaps for the last, they are *not* so-called. Any thoughts?

2 1

Fwd: [oXygen-user] [Ann] New Oxygen add-on to help translators
by Lou Burnard 03 Sep '20

03 Sep '20

Reluctantly using Outlook for Android<https://aka.ms/ghei36> ________________________________ From: oXygen-user <oxygen-user-bounces(a)oxygenxml.com> on behalf of Radu Coravu <radu_coravu(a)sync.ro> Sent: Thursday, September 3, 2020 8:44:57 AM To: oxygen-user(a)oxygenxml.com <oxygen-user(a)oxygenxml.com> Subject: [oXygen-user] [Ann] New Oxygen add-on to help translators Hi everyone, Over the course of this summer one of our interns, Mircea Badoi, worked on a free Oxygen XML add-on designed to help translating XML content. Starting from yesterday, the add-on is available for Oxygen vesions 21.1 or newer in our default add-on repository. If you want to install it, you can use the Oxygen main menu "Help->Install new add-ons", choose the default Oxygen add-on update site and you will find an add-on named "Translator Helper (Experimental)" in the list. The add-on has two main features: 1. You can translate content using Google Translate to various languages: * Select the content to translate in the Author visual editing mode. You can also select the entire document contents. DITA topics are small so you can select the entire topic contents. * Right click. Select "Google Translate into" and choose the target language. * Copy the translated content from the opened web page. * Click Replace in the Oxygen Translate using Google Translate dialog that showed up. The original content should now be replaced with the translated content, the original element structure and attributes should remain unchanged. * In addition you can choose to show the original document content in the Translator Helper side view. This will allow you to correct the translation further by looking at the original text and the translated text side by side. 2. You can see the original content side by side with the content that you are translating, so you can translate correctly and easy by right clicking in the Author visual editing mode and invoking the Show current content in side view action. So I hope you will enjoy the add-on, if you have questions or improvement requests, they are as usual welcomed. One area in which the plugin may be useful is for example if you want to quickly demo to a customer how a topic written in English would look like in other languages like Japanese Chinese, French, German, Russian, etc. Regards, Radu Radu Coravu Oxygen XML Editor

1 0

Stylesheets meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 01 Sep '20

01 Sep '20

Dear all, This is the Zoom-Link for our Stylesheets Meeting tomorrow: https://us02web.zoom.us/j/88599847406?pwd=WGZJUkQ4RGhYQXplcnNyc1RWQU4xdz09 Best, Martina

4 3

Stylesheets meeting in < 12 hours
by Syd Bauman 01 Sep '20

01 Sep '20

Thank you, Martina, for the reminder. For some reason I had thought Council meeting was tomorrow, Stylesheets the week after. We will meet (without Raff -- snif!) at 13:00Z. That's: * 06:00 PDT * 09:00 EDT * 14:00 BST * 15:00 CEST Martina has set up a Zoom meeting space for us. (See [1], below for the URL.) Possible topics, in no intelligent order, include: a) Overview of new Makefile in Test/ b) Changes to Test2/, if there were any interesting changes to Test2/. c) New P5/Utilities/subset.xsl -- How often do you get to use "shallow-skip"? d) Ticket #237 -- I do not think there is any chance of solving it in 1 meeting (even if we did nothing else), but it is an interesting one and we might make some good progress in understanding exactly what is happening and why. e) Ticket #370 -- We made progress previously, and could push forward on this. f) Ticket #454 -- if anyone else has something to contribute. I put an *awful* lot of work into this just before release, and was not able to solve it. I barely remember anything about it at all now, a sign that it is gnarly enough my brain wanted to leave it behind. g) Ticket #449 -- The code that needs to be tweaked is shellscript, not XSLT, but I am not opposed to working on this if people want. h) Ticket #447 -- Perhaps we can at least figure out where that space is coming from. below ----- [1] https://us02web.zoom.us/j/88599847406?pwd=WGZJUkQ4RGhYQXplcnNyc1RWQU4xdz09

2 1

proposal for encoding ruby glosses
by Scholger, Martina (martina.scholger＠uni-graz.at) 28 Aug '20

28 Aug '20

Dear all, I'd like to share with you the proposal from Kiyonori Nagasaki and his colleagues from the East Asian / Japanese SIG on encoding ruby glosses in TEI https://docs.google.com/document/d/1rRgBRYpxUlsnMEHbOPW-92u_AIMNwq9axGtpI1U… Please have a look at it. Best, Martina

1 0

oXygen TEI plugin and debian packages
by Scholger, Martina (martina.scholger＠uni-graz.at) 21 Aug '20

21 Aug '20

Dear TEI Community, The oXygen TEI plugin has been updated with the latest version of the TEI Guidelines 4.1.0 and Stylesheets 7.50.0. A description on "How to automatically update your TEI framework in oXygen" can be found here: https://github.com/TEIC/oxygen-tei/blob/master/oxygen-tei-plugin.md Furthermore, the Debian packages are available at https://packages.tei-c.org/deb/. 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/

1 0

No masters
by Hugh Cayless 20 Aug '20

20 Aug '20

Hi All, I have deleted the master branches for TEI and Stylesheets, and plan to gradually work through the remainder. My inclination on most of them is probably to wait until there's an automated migration tool, as I understand pull requests may break, etc. Hugh

2 2

Release 4.1.0 complete
by Hugh Cayless 19 Aug '20

19 Aug '20

Dear All, especially Martina who can now announce it, We (Jessica, Nick, and I) have completed the release. You are free to commit to dev again. Thanks to all who dropped in on Slack to help out. The only remaining bits are the Oxygen plugin, which I can't build, and the Debian packages, because I was a bad release technician and forgot to ask Peter for the passphrase. All the best, Hugh

4 7

release minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 Aug '20

19 Aug '20

Dear release technicians, here is a document were you can take notes during the release (in case this is necessary). It also contains the email to the TEI-L https://docs.google.com/document/d/1PJryKNeKIzUEpdFlaQaJAhO9F3XM23IU66lB3QR… Best, Martina

2 1

release notes
by Syd Bauman 19 Aug '20

19 Aug '20

I updated the release notes *in the release-4.1.0 branch* (because that's what Martina did). While there are always improvements to be made, I think they are mostly good to go. Still need a release code name (why do we have those -- they are fun for us, but since we do not actually use them ...?). And I think we should consider deleting the prhase "to represent primary source materials" from the 1st bullet point.

2 1

Deb build warning
by Martin Holmes 17 Aug '20

17 Aug '20

Hi all, I'm still getting this warning on the release branch of the Stylesheets: dh_clean: warning: Compatibility levels before 9 are deprecated (level 5 in use) Didn't we decide to push that compat value up to 9? Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Release branches
by Hugh Cayless 17 Aug '20

17 Aug '20

Dear All, I've created release branches "release-4.1.0" for the Guidelines, and "release-7.50.0" for the Stylesheets. All the best, Hugh

3 3

Annotations and impasses
by Hugh Cayless 17 Aug '20

17 Aug '20

Hi All, Since we essentially have today to make the go/no-go decision for getting Annotations into this release. We seem to be deadlocked in a couple of ways, and I would like to see if we can un-jam things. Syd and I are arguing over whether annotations should look like: <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <respStmt xml:id="HAC"> <resp>creator</resp> <persName>Hugh Cayless</persName> </respStmt> <ptr target="http://example.org/description1"/> <note>tag1</note> </annotation> or <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <annMeta> <respStmt xml:id="SB"> <resp>creator</resp> <persName>Syd Bauman</persName> </respStmt> </annMeta> <annBody> <ptr target="http://example.org/description1"/> <note>tag1</note> </annBody> </annotation> Syd's argument (and you should correct me if I'm misrepresenting your opinion, Syd) is that it's cleaner to partition things this way and we might want in the future to say virtually any TEI element could be an annotation body. My counter to this is that we set out here to implement the Web Annotation Data Model (or parts of it at least) in TEI, and that WADM doesn't have extra containers for annotation metadata or bodies. Further, WADM doesn't do specialized body types. They have text and they have URIs. I'm certainly in favor of adding useful features to TEI annotations, but if we want to do that in the next round of work on annotations, we'll have to do it by adding new TEI functionality (probably via new elements), and I don't think partitioning the content of annotation will buy us anything. It might make it worse, because the extra-sparkly new TEI functionality won't be compatible with WADM:body and therefore probably shouldn't go in an <annBody> element. To compound this, Laurent seems to say that WADM was only ever meant to be an inspiration and actual interoperability with Web Annotation wasn't a goal they had in mind in requesting this feature. I'm just going to go cry for a bit...excuse me. Ok. I will sum up: I would really like to have WADM compatibility this year because I have things I want to do with it. My proposal is that we proceed with WADM-compatible annotations and then begin work on more powerful TEI annotations. I would like to keep the content model of <annotation> as simple and as close to WADM as possible, but I won't pout if I'm voted down on that. What do you all think? Hugh

7 12

Freeze
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 Aug '20

16 Aug '20

Dear all, I would like to remind you that we had agreed to freeze starting tonight. Please keep that in mind and check with the release technicians in case of late changes. Best, Martina Von meinem Huawei-Mobiltelefon gesendet

2 1

Stylesheets 454 and thus TEI 1848
by Syd Bauman 16 Aug '20

16 Aug '20

I have put multiple days of debugging work into Stylesheets 454, the release-blocking error that means a <classRef>, or at least a <classRef> with an @except, is ignored when processing an ODD. While I have made serious progress (some of which is in the sydb-454 branch), it is looking like I will not have a viable solution by the end of the day. Thus I think we need an alternate solution, which would be to back out [1] and either leave title page stuff out of <lem> and <rdg> for this release, or use some other ODD mechanism to put them in there. Possibilities (listed in my order of preference) include: 1. Use a bunch of <elementRef>s 2. Use <classRef> w/o @except, and add a <constraint> to flag <binaryObject>, <graphic>, and <castList> as invalid 3. Make a new class "model.frontPart.apparatusable" and put the needed elements in it. 4. Use <classRef> w/ @include (but I am highly suspicious that this will fail in exactly the same way). We can change any of the above back to <classRef> w/ @except after 454 is fixed. The other possibility, of course, is that someone else will take a look at this and fix the bug in the next few hours. If anyone wants to join my for a screen-sharing debugging session, speak up. That said, I really have other things I need to do today, too. :-| Notes ----- [1] TEI repo commit 193e6283321aeeb68b9a93b0d95b10a82148ef74

1 0

OxGarage release
by Peter Stadler 13 Aug '20

13 Aug '20

Hi all, the last release of OxGarage was done in June 2019 and since then not much development has happened, yet there are some minor changes that IMHO qualify for a new release. Most of all, the current master branch won’t build anymore on Travis nor on DockerHub – which is already fixed in dev. While at it, I already created a new main branch to eventually replace master starting with this release. (As a side note, Hugh was right about GitHub providing tools for doing this change later this year, see https://github.com/github/renaming#later-this-year. So I won’t touch other repos …) So, my proposal is to release OxGarage v3.1.0 next week and take care of the branch name switch with this release. If I hear no objections, I will take this as silent consent and do so :) Best Peter

1 1

REGENERATING, NOT!
by Syd Bauman 11 Aug '20

11 Aug '20

Re: Stylesheets meeting further info BTW, passing REGENERATING=1 to the Stylesheets/Test/Makefile tells the Makefile to not bother doing all those `diff` commands, but it does NOT actually regenerate the expected_results/. I.e., it just generates the output files (like test15.odd.rnc), but does not move them into expected_results/. One would have to do that by hand. (I think this was a purposeful change by Martin or someone just to avoid clobbering all the expected_results/.) Moreover, back on 2020-03-18 Martin commented out the diffs of test21.rnc, test30.rnc, and test30.dtd. I think we should probably put those back, yes, Martin?

3 2

Slightly Updated: Steps for updating p5subset.xml in Stylesheets repo
by Martin Holmes 11 Aug '20

11 Aug '20

This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets. The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release. This is how it goes: 1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5. 2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull. 3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch. 4. Replace the source/p5subset.xml in the subsetSetup branch with the fresh one. 5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch. 6. Fix any problems. At this point, if there are problems too difficult to fix in the time you have available, abandon the process and put in a ticket for the Stylesheets repo. If the error is serious, make it a release-blocking bug. 7. Commit changes to subsetSetup branch. git push. 8. Switch back to the dev branch, git pull, and merge changes from the subsetSetup branch. git push. 9. Watch Mr Jenkins to make sure all is well. -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

2 2

Fwd: Steps for updating p5subset.xml in Stylesheets repo
by Martin Holmes 11 Aug '20

11 Aug '20

-------- Forwarded Message -------- Subject: Steps for updating p5subset.xml in Stylesheets repo Date: Fri, 7 Aug 2020 08:41:32 -0700 From: Martin Holmes <mholmes(a)uvic.ca> To: Syd Bauman <s.bauman(a)neu.edu> CC: Martin Holmes <mholmes(a)uvic.ca> This is an outline of the process we designed for updating the local copy of p5subset.xml in the Stylesheets. The rationale for this process is that changes to P5 inevitably require changes to the Stylesheets, but it makes more sense to deal with those required changes in batches, periodically, rather than making every change to P5 trigger frantic work on the Stylesheets (which the P5 ticket implementer may not be able to undertake at the time). The Stylesheets Group should probably undertake this work, and it must happen in a timely manner before any release. This is how it goes: 1. Retrieve a fresh copy of p5subset.xml, built using the current dev branch of P5. 2. In the Stylesheets, switch to the dev branch and git pull. Switch to the subsetSetup branch, which is intended for this work, and git pull. 3. Merge any changes from the Stylesheets dev branch into the subsetSetup branch. 4. Replace the p5subset.xml in the subsetSetup branch with the fresh one. 5. Run the Stylesheets tests (Test and Test2) in the subsetSetup branch. 6. Fix any problems. 7. Commit changes to subsetSetup branch. git push. 8. Switch back to the dev branch, git pull, and merge changes. git push. 9. Watch Mr Jenkins to make sure all is well. -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Stylesheets meeting Tue 11 Aug
by Syd Bauman 11 Aug '20

11 Aug '20

Time to get our heads spinning 'round circularity! We are planning a Stylesheets group meeting for this Tue 11 Aug at 13:00Z.[1] This is an important meeting, because we are going to step through the process of updating the p5subset.xml that the various build processes are using; i.e., we are implementing (for the first time) our planned "fix" for the circularity problem. (Not really so much a fix as a work-around, IMHO.) I expect we will be using Google Hangouts unless someone says otherwise. Notes ----- [1] 13:00 UTC is: 06:00 PDT 09:00 EDT 14:00 BST 15:00 CEST

3 2

Guidelines JQuery
by Hugh Cayless 06 Aug '20

06 Aug '20

Hi All, I've upgraded the Guidelines' copy of JQuery to 3.5.1 (the latest) and fixed a bug that followed on from that. Does anyone remember why we haven't nuked P5/Utilities-1 (which I believe was where old XSLT 1.0 Guidelines generation code got put, like over a decade ago). Can I get rid of it? Please? This is the sort of thing I was calling "cruft" in the meeting this morning :-). Hugh

4 5

WG: TEI and meeting the needs of most users most of the time
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Aug '20

04 Aug '20

Dear all, FYI - I would like to share with you an email from Martin Mueller. Best, Martina Von: Martin Mueller <martinmueller(a)northwestern.edu> Gesendet: Samstag, 18. Juli 2020 00:25 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Betreff: TEI and meeting the needs of most users most of the time Dear Martina, I have been working with TEI Publisher 6.0 (or rather trying to wrap my aging brain around its complexities), and in doing so I have spent the past two days looking at TEI documentation. This has confirmed my long-held conviction that TEI documentation is very good for folks who know what they are doing but need to look up this or that. It does not do much “newbies”. Luther’s “Kleiner Katechismus” (1529) has often been on my mind when thinking about TEI documentation. It badly needs its own Small Catechism in which everything that you need most of the time is clearly described then and there without reference to a very large document, which becomes useful only after weeks of using it. Within a few years of the first release of the TEI Lou and Michael published TEI-Lite with the goal of meeting 90% of the uses of 90% of the users—a classic and extremely successful implementation of the 80/20 rule. For quite a few years there was a very nice guide to it on an Oxford site. I think it was Sebastian’s work. It told you everything about the ~150 elements of that schema without distracting the users’ minds with stuff they did not (yet) need to know. In the years since then the TEI has spent a lot more time refining this and that but has spent hardly any time or energy on “preaching beyond the choir”. There are many reasons for the absolute and relative decline of the TEI as an institution, but the lack of attention to ordinary users has probably had a good deal to do with. One of my friends tells me that in Medical School he got the advice “When you hear hooves clattering behind you, think horses not zebras”. The TEI has been all about zebras. An almost funny example is the documentation for TEI Simple, the project that Sebastian and I worked on and that suffered greatly from his illness and death, although its Processing Model was eagerly picked up by Wolfgang Meier and Joe Wicentowski. In the final report to the Mellon Foundation I wrote the following paragraph about it: At an earlier stage the project was called TEI Nudge, and throughout it has taken inspiration from Richard Thaler's and Cass Sunstein's Nudge with its persuasive argument that in many walks of life people will make better choices if they are offered well-designed default solutions, as long as they are free to opt out of them. TEI Simple focuses on interoperability, machine generation, and low-cost integration. The TEI architecture facilitates customizations of many kinds; TEI Simple aims to produce a complete ‘out of the box’ customization that meets the needs of the many users for whom the task of creating a customization is daunting or seems irrelevant. TEI Simple in no way intends to constrain the expressive liberty of encoders who do not think that it is either possible or desirable to follow this path. It does, however, promise to make life easier for those who think there is some virtue in travelling that path as far as it will take you, which for quite a few projects will be far enough. Some users will never feel the need to move beyond it, others will outgrow it, and when they do they will have learned enough to do so. On the Customization page of the TEI site, TEI simplePrint is described as “An entry-level customization, focused primarily on the needs of those encoding Western European early modern printed material”. Instead of stressing what you can do with it, the description dwells on what you cannot do. This is plain wrong in several ways. You can encode the Iliad in Greek, the Torah in ancient Hebrew, Anna Karenina in the Cyrillic alphabet, the Koran in Arabic (I believe),and a lot of other stuff. It is neither “Western” nor “early modern” But the summary of TEI Lite is not much better, describing it as “basic elements for simple documents”. Its 150 elements are not particularly ‘basic’, and the documents encoded by it are anything but simple. I wrote an early draft of the documentation for TEI Simple, using (with their permission) Lou’s and Michael’s’ excellent TEI Lite documentation, but did not see the final version, and indeed until this morning never read the following paragraphs to which I would have strongly objected at the time: Like every other TEI customization, TEI simplePrint was designed for use with a particular type of material. If the material you are planning to encode matches the following criteria, then TEI simplePrint is for you. If it does not, it may not be. You are encoding print material, rather than manuscript: simplePrint provides no way of encoding manuscript features such as correction, deletion, or scribal variation. You are encoding material from the Early Modern period (i.e., up to the end of the nineteenth century): some of the features for which simplePrint provides encodings are rarely found in modern materials. You are encoding material written, broadly speaking, within the Western European tradition, using largely Western European characters. simplePrint does provide facilities for encoding short passages in non Western European languages, but many features needed to cope with Asian or ancient scripts are missing. Your intention is to provide a relatively simple encoding for a large amount of material, rather than a rich encoding of a small amount of material: simplePrint is intended to help libraries and archives wishing to go beyond basic digital facsimiles, rather than to support specialist research. It does not, for example, include features for detailed linguistic tagging beyond simple word-level tagging, nor for specialised text types such as dictionaries, historical or biographical databases, etc. These paragraphs are condescending in tone and inaccurate in substance . The term “Early Modern” is misused, the reference to “Western European characters” is grossly inaccurate, and the claim that texts encoded in this fashion do not “support specialist research” does not hold up to much examination. My mother, a pediatrician, did not care much for Dieter Borsche, especially in one of his films where as a doctor he proclaims that “Der ist kein wahrer Arzt der noch kein Serum hat erfunden.” Medicine most of the time is about horses, not zebras—a useful lesson right now when the daily Corona virus deaths in Florida (20 million people) are as many as in the European Union (400 million people). But the TEI is also about horses most of the time—a dangerous thing to forget. The language of the Simple documentation and of quite a few paragraphs in the Guidelines carries an undertone of indifference to encoding schemes that fall below some level of complexity, as if the interest of a TEI encoded document were only a function of the complexity of its encoding. But this is exactly the wrong way of looking at it. Most encounters of end users with TEI-encoded documents involve documents with moderately complex encoding. I can certainly appreciate the challenges of virtuoso encoding and the pleasures of a difficulté vaincue , but the thriving of the TEI depends primarily on providing quite mundane services to a growing community of readers and users. This is not a new topic for me: some years ago I warned that the TEI might become an Orchideenfach. https://sites.northwestern.edu/scalablereading/2016/09/20/whither-tei-the-n… Chapter 23 of the Guidelines has the sentence “it is almost impossible to use the TEI schema without customizing it in some way.” That is not true: a large majority of TEI encoded texts have been encoded encoded in schemas that are identical with or slight variants of TEI Lite, TEI Guidelines for Libraries, Level 4, the EEBO dtd, the DTA schema, the Clarin schema and perhaps a few others. “ Standardize where you can, customize where you must” might be good advice. It would not be difficult to derive from these schemas a new version of TEI Lite. I would call it TEI Vanilla because it does for encoding what Vanilla does for ice cream: it works most of the time in the sense of supporting moderately complex encodings of quite complex documents. If the TEI wants to thrive it needs to have some version of TEI Vanilla with a built-in Processing Model and a documentation that has the virtues of Luther’s Small Catechism: enough to give ordinary users a clear pathway to heaven. Feel free to share this letter with the Council or Board With best wishes MM Martin Mueller Professor emeritus of English and Classics Northwestern University

4 3

meeting starts in 15 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Aug '20

04 Aug '20

Dear all, our Council meeting starts in 15 minutes, this is the agenda with the zoom link: https://docs.google.com/document/d/1HhU-alLRORO-aHpNH07xXU0NugTsKWACrODIDib… Best, Martina

1 0

Next Council meeting - Tues, Aug 4
by Scholger, Martina (martina.scholger＠uni-graz.at) 03 Aug '20

03 Aug '20

Dear all, After receiving some feedback on my request to swap the Council and the Stylesheets meeting, the Council meeting will now be tomorrow (Tues, Aug 4) at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30. This is the agenda for the meeting: https://docs.google.com/document/d/1HhU-alLRORO-aHpNH07xXU0NugTsKWACrODIDib… Please find the zoom link in the agenda. Best, Martina

1 0

refrigeration & next meetings
by Scholger, Martina (martina.scholger＠uni-graz.at) 02 Aug '20

02 Aug '20

Dear all, I would like to remind us that we are already in the refrigeration period. There are still a lot of issues labeled with milestone 4.1.0 (https://github.com/TEIC/TEI/issues?q=is%3Aissue+milestone%3A%22Guidelines+4…) Please have a look at the list and remove those issues, that you will not tackle before the next release. Our next Stylesheets meeting is scheduled for Tuesday, August 4; the next Council meeting is scheduled for Tuesday, August 11 (one day before release on August 12). I would like to propose to switch these dates and have our Council meeting on Tuesday, August 4. This would give us the opportunity to prepare for the release and to clarify open questions. Let me know what you think. Best, Martina

5 4

oh, duh: <listAnnotation> in upcoming release?
by Syd Bauman 31 Jul '20

31 Jul '20

My vague recollection is we had wanted <listAnnotation> to go into the upcoming release whether <annotation> was ready or not. It is not ready. However, I am just newly reminded that 1. There is no prose in the Guidelines that discusses <listAnnotation>; 2. thus there is no place for the <listRef> of <listAnnotation> to point; and 3. the <desc> of <listAnnotation> (and presumably any prose that discusses <listAnnotation>) makes reference to <annotation>, which does not exist.

5 6

Chapt 11 PR: when do we freeze?
by Raffaele Viglianti 31 Jul '20

31 Jul '20

Hello, I know we entered the refrigeration period yesterday, though I see some activity on the chapt 11 PR https://github.com/TEIC/TEI/pull/2014 It would be awesome to be able to include these changes if we get sufficient feedback. Since they're all prose changes, I'd say that we can push closer to the release date, because the build is not likely to be gravely affected by these changes. However, it would be good to have a firm deadline (a freeze?) also to put some pressure on those contributing. Any suggestions or concerns? What about a deadline of August 9, the Sunday before the release on the 12th? Raff

3 2

Re: [Tei-council] git help: 24 behind, but merge says up-to-date
by Bauman, Syd 31 Jul '20

31 Jul '20

MH> Have you switched to dev and done a pull? PS> your local dev branch is probably out of date. Try to checkout (switch to) dev first and do a `git pull` there. Then switch back to your standoff branch and do the merge. PS> (There is also `git pull -- all` but use with caution) RV> I haven't used -m with git merge, so I'd be tempted to try RV> $ git merge dev RV> And see if that makes a difference. It should prompt you to add a message (usually pregenerated for merges). RV> You could also try to fetch before merging RV> $ git fetch RV> $ git merge dev Thank you, gentlemen. Yes, I had failed to (properly) pull into dev. BTW, I use the -m switch (which allows you to specify the commit message on the commandline) rather than rely on the default behavior because when git tries to prompt for the commit message from within Emacs it fails, kinda spectacularly. (All right, that may be an exaggeration, but certainly annoyingly.)

2 2

UVic Jenkins down
by Martin Holmes 30 Jul '20

30 Jul '20

Hi all, Just a heads-up that the UVic Jenkins server is down. Our sysadmins tried to migrate it to a new VM infrastructure yesterday, and it looks like the process was not successful. I'm currently on vacation and don't have regular network access, so the timing wasn't great. I don't know when it's expected to be back up, I'm afraid. Cheers, Martin

1 0

git help: 24 behind, but merge says up-to-date
by Syd Bauman 30 Jul '20

30 Jul '20

If I look at the sydb-standOff branch on GitHub[1], I find that the standOff branch is 24 commits behind dev. But if I try to merge, I am told that it is already up-to-date: $ pwd | /home/syd/Documents/TEI_sydb-standOff $ git status -uno | On branch sydb-standOff | Your branch is up-to-date with 'origin/sydb-standOff'. | nothing to commit (use -u to show untracked files) $ git pull # not that I expect anything | Already up-to-date. $ git merge -m "What happens in dev does not stay in dev" dev | Already up-to-date. $ # What? Website says I'm behind 'dev' by 24 commits. What am I doing something wrong here? Kinda pressing, because this branch should be folded into dev before we refrigerate (or at least before we freeze). Notes ----- [1] https://github.com/TEIC/TEI/tree/sydb-standOff

2 1

WADM mtg
by Syd Bauman 21 Jul '20

21 Jul '20

Since no one answered my 2 e-mails from this morning, I am very suspicious they did not make it to the list (and I cannot check, due to certificate error from https://lists.lists.tei-c.org/mailman/listinfo/tei-council) And while I’m at it, Hugh had a document with several proposals for encoding WADM. Is that the Annotations in TEI GoogleDoc, or is there a separate document I can’t find at the moment? We (SB, HC, NC, RV, and anyone else who wants to) are still planning to meet tomorrow 13:00Z, right? Where are we meeting? I did not get a chance to look at WADM over the weekend as planned (entirely frustrated by Linux installation stuff instead), but am planning to start looking at WADM now.

5 5

is TEI-C down?
by Meaghan Brown 20 Jul '20

20 Jul '20

I'm getting a 502 Bad Gateway when trying to access https://tei-c.org/ -- is this a known issue? Cheers, Meaghan -- Dr. Meaghan Brown

3 2

upcoming WADM meeting
by Syd Bauman 20 Jul '20

20 Jul '20

We (SB, HC, NC, RV, and anyone else who wants to) are still planning to meet tomorrow 13:00Z, right? Where are we meeting? I did not get a chance to look at WADM over the weekend as planned (entirely frustrated by Linux installation stuff instead), but am planning to start looking at WADM now.

1 0

Meeting today
by Scholger, Martina (martina.scholger＠uni-graz.at) 14 Jul '20

14 Jul '20

Dear all, Please find the agenda and the zoom link for today's meeting here: https://docs.google.com/document/d/1ffGOmKq_EY_ZFBNMfoR59VlX6QfaHBuwCpmvOvH…<https://docs.google.com/document/d/1ffGOmKq_EY_ZFBNMfoR59VlX6QfaHBuwCpmvOvH…> Best, Martina Von: Scholger, Martina (martina.scholger(a)uni-graz.at) Gesendet: Freitag, 10. Juli 2020 20:16 An: TEI Council <tei-council(a)lists.tei-c.org> Betreff: Next meeting: July 14 Dear all, Our next Council meeting is on Tuesday, July 14 at EST 09:00-10:30 / GMT 14:00-15:30 / CEST 15:00-16:30. Please add issues to the agenda that you want to discuss on Tuesday: https://docs.google.com/document/d/1ffGOmKq_EY_ZFBNMfoR59VlX6QfaHBuwCpmvOvH…<https://docs.google.com/document/d/1ffGOmKq_EY_ZFBNMfoR59VlX6QfaHBuwCpmvOvH…> The Zoom-link is in the google doc. Best, Martina

2 1

Next meeting: July 14
by Scholger, Martina (martina.scholger＠uni-graz.at) 10 Jul '20

10 Jul '20

Dear all, Our next Council meeting is on Tuesday, July 14 at EST 09:00-10:30 / GMT 14:00-15:30 / CEST 15:00-16:30. Please add issues to the agenda that you want to discuss on Tuesday: https://docs.google.com/document/d/1ffGOmKq_EY_ZFBNMfoR59VlX6QfaHBuwCpmvOvH… The Zoom-link is in the google doc. Best, Martina

1 0

Stylesheets coop meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 06 Jul '20

06 Jul '20

Dear all, I've set up a zoom meeting for our cooperative Stylesheets meeting tomorrow at 6:00 PDT / 9:00 EDT / 14:00 BST / 15:00 CEST: https://us02web.zoom.us/j/83142838842?pwd=NUFSS05UNXVEWnlTQkpzUDBmVDdndz09 Best, Martina

1 0

ack! bad Syd, bad!
by Syd Bauman 04 Jul '20

04 Jul '20

I just went to see from whom I am taking over as ticket triage person only to find that I screwed up, I was the ticket triage person for June, not July. Elisa -- you are the ticket triage person for July. I plan to make a run through the tickets tomorrow, and will hand the baton over to you shortly thereafter, OK? Sorry, y'all.

3 4

Git branch naming
by Hugh Cayless 03 Jul '20

03 Jul '20

Hi All, Some of you may have come across the recent move toward changing the default branch name in Git away from "master" to (probably) "main". My understanding is that GitHub is working on this, and that it will probably happen in Git as well. I'm aware of a number of projects that are moving ahead immediately on renaming their master branches. On the one hand, I'm generally in favor of this. The "master" terminology probably came from BitKeeper, which had "master" and "slave" repositories (rather than branches). I had always assumed it was meant in the sense of "master copy", like in sound recordings. But see also https://twitter.com/xpasky/status/1271477451756056577 from the person responsible for the name (not a native English speaker). On the other hand, I'm slightly cynical about this sort of thing, as it's the kind of change one can make and feel righteous about without being *actually* significantly anti-racist. It's a bit performative, but sometimes it's important to set an example. So I think we should consider going through the renaming process for TEI repos. There are probably some implications to doing that, broken links being the first one that comes to mind. What do you all think? Hugh

10 20

Re: [Tei-council] WG: A new tool for the TEI!
by Raffaele Viglianti 30 Jun '20

30 Jun '20

Didn't hit reply all. See below On Tue, Jun 30, 2020, 12:12 PM Raffaele Viglianti < raffaeleviglianti(a)gmail.com> wrote: > Hi Martina, > > Overall, it seems pretty fast to me, and I like how it's simple to create > a TEI file from a template and that elements and attributes are suggested > as you type. > Here are a few comments from testing on Ubuntu 18.04.4 LTS. > > These things should be there to make it truly useful in a teaching context: > - validation doesn't seem to trigger automatically, one needs to click > "Parse Buffer" to initiate it. This isn't bad per se, but it took me too > long to figure it out. I would recommend making the button more visible > (icon?) and call it something more descriptive (e.g. "Parse and Validate") > - show <a:documentation> values from the RNG when scrolling through > possible elements and attributes. This is the easiest way to know whether > an element is appropriate or not; I rely on it as a training device > - attribute values from closed or semi lists should be shown and documented > > Desiderata (besides the ones already mentioned by them): > - I'm not a jEdit user, but when the plugin is activated, all its > components appear in tiny floating windows that need to be docked. It's a > one-off operation, but frustrating, and I suspect younger students will not > be familiar with this kind of UI. It's possible that nothing can be done > about this, unless jEdit's API allows for a plugin to start "docked". > - it would be great to have a wrap element button or shortcut (Oygen's > Ctrl+e) > > Best, > Raff > > On Mon, Jun 29, 2020 at 8:12 AM Scholger, Martina ( > martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> wrote: > >> Dear Council, >> >> >> >> Marjorie Burghart and Conal Tuohy have released their TEI plugin for the >> open source editor in jEdit. They would like to invite us for testing the >> tool and sending them feedback. >> >> Please see Marjorie’s email with all the details below. >> >> >> >> Best, >> >> Martina >> >> >> >> *Von:* Marjorie Burghart <marjorie.burghart(a)gmail.com> >> *Gesendet:* Montag, 22. Juni 2020 16:51 >> *An:* Scholger, Martina (martina.scholger(a)uni-graz.at) < >> martina.scholger(a)uni-graz.at>; James Cummings < >> James.Cummings(a)newcastle.ac.uk>; louburnard <lou.burnard(a)gmail.com> >> *Cc:* Conal Tuohy <conal.tuohy(a)gmail.com> >> *Betreff:* A new tool for the TEI! >> >> >> >> Dear Martina, Lou, Hugh and James, >> >> >> >> Conal and I are very pleased to let you know that a TEI plugin for the >> open source editor jEdit has been officially released: >> >> >> >> http://plugins.jedit.org/plugins/?TEI >> >> The plugin is slowly propagating through the mirrors of jEdit's Plugin >> Central, if you don't see it there yet it should appear shortly. >> >> >> >> Before making an official announcement, we would appreciate getting >> feedback from "power users" of the TEI :) We thought of you (and through >> Martina, of all Council members). If you have the time to give it a try, we >> would very much appreciate your feedback on potential bugs, ergonomy >> issues, etc. Conal thinks those first bugs could be fixed in a new release >> in a couple of weeks. >> >> >> >> Conal is hosting the source code on his github, where you could report >> issues: >> >> https://github.com/Conal-Tuohy/jEdit-TEIPlugin/issues >> >> and he has created a wiki page: >> >> https://github.com/Conal-Tuohy/jEdit-TEIPlugin/wiki >> >> >> >> How to proceed: >> >> - Install the latest version of jEdit http://www.jedit.org/ >> >> - Through the plugin manager (Plugins > Plugin Manager...), search the >> "TEI" plugin and install it with all its dependencies >> >> NOTA BENE: if you already had jEdit with the XML plugin installed, you >> will also need to update the XML plugin to the latest version. >> >> >> >> What it does: well, not everything :) The aim is NOT to replace Oxygen >> entirely, but to offer the community a viable free alternative, especially >> for teaching workshops and users with basic needs. We tried to cover the >> needs listed here (basic, and even some some deemed superfluous) : >> >> https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features >> >> >> Conal is currently working on two other improvements: >> >> - schematron support >> >> - a mechanism akin to Oxygen's validation scenarios. >> >> >> >> The plugin has been developed by Conal, and the first steps in its >> development funded by a small grant I obtained from DARIAH - but Conal has >> done much more work "pro bono", and is kindly continuing development to >> enhance the features. If the community sees some use in this first step, I >> am planning to do my best to get further developments funded. >> >> >> >> Best wishes, >> >> Marjorie >> >> >> >> >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >

1 0

TCW30
by Scholger, Martina (martina.scholger＠uni-graz.at) 30 Jun '20

30 Jun '20

Dear Council, I've published the "Workload and Guidelines for Resignation" as TCW30: http://teic.github.io/TCW/tcw30.html Best, Martina

2 1

WG: A new tool for the TEI!
by Scholger, Martina (martina.scholger＠uni-graz.at) 29 Jun '20

29 Jun '20

Dear Council, Marjorie Burghart and Conal Tuohy have released their TEI plugin for the open source editor in jEdit. They would like to invite us for testing the tool and sending them feedback. Please see Marjorie’s email with all the details below. Best, Martina Von: Marjorie Burghart <marjorie.burghart(a)gmail.com> Gesendet: Montag, 22. Juni 2020 16:51 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at>; James Cummings <James.Cummings(a)newcastle.ac.uk>; louburnard <lou.burnard(a)gmail.com> Cc: Conal Tuohy <conal.tuohy(a)gmail.com> Betreff: A new tool for the TEI! Dear Martina, Lou, Hugh and James, Conal and I are very pleased to let you know that a TEI plugin for the open source editor jEdit has been officially released: http://plugins.jedit.org/plugins/?TEI The plugin is slowly propagating through the mirrors of jEdit's Plugin Central, if you don't see it there yet it should appear shortly. Before making an official announcement, we would appreciate getting feedback from "power users" of the TEI :) We thought of you (and through Martina, of all Council members). If you have the time to give it a try, we would very much appreciate your feedback on potential bugs, ergonomy issues, etc. Conal thinks those first bugs could be fixed in a new release in a couple of weeks. Conal is hosting the source code on his github, where you could report issues: https://github.com/Conal-Tuohy/jEdit-TEIPlugin/issues and he has created a wiki page: https://github.com/Conal-Tuohy/jEdit-TEIPlugin/wiki How to proceed: - Install the latest version of jEdit http://www.jedit.org/ - Through the plugin manager (Plugins > Plugin Manager...), search the "TEI" plugin and install it with all its dependencies NOTA BENE: if you already had jEdit with the XML plugin installed, you will also need to update the XML plugin to the latest version. What it does: well, not everything :) The aim is NOT to replace Oxygen entirely, but to offer the community a viable free alternative, especially for teaching workshops and users with basic needs. We tried to cover the needs listed here (basic, and even some some deemed superfluous) : https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features Conal is currently working on two other improvements: - schematron support - a mechanism akin to Oxygen's validation scenarios. The plugin has been developed by Conal, and the first steps in its development funded by a small grant I obtained from DARIAH - but Conal has done much more work "pro bono", and is kindly continuing development to enhance the features. If the community sees some use in this first step, I am planning to do my best to get further developments funded. Best wishes, Marjorie

1 0

circular build headache suggestion
by Syd Bauman 16 Jun '20

16 Jun '20

The circularity of the P5 and Stylesheets builds depending on each other has bitten us once again. (Ouch!) We have a situation now where the Stylesheets tests can succeed only against either the release branch of P5 or the dev branch of P5, but not both simultaneously. This sucks. Right now Stylesheets dev branch is successfully building against P5 release[1], but failing against P5 dev branch[2]. We believe that the reverse would make a lot more sense. While it is desirable that it build against both branches, it is frequently impossible. So we have to pick one, and we (Martin & Syd) think we should pick them as follows: * P5 release branch should be built with the P5 release Stylesheets * P5 dev branch should be built with the P5 dev Stylesheets * Stylesheets release should be built against P5 release branch * Stylesheets dev should be built against P5 release dev as a general rule. This means we would have to always release a new Stylesheets the same day we release P5 every time. It also means that if we ever had a reason we needed to do an interim release of either, we would have to fight with the circularity problem (probably by trying to make sure both branches work against each other, or temporarily suppressing some finicky tests). But the advantage is that "normal" releases and updates would work properly. So what we would like to do is: * Update Stylesheets deb branch tests so that they work against P5 deb (which will break them against P5 release branch) * Have Peter & Martin agree on a consistent set of explicit job names in Jenkins that perform the 4 builds listed above. Notes ----- [1] E.g. on jenkins.tei-c job "Stylesheets-dev" and jenkins2.tei-c job "Stylesheets-dev-against-P5-release". [2] E.g. on jenkins.tei-c job "Stylesheets-dev-against-TEIP5-dev" and jenkins2.tei-c job "Stylesheets-dev-against-TEIP5-dev".

3 8

off topic: new ODD based non-TEI schema
by Peter Stadler 16 Jun '20

16 Jun '20

Dear all, here I want to bring to your attention a project of a colleague called "Music Performance Markup" (MPM): https://axelberndt.github.io/MPM/ I want to share this with you because it’s a great example of an ODD based non-TEI schema, and it features a nice rendering of the documentation. If we ever wanted to redesign our Spec pages, this might give us some ideas :) Have fun Peter

1 0

Another thought on <annotation>
by Hugh Cayless 12 Jun '20

12 Jun '20

Had a bit of a brainstorm this morning, and I came up with another idea re representing WADM annotations. See #9 at https://docs.google.com/document/d/15lPVs89ehDNpQQ3Qf79kfRAECSN-MT_SpBlQpHU…. I'd be grateful for your opinions. Hugh

1 0

Progress on labeling tickets
by Martin Holmes 11 Jun '20

11 Jun '20

Hi all, Today Elisa and I added all the labels we think appropriate for all tickets starting at the oldest and running up to #319. That seems to be half of the tickets, so we think our work is done. A few tickets got closed in the process. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

housekeeping: delete stale branches
by Peter Stadler 10 Jun '20

10 Jun '20

Dear all, here’s yet another(?) proposal for housekeeping: Both Stylesheets and Guidelines repo feature various stale branches which I would like to get rid off [1,2]. Some of those are prefixed with a Councilists name so I encourage everyone to look through his/her branches and eventually delete outdated/unused/forgotten branches. Some of the stale branches are even just behind dev without featuring any commits *ahead* of dev (e.g. the TEI/help branch). I think those can safely be removed and would do so in the next days if no one objects. This does include release branches which I’d also like to get rid of because IMHO they do not serve any purpose anymore (the important information is kept in the tags). Best Peter [1] https://github.com/TEIC/Stylesheets/branches/stale [2] https://github.com/TEIC/TEI/branches/stale [3] https://github.com/TEIC/TEI/tree/help

3 3

call in 10 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Jun '20

09 Jun '20

Dear all, Our call starts in 10 minutes: https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w… Best, Martina

1 0

Reminder: Council meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Jun '20

08 Jun '20

Dear all, This is a reminder that our next Council meeting is tomorrow, June 9 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30 Please find the agenda here and add topics that we should discuss https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w…<https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w…> You can find the zoom link for the meeting in the google doc. Best, Martina

1 0

Next Council meeting: Tuesday, June 9
by Scholger, Martina (martina.scholger＠uni-graz.at) 05 Jun '20

05 Jun '20

Dear all, Our next Council meeting is on Tuesday, June 9 at EST 09:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30 Please find the agenda here and add topics that we should discuss https://docs.google.com/document/d/1MK5fPZS0sHMJ1HMumwU6YpqH6JKgMRhB72lv38w… You can find the zoom link for the meeting in the google doc. Best, Martina

1 0

P5/Utilities-1 and P5/Utilities
by Peter Stadler 04 Jun '20

04 Jun '20

Dear all, while working on some old TEI->LaTeX->PDF issues I stumbled (once again) across those two folders P5/Utilities-1 and P5/Utilities in the Guidelines repo. Can somebody shed some light on the difference of these folders? I’m especially interested in the file guidelines-latex.xsl which exists in both directories but only the one in Utilities seems to be used for building the PDF version of the Guidelines? Many thanks Peter

2 2

Noto fonts
by Peter Stadler 03 Jun '20

03 Jun '20

Hi Martin, I'm about to push some changes to the TEI repo that will set the Google Noto fonts as default for the PDF Guidelines (processed via LaTeX). That requires the fonts-noto-cjk package (on Debian) in the respective build environment. It is already included in our Jenkins Docker image but you might need to add that manually to your Jenkins? Just wanted to give you a warning (shortly) ahead of time ;) Best Peter

2 1

plan for Stylesheets, and versions, and tags, oh my!
by Syd Bauman 03 Jun '20

03 Jun '20

At one point we had a Stylesheets meeting planned for this Tue 02 Jun at 13:00Z. Various other plans have cropped up since. Basically, Elisa, Martin, Peter, and I have not finished the Stylesheets categorization project; although we have made good progress, we still have more to go, and would like to use that time slot. Furthermore, Peter has suggested (and I readily agree) that we, Council, need to talk about teidata.version. Thus my suggestion is 1. a 1-hour meeting at 13:00Z with as many Council members as will show up to discuss version numbering and (time permitting) Stylesheets 2. a 1-hour meeting at 14:00Z of PS & SB and MH & EB to do more Stylesheets labeling. I, for one, have another meeting at 15:00Z which I do not want to be late for.

10 11

Do we need better issues?
by Raffaele Viglianti 29 May '20

29 May '20

Hi all, After today's meeting, I started thinking about why we often end up in loops of discussion. Keeping in mind that this is a partial and personal view, I think that this happens for a few reasons: some are good (e.g. disagreement that needs to be worked out), some are ok (e.g. someone forms an opinion while missing a key piece of context --mea culpa), others are due to the ticket (e.g. it's verbose, it's unclear, it's too short, the discussion is long, etc.) To address the latter, I think we need to ask more of our submitters (including ourselves when creating issues). Each issue should state clearly what the problem is, show clear examples, and offer a solution. Many issues do (I think of the UVic ones are particularly exemplary, however extreme their requests may often appear to me :) ), but the style varies too much and it makes it time consuming for us to figure out what the real issue is and to reprise quickly on second iterations. I wonder if a strict issue template may help us here. GitHub allows to configure multiple templates <https://help.github.com/en/github/building-a-strong-community/using-templat…> (e.g. a bug report template could be default, with the possibility to switch to a feature request one, and perhaps others). Templates pre-populate an issue with headers and a description of what's required for consideration, thus at least encouraging a standardized way of formulating a bug report/feature request. Even if these templates were fairly simple we would still benefit. But I think we could go further and take inspiration from software design documents as a template, which will require the issue reporters to not just do their research, but present it properly too. The DocNow project at MITH creates such documents (publicly) to help discussion within the dev group, and as a crucial means to remind ourselves of why we set to do something (because we all work on dozens of projects and forget things). Here is a very good example <https://www.docnow.io/design/2019-05-21-conversation>. I think forcing this on submitters will weed out partially thought out requests, which will always result in us at least wasting time at best closing or getting back to the submitter, at worst engage in loopy "what if" discussions. We have plenty of issues, so I'm not worried about scaring people away. In fact, i wonder if more structure may even encourage less proficient users to contribute more meaningfully. Templates will also give us -- hopefully -- clearer requests with a proposal for a solution built-in. What do you think? Finally, if we did choose to use this GitHub feature, we should also look at their recommendations for adding a code of conduct <https://help.github.com/en/github/building-a-strong-community/adding-a-code…>. TEI's is hidden deep in the tei-c site <https://tei-c.org/about/code-of-conduct/> but we may want to bring it into the repository and close to the issue submitting process. Thanks for indulging me and I'm well prepared to be told that this in an unnecessary complication and that we should proceed as usual :) Best, Raff

6 6

labels for Stylesheets issues
by Syd Bauman 25 May '20

25 May '20

Martin and I came up with a proposed list of labels for Stylesheets issues today. My suggested schedule is that over the next week we review and tweak the list as needed. Then on or about Sun 17 May someone who has some color sense will go ahead and actually change the label values in GitHub. Then during the week of the 18th, flowing over to the week of the 25th as needed, the subgroups (SB, PS, MH, EB|MS) work on categorizing the 139 open issues with the new labels. The list proposed is not intended to be definitive. I expect it to be adjusted both now by Council, and then during the actual cataloging exercise. So take a loot at https://docs.google.com/spreadsheets/d/1TugARD1amG-ZeMPl2Fo-e88VXqirHawmOs5… and comment away.

6 15

meeting in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 May '20

19 May '20

Dear all, Our meeting starts in 30 minutes. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina -----Ursprüngliche Nachricht----- Von: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Gesendet: Samstag, 16. Mai 2020 21:16 An: tei-council <tei-council(a)lists.tei-c.org> Betreff: Meeting on Tuesday Dear all, In our last meeting we agreed to continue one more time with reviewing issues from the VF2F on Tuesday, May 19 at 9:00 EDT, 14:00 BST, 15:00 CEST. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina Von meinem Huawei-Mobiltelefon gesendet

1 0

Meeting on Tuesday
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 May '20

16 May '20

Dear all, In our last meeting we agreed to continue one more time with reviewing issues from the VF2F on Tuesday, May 19 at 9:00 EDT, 14:00 BST, 15:00 CEST. Please find the zoom meeting link in the google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Best, Martina Von meinem Huawei-Mobiltelefon gesendet

1 0

Council meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 May '20

11 May '20

Dear all, For the Council meeting tomorrow (9:00 EDT, 14:00 BST, 15:00 CEST) we continue with our tickets review in the VF2F google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…<https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…> The link to the zoom meeting is the same - see beginning of the document. Best, Martina

1 0

reuse TEITechnicalCouncil user at GitHub as DockerHub build bot
by Peter Stadler 07 May '20

07 May '20

Dear all, you might have received a notification from GitHub that I added the docker-pkp-ojs repo to the TEIC realm at GitHub. Next, I wanted to integrate with DockerHub for automated builds but DockerHub changed something (already some time ago) in that step that makes it necessary to re-connect a GitHub account with DockerHub. They recommend to use a dedicated service user for that rather than using an individuals account because otherwise the whole TEI group/organization at DockerHub would get access to that individuals repositories. Makes sense … So, I’m now looking for a service account I could use and found the existing user TEITechnicalCouncil – which is not really needed, methinks? The only caveat I see is that this user is currently in the group „owners“ and has admin access to all repositories. We should downgrade that user but that might have side effects? If I was to create a new account at GitHub I’d need an email-address that is not already registered with GitHub. So, it'd probably result in two new accounts which seems a bit messy to me. Any objections to downgrading the TEITechnicalCouncil user and turning that into a bot? If I do not receive any objections I will proceed in that direction. Best Peter

4 4

Meeting tomorrow
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 May '20

04 May '20

Dear all, For our Council meeting tomorrow (9:00 EDT, 14:00 BST, 15:00 CEST) I propose that we continue with our tickets review in the VF2F google doc: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… The link to the zoom meeting has not changed (see beginning of the document). Best, Martina

1 0

Virtual F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 30 Apr '20

30 Apr '20

Dear all, Our Council meeting is just around the corner. Please find the schedule and agenda for our virtual F2F meeting here: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…<https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU…> The Zoom-Link for the meeting is in the document. Meeting Times: Friday, May 1 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST Saturday, May 2 European break-outs 9:00-12:00 GMT 10:00-13:00 CEST all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST American break-outs 15:00-18:00 EDT Sunday, May 3 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST Looking forward to seeing you tomorrow! Best, Martina

1 0

Virtual F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 24 Apr '20

24 Apr '20

Hi all, this is the preliminary schedule for our virtual F2F meeting next week: https://docs.google.com/document/d/1tIA1pWABSJlL9KfCwK6t6zwVXm762LNAbvs45YU… Please feel free to comment on that. You can find the Zoom-Link in the Google Doc Meeting Times: Friday, May 1 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST Saturday, May 2 European break-outs 9:00-12:00 GMT 10:00-13:00 CEST all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST American break-outs 15:00-18:00 EDT Sunday, May 3 all 09:00-13:00 EDT 14:00-18:00 GMT 15:00-19:00 CEST I'll have a look at the Guidelines and Stylesheeet issues and will add a table with issues that 'need discussion' soon. Best, Martina

1 0