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

how many namespaces?
by Bauman, Syd 12 Apr '22

12 Apr '22

I added a new routine to TEI/P5/Utilities/ called namespaces.xslt that generates a table that gives you counts of namespace nodes. See https://bauman.zapto.org/~syd/temp/4TEICouncil/namespaces_in_P5.xhtml.

1 2

Call in 25 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Apr '22

08 Apr '22

Here is the agenda: https://docs.google.com/document/d/1raASYeayA9dzeEWcvi1Zk17UGQAoqgnc-W8nbw4… Best, Martina

1 0

Next meeting: April 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 06 Apr '22

06 Apr '22

Dear all, Our next meeting is on Friday, April 8 at 7am PDT / 10am EDT / 4pm CEST. Please add open issue/PR's to the agenda that we need to discuss for the release: https://docs.google.com/document/d/1raASYeayA9dzeEWcvi1Zk17UGQAoqgnc-W8nbw4… I'll add to the agenda tomorrow. Best, Martina

1 0

faster testing
by Bauman, Syd 06 Apr '22

06 Apr '22

One of the reasons the test procedure in Stylesheets/Test2/ is dramatically faster than the one in Stylesheets/Test/ is that it is, by default, run in parallel.[1,2] You can also ask the make command to run multiple jobs at once. The switches that control this are --jobs= and --output-sync=. I just tried an experiment, comparing how long it took to run make vs make --jobs=7 --output-sync=lines. (I chose 7 because my system has 8 threads, and I wanted to have some CPU available. What little I have found on the web seems to suggest I may as well go ahead and use 8.) The result was faster, although not even close to 7 times faster: down to 03:32 from 04:36. I compared the output of the 2 commands, and they were identical. On GNU/Linux, at least, the nproc command will tell you how many threads are available. Thus using the command $ make --jobs=`nproc 2>/dev/null || echo 1` -Oline seems to make sense to me. (-O is shorthand for --output-sync=.) It is also possible to get the Makefile to do that on its own. My first thought is that might not be such a good idea, because you may want to run with --jobs=1 in order to force error messages into the right order. (I.e., in case -Oline wasn’t good enough.) I ran the experiment again, this time using --jobs=8 and getting screen captures of the process monitor roughly 40 s after the make command started.[3] The timing results were very similar (down to 03:36 from 04:36), but the order of output lines was different. (Same output; i.e., they were identical after sorting and removing timestamps.) So I think anyone running the Stylesheets test process would do well to use the --jobs switch. You could use any of * -j 8 # if you know you have 8 threads, e.g. * --jobs=`nproc` # if you know the nproc command works on your system * -j `nproc 2> /dev/null || echo 1` # if there is a chance nproc fails, so it defaults to '1' Martina — could you either update the notes we have about updating P5 subset, or remind me where they are and I will? Thanks. Notes [1] ant test runs them in parallel; if you want them in series (likely because the order of messages was confusing when run in parallel) use ant testSeries. [2] There are other reasons, like it is written to be less redundant, and the JVM is only spun up once, rather than once for every test. [3] For evidence as to why --jobs makes make faster, see https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_process_m… and https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_-j_proces…

2 1

TEI PR #2204
by Bauman, Syd 03 Apr '22

03 Apr '22

Re: “Confirm with SB that https://github.com/TEIC/TEI/pull/2204 is ready to merge.” — agenda from yesterday’s meeting I think I have addressed Magdalena’s (reasonable) question on the PR<https://github.com/TEIC/TEI/pull/2204#pullrequestreview-929550387>. Thus, unless she or someone else disagrees, yes, PR #2204 is, IMHO, ready to merge. And I have just merged dev branch into the issue branch (sydb_issue-2185_URI_spaces).

1 0

Oxygen plugin
by Martin Holmes 01 Apr '22

01 Apr '22

Hi all, I'd like to draw Council's attention to these two tickets: <https://github.com/TEIC/oxygen-tei/issues/54> <https://github.com/TEIC/TEI/issues/2251> where two things have happened: 1. As usual, we were caught unawares when Oxygen released an update which broke functionality in the TEI Oxygen plugin version that we maintain. Oxygen maintain their own fork of the plugin repo and up to now, they've been making any necessary changes silently before an Oxygen release; then we realize that something is broken and struggle to catch up. I now have a pull request that I've asked Radu Coravu from Oxygen to review before I merge it, updating the included libs for transformations to take account of log4j changes. For those new to the situation, it's a bit complicated: the Oxygen folks only care about ensuring that the version of the plugin that ships with Oxygen works with the Oxygen version it ships with. However, we have different requirements, because we attempt to maintain support for older versions of Oxygen, so that those who cannot upgrade for some reason are still able to get up-to-date versions of P5, the Stylesheets, and the transformations in their older Oxygen. This means that we can't simply adopt any of the changes that the Oxygen folks make directly into our own branch; that would remove functionality for earlier Oxygen versions. So we have to try to merge the changes carefully. When the pull request is checked and merged, then our bleeding-edge version of the plugin will build, and those of us using it (which I hope is a reasonable subset of the Council) are able to test and make sure nothing is badly broken. We don't have a formal testing procedure, though, especially for older versions of Oxygen, because few of us run older versions. If the bleeding edge version is deemed OK, then Council will need to release the corresponding stable version using the procedure that's normally followed when we do a P5/Stylesheets release. There is a degree of urgency here because currently, anyone who is subscribed to our plugin and has upgraded their Oxygen to the current version will not be able to use any of the transformations, as Laurent discovered. 2. Radu has kindly agreed to raise issues on our plugin repo when they make changes in future, so we can try to avoid this happening again. I think I'm the only one who watches this repo at the moment, which is not really ideal. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.

