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

checking out <standOff>
by Syd Bauman 02 Feb '20

02 Feb '20

Stuff that's been done: * changed model.resourceLike to model.resource, and removed <TEI> from it * added new model.describedResource, which contains only <TEI> and <teiCorpus> * changed content models of <TEI> and <teiHeader> as discussed * created new <standOff> and model.standOffPart (to SA) * tweaked various bits of prose, e.g. the <remarks> for <settingDesc>, to talk about new <standOff> * updated the beginning of DS * changed prose and an example or two in CC where it talks about major structures for corpora to allow for nested <TEI> * tweaked prose in FS where free-standing <fsdDecl> is mentioned * tweaked prose in MS where <person> is discussed * changed an example in CO to show <standOff> * added a paragraph to DR about using <standOff> for a <castList> * changed prose and an example or two in ND to accommodate <standOff> * tweaked prose in PH to mention that <listTranspose> could be in <standOff> * tweaked beginning of SA, and added an entire new subsection later on, to discuss <standOff> - NOTE: left a stub "Placement of Stand-off Markup and Contextual Information" section that I haven't figured out if it should be kept or deleted, pr new subsection should be moved into it, or what * tweaked TS to remove implication that <listPerson> must be in <particDesc> (although for typical transcriptions of speech it may well be) What I think should be done next is each member of Council should pick one changed chapter and do a quick comparison of it between branch sydb-standOff and dev, reading the changed portions to see if they're OK.[1] In addition, a few people should read the <standOff> tagdoc and play with the schemas. So here is a checklist: https://docs.google.com/document/d/17S_W5vHzJZ_vCQw-Ze6SbOebqfz5KHq0xR9wauB… Please sign up for at least 1 chapter. Note that each chapter or tagdoc name is a link to the sydb-standOff version thereof. It would be good if all the reviews could be done by early Fri morning 24 Jan my time (EST). Notes ----- [1] For me the easiest way to do this is to put the dev and sydb-standOff versions of the HTML in two tabs in one window and pop back and forth between them. But to each his or her own. (But do note that there have been whitespace changes to some of the source files, so GitHub's compare functionality may not be ideal.)

3 3

Nicholas in GitHub?
by Raffaele Viglianti 30 Jan '20

30 Jan '20

Hi Nicholas, Could you let us know your GitHub account so we can add you to the TEI Council group and start assigning you tickets? :) Thanks! Raff

2 3

Taking stock, going into refrigeration pre-release?
by Elisa Beshero-Bondar 29 Jan '20

29 Jan '20

Hi all-- Just checking in with everyone as we're heading into refrigeration. I know we have some tickets in a molten or even "on fire" state just now, and wondering if we need to revisit our refrigeration and release dates? Elisa -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> Development site: http://newtfire.org

1 0

git merging into fork
by Syd Bauman 28 Jan '20

28 Jan '20

So, I wanna do at least a little due diligence on Unihan. @duncdrum has forked TEI, and issued a PR of his "unihan-phase2" branch into the main TEI 'dev' branch. I'd like to create a (local) test copy of the TEI repo that has both the 31 new commits to TEI:dev since @duncdrum last merged, and the PR. I do *not* want this to signal accepting the PR into our branch. Seems to me there are two approaches, neither of which I know how to do off the top of my head: 1) from my local copy of duncdrum:TEI:unihan-phase2 somehow merge in TEIC:TEI:dev 2) from my local copy of TEIC:TEI:dev somehow merge in duncdrum:TEI:unihan-phase2 I don't care which I do, so long as there is no affect to the GitHub versions of this stuff. Any suggestions?

2 1

hangouts uniHan call
by Scholger, Martina (martina.scholger＠uni-graz.at) 27 Jan '20

27 Jan '20

Dear all, This is the hangouts link for our uniHan call today: https://hangouts.google.com/call/vp1RDBzAabItP-WtiZHfAEEI (10:00-11:15 PST, 13:00-14:15 EST, 19:00-20:15 CET) Best, Martina

2 2

unihan meeting on Monday
by Scholger, Martina (martina.scholger＠uni-graz.at) 27 Jan '20

27 Jan '20

Dear all, Our uniHan-meeting is on Monday, Jan 27 from 10:00-11:15 PST, 13:00-14:15 EST, 19:00-20:15 CET (Syd will join us 15 min later, Raff needs to run to another meeting at 2pm). Please have a look at the original uniHan issue https://github.com/TEIC/TEI/issues/1805 and the pull request from Duncan https://github.com/TEIC/TEI/pull/1901 FYI, here are the minutes from the calls last year: https://docs.google.com/document/d/1XfhG5VBwYsMulp1T-BF3sDES6dtr04_Q9MuJCO3… https://docs.google.com/document/d/1JsEaZU1H7EJMwXJmNgRLjOZoJOg6AHzMcDM41zb… Best, Martina

