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

Fwd: TEI Question
by Elisa Beshero-Bondar 24 Feb '20

24 Feb '20

Dear Council colleagues, Can any of you shed light on this interesting question? Are we indeed using the words "licence" and "license" inconsistently in the Guidelines vs. the website? Best, Elisa ---------- Forwarded message --------- From: Sarah Ketchley <ketchley(a)uw.edu> Date: Sun, Feb 23, 2020 at 9:09 PM Subject: TEI Question To: Elisa Beshero-Bondar <ebb8(a)pitt.edu> Hi Elisa, I hope you are well! I have a question about spelling on the TEI website and in its guidelines. One of my eagle-eyed students in the Intro to DH class I’m currently teaching questioned the spelling of the TEI element < licence <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-licence.html>>. My immediate response was that it was based on British English, but then I started digging around the website, and came to the ‘Licensing page’ : https://tei-c.org/guidelines/licensing-and-citation/ where the noun is spelled ‘license’. Any insights on this?! Sorry to throw a left-fielder at you! best Sarah [image: Newbook Digital Texts] Dr. Sarah Ketchley / Egyptology | Digital Humanities ketchley(a)uw.edu University of Washington Department of Near Eastern Languages & Civilization M220D Denny Hall www.emmabandrews.org www.sarahketchley.com www.newbookdigitaltexts.org [image: Twitter] <https://htmlsig.com/t/000001CSRE2Z> [image: Facebook] <https://htmlsig.com/t/000001CP3HD8> [image: LinkedIn] <https://htmlsig.com/t/000001CP21K7> [image: Github] <https://htmlsig.com/t/000001CMN2AT> -- 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

3 2

Debian 9 -> Debian 10
by Luis Meneses 21 Feb '20

21 Feb '20

Hi All, I received an email from Joel at Huma-num about migrating two of our servers (web server and svn server) to Debian 10. I am including the translated message below. In this case, the migration path is an easy one since Huma-num is offering to do it for us. I will ask Joel for a timeframe when this will happen, but the transition should be transparent for us. Best, ----- -Luis Translation (courtesy of https://translate.google.ca) You are in charge of the administration of one or more virtual machines under Linux Debian 9, which run on our infrastructure. Debian 9 support for the Debian project has expired. All that remains is community support in "best effort" mode. We therefore invite you to plan the migration to Debian 10, which is as always easy, and must be almost transparent in a large part of the cases. We can of course help you to accompany you in this migration: - we do it - you validate in the process that everything works, and correct any concerns if necessary. NB: an easy and quick backtrack is always possible if in the last hours you have not changed the data contained in your virtual machine. This via the snapshot mechanism of our NetApp file server. ----- -Luis

2 2

on the content of <mapping>
by Syd Bauman 19 Feb '20

19 Feb '20

There are 21 examples of <mapping> in the _Guidelines_, and 5 different methods of representing the content thereof. (Although three of these methods are variants of the same idea.) The content model of <mapping> is macro.xtext, thus it can have only character data or <g>. Of the 21 of them, the desired mapping is represented in the content as: * straight character content in 15 (1 of those is multi-character, the rest are single characters); * numeric character references[1] in 3 (1 of those is multi-character, the others are single characters); * a <g> element in 1; and * the standard Unicode representation[2] in 2, i.e. they match "U\+[0-9A-F]{4,6}". The first three are variations of the same theme: the *content* of <mapping> *is* the character to which the character or glyph being defined should be mapped (whether expressed as character data, NCR(s), <g>(s), or some combination thereof). The last is entirely different. I think we can all agree that <mapping>U+00B5</mapping> means that the character or glyph currently being defined should be mapped to a single character µ = µ = µ = <g ref="#micro"/>, NOT a sequence of 6 characters U+00B5 = U+00B5. (Note that in the examples in _Guidelines_, the Unicode standard notational convention is used for all <mapping type="PUA">, and no other types of <mapping>.) But, as far as I know *nowhere* is this (the use of Unicode standard notation) mentioned in the _Guidelines_. Although I may be wrong about this, I do not think it would ever make sense to map a <char> onto a literal string "U+0123" (or "V=3456"). Furthermore, I think use of Unicode notation is a *really* good idea, *especially* if the character being represented is in the PUA; furthermore I suspect that the intention of whoever wrote this in the past was just that: Unicode standard convention should be used rather than actually putting PUA characters in a document instance. Thus I think the right solution is to: a) Have a _suggest values include_ list for mapping/@type (after all, we have it in the prose, sort of). b) Add some prose to 5.2 (#D25-20) that explains that in general "U+0123" notation may be used instead of "ģ" or "ģ", and that if the mapping is to the PUA area, this is the (vastly) preferred method. c) If anyone thinks it important to be able to map to absolutely arbitrary strings, then pick some value of @type (say "exact") for which use of "U+0123" would actually map to the string "U+0123". Notes ----- [1] Of course, they occur with "&" instead of an actual ampersand if you are reading the source. [2] Per the Unicode Standard Appendix A, "Notational Conventions".

2 3

guidance on last char of each <desc>
by Syd Bauman 17 Feb '20

17 Feb '20

labels: * TEI: Guidelines & Documentation * Priority: Low * CouncilResponsibility I had intended to submit a ticket on this topic, but after a bit of research realize I don't know what the ticket should say. So I'm asking for guidance from y'all -- what should we do about the following issue? IIRC, in general a <desc> should be 1 sentence that does not start with a capital letter, but does end in a full stop. By my count there are 10,475 <tei:desc> elements in the _Guidelines_. (That's not counting the 228 that are inside <egXML>; they are <teix:desc> elements that probably should be addressed, too.) Of those, 7689 end in a full stop,[1,2] and the other 2786 do not. That's a lot. Of course some of them should not end in full stop (e.g., those that end in ".)" or those that should not be a <desc> at all like the gloss of the value "group" of the @org attribute of <attList>). But most, I suspect, should. What to do? I submit that a) 2786 is way too many for manual intervention b) there are a bunch that end in screwy characters that probably need to be looked at (e.g., '>', superscript digits, '*') c) I am utterly unqualified to deal with non-English cases One thought is to divvy them up by language, so that (for example) I only have to deal with English, and ask for help for the other languages (perhaps ask Peter or Martina to deal with the German cases, Martin the Japanese, Raff the Italian, Alejandro the Spanish). Each language would be much more manageable on its own, I suspect. At least, the English certainly would be. There are only 9 categories: 1424 . 404 [a-z] 15 ) 2 [superscript digit] 2 [A-Z] 1 5 1 … 1 " 1 ; After some spot-checking, I would not be surprised if it made sense to automatically insert a period after all the [a-z] and ')' cases, leaving only 8 cases (in 6 categories) to be examined by hand. Thoughts? In case you want to see them (clicking on a column headings sorts): * All of them: https://bauman.zapto.org/~syd/temp/4TEICouncil/last_of_the_descs/lotd.xhtml * Only those that end in something other than full stop: https://bauman.zapto.org/~syd/temp/4TEICouncil/last_of_the_descs/lotdnfsonl… * Only those that are in English: https://bauman.zapto.org/~syd/temp/4TEICouncil/last_of_the_descs/lotend.xht… * Only those that are in English and do not end in full stop: https://bauman.zapto.org/~syd/temp/4TEICouncil/last_of_the_descs/lotendnfso… Notes ----- [1] I get bizarrely different results with different counting methods, not sure why. [2] 1002 are U+3002, IDEOGRAPHIC FULL STOP, mostly in zh-TW, but 57 in ja 1370 are U+FF0E, FULLWIDTH FULL STOP, most if not all in ja 5317 are U+002E, FULLSTOP, in lots of other languages