1 0

VF2F meeting this weekend
by Scholger, Martina (martina.scholger＠uni-graz.at) 31 Mar '22

31 Mar '22

Dear Council, This is the agenda for our virtual F2F meeting on Friday and Saturday (April 1 and 2): https://docs.google.com/document/d/1WhGAcLK0H_xNNPoEECBk9f0eEn-qhSiWfqnhaik… Please feel free to add more topics to the agenda. Meeting times: Friday, Apr 1: North American break-outs The North American group needs to decide whether to start at 12 PDT / 15 EDT or at 13 PDT / 16 EDT (see poll on slack). Saturday, Apr 2: European break-outs 10:00-13:00 CEST Full Council 06:00-10:00 PDT 09:00-13:00 EDT 15:00-19:00 CEST I'll add the table with links to the Guidelines/Stylesheets issues tomorrow. Best, Martina Dr. 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 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/

3 3

@docLang chaining issues
by Lou Burnard 31 Mar '22

31 Mar '22

And here are my opinions on these questions: >p5subset.xml has all the languages (as it does); customization1.odd specifies >@docLang="en" customization2.odd, which points to customization1.odd, specifies >@docLang="it" What language should the output schema use? Schemas compiled against customization1 will see help popups in English, and those compiled against customization2 will see them in Italian. That is, assuming neither ODD has done anything to remove the relevant components. The languages available from a compiled ODD should presumably be managed in the same way as anything else. So if I delete an English <gloss> in my customization, and then compile that to use as a basis for a further customization, the compiled version will no longer have an English gloss to use, so specifying @docLang='en' won't produce anything. In general specifying @docLang only expresses an output preference; it has nothing to do with determining what components are available from a compiled version of the ODD. 2. Imagine: >customization1.odd modifies an element, replacing the English gloss with >something different. customization2.off specifies @docLang="es" Where should the >gloss be taken from in the output of the chain? I think I already answered that. If "customisation2.off" is using a compiled version of customization1.odd then the spanish gloss will be taken from that, if it's there. >3. Should it be part of the system that you can specify a series of languages in >order of preference, from which text will be taken if something is not available >in the main docLang? Seems like an over-complication. There is a canonical language in which ODD glosses are written, which is currently labelled "en" (unless and until the TEI becomes a purely Chinese -- say -- project). So it is not unreasonable to say if @docLang requests a language that's not available (for whatever reason), a version using the canonical language is the fallback. If you really want to I suppose you could supply multiple values for @docLang to indicate acceptable languages, and then choose whichever comes first on the list, but this seems like over-egging the pudding to me.

1 0

next stylesheets meeting
by BERMUDEZ SABEL Helena 25 Mar '22

25 Mar '22

Hello! On Friday March 25th we have our next Stylesheets meeting. Since our time zones are out of sync this week, I think it might be worth to conduct a vote for the preferred time: the time provided in our Google Calendar might not be what many of us had in mind. - 15h00Z (08:00 Pacific, 11:00 Eastern, 16:00 CET) (time according to our Google Calendar) - 16h00Z (09:00 Pacific, 12:00 Eastern, 17:00 CET) Please find the poll in our #general channel at Slack. The suggested agenda of the meeting is available at: https://docs.google.com/document/d/1LHIhvuNTISCrlMZDZx7jkVbDt8teivQTbJrF0EV… Do not hesitate to add other topics! Best, H. Helena Bermúdez Sabel Chercheuse FNS senior Institut des sciences du langage Université de Neuchâtel

5 6

Stylesheets Task Force Charge
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Mar '22

23 Mar '22

Dear all, Thank you for voting on the Stylesheets Task Force document. The Council now officially charges the Task Force with the implementation. Many thanks to Syd, Martin, and Helena for taking on this task. I added a page in wordpress and linked it from here https://tei-c.org/activities/workgroups/. Speaking of workgroups: can we move TEI Tite and TEI Pointer/Stand-off Markup to "concluded"? Best, Martina Dr. 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 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/

2 2