2 1

Stylesheets tutorial -- doodle
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Jan '20

23 Jan '20

Dear all, In our last Stylesheets meeting we agreed to organize a Stylesheets tutorial meeting in the week February 17 to 21 for our new members and all who are interested to get started with editing the Stylesheets (e.g. where to find the files; dependencies; tests etc.). Please fill in the doodle: https://doodle.com/poll/w85u435vbcm5rfhc Best, Martina

1 0

fixing expected results
by Syd Bauman 22 Jan '20

22 Jan '20

Martin and Peter (and Martina and Jessica) -- When I run a `make test` in my local Stylesheets/ to find the diff errors, which version of TEI Guidelines should I be working against? (I.e., which one does Mr. Jenkins use? I can't duplicate the error whether I use my copy of dev or Vault/P5/current/xml/tei/odd/p5subset.xml.)

3 3

Stylesheets - hangouts link
by Scholger, Martina (martina.scholger＠uni-graz.at) 21 Jan '20

21 Jan '20

Dear all, This is the hangouts link for the Stylesheets meeting: https://hangouts.google.com/group/kuXq75FVLyU6w7nS7 Best, Martina

2 1

Stylesheets meeting tomorrw, Tue 20 Jan 14:00Z
by Syd Bauman 20 Jan '20

20 Jan '20

Sorry I'm late on this. (I try to post these 24 to 72 hours in advance.) As Martina just mentioned, we have a Stylesheets Group meeting scheduled for tomorrow, Tue 2020-01-21 14:00Z. timing ------ It will be: * 06:00 PST (Victoria) * 09:00 EST (New York) * 14:00 GMT (London) * 15:00 CET (Berlin) place ----- Martina will initiate a Google Hangouts session. topics ------ 0) Meeting time for next month. 1) Ticket 404.[1] 2) Ticket 403.[2] 3) Ticket 393.[3] 4) Ticket 399.[4] notes ----- [1] https://github.com/TEIC/Stylesheets/issues/404 [2] https://github.com/TEIC/Stylesheets/issues/403 [3] https://github.com/TEIC/Stylesheets/issues/393 [4] https://github.com/TEIC/Stylesheets/issues/399

1 0

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

20 Jan '20

Dear all, Our next Stylesheets meeting is tomorrow: PST 6:00-7:30, EDT 9:00–10:30, GMT 14:00–15:30, CEST 15:00–16:30. I'll start the call (hangouts). Best, Martina Von meinem Huawei-Mobiltelefon gesendet

1 0

unihan call
by Scholger, Martina (martina.scholger＠uni-graz.at) 20 Jan '20

20 Jan '20

Dear all, In the last Council call on Thursday we agreed to organize a separate uniHan call. For those who want to participate: please fill in the doodle due Monday, Jan 20. https://doodle.com/poll/7izgnrr84fghp7xn Best, Martina

1 1

call in 15 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 Jan '20

16 Jan '20

Dear all, Please click this link to join the call: https://meet.google.com/gxh-epwq-isq (thanks Hugh!) https://docs.google.com/document/d/1x51scPEkfUTSwdDGXxsJDLcjbjgpfVWEEDaH-18… Best, Martina

1 0

SSH access to the TEI server for the release technicians
by Peter Stadler 15 Jan '20

15 Jan '20

Dear all, can the release technicians please send me their public SSH keys so I can put them in place for logging in to the TEI server? Background: the infrastructure group decided that we’ll have a tei user (again) that will perform the release on the TEI server. For security reasons we’ll nuke the authorized_keys for that tei user after each release so only the current release technicians will have the proper permissions and can be held responsible ;) Best Peter

1 0

Reminder: Council call -- Jan 16
by Scholger, Martina (martina.scholger＠uni-graz.at) 15 Jan '20

15 Jan '20

Dear all, Our next Council meeting is scheduled for Jan 16, EDT 9:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30. Please feel free to add topics to the agenda: https://docs.google.com/document/d/1x51scPEkfUTSwdDGXxsJDLcjbjgpfVWEEDaH-18…<https://docs.google.com/document/d/1x51scPEkfUTSwdDGXxsJDLcjbjgpfVWEEDaH-18…> Best, Martina