1 0

Travis check failures
by Martin Holmes 14 Feb '20

14 Feb '20

Hi all, I haven't really been involved in the setup of the Travis checks, so I don't really know what they're doing. Ron has made a pull request which I'd like to approve: <https://github.com/TEIC/Stylesheets/pull/420/> (I don't see anything wrong with it), but the Travis checks are failing. I can't see how to tell what checks have failed or why they've failed. When I ask Travis to re-run the checks, it shows "Re-running checks", but never seems to complete. Cheers, Martin -- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

2 2

model.resource
by Peter Stadler 14 Feb '20

14 Feb '20

Hy Syd (hold you responsible), I have to admit that this slipped my notice in the last days but now that I do, I believe renaming model.resourceLike to model.resource was a bad idea. There’s even no deprecation for this class so all the customizations will suddenly break (this is how I noticed) for people using this class for e.g. hooking in other stuff … Just wanted to be the first to complain ;) Best Peter

5 5

Stylesheet BIBL ptrs mess up test?
by Syd Bauman 13 Feb '20

13 Feb '20

I don't get this. I just tried a local `make test` in Stylesheets (setting the DEFAULTSOURCE to my local 'dev' copy of p5subst), and it failed because of an expected results error. But I personally copied over the expected results file in question yesterday or the day before. The diff failure is: result: ! defined in <ref target="http://www.tei-c.org/release/doc/tei-p5-doc/en/html/BIB.html#XSLT2">6.2. </ref>.</p> exptected result: ! defined in <ptr target="#XSLT2"/>.</p> and 1/2 dozen others exactly like that. I.e., w/ full URI instead of just bare name identifier. What gives? Has anyone changed anything that should have anything to do with this? Is it something on my local system? (That's a rhetorical question.) Could one of the CI maintainers kick off the Stylesheets-dev-against-TEIP5-dev job?

4 12

Freeze! Don't push to the dev branch of TEI or Stylesheets
by Elisa Beshero-Bondar 12 Feb '20

12 Feb '20

Dear Council: I'm at last creating the release branches for 3.7.0, so please don't push to dev for a moment until I send the "all clear"! Elisa -- Elisa Beshero-Bondar, PhD Associate Professor of English University of Pittsburgh at Greensburg Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu

4 6

test issue #1625
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Feb '20

11 Feb '20

Hi all, does anyone have time to test this issue? https://github.com/TEIC/TEI/issues/1625. It would be great if we could close this issue. Thanks! Best, Martina

2 1

Documentation
by Hugh Cayless 11 Feb '20

11 Feb '20

Hi All, I've been looking at implementing a slightly more robust documentation-publishing scheme for things like TCWs using Travis to automatically publish stuff pushed to the Documentation repo on GitHub Pages (and maybe in future to the website as well). We moved the TCW (Technical Council Working papers) docs over to https://github.com/TEIC/Documentation, but there is also https://github.com/TEIC/TEI/tree/dev/Documents, and in fact some of the content at http://teic.github.io/TCW/ and https://github.com/TEIC/teic.github.io/tree/master/TCW comes from the latter. So not everything in the TCW directory is a TCW, nor is everything listed in our GitHub Pages TCW site from the TCW directory. In short, it's a shambles :-). I would like to organize all this in a more sensible and intuitive way. So I have questions: 1) What documents should we surface? There's a lot of stuff in the TEI/Documents folder that's old (obsolete? Of historical interest?). 2) Should we try to merge all the documentation? We moved the TCWs out of TEI for reasons that may no longer pertain. Or we could move all the stuff in TEI/Documents out into the Documentation repo. What do we think? Hugh

1 1