2 1

Spring F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 13 Jan '20

13 Jan '20

Dear all, I had a final look at the doodle for the spring F2F meeting and unfortunately there is no ideal option where everyone would be available. The best option with three consecutive days in a row is May 1-3 (Friday to Sunday). Sadly, Vanessa cannot make it at those dates and Nicolas is not available for the Sunday, according to the doodle. Can the two of you look into it again please and see if you may be able to attend or if you would be available remotely? Best, Martina

1 0

Next Council call -- Jan 16
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Jan '20

09 Jan '20

Dear all, Since most of us agreed on moving the Council meeting from Tuesday, Jan 14 to Thursday, Jan 16 I can now confirm the new date: Our meeting is scheduled for Jan 16, EDT 9:00-10:30, GMT 14:00-15:30, CEST 15:00-16:30. And this is the agenda: https://docs.google.com/document/d/1x51scPEkfUTSwdDGXxsJDLcjbjgpfVWEEDaH-18… Best, Martina

1 0

meetings and containers (was "Re: Stylesheets (and other) meeting time")
by Bauman, Syd 07 Jan '20

07 Jan '20

[Originally sent Mon, 23 Dec 2019 09:51:27 -0500, but bounced due to a networking problem here with my Northeastern machine. You may notice that this is not a true reply, just a new e-mail with a subject line that looks like it is a reply. Sigh. Note that I will likely have trouble sending e-mail for some time to come.] So, it sounds like we should move the January Stylesheets group meeting to Tue 21 Jan 20 at 14:00Z. That is: 06:00 PST 09:00 EST 14:00 GMT 15:00 CET (Do we have any other time zones represented on Council?) Unless I hear strenuous objections pretty soon, we will plan on that. I am likely to miss the Council meeting of Tue 14 Jan 20 14:00Z. (I will be traveling in London; depending on train schedules, my family, etc., I may be able to make it, but I am not counting on it.) Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order. * It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it. * The solution is probably administrative, not technical. * It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility. * My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container. * Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly.

7 10

Update on F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 06 Jan '20

06 Jan '20

Dear all, I wish you a happy and healthy new year! Looking at the doodle for our spring F2F meeting it seems to be almost impossible to get all of us together at one time for three days in a row. The two most promising time periods are May 18 to 22 and April 30 to May 4 I would ask everyone to check the doodle and their calendars again until Wednesday with these dates in mind and see if you could organize to make it even if you didn't pick that date before: https://doodle.com/poll/zaeh4k9kfu5wdhfp Best, Martina

1 1

Council list archive is broken
by Martin Holmes 03 Jan '20

03 Jan '20

Hi Luis, The Council list archive here: <http://lists.lists.tei-c.org/mailman/listinfo/tei-council> is currently broken, because the server has HSTS turned on, but there's no valid cert for the subdomain lists.lists.tei-c.org. lists.tei-c.org works fine, but the archive itself is on lists.lists. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

2 3

Docker containers and user permissions
by Martin Holmes 19 Dec '19

19 Dec '19

Hi all, I've just been experimenting a bit further with the docker containers, and come across something that I've found in the past, which can cause problems on *NIX systems. By default, when you run a docker container, you end up as the root user in the container. That means that when you run a build process, if you save the output to a directory that's actually on your host filesystem, those files and folders may be owned by root, and you'll then have to use sudo to remove them. What I've done in the past is to use a run command like this: docker run --user $(id -u) --name tei -v /home/mholmes/WorkData/tei:/tei -it -e TZ=America/Vancouver teic/teidev-docker which runs the docker container and logs you in with the same user id that you have on your host system (in my case 1001); that means that when files are saved from a build process, they belong to you. In some cases, you'll end up logged in with a prompt like this: I have no name!@e08387ca074c:/tei/ which means that there is no user in the container with the same uuid as your user on the host system, but that doesn't matter; files will be saved under the correct user id, so on your host system they'll belong to you, not to root. (They may have group root, but that doesn't matter if you own them.) This just makes it easier to examine and clean up any products from the build process that remain on your host filesystem. You can actually create a parallel user with the same name and uid as your own in the docker container if you like, but that will get blown away every time you remove the container, of course. Incidentally, on the issue of vulnerable docker containers, I'm not alone in being worried: <https://www.techrepublic.com/article/docker-containers-are-filled-with-vuln…> The assumption that nothing malignant can get into your docker container, and that nothing can escape from it into your host system, is I think flawed: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14271> and in particular, if actions in the container are running as root, I believe you are running a risk. I think it's important that docker containers are regularly updated by their maintainers, but I also do run apt update and apt dist-upgrade or the equivalent as root in the container if it's one I'm keeping around. That does of course risk breaking the container's ability to do the build processes if some software the build is dependent on is updated in an unexpected way, but we want to know that anyway so we can fix it. And updating your container is no different from updating one of the live Jenkins servers, which is something I do with my server religiously every day. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

1 0

workshop "Building the TEI Guidelines locally"
by Peter Stadler 18 Dec '19

18 Dec '19

Dear all, tomorrow we’ll be having our little workshop on how to build the TEI Guidelines (and Stylesheets) locally and although I’m quite late, may I ask you to prepare your computers by installing Docker (Community Edition) [1] and download (aka ‚pull‘) the teic/jenkins image? That is, once you have Docker installed (and the Docker daemon is running; you can tell when the little Docker whale stops loading in your system tray) you simply hit `docker pull teic/jenkins` on the command line. This will take some minutes (depending on your connection) since the image is about 800 MB! Oh, and of course you will need to have a clone of the TEI [2] and the Stylesheets repo [3] on your machine. Best Peter [1] https://docs.docker.com/v17.09/engine/installation/ [2] https://github.com/TEIC/TEI [3] https://github.com/TEIC/Stylesheets

2 2

Stylesheets (and other) meeting time
by Syd Bauman 17 Dec '19

17 Dec '19

We agreed Stylesheets meetings should be 1st Tue of the month at 13:00Z. Two problems, the first with just Jan, the second more general. * I will be traveling on Tue 07 Jan; it is perhaps 50/50 I will be able to make the call, and if I do, I am likely to be a jet-lagged blithering idiot. (I am taking a red-eye from Boston to Leeds, UK overnight Mon 06 to Tue 07.) * The time is a bit of a problem for Martin. During daylight's saving time (Mar-Oct) it is 06:00, which is fine. But during standard time (Jan, Feb, Nov, Dec) 13:00Z is 05:00 PST. Thus we would not have Martin for the 1st hour of the Jan, Feb, Nov, or Dec meetings. Thoughts?

6 5

Council meeting times
by Scholger, Martina (martina.scholger＠uni-graz.at) 17 Dec '19

17 Dec '19

Dear Council, I've added our monthly Council meetings to the google calendar. We agreed that it should be the 2nd Tuesday of the month at: 9:00-10:30 (EST/EDT) / 14:00-15:30 (GMT/BST) / 15:00-16:30 (CET/CEST). Only the meeting on March 10 is affected by the switch to summer time, therefore the meeting will be at 9:00-10:30 (EDT) / 13:00-14:30 (GMT) / 14:00-15:30 (CET). Our next regular Council call is on Tuesday, January 14. Best, Martina

1 0

Is oxygen plugin message from tei-c.org incorrect?
by Elisa Beshero-Bondar 14 Dec '19

14 Dec '19

Dear TEI Councillors, Today I was showing Jessica Lu how to access the oXygen plugin from its supposedly canonical location tied to the latest release: https://www.tei-c.org/release/oxygen/updateSite.oxygen Or at least I *think* this is the correct site. Am I right about the URL? I'm writing up our documentation now for how the TEI community should install the oxygen plugin, having just walked Jessica through the process. The reason I'm suddenly uncertain about it is the message that pops up upon adding it, which warns the user, "Use this only if you are testing the plugin." Here's the message in full: DEVELOPMENT BUILD of the Oxygen TEI plugin based on the current trunk versions of TEI P5 and the TEI Stylesheets.Jenkins build number: 2019-07-18-143911. Use this only if you are testing the plugin. To avoid conflict with builtin framework, please ensure that you have gone to Preferences->Document Type Association in oXygen and deactivated all the TEI frameworks that have "External" in the storage columns. Is that the message that should be appearing with this plugin? It seems like the same message we see on the bleeding-edge plugin, and indeed it is: On installing the bleeding-edge plugin (from http://jenkins.tei-c.org/job/oxygen-tei-stable/lastSuccessfulBuild/artifact… ) the message is the same: "Use this only if you are testing the plugin. " I don't think we intend for those messages to be so much the same, do we? But I want to check with you all and make sure I have the right URLs for the plugins first. Should I open a ticket about this on the TEI oxygen plugin repo? On the verge of opening said ticket, Elisa -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu <ebb8(a)pitt.edu> Development site: http://newtfire.org

2 3