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

Roma for class
by Syd Bauman 06 Mar '19

06 Mar '19

I am teaching a class on TEI schemas Fri 03-08 10:00/12:00-05:00. At the moment * https://tei-c.org/tools/roma/ does NOT work * https://roma.tei-c.org/ does NOT work -- bad certificate * https://roma2.tei-c.org/ does work Question 1: Are there other instances of Roma runinng that I might use? Does anyone happen to have one up? (I used to have one at Brown, but never set it up at Northeastern.) Question 2 (mostly for Raff): Bad or good idea to show them RomaJS?

1 0

RomaJS - update and meeting
by Raffaele Viglianti 05 Feb '19

05 Feb '19

Hello Council, Now that the new release is (mostly) behind us (thanks Elli, Hugh, at al!), I wanted to give you a quick update about RomaJS and attempt to schedule a call for the second week of February to discuss development and get started on planning user testing. DOODLE for meeting: https://doodle.com/poll/8p7exq3vptpb8g9t I've just updated the demo at http://mith.us/romajs. Feel free to try it out and let me know what's broken. I've been using waffle.io to keep track of GitHub issues and I found it very helpful to make sure what I do is reflected as much as possible into GitHub. The board is public and accessible here: https://waffle.io/TEIC/romajs If you have permissions on Github for TEIC, you will also be able to do stuff here if you log in. All of this is also available on GitHub issues, I just like the kanban style of waffle. To get a summary of what I've been working on since mid-December have a look at the "Done" column on the right. Here's a couple of highlights: - Create new classes and new elements in custom namespace - Implement revert to source button - Update material components web (you'll notice that the UI is pretty much the same but a little slicker) - Split updateOdd reducers (huge task with little practical effects, but that has greatly affected code readability) Please fill in the doodle and don't hesitate to ask questions here or on slack (there's a romajs channel). Thank you! Raff

1 1

additions/improvements to tcw22
by Mylonas, Elli 05 Feb '19

05 Feb '19

Hi all - I have notes that include improvements to tcw22 from the latest release experience. (The Raven...) Should I go ahead and edit? what is the protocol? --elli

2 3

Re: [Tei-council] dataSpec content
by James Cummings 03 Feb '19

03 Feb '19

If I understand Raff's suggestion correctly, then I would support the restrictive approach to only allow users possibilities of making dataTypes that 'Make Sense'. If they want to do something so weird as put an elementRef into the content of a dataSpec then they clearly should understand it well enough to be hand-editing their ODD, and then explain to us why it should be allowed in RomaJS. (But generally, RomaJS doesn't have to do everything that is possible, but only what we recommend people do.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 02 February 2019 12:04 To: lou.burnard(a)retired.ox.ac.uk; TEI Council Subject: Re: [Tei-council] dataSpec content [Trying to channel Raff, who is probably still asleep.] 1. Actual content model (that Raff was discussing -- i.e., a model against which all of our current dataSpec/content elements are valid): ( dataRef* | valList | textNode | aDr | avL | atN ) aDr = element alternate { dataRef* } avL = element alternate { valList } atN = element alternate { textNode } 2. No, Raff was not suggesting any change to content models, only to his user interface in RomaJS. But now that you point it out, it would probably make sense to disallow at least <empty>, <anyElement>, <elementRef>, & <classRef>, and probably even <macroRef> from the <content> of a <dataSpec>. > Firstly, I dont understand your pseudocode content model. Does it > mean the same as the following: > > <alternate minOccurs="1" maxOccurs="undefined"> > <elementRef key="dataRef"/> > <elementRef key="valList"/> > <elementRef key="textNode"/> > </alternate> > > > Are you proposing to change the current content model of <content> > or of <dataSpec> ? > > In either case, I suggest defining a class model.dataSpecPart might > help. > > Or is it just about how selective your interface should be in what > it permits, perhaps as a not-so-subtle way of avoiding the > question? > > Current practice in defining dataSpecs is constrained by what was > done in P4: I re-used the <content> element here because we also > used it to define the expansion of macroSpecs (i.e parameter > entities) back in the day, but that's a historical explanation. > This over-generates, as you rightly say: it's not at all clear what > it might mean to put e.g. an elementRef into the content of a > dataSpec! _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

3 2

Re: [Tei-council] Stylesheets: rub out tei: prefix?
by James Cummings 02 Feb '19

02 Feb '19

Syd: To clarify, yes #2, get rid of them, but I'm not going to worry about it too much if you don't. ;-) Apologies for my confusion. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 02 February 2019 12:21 To: Lou Burnard; TEI Council; Martin Holmes Subject: Re: [Tei-council] Stylesheets: rub out tei: prefix? Four of you have still not voted. summary so far ------- -- --- 1) I very much want to get rid of the "tei:" prefix in XPaths 2) I prefer to get rid of them, but don't care much 3) It makes no difference to me, mate 4) I prefer to keep them, but don't care much 5) I very much want to keep the "tei:" prefix in XPaths SB: 0 (My vote is weighted :-) EB: 1 LB: 4 ? HC: JC: 2 (Said "4", but seems to have meant "2") MH: 1 VJ: EM: 4 MS: 5 PS: 5 SS: MT: RV: 5 That's a total of 27 in 9 votes, for an average of exactly 3! Thus the remaining 4 votes will likely be the deciding ones ... what a nail-biter! _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] Stylesheets: rub out tei: prefix?
by James Cummings 02 Feb '19

02 Feb '19

Just to point out an option that Syd didn't suggest: - Use both prefix and xpath-default-namespace. This gives you the tei: prefix when you want to use it, but if you forget, defaults to the TEI namespace anyway. This is, of course, a _horrible_ idea for which I hope there is no support. Except if we were adopting a process of gradual conversion from prefixed to not. However, I would point out that xpath-default-namespace is used throughout the Stylesheets repository so that we are *already* inconsistent in our practice. So really we're already doing my horrible idea, though not commonly in a single stylesheet but more metaphorically throughout the repository as a whole. c.f. https://github.com/TEIC/Stylesheets/search?q=xpath-default-namespace&unscop… Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 04 January 2019 19:14:00 To: Elisa Beshero-Bondar; Lou Burnard Cc: TEI Council; Martin Holmes Subject: Re: [Tei-council] Stylesheets: rub out tei: prefix? Hi all, I usually use prefixes. So I would prefer option 5. Martina Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Elisa Beshero-Bondar Gesendet: Freitag, 4. Januar 2019 19:48 An: Lou Burnard <lou.burnard(a)retired.ox.ac.uk> Cc: TEI Council <tei-council(a)lists.tei-c.org>; Martin Holmes <mholmes(a)uvic.ca> Betreff: Re: [Tei-council] Stylesheets: rub out tei: prefix? And it's one more thing to forget! Life's challenging enough. When you have an opportunity to use a default namespace, why not use it? E :) On Fri, Jan 4, 2019 at 1:47 PM Lou Burnard <lou(a)ox.ac.uk<mailto:lou@ox.ac.uk>> wrote: (which is what I do, btw) they're only pesky if you forget them! On 04/01/2019 18:45, Mylonas, Elli wrote: you can always abbreviate to a single letter... On Fri, Jan 4, 2019 at 1:43 PM Elisa Beshero-Bondar <ebb8(a)pitt.edu<mailto:ebb8@pitt.edu>> wrote: I will take this opportunity to express surprise that so many of you like those pesky prefixes! Forgetting to use them drives me mad--think of occasions in writing XSLT where it's just so many extra keystrokes and one thing more to debug. Anyway, happy new year, you namespace-prefix-lovers! Elisa On Fri, Jan 4, 2019 at 1:41 PM Mylonas, Elli <elli_mylonas(a)brown.edu<mailto:elli_mylonas@brown.edu>> wrote: Hi all - I tend to prefer tp see namespaces expressed explicitly. But agree with James that Syd is the one groping around in the code. So 4 or 5 for me. --elli On Fri, Jan 4, 2019 at 11:44 AM James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>> wrote: Hi all, I simultaneously agree that explicitness is good and tend to use xpath-default-namespace all the time myself. I also remember learning from Sebastian that you *always* check namespaces first when something goes wrong. ;-) But since ODDs are always written in TEI (even non-TEI ODDs), it makes sense to me to use default namespace for TEI. I'd vote 4. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Lou Burnard <lou(a)OX.AC.UK<mailto:lou@OX.AC.UK>> Sent: 04 January 2019 15:07:27 To: Raffaele Viglianti; Elisa Beshero-Bondar Cc: Peter Stadler; Lou Burnard; TEI Council; Martin Holmes Subject: Re: [Tei-council] Stylesheets: rub out tei: prefix? FWIW, I agree with Raffaele and Peter in preferring the explicitness and clarity of a prefix. Sebastian always used to say that whenever a stylesheet didn't behave as expected, it was a namespace problem. But if Syd is producing a new version, clearly he has the right to make whatever cosmetic changes he is more comfortable with. Might be a good idea to keep the old version around for a while though, just to check nothing has been broken by such changes, if I may state the obvious. On 04/01/2019 11:44, Raffaele Viglianti wrote: I always use prefixes. I think it helps with clarity and feels more rigorous/consistent. So my preference would be 5. Raff On Fri, Jan 4, 2019, 5:09 AM Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com> wrote: By the way, I think there’s a way to do it in pure Schematron, but I am not sure (have to check) if it can be done in the ODD context. If I remember right for pure Schematron at least, the question is whether you have to set the prefix on the Schematron elements or the TEI ones. Elisa Sent from my iPhone > On Jan 4, 2019, at 5:05 AM, Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com>> wrote: > > Having worked with setting default namespaces rather a lot in various contexts (XSLT, XQuery, Schematron, I vote enthusiastically for 1). This really just amounts to a change that reduces verbosity, as Syd indicates, but also reflects the default centrality of the TEI in the Stylesheets anyway. And it is a pain to have to remember the default prefix all the time when we gave to edit. > > Elisa > > Sent from my iPhone > >> On Jan 4, 2019, at 3:54 AM, Peter Stadler <pstadler(a)mail.uni-paderborn.de<mailto:pstadler@mail.uni-paderborn.de>> wrote: >> >> I honestly prefer the verbosity of 5) — and I don’t think these XPath expressions can be significantly simplified nor compressed by removing those namespace prefixes. >> But just to make double sure: This is just a (proposed) cosmetic change due to your personal preference, right? This wouldn’t be bad thing, though, and I think you deserve to do it your way since you are the ODD one :) >> >> Cheers >> Peter >> >>> Am 04.01.2019 um 02:18 schrieb Syd Bauman <s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>>: >>> >>> The current odd2odd.xsl (like most of the stylesheets) uses the >>> explicitly bound namespace prefix "tei:" in XPaths. I am inclined to >>> use @xpath-default-namespace and get rid of them. I think our XPaths >>> are often already long enough to wrap around even a wide screen >>> twice, and things like "ancestor::tei:teiHeader" are just harder to >>> read. >>> >>> Please vote (fast): >>> 1) I very much want to get rid of the "tei:" prefix in XPaths >>> 2) I prefer to get rid of them, but don't care much >>> 3) Makes no difference to me, mate >>> 4) I prefer to keep them, but don't care much >>> 5) I very much want to keep the "tei: prefix in XPaths >>> >>> In case you're curious, there are approximately >>> 517 tei: >>> 38 rng: >>> 15 xs: >>> 5 a: >>> 4 xml: >>> 2 sch: >>> prefixes in odd2odd.xsl. (Looking only in attr values.) >>> _______________________________________________ >>> Tei-council mailing list >>> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/> _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/>

3 2

dataSpec content
by Raffaele Viglianti 02 Feb '19

02 Feb '19

Hello Council and Lou, As I'm working on supporting dataSpec in RomaJS, I've been thinking about what an interface for defining a datatype's content would look like. I did a quick survey of teidata.* source files and it looks like <content> is limited to this pseudocode content model (I hope it makes sense): (dataRef* | valList | textNode) | alternate { (dataRef* | valList | textNode) } I don't see any use of <sequence>, <empty>, <anyElement>, other *Ref elements besides dataRef, or multiple <valList>s and <textNode>s. This makes perfect sense to me. The question is: should I limit the interface to allow users to build only datatypes that "make sense", or allow more flexibility? The advantage of a more restrictive approach, which I support, is that the interface can be more to the point. If we wanted more flexibility, I'd implement the Blockly interface that is currently in use for <elementSpec>s. But I think it might discourage people from defining good datatypes as it's not immediately obvious how to use it. I wanted to run this by the group to make sure I analyzed this correctly. Does this make sense? Also a quick reminder to fill the Doodle for a call in the second week of February if you're interested in participating https://doodle.com/poll/8p7exq3vptpb8g9t Thank you! Raff

3 3

Re: [Tei-council] OxGarage and Roma updated
by James Cummings 01 Feb '19

01 Feb '19

That sounds reasonable (though the argument that John Unsworth originally made for paying our way by using commercially purchased systems, and not relying on handouts dependent on particular projects, institutions, and individuals, also sounds reasonable). I'd humbly suggest, if they are willing, that the maintainers of parts of our infrastructure like those hosting Jenkins, OxGarage, and developer of new bit of infrastructure RomaJS should all be part of that larger group. (But understand that they're busy.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 01 February 2019 06:39 To: James Cummings; TEI Council Cc: Martin Holmes Subject: AW: [Tei-council] OxGarage and Roma updated Hi, The reasoning behind moving the servers to HumaNum is that the current ADHO servers are rented from a commercial supplier whereas the HumaNum servers are actually maintained by a university based DH institution … I think. I would suggest that we decide on who of us should get involved with this process on behalf of the Council (checking requirements, etc.). Then I would write to the Board-Council list to suggest a dedicated call with Laurent, Luis and whoever will represent the Council and the Board. Meanwhile, I will ask Luis how far the process already is. Mahna Mahna, Martina Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von James Cummings Gesendet: Donnerstag, 31. Januar 2019 16:15 An: TEI Council <tei-council(a)lists.tei-c.org> Cc: Martin Holmes <mholmes(a)uvic.ca> Betreff: Re: [Tei-council] OxGarage and Roma updated Out of curiosity, what is the benefit of having the hosting with HumaNum[1] as opposed to ADHO? Doesn't this shift our eggs out of one basket and into another? Or is it cloud-based hosting with redundancy or something? Not arguing against it, just curious as to what it gets us. (It might be better, for example, to have a mirrored site or geographically dispersed copies for redundancy and load-balancing, but still seems like overkill to me.) Many thanks, James [1] Whenever I say this in my head I hear the muppets version of Mahna Mahna. https://en.wikipedia.org/wiki/Mah_N%C3%A0_Mah_N%C3%A0 -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Hugh Cayless <philomousos(a)gmail.com<mailto:philomousos@gmail.com>> Sent: 31 January 2019 12:21:26 To: Peter Stadler Cc: TEI Council; Martin Holmes Subject: Re: [Tei-council] OxGarage and Roma updated There’s an (exploratory I think at this stage) effort underway to move the website hosting to HumaNum. I’m not sure what the implications are for our other services. Probably we should schedule a meeting with the interested parties before things progress much further. That message should come from Martina as Chair I think. > On Jan 31, 2019, at 06:28, Peter Stadler <stadler(a)edirom.de<mailto:stadler@edirom.de>> wrote: > > My ultimate goal would be for the tei user to be member of the Unix group ‚docker‘ — that would allow us to restart those containers. We’ll have to sort that out with the new ADHO sysadmin who will hopefully be installed in the near future. > > Another option would be to move these services into some AWS or Azure (or whatheveyou) cloud. Kathryn was suggesting (in her recent mail to TEI-L) that "we have already begun to make significant changes to the TEI-C infrastructure in response to last summer’s server fail. Thanks to outgoing Board member Laurent Romary, our webmaster Luis Meneses is working with HumaNum to establish a more reliable foundation for our data.“ — I don’t know what that means?!? Has anyone some insights? > > Best > Peter > >> Am 31.01.2019 um 12:22 schrieb James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>>: >> >> >> That is good! Is there a way to have it so that the tei user on tei-c.org has the ability to restart these services? >> >> Many thanks, >> James >> >> -- >> Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> >> Senior Lecturer in Late-Medieval Literature and Digital Humanities >> School of English, Newcastle University >> From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Peter Stadler <stadler(a)edirom.de<mailto:stadler@edirom.de>> >> Sent: 31 January 2019 09:28:56 >> To: TEI Council >> Cc: Martin Holmes >> Subject: [Tei-council] OxGarage and Roma updated >> >> Dear all, >> >> I just had an excellent admin session with Christof Schöch (many thanks!) and we managed to restart the Roma and OxGarage services. Both should now run with the current Stylesheets and TEI sources. >> >> So, OxGarage, Roma, and the Debian packages should be updated to the current release (please test!), let alone the Oxygen plugin still needs some attention. >> >> Best >> Peter > > _______________________________________________ > Tei-council mailing list > Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> > http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

4 3

Re: [Tei-council] OxGarage and Roma updated
by James Cummings 01 Feb '19

01 Feb '19

Out of curiosity, what is the benefit of having the hosting with HumaNum[1] as opposed to ADHO? Doesn't this shift our eggs out of one basket and into another? Or is it cloud-based hosting with redundancy or something? Not arguing against it, just curious as to what it gets us. (It might be better, for example, to have a mirrored site or geographically dispersed copies for redundancy and load-balancing, but still seems like overkill to me.) Many thanks, James [1] Whenever I say this in my head I hear the muppets version of Mahna Mahna. https://en.wikipedia.org/wiki/Mah_N%C3%A0_Mah_N%C3%A0 -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Hugh Cayless <philomousos(a)gmail.com> Sent: 31 January 2019 12:21:26 To: Peter Stadler Cc: TEI Council; Martin Holmes Subject: Re: [Tei-council] OxGarage and Roma updated There’s an (exploratory I think at this stage) effort underway to move the website hosting to HumaNum. I’m not sure what the implications are for our other services. Probably we should schedule a meeting with the interested parties before things progress much further. That message should come from Martina as Chair I think. > On Jan 31, 2019, at 06:28, Peter Stadler <stadler(a)edirom.de> wrote: > > My ultimate goal would be for the tei user to be member of the Unix group ‚docker‘ — that would allow us to restart those containers. We’ll have to sort that out with the new ADHO sysadmin who will hopefully be installed in the near future. > > Another option would be to move these services into some AWS or Azure (or whatheveyou) cloud. Kathryn was suggesting (in her recent mail to TEI-L) that "we have already begun to make significant changes to the TEI-C infrastructure in response to last summer’s server fail. Thanks to outgoing Board member Laurent Romary, our webmaster Luis Meneses is working with HumaNum to establish a more reliable foundation for our data.“ — I don’t know what that means?!? Has anyone some insights? > > Best > Peter > >> Am 31.01.2019 um 12:22 schrieb James Cummings <James.Cummings(a)newcastle.ac.uk>: >> >> >> That is good! Is there a way to have it so that the tei user on tei-c.org has the ability to restart these services? >> >> Many thanks, >> James >> >> -- >> Dr James Cummings, James.Cummings(a)newcastle.ac.uk >> Senior Lecturer in Late-Medieval Literature and Digital Humanities >> School of English, Newcastle University >> From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Peter Stadler <stadler(a)edirom.de> >> Sent: 31 January 2019 09:28:56 >> To: TEI Council >> Cc: Martin Holmes >> Subject: [Tei-council] OxGarage and Roma updated >> >> Dear all, >> >> I just had an excellent admin session with Christof Schöch (many thanks!) and we managed to restart the Roma and OxGarage services. Both should now run with the current Stylesheets and TEI sources. >> >> So, OxGarage, Roma, and the Debian packages should be updated to the current release (please test!), let alone the Oxygen plugin still needs some attention. >> >> Best >> Peter > > _______________________________________________ > Tei-council mailing list > Tei-council(a)lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 1

Release post mortem
by Hugh Cayless 31 Jan '19

31 Jan '19

Hi All, 3.5.0 wasn't entirely smooth. Remaining tasks are reloading OxGarage and Roma Docker containers (request has been sent), doing the Oxygen plugin release, and doing the Debian release. The latter process fails due to an SSL error. I suspect it may have to do with the ancient version of Ant on the TEI server and maybe wonky SSL support in an older Java library. Upgrading Ant might fix everything. I think it worked before because Jenkins wasn't under HTTPS. Notes on updates needed to the release docs are at https://docs.google.com/document/d/1fTrCQrC8tRTZWLGScXKb0R_brwhOoRA6uta4c1h… . Comments welcome. We got bitten (again!) by the circular dependency between the Stylesheets and Guidelines. The Stylesheets build started failing after the Guidelines were released because it uses the p5subset from the latest release, meaning we're not *actually* testing the Stylesheets against the latest GLs build. Martin spotted a problem with the SimplePrint exemplar post release, which we decided to go back and fix. Moving the att.tableDecoration class into the figure module broke SimplePrint because it references nearly everything directly, bypassing the modules. So we inadvertently lost table attributes by putting them alongside tables (where they should have been in the first place). This is something we'll have to keep an eye out for in the future. but note https://github.com/TEIC/TEI/issues/1853. I think that was the gist of it. Overall, we've had better releases, but it wasn't too bad. Elli may have some followup if I missed anything. Thanks to everyone who helped today! Hugh

5 9

Re: [Tei-council] Travel to and Accommodation in DC
by James Cummings 31 Jan '19

31 Jan '19

(BTW, my research so far seems to show that airline prices skyrocket if I don't include a Saturday in the trip. i.e. they go up by several hundred pounds, more than the extra night's hotel. So I'm planning on arriving late Saturday night since that will work out cheaper if anyone is interested. I don't know if this price hike without Saturday is just a UK thing or Europe wide.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of James Cummings <James.Cummings(a)newcastle.ac.uk> Sent: 31 January 2019 15:22:18 To: Raffaele Viglianti; TEI Council Subject: Re: [Tei-council] Travel to and Accommodation in DC Hi all, I'm just starting to look at booking flights and getting a hotel or airbnb and not booked anything yet. Thanks Raff for all the helpful advice. If you've already booked flights/hotel then I put a table at the bottom of Raff's Google Doc where we can put all that information in. (Potential sharing transport, knowing ppl are in the same hotel as you, etc.) https://goo.gl/nDzGq9 Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Raffaele Viglianti <raffaeleviglianti(a)gmail.com> Sent: 17 January 2019 01:52:37 To: TEI Council Subject: [Tei-council] Travel to and Accommodation in DC Dear Council, As you start planning for your trip to DC in May, I thought I would send over some recommendations. Here is a map summarizing the information below: https://goo.gl/bqEA4k You have writing access to add hotels / AirBnBs you find if you so wish. Here is a google doc with the same text as below: https://goo.gl/nDzGq9 Both are in our TEI Council shared folder on Google Drive. Airports See if you are able to arrive to and leave from National Airport (DCA). You may find good flights via NYC or other East Coast cities, but no direct international flights except Canada. This airport is very close to downtown and very easy to reach by public transport or by a very affordable ride with a rideshare app. The main international airports are Dulles airport (IAD) and Baltimore-Washington (BWI). IAD has shared shuttle services (e.g. https://www.supershuttle.com/) as the metro to the airport is still under construction. BWI has shared shuttles and a train to Union Station. It also has a bus to the nearest DC metro station (Greenbelt), cash only https://www.bwiairport.com/to-from-bwi/transportation/transit/wmata. Accommodation DC hotels can be expensive. I would recommend to keep an eye out for deals. AirBnB is a more affordable alternative, where I see options under USD$100 per night. I recommend booking soon. Given that we'll spend most of our time at the Folger, I would recommend staying in these areas. Walking distance: Eastern Market, Capitol HIll, H Street Corridor, Union Station Easy metro or bus access (see below): Penn Quarter, Chinatown, Mt Vernon Sq/Convention center, NoMa, Southwest Waterfront, Navy Yard Travel within the city The DC area transport authority is called WMATA. The metro is frequent but will be packed downtown at peak times (if the government is open, lol). Buses are frequent, reliable and go everywhere. Find routes and a trip planner here: https://www.wmata.com/ . Google Maps is fairly reliable too as it uses their API. I strongly recommend purchasing a SmartTrip card at the dedicated machines in metro stations. They cost $10 with $8 credit. A bus ride will be around $2, while metro rides start at $2 and will cost more based on distance traveled. NB If your card credit goes negative after a metro ride, you will have to top up the card in order to exit the station. Food There will be plenty of lunch options around Folger at a 5-10 minute walk. For dinner, if we want to stick together, we'll likely hang around Eastern market (10min walk), H street (25min walk), or Chinatown (30min walk) depending on where people's hotels are, etc. I would love to have you all over at my place in the Columbia Heights neighborhood for dinner one evening. It's easily accessible via metro or bus. I'm not sure what would be the best evening for that, though. Suggestions welcome! Hope this helps and I look forward to having you in DC! Let me know if you have questions. Raff

3 2

Re: [Tei-council] Travel to and Accommodation in DC
by James Cummings 31 Jan '19

31 Jan '19

Hi all, I'm just starting to look at booking flights and getting a hotel or airbnb and not booked anything yet. Thanks Raff for all the helpful advice. If you've already booked flights/hotel then I put a table at the bottom of Raff's Google Doc where we can put all that information in. (Potential sharing transport, knowing ppl are in the same hotel as you, etc.) https://goo.gl/nDzGq9 Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Raffaele Viglianti <raffaeleviglianti(a)gmail.com> Sent: 17 January 2019 01:52:37 To: TEI Council Subject: [Tei-council] Travel to and Accommodation in DC Dear Council, As you start planning for your trip to DC in May, I thought I would send over some recommendations. Here is a map summarizing the information below: https://goo.gl/bqEA4k You have writing access to add hotels / AirBnBs you find if you so wish. Here is a google doc with the same text as below: https://goo.gl/nDzGq9 Both are in our TEI Council shared folder on Google Drive. Airports See if you are able to arrive to and leave from National Airport (DCA). You may find good flights via NYC or other East Coast cities, but no direct international flights except Canada. This airport is very close to downtown and very easy to reach by public transport or by a very affordable ride with a rideshare app. The main international airports are Dulles airport (IAD) and Baltimore-Washington (BWI). IAD has shared shuttle services (e.g. https://www.supershuttle.com/) as the metro to the airport is still under construction. BWI has shared shuttles and a train to Union Station. It also has a bus to the nearest DC metro station (Greenbelt), cash only https://www.bwiairport.com/to-from-bwi/transportation/transit/wmata. Accommodation DC hotels can be expensive. I would recommend to keep an eye out for deals. AirBnB is a more affordable alternative, where I see options under USD$100 per night. I recommend booking soon. Given that we'll spend most of our time at the Folger, I would recommend staying in these areas. Walking distance: Eastern Market, Capitol HIll, H Street Corridor, Union Station Easy metro or bus access (see below): Penn Quarter, Chinatown, Mt Vernon Sq/Convention center, NoMa, Southwest Waterfront, Navy Yard Travel within the city The DC area transport authority is called WMATA. The metro is frequent but will be packed downtown at peak times (if the government is open, lol). Buses are frequent, reliable and go everywhere. Find routes and a trip planner here: https://www.wmata.com/ . Google Maps is fairly reliable too as it uses their API. I strongly recommend purchasing a SmartTrip card at the dedicated machines in metro stations. They cost $10 with $8 credit. A bus ride will be around $2, while metro rides start at $2 and will cost more based on distance traveled. NB If your card credit goes negative after a metro ride, you will have to top up the card in order to exit the station. Food There will be plenty of lunch options around Folger at a 5-10 minute walk. For dinner, if we want to stick together, we'll likely hang around Eastern market (10min walk), H street (25min walk), or Chinatown (30min walk) depending on where people's hotels are, etc. I would love to have you all over at my place in the Columbia Heights neighborhood for dinner one evening. It's easily accessible via metro or bus. I'm not sure what would be the best evening for that, though. Suggestions welcome! Hope this helps and I look forward to having you in DC! Let me know if you have questions. Raff

1 0

Re: [Tei-council] OxGarage and Roma updated
by James Cummings 31 Jan '19

31 Jan '19

That is good! Is there a way to have it so that the tei user on tei-c.org has the ability to restart these services? Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Peter Stadler <stadler(a)edirom.de> Sent: 31 January 2019 09:28:56 To: TEI Council Cc: Martin Holmes Subject: [Tei-council] OxGarage and Roma updated Dear all, I just had an excellent admin session with Christof Schöch (many thanks!) and we managed to restart the Roma and OxGarage services. Both should now run with the current Stylesheets and TEI sources. So, OxGarage, Roma, and the Debian packages should be updated to the current release (please test!), let alone the Oxygen plugin still needs some attention. Best Peter

4 3

OxGarage and Roma updated
by Peter Stadler 31 Jan '19

31 Jan '19

Dear all, I just had an excellent admin session with Christof Schöch (many thanks!) and we managed to restart the Roma and OxGarage services. Both should now run with the current Stylesheets and TEI sources. So, OxGarage, Roma, and the Debian packages should be updated to the current release (please test!), let alone the Oxygen plugin still needs some attention. Best Peter

2 1

Updating Roma
by Hugh Cayless 30 Jan '19

30 Jan '19

Hi Ian, We're working on completing the latest TEI release. Can you update the Roma Docker container? Thanks, Hugh

3 3

Hands off the release branches
by Hugh Cayless 29 Jan '19

29 Jan '19

Hi All, we're in the process of releasing 3.5.0, so please do not push anything to either the Guidelines or Stylesheets release branches! Thanks, Hugh and Elli

2 2

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

29 Jan '19

Dear all, in case we need to take some notes during the release process, here is a document. It also contains the draft of the email for the TEI-L. https://docs.google.com/document/d/1fTrCQrC8tRTZWLGScXKb0R_brwhOoRA6uta4c1h… Martina

1 0

release branch
by Mylonas, Elli 29 Jan '19

29 Jan '19

Dear TEI Council: I am about to create the release branch for the release that Syd suggests several code names. I am unilaterally selecting the name "Raven" because Providence has a strong Edgar Allan Poe connection. Please do not commit any further changes, unless they are to the release notes or unless you communicate first with the release technicians or the chair. Release technicians are Hugh Cayless and myself. Thank you! --elli

6 14

Release Branch for release "The Raven" has been created
by Mylonas, Elli 25 Jan '19

25 Jan '19

Jenkins Maintainers please add built of the release branch "release-3.5.0" Thank you! --elli

1 0

Re: [Tei-council] first draft release notes
by James Cummings 25 Jan '19

25 Jan '19

Re: html:* passthrough. Sure, but I know SPQR used it for things locally in Oxford as well. But you could probably remove without side-effect. I doubt many other people are using them. (Though, how would we know?) re: highlighting github lines in a link. Cool isn't it. ;-) It is the way we should talk about code when discussing where some error is, by URI that references the lines (of a particular revision even better for historical completeness) Re: nuking ref I'm assuming you mean only the ones wrapped around gi? As there are some (pointing to things like classes etc) that we do need, obviously. Let me know if I can help, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 25 January 2019 19:45:16 To: TEI Council Subject: Re: [Tei-council] first draft release notes > That is the standard way that those profiles work, ... Yes, indeed. I was just listing 'em as that's the set of files I looked through. > The HTML is just a pass through for those doing readme files that > have some html embedded. Ummm ... OK. But of the 35 readme-*.xml files we have in P5/RelaseNotes/, not one has a single non-TEI element. > The makefile I was referring to was the P5 one at: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com… Wow. Thanks. (Not so much for the Makefile pointer, but for the cool demo of highlighting lines in GitHub source!) > You are right that grabbing version is a problem, but you've > omitted the _real_ problem which is that xslt is run over every xml > file in the directory. So you can't pass it the current version. > Instead, you would need to get it from the filename itself. Oh, good point! > Note, if doing this that it would have to be > tei:gi[not(ancestor::tei:ref)] or something, right? (Since there > are readme files that already have the refs around them. ;-) Sure, but my plan was to just nuke those <ref> elements. (After all, there are only 35 files ...) > Just thinking out loud, Thanks for doing so. I will get on that v. important version number bit in a few mins. Also need to add code for <att> and <ident>, which also occur inside <ref> in our collection of readmes. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] first draft release notes
by James Cummings 25 Jan '19

25 Jan '19

Hi Syd, That is the standard way that those profiles work, by importing html.xsl (which of course imports all the common and html xslt), isn't it? The HTML is just a pass through for those doing readme files that have some html embedded. The makefile I was referring to was the P5 one at: https://github.com/TEIC/TEI/blob/dev/P5/Makefile#L271-L273 But that was just how I was figured out which XSLT profile is being called for the release notes. You are right that grabbing version is a problem, but you've omitted the _real_ problem which is that xslt is run over every xml file in the directory. So you can't pass it the current version. Instead, you would need to get it from the filename itself. So we'd have to get it from the filename. We should be able to do something like: <xsl:variable name="filename" select="(tokenize($document-uri,'/'))[last()]"/> to get the filename and then remove the version number from that. Note, if doing this that it would have to be tei:gi[not(ancestor::tei:ref)] or something, right? (Since there are readme files that already have the refs around them. ;-) Just thinking out loud, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 25 January 2019 17:36:38 To: TEI Council Subject: Re: [Tei-council] first draft release notes Boy, I never looked at it before, but profiles/readme/html/to.xsl looks like a very weird animal. It has templates that match the HTML namespace and ones that match the TEI namespace. That file imports html/html.xsl, which itself imports: common/verbatim.xsl, html/html_param.xsl, and common/common.xsl, which itself imports: common/common_param.xsl, common/common_core.xsl, common/common_textstructure.xsl, common/common_header.xsl, common/common_linking.xsl, common/common_msdescription.xsl, common/common_figures.xsl, common/common_textcrit.xsl, common/common_gaiji.xsl, common/i18n.xsl, and common/functions.xsl I've just looked through all of those (quickly), and none seem to have a template that matches <gi> explicitly. So I think it's probably quite reasonable to just tuck it in here. How would the code in to.xsl get the version number (to point to the Vault)? A parameter? Read P5/VERSION (in which case it needs to be updated before this is run)? > Not sure it does work automatically, one would think that it would > follow the same thing that happens with the Guidelines but looking > back through some earlier ones I'm not sure it does. > > Looking at the makefile which calls the ant script, I think that > the release notes are generated using the 'readme' profile of the > stylesheets. So: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com… > > If we put a template in to handle tei:gi in that stylesheet that > would probably do it. (Anyone else see a problem with that?) > > And yes, I think release notes should always point to the Vault of > that version of the the Guidelines because if they point to the > live site then by next version they might be out of date. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 1

Re: [Tei-council] first draft release notes
by James Cummings 25 Jan '19

25 Jan '19

Hi Martina, Not sure it does work automatically, one would think that it would follow the same thing that happens with the Guidelines but looking back through some earlier ones I'm not sure it does. Looking at the makefile which calls the ant script, I think that the release notes are generated using the 'readme' profile of the stylesheets. So: https://github.com/TEIC/Stylesheets/blob/dev/profiles/readme/html/to.xsl If we put a template in to handle tei:gi in that stylesheet that would probably do it. (Anyone else see a problem with that?) And yes, I think release notes should always point to the Vault of that version of the the Guidelines because if they point to the live site then by next version they might be out of date. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 24 January 2019 21:38:27 To: James Cummings; TEI Council Subject: AW: first draft release notes Hi James, That would be convenient! But I can’t find an example where this works – do you have one? I have seen that in some older versions the links point to the Vault. Should we change that? Best wishes, Martina Von: James Cummings <James.Cummings(a)newcastle.ac.uk> Gesendet: Donnerstag, 24. Januar 2019 18:07 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at>; TEI Council <tei-council(a)lists.tei-c.org> Betreff: Re: first draft release notes I notice in the Release Notes that we seem to be putting both <ref> and <gi> around element names? This only seems to have started in the last few releases where before we just put <gi> and the magic of the build process turned this into a link in the release notes. Can someone confirm/deny whether we need to do this or not? If we do it seems like we should change the script rather than the encoding. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> Sent: 23 January 2019 23:41:16 To: TEI Council Subject: [Tei-council] first draft release notes Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

2 2

Re: [Tei-council] first draft release notes
by James Cummings 24 Jan '19

24 Jan '19

I notice in the Release Notes that we seem to be putting both <ref> and <gi> around element names? This only seems to have started in the last few releases where before we just put <gi> and the magic of the build process turned this into a link in the release notes. Can someone confirm/deny whether we need to do this or not? If we do it seems like we should change the script rather than the encoding. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 23 January 2019 23:41:16 To: TEI Council Subject: [Tei-council] first draft release notes Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

2 1

first draft release notes
by Scholger, Martina (martina.scholger＠uni-graz.at) 24 Jan '19

24 Jan '19

Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

4 8

Re: [Tei-council] first draft release notes
by James Cummings 24 Jan '19

24 Jan '19

I notice in the Release Notes that we seem to be putting both <ref> and <gi> around element names? This only seems to have started in the last few releases where before we just put <gi> and the magic of the build process turned this into a link in the release notes. Can someone confirm/deny whether we need to do this or not? If we do it seems like we should change the script rather than the encoding. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 23 January 2019 23:41:16 To: TEI Council Subject: [Tei-council] first draft release notes Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

1 0

Refridge
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Jan '19

23 Jan '19

Dear all, this is a reminder that we are in the middle of the "refridge phase". This means that it is fine to fix typos and do small changes in prose, but please don't change the schema any more. Freeze is on Thursday, Elli will do the release branch on Friday. Best wishes, Martina Mag. Dr.phil. Martina Scholger Zentrum für Informationsmodellierung - Austrian Centre for Digital Humanities Elisabethstraße 59/III 8010 Graz Austria martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at> https://informationsmodellierung.uni-graz.at<https://informationsmodellierung.uni-graz.at/> | https://gams.uni.graz.at<https://gams.uni.graz.at/> Institut für Dokumentologie und Editorik e.V. | https://i-d-e.de<https://i-d-e.de/> Chair of the TEI Technical Council | http://tei-c.org

1 0

Re: [Tei-council] cancel Stylesheets meeting?
by James Cummings 21 Jan '19

21 Jan '19

Hi, I can be there if people want. Otherwise, happy to open a chat and just work on tickets. ;-) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 18 January 2019 21:36:59 To: TEI Council; Lou Burnard; Martin Holmes Subject: [Tei-council] cancel Stylesheets meeting? For various reasons it looks like Martin, Elisa, and myself are the only ones who will make the Stylesheets meeting this coming Mon 21 Jan 19 at 14:00Z. (James? Maybe you will be there?) Thus perhaps we should cancel this one, especially since Mon is the last day to work on tickets (other than typos) before release. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

3 3

cancel Stylesheets meeting?
by Syd Bauman 18 Jan '19

18 Jan '19

For various reasons it looks like Martin, Elisa, and myself are the only ones who will make the Stylesheets meeting this coming Mon 21 Jan 19 at 14:00Z. (James? Maybe you will be there?) Thus perhaps we should cancel this one, especially since Mon is the last day to work on tickets (other than typos) before release.

1 0

Call in 20 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 18 Jan '19

18 Jan '19

Dear all, Our call starts in 20 minutes. https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh…<https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh…> Best wishes, Martina

1 0

tei:object updates
by James Cummings 17 Jan '19

17 Jan '19

Hi TEI Council, Minor changes: As you know I'm finishing off the tei:object element introduction and I've made a number of requested changes. I modified objIdentifier to objectIdentifier, added some more prose including a note in the prose of the Guidelines saying: "Please note: The object<https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rel…> element is a recent addition to the TEI Guidelines and as such may be more prone to further revision as its use develops. This may be particularly evident where its contents borrowed from msDesc<https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rel…> have yet to be generalized from their use in the context of manuscript descriptions." (I've made a note to myself to remove this at a later date.) Perhaps I should also put it as a remark on the object element specification page. Lots of minor changes: One of the legacy problems about basing object descriptions on (and as a more general form of) manuscript description is that numerous of the descendants of object specify in their descriptions that they are specifically to do with manuscripts. Often quite unnecessarily so. This is *already* out of date because with elements like typeDesc and typeNote we explicitly recommend the use of msDesc for objects which are not manuscripts (but early printed books, clay tablets, etc.). To solve this problem I've gone through all of the elements instantiated by the manuscript description chapter and rephrased any manuscript-specific terminology in the most minimal way possible. In almost all the cases this involved merely inserting 'or other object' after the word 'manuscript'. In some cases the description already said 'manuscript or manuscript part' and I changed this to 'manuscript, manuscript part, or other object'. Generally the changes were fairly simple, for example with the 'institution' element I changed it from: === <desc versionDate="2007-04-26" xml:lang="en">contains the name of an organization such as a university or library, with which a manuscript is identified, generally its holding institution.</desc> === to: === <desc versionDate="2019-01-17" xml:lang="en">contains the name of an organization such as a university or library, with which a manuscript or other object is identified, generally its holding institution.</desc> === A list of all of the changes as a single commit is at: https://github.com/TEIC/TEI/commit/41e7ce9ff35fd584eb3b314398a223987a04f5b0 if anyone wishes to check through them. In some cases (such as institution above) it might be better if instead of a phrase like 'manuscript or other object' or indeed 'manuscript, manuscript part, or other object' we just changed it to 'object'. i.e. above "contains the name of an organization such as a university or library, with which an object is identified, generally its holding institution". The reason I've not done this at the moment is to maintain the transparency of the legacy of these elements originating from the manuscript description module. (And indeed, one does not get these elements inside object unless that module is loaded -- which is fine to me.) Dimensions: On a related but slightly different issue, while going through the elements instantiated by the manuscript description module I reminded myself that dimensions, dim, height, width, and depth are all instantiated by this module even though I believe they are used by people not doing manuscript descriptions. I believe it might be worth revisiting their descriptions and consider moving them to the core module or similar at some point. One of the things that I noticed is that the descriptions of height, width, and depth are specific to text-bearing objects. So without change, for example, I could not provide the height, width, depth of an object that has not got any text on it. The descriptions are: === <depth> contains a measurement measured across the spine of a book or codex, or (for other text-bearing objects) perpendicular to the measurement given by the width element. <height> contains a measurement measured along the axis at right angles to the bottom of the written surface, i.e. parallel to the spine for a codex or book. <width> contains a measurement measured along the axis parallel to the bottom of the written surface, i.e. perpendicular to the spine of a book or codex. === I'm happy to put in an issue about this but potential generalising rewording might be: === <depth> contains a measurement from the front to the back of an object, perpendicular to the measurement given by the <width> element. <height> contains a measurement measured along the axis at a right angle to the bottom of the object. <width> contains a measurement of an object along the axis parallel to its bottom, e.g. perpendicular to the spine of a book or codex. === I'll stick this last bit in an issue. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University

1 0

Travel to and Accommodation in DC
by Raffaele Viglianti 17 Jan '19

17 Jan '19

Dear Council, As you start planning for your trip to DC in May, I thought I would send over some recommendations. Here is a map summarizing the information below: https://goo.gl/bqEA4k You have writing access to add hotels / AirBnBs you find if you so wish. Here is a google doc with the same text as below: https://goo.gl/nDzGq9 Both are in our TEI Council shared folder on Google Drive. *Airports*See if you are able to arrive to and leave from National Airport (DCA). You may find good flights via NYC or other East Coast cities, but no direct international flights except Canada. This airport is very close to downtown and very easy to reach by public transport or by a very affordable ride with a rideshare app. The main international airports are Dulles airport (IAD) and Baltimore-Washington (BWI). IAD has shared shuttle services (e.g. https://www.supershuttle.com/) as the metro to the airport is still under construction. BWI has shared shuttles and a train to Union Station. It also has a bus to the nearest DC metro station (Greenbelt), cash only https://www.bwiairport.com/to-from-bwi/transportation/transit/wmata. *Accommodation* DC hotels can be expensive. I would recommend to keep an eye out for deals. AirBnB is a more affordable alternative, where I see options under USD$100 per night. I recommend booking soon. Given that we'll spend most of our time at the Folger, I would recommend staying in these areas. *Walking distance*: Eastern Market, Capitol HIll, H Street Corridor, Union Station *Easy metro or bus access* (see below): Penn Quarter, Chinatown, Mt Vernon Sq/Convention center, NoMa, Southwest Waterfront, Navy Yard *Travel within the city* The DC area transport authority is called WMATA. The metro is frequent but will be packed downtown at peak times (if the government is open, lol). Buses are frequent, reliable and go everywhere. Find routes and a trip planner here: https://www.wmata.com/ . Google Maps is fairly reliable too as it uses their API. I strongly recommend purchasing a SmartTrip card at the dedicated machines in metro stations. They cost $10 with $8 credit. A bus ride will be around $2, while metro rides start at $2 and will cost more based on distance traveled. NB If your card credit goes negative after a metro ride, you will have to top up the card in order to exit the station. *Food* There will be plenty of lunch options around Folger at a 5-10 minute walk. For dinner, if we want to stick together, we'll likely hang around Eastern market (10min walk), H street (25min walk), or Chinatown (30min walk) depending on where people's hotels are, etc. I would love to have you all over at my place in the Columbia Heights neighborhood for dinner one evening. It's easily accessible via metro or bus. I'm not sure what would be the best evening for that, though. Suggestions welcome! Hope this helps and I look forward to having you in DC! Let me know if you have questions. Raff

1 0

Next call: January 18
by Scholger, Martina (martina.scholger＠uni-graz.at) 15 Jan '19

15 Jan '19

Dear all, this is the agenda for our next call on Friday, January 18 (16:00-17:30 EST, 21-22:30 GMT, 22:00-23:30 CET) https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh… Please add topics / issues to the agenda. @Hugh: can we use this meet link again: https://meet.google.com/rnm-hjax-dgg ? Best wishes, Martina

1 0

unihanProp element #1805
by Scholger, Martina (martina.scholger＠uni-graz.at) 14 Jan '19

14 Jan '19

Dear Council, Last week we (SB, RV, HC, MS) had a productive call with Martin Holmes and Duncan Paterson on issue #1805 (https://github.com/TEIC/TEI/issues/1805) the new <uniHan> element. These are the full minutes (https://docs.google.com/document/d/1JsEaZU1H7EJMwXJmNgRLjOZoJOg6AHzMcDM41zb…) and here is the summary of our proposal (please correct me if I forgot something): We have all agreed that the introduction of a new element is a good idea. But we then came to the conclusion to better call it <unihanProp>. In the course of this, we would suggest to introduce two more elements, <localProp> and <unicodeProp>. The three elements should be child elements of <char> and <glyph> and have @name and @value (instead of the property name in <localName>/<unicodeName> and <value>). Consequently, this would necessitate to deprecate <charProp>. * Phase 0: Create att.gaijiProperties with @name and @value, to be used by <unicodeProp>, <localProp>, and <unihanProp>. * Phase 1: add the new <unicodeProp>, <unihanProp>, and <localProp> elements with closed valList for unicodeProp/@name and unihanProp/@name, along with prose changes. * NOTE: The entry for "charProp" in the content models of <char> and <glyph> becomes instead " ( charProp* | ( unicodeProp | unihanProp | localProp )* )", and a) <charProp> is deprecated (for some years), and b) the three new elements are members of a new class that has a required @name (which used to be the content) and a maybe required @value (which used to be the sibling <value>). * Phase 2: Test the more aggressive validation of all @values based on @name and regexes from TR 38. If it's not too onerous to run and to maintain, integrate it. * Phase 3: Update prose and specs for <unicodeName> and <localName> to deprecate the old mechanisms and recommend the new attributes. * Phase 4: Write scripts to pull values from Unicode documents as part of the TEI build process to validate @name and @value. This is the current mechanism: <charProp> <localName>daikanwa</localName> <value>36</value> </charProp> And this would be the new one: <char> ... <localName property="daikanawa" value="36" /> ... </char> And here a <unihanProp> example: <char> ... <unihanProp property="kRSUnicode" value="r1"/> ... </charProp> Please let us know what you think of our proposal soon. As soon as we give Duncan the green light, he will work on the implementation. Just for clarification: this will not go into the January release. Best wishes, Martina

1 0

GitHub & CI server questions
by Syd Bauman 07 Jan '19

07 Jan '19

1) Is there a continuous integration server (Jenkins or otherwise) that has picked up the new sydb-radd Stylesheets branch and is building with it? 2) Anyone know what the little orange dot or red X after a commit is on GitHub? Here [1] is a small (thus low quality) screenshot of [2], which no longer has the orange dot, that shows what I'm asking about. I'm mildly suspicious that these might be related questions. [1] https://bauman.zapto.org/~syd/temp/4TEICouncil/screenshot_for_GitHub_questi… [2] https://github.com/TEIC/Stylesheets/commits/sydb-radd/odds/odd2odd.xsl

2 2

<specGrpRef> processing
by Syd Bauman 07 Jan '19

07 Jan '19

I don't get it. Can someone explain to me what the template for <specGrpRef> in odds/odd2odd.xsl is doing around line 489 (dev branch)? It looks like the structure is: <choose> <when test="LOCAL POINTER"> <apply-templates select="CHILDREN OF THAT WHICH IS POINTED TO"/> </when> <otherwise> <for-each select="THAT WHICH IS POINTED TO">  <choose> <when test="child::specGrp"> ???? <apply-templates select="child::specGrp/child::*"/> </when> <otherwise> <apply-templates select="child::*"/> </otherwise> </choose> </for-each> </otherwise> <choose> I find this bizarre, but I may be missing something here. A specGrpRef/@target is supposed to point to a <specGrp>. A <specGrp>, of course, can contain children <specGrp>s (not that any of ours do that). So it looks to me like ... ... given the following somewhere in file A.xml <specGrp xml:id="sciencyStuff"> <elementRef key="measureGrp"/> <elementRef key="measure"/> <specGrp xml:id="detailedScienceStuff"> <elementRef key="unit"/> <elementRef key="num"/> </specGrp> </specGrp> ... and the following in file B.xml <specGrpRef target="A.xml#sciencyStuff"/> then odd2odd.xsl will only process 'unit' and 'num', not 'measureGrp' and 'measure', for which I can see absolutely no reason. Am I going nuts, here? Was there a period in ODD history when a <specGrpRef> would point to the *parent* of the desired <specGrp>, not to the <specGrp> itself?

1 0

Re: [Tei-council] Stylesheets: rub out tei: prefix?
by James Cummings 04 Jan '19

04 Jan '19

Hi all, I simultaneously agree that explicitness is good and tend to use xpath-default-namespace all the time myself. I also remember learning from Sebastian that you *always* check namespaces first when something goes wrong. ;-) But since ODDs are always written in TEI (even non-TEI ODDs), it makes sense to me to use default namespace for TEI. I'd vote 4. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Lou Burnard <lou(a)OX.AC.UK> Sent: 04 January 2019 15:07:27 To: Raffaele Viglianti; Elisa Beshero-Bondar Cc: Peter Stadler; Lou Burnard; TEI Council; Martin Holmes Subject: Re: [Tei-council] Stylesheets: rub out tei: prefix? FWIW, I agree with Raffaele and Peter in preferring the explicitness and clarity of a prefix. Sebastian always used to say that whenever a stylesheet didn't behave as expected, it was a namespace problem. But if Syd is producing a new version, clearly he has the right to make whatever cosmetic changes he is more comfortable with. Might be a good idea to keep the old version around for a while though, just to check nothing has been broken by such changes, if I may state the obvious. On 04/01/2019 11:44, Raffaele Viglianti wrote: I always use prefixes. I think it helps with clarity and feels more rigorous/consistent. So my preference would be 5. Raff On Fri, Jan 4, 2019, 5:09 AM Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com> wrote: By the way, I think there’s a way to do it in pure Schematron, but I am not sure (have to check) if it can be done in the ODD context. If I remember right for pure Schematron at least, the question is whether you have to set the prefix on the Schematron elements or the TEI ones. Elisa Sent from my iPhone > On Jan 4, 2019, at 5:05 AM, Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com>> wrote: > > Having worked with setting default namespaces rather a lot in various contexts (XSLT, XQuery, Schematron, I vote enthusiastically for 1). This really just amounts to a change that reduces verbosity, as Syd indicates, but also reflects the default centrality of the TEI in the Stylesheets anyway. And it is a pain to have to remember the default prefix all the time when we gave to edit. > > Elisa > > Sent from my iPhone > >> On Jan 4, 2019, at 3:54 AM, Peter Stadler <pstadler(a)mail.uni-paderborn.de<mailto:pstadler@mail.uni-paderborn.de>> wrote: >> >> I honestly prefer the verbosity of 5) — and I don’t think these XPath expressions can be significantly simplified nor compressed by removing those namespace prefixes. >> But just to make double sure: This is just a (proposed) cosmetic change due to your personal preference, right? This wouldn’t be bad thing, though, and I think you deserve to do it your way since you are the ODD one :) >> >> Cheers >> Peter >> >>> Am 04.01.2019 um 02:18 schrieb Syd Bauman <s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>>: >>> >>> The current odd2odd.xsl (like most of the stylesheets) uses the >>> explicitly bound namespace prefix "tei:" in XPaths. I am inclined to >>> use @xpath-default-namespace and get rid of them. I think our XPaths >>> are often already long enough to wrap around even a wide screen >>> twice, and things like "ancestor::tei:teiHeader" are just harder to >>> read. >>> >>> Please vote (fast): >>> 1) I very much want to get rid of the "tei:" prefix in XPaths >>> 2) I prefer to get rid of them, but don't care much >>> 3) Makes no difference to me, mate >>> 4) I prefer to keep them, but don't care much >>> 5) I very much want to keep the "tei: prefix in XPaths >>> >>> In case you're curious, there are approximately >>> 517 tei: >>> 38 rng: >>> 15 xs: >>> 5 a: >>> 4 xml: >>> 2 sch: >>> prefixes in odd2odd.xsl. (Looking only in attr values.) >>> _______________________________________________ >>> Tei-council mailing list >>> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

5 6

Stylesheets: rub out tei: prefix?
by Syd Bauman 04 Jan '19

04 Jan '19

The current odd2odd.xsl (like most of the stylesheets) uses the explicitly bound namespace prefix "tei:" in XPaths. I am inclined to use @xpath-default-namespace and get rid of them. I think our XPaths are often already long enough to wrap around even a wide screen twice, and things like "ancestor::tei:teiHeader" are just harder to read. Please vote (fast): 1) I very much want to get rid of the "tei:" prefix in XPaths 2) I prefer to get rid of them, but don't care much 3) Makes no difference to me, mate 4) I prefer to keep them, but don't care much 5) I very much want to keep the "tei: prefix in XPaths In case you're curious, there are approximately 517 tei: 38 rng: 15 xs: 5 a: 4 xml: 2 sch: prefixes in odd2odd.xsl. (Looking only in attr values.)

6 6

Release timeline
by Scholger, Martina (martina.scholger＠uni-graz.at) 03 Jan '19

03 Jan '19

Dear Council, I hope you had some relaxing holidays and I wish you a happy new year! Thankfully, Elli and Hugh agreed to postpone the release date to January 29. This will give us a bit more time to finish some open issues. This is our suggested timeline: Refridge: Jan 17 (Thursday) - no major changes to the schema should be done after that; minor changes (wording, typos, examples, etc.) are fine. Freeze: Jan 23 (Wednesday) - no more changes can be done in the dev branch Create release branch: Jan 24 (Thursday) - after that, only minor changes (typos) can be done in the release branch Release: Jan 29 (Tuesday) I added the dates to the Google calendar. Our next Council call is between refridge and freeze, on January 18. Best wishes, Martina

1 0

starting rub-a-dub-dub
by Syd Bauman 03 Jan '19

03 Jan '19

Exactly 1 year to the day after abandoning the project, I am restarting it. Yay! New branch for this work will be called sydb-radd. First question: is there any difference between the 'master' and 'release-3.4.0' branches of TEI? Any significant difference? And, perhaps more importantly, how would I go about asking `git` that question? (Why, you ask? Because in order to test the Stylesheets they need to be building against some version of TEI P5. I'd like to use a local version so I don't have to wait the extra second or so it takes to download it every time I test the Stylesheets. Besides, it would be nice to know definitively which version I am testing against.)

1 0

Re: [Tei-council] rub-a-dub revisited
by James Cummings 30 Dec '18

30 Dec '18

With apologies to Syd, I've only got around to reading this now. It seems a good description to me. I'd add that before he stopped working on the Stylesheets Sebastian did recognise that although he'd moved it to be XSLT2 technically much of the way it worked was still with XSLT1 constructs. The one I discussed most with him was the interminable call-templates constructions that could be simplified significantly with functions. (And even where the same depths of constructs, it would be clearer.) Many thanks for all your hard work, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 24 December 2018 17:17:42 To: TEI Council Cc: Lou Burnard; Martin Holmes Subject: [Tei-council] rub-a-dub revisited Vanessa, and everyone -- I was tasked with writing up an explanation of the rub-a-dub revisited project, primarily for Vanessa, but for all, really. So here goes. background ---------- [Note -- this is intended to be a "get your head around this issue" sort of history, not a detailed highly accurate accounting. Lou and James probably know a lot more about the early history than I.] The TEI Consortium, through the TEI Council, maintains a set of stylesheets called (unimaginatively) "the stylesheets" or (not much better) "the TEI stylesheets". They were originally started (back in early 2000s?), I think, as two separate projects. The first was to have a workflow with which the TEI Guidelines, written in TEI/ODD, could be converted to HTML and print (PDF), and later ePUB, etc. The second was to provide a stylesheet for producing some semblance of readable output (HTML or PDF) from TEI Lite. It quickly became clear that these two projects had a *lot* in common, and so they were merged. And, in fact, the code base for TEI P4 and TEI P5 also had a lot in common, and they were merged, too. (We no longer support P4, though.) The main, almost sole, programmer behind this effort was the amazing Sebastian Rahtz. Sebastian was a brilliant, talented, and frighteningly fast XSLT programmer. An archaeologist by training, and an expert in the TeX and LaTeX typesetting systems, Sebastian never had any formal training in CS, at least none he would confess to me. Sebastian did not believe in internal documentation (e.g., comments) and did not care about indentation or consistency of namespace prefixes (the latter two, I suspect, because he was so brilliant he parsed XML on the fly in his head :-). He wrote these stylesheets over many years, adding features (often only a few hours after a request was made) in a somewhat willy-nilly fashion. Oh, and he started this project in XSLT1, converting to XSLT2 years later. situation --------- Due to brain cancer Sebastian stopped contributing to the stylesheets in late 2015 and died in early 2016. So now we (the Council) are left with a wonderfully powerful, modularized, parameterized, flexible set of stylesheets that are ridiculously difficult to maintain. Roughly 6 months after the gut-wrenching loss of our dear friend and colleague, the TEI Council established a group of interested parties to co-operatively educate ourselves as to how these stylesheets worked. All of TEI Council plus anyone who had ever contributed to the Stylesheets repo was invited. This group (chaired by me) has evolved from a self-education group to a Stylesheets-fixing group over time. The only people still on it are Martin Holmes, Lou Burnard, and various members of Council. One of the first things this group did was map out how the Stylesheets actually work. Some of that knowledge is represented in https://wiki.tei-c.org/index.php/Mapping_ODD_processing. desires ------- Martin and I have a (somewhat aspirational, but somewhat realistic) plan to re-write the ODD portion of the Stylesheets from scratch. That is, we would like to write a completely new code base (in XSLT 3.0) for processing the source of P5 into the P5 outputs (in PDF via XSLFO, as opposed to via LaTeX; HTML5; ePUB; etc.), and for processing customization ODDs into schemas and documentation. We do not want to rewrite the rest of the Stylesheets, i.e. those parts that transform generic TEI Lite into useful output, and do various other conversions. (These same stylesheets are the backbone of OxGarage.) However, that would take a long time, and in the meantime we still have a nearly unmaintainable mess. cleaning up -------- -- I have often been frustrated reading Sebastian's code. I am not nearly as brilliant as he was, so I like having helpful comments along the way, proper indentation, some consistent method of variable and function names, etc. I also find long-winded XSLT 1.0 constructs where a short bit of XSLT 2.0 can do the same thing quite frustrating. So every time I dive into the stylesheets, I think "this really has to be cleaned up". But usually I don't want to do any actual cleaning, in order to keep the delta between the code base before and after whatever fix I am applying as small as possible, to make it easier to double-check that it hasn't introduced new errors. There are some people a lot smarter than I who say that it is always better to clean up a code base than re-write it from scratch. One of them wrote a lovely blog post about it. See https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/ While I am sure there are computer scientists who disagree, it is a quite compelling article. rub-a-dub 1 --------- - So I convinced Martin that we should take a crack at cleaning the Stylesheets first (it wasn't hard). I then convinced Council of the same thing (not much harder). In late 2017 Council explicitly charged me with performing a clean up operation (called "rub a dub" or "rub a dub dub" based on what Joel called it in his blog) on a single, large, part of the Stylesheets: the odd2odd program. I spent my winter break exactly a year ago working my tail off for hours on end cleaning up code in ways that should not change the output. Pretty much every time I saved the file, I kicked off a test process to make sure the output came out the same. And it did! Every time. It wasn't until I was well over halfway through rubbing and dubbing that I discovered that, due to a misunderstanding between me & Martin (no blame on Martin, I just mistook what he said), the test procedure I was using was not actually testing odd2odd! I had been comparing the wrong output files, so of course they were the same every time. Sigh. In fact, while I blissfully thought I was doing such a great job, I had in fact mucked up the output almost beyond recognition. Sigh. rub-a-dub 2 --------- - So Martin and I redoubled our efforts on getting ODD testing in the Test2 system to work properly, and are almost finished with that. (Martin presented the Test2 system at our last Stylesheets group meeting.) Once that is done (my current goal is before I leave for a conference in Texas on Wed 09 Jan), I will attack rub-a-dub of odd2odd again, probably shortly after I get back from Texas. The over-arching goal will be to end up with a version of odd2odd that does the same thing, but is *much* easier to maintain. Some of the ancillary files (like common_functions) will likely need to be changed somewhat, too. By "the same thing" I mean "have essentially the same XML tree as output". I don't care about the incidentals of serialization, and may well sprinkle the output with comments if it seems to help. The point is I intend to try to explicitly avoid "improving" the processor as I go along. The detailed tasks I expect to work on to make it more maintainable are somewhat flexible, likely to change as I go along. But the following are the kinds of things I mean: * Reasonable indentation * Adding internal documentation * Re-factoring XSLT 1.0 constructs into XSLT 2.0 * Collapsing equivalent functions, modes, and templates where appropriate. (There are several cases where the Stylesheets have 2 or even 3 versions of what appear to be almost the same function, mode, or template.) * Changing names of functions, modes, templates, and variables in order to approach consistency * Re-factor logic to avoid double negatives where reasonable This, of course, will all be carried out in a separate branch, so as not to interfere with normal bug-fixing and the late Jan release. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

rub-a-dub revisited
by Syd Bauman 24 Dec '18

24 Dec '18

Vanessa, and everyone -- I was tasked with writing up an explanation of the rub-a-dub revisited project, primarily for Vanessa, but for all, really. So here goes. background ---------- [Note -- this is intended to be a "get your head around this issue" sort of history, not a detailed highly accurate accounting. Lou and James probably know a lot more about the early history than I.] The TEI Consortium, through the TEI Council, maintains a set of stylesheets called (unimaginatively) "the stylesheets" or (not much better) "the TEI stylesheets". They were originally started (back in early 2000s?), I think, as two separate projects. The first was to have a workflow with which the TEI Guidelines, written in TEI/ODD, could be converted to HTML and print (PDF), and later ePUB, etc. The second was to provide a stylesheet for producing some semblance of readable output (HTML or PDF) from TEI Lite. It quickly became clear that these two projects had a *lot* in common, and so they were merged. And, in fact, the code base for TEI P4 and TEI P5 also had a lot in common, and they were merged, too. (We no longer support P4, though.) The main, almost sole, programmer behind this effort was the amazing Sebastian Rahtz. Sebastian was a brilliant, talented, and frighteningly fast XSLT programmer. An archaeologist by training, and an expert in the TeX and LaTeX typesetting systems, Sebastian never had any formal training in CS, at least none he would confess to me. Sebastian did not believe in internal documentation (e.g., comments) and did not care about indentation or consistency of namespace prefixes (the latter two, I suspect, because he was so brilliant he parsed XML on the fly in his head :-). He wrote these stylesheets over many years, adding features (often only a few hours after a request was made) in a somewhat willy-nilly fashion. Oh, and he started this project in XSLT1, converting to XSLT2 years later. situation --------- Due to brain cancer Sebastian stopped contributing to the stylesheets in late 2015 and died in early 2016. So now we (the Council) are left with a wonderfully powerful, modularized, parameterized, flexible set of stylesheets that are ridiculously difficult to maintain. Roughly 6 months after the gut-wrenching loss of our dear friend and colleague, the TEI Council established a group of interested parties to co-operatively educate ourselves as to how these stylesheets worked. All of TEI Council plus anyone who had ever contributed to the Stylesheets repo was invited. This group (chaired by me) has evolved from a self-education group to a Stylesheets-fixing group over time. The only people still on it are Martin Holmes, Lou Burnard, and various members of Council. One of the first things this group did was map out how the Stylesheets actually work. Some of that knowledge is represented in https://wiki.tei-c.org/index.php/Mapping_ODD_processing. desires ------- Martin and I have a (somewhat aspirational, but somewhat realistic) plan to re-write the ODD portion of the Stylesheets from scratch. That is, we would like to write a completely new code base (in XSLT 3.0) for processing the source of P5 into the P5 outputs (in PDF via XSLFO, as opposed to via LaTeX; HTML5; ePUB; etc.), and for processing customization ODDs into schemas and documentation. We do not want to rewrite the rest of the Stylesheets, i.e. those parts that transform generic TEI Lite into useful output, and do various other conversions. (These same stylesheets are the backbone of OxGarage.) However, that would take a long time, and in the meantime we still have a nearly unmaintainable mess. cleaning up -------- -- I have often been frustrated reading Sebastian's code. I am not nearly as brilliant as he was, so I like having helpful comments along the way, proper indentation, some consistent method of variable and function names, etc. I also find long-winded XSLT 1.0 constructs where a short bit of XSLT 2.0 can do the same thing quite frustrating. So every time I dive into the stylesheets, I think "this really has to be cleaned up". But usually I don't want to do any actual cleaning, in order to keep the delta between the code base before and after whatever fix I am applying as small as possible, to make it easier to double-check that it hasn't introduced new errors. There are some people a lot smarter than I who say that it is always better to clean up a code base than re-write it from scratch. One of them wrote a lovely blog post about it. See https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/ While I am sure there are computer scientists who disagree, it is a quite compelling article. rub-a-dub 1 --------- - So I convinced Martin that we should take a crack at cleaning the Stylesheets first (it wasn't hard). I then convinced Council of the same thing (not much harder). In late 2017 Council explicitly charged me with performing a clean up operation (called "rub a dub" or "rub a dub dub" based on what Joel called it in his blog) on a single, large, part of the Stylesheets: the odd2odd program. I spent my winter break exactly a year ago working my tail off for hours on end cleaning up code in ways that should not change the output. Pretty much every time I saved the file, I kicked off a test process to make sure the output came out the same. And it did! Every time. It wasn't until I was well over halfway through rubbing and dubbing that I discovered that, due to a misunderstanding between me & Martin (no blame on Martin, I just mistook what he said), the test procedure I was using was not actually testing odd2odd! I had been comparing the wrong output files, so of course they were the same every time. Sigh. In fact, while I blissfully thought I was doing such a great job, I had in fact mucked up the output almost beyond recognition. Sigh. rub-a-dub 2 --------- - So Martin and I redoubled our efforts on getting ODD testing in the Test2 system to work properly, and are almost finished with that. (Martin presented the Test2 system at our last Stylesheets group meeting.) Once that is done (my current goal is before I leave for a conference in Texas on Wed 09 Jan), I will attack rub-a-dub of odd2odd again, probably shortly after I get back from Texas. The over-arching goal will be to end up with a version of odd2odd that does the same thing, but is *much* easier to maintain. Some of the ancillary files (like common_functions) will likely need to be changed somewhat, too. By "the same thing" I mean "have essentially the same XML tree as output". I don't care about the incidentals of serialization, and may well sprinkle the output with comments if it seems to help. The point is I intend to try to explicitly avoid "improving" the processor as I go along. The detailed tasks I expect to work on to make it more maintainable are somewhat flexible, likely to change as I go along. But the following are the kinds of things I mean: * Reasonable indentation * Adding internal documentation * Re-factoring XSLT 1.0 constructs into XSLT 2.0 * Collapsing equivalent functions, modes, and templates where appropriate. (There are several cases where the Stylesheets have 2 or even 3 versions of what appear to be almost the same function, mode, or template.) * Changing names of functions, modes, templates, and variables in order to approach consistency * Re-factor logic to avoid double negatives where reasonable This, of course, will all be carried out in a separate branch, so as not to interfere with normal bug-fixing and the late Jan release.

1 0

Stylesheets group meeting
by Syd Bauman 21 Dec '18

21 Dec '18

We have a Stylesheets group meeting scheduled for today, Fri 21 Dec 18 at 21:00Z. (That's 13:00 PST, 16:00 EST, 21:00 GMT, and 22:00 CET.) Our agenda includes: * MH & SB presenting the progress so far on Test2/ (Mostly MH both because he's done more of the work, and because SB's voice is shot.) See https://github.com/TEIC/Stylesheets/blob/dev/Test2/README_build_odd.md for some (brand new!) documentation. * Ticket 325: https://github.com/TEIC/Stylesheets/issues/325 Talk to you soon! (Or, at least, whisper at you.)-:

3 2

Re: [Tei-council] Japanese translations incoming
by James Cummings 19 Dec '18

19 Dec '18

a) I agree marking up these phrases might be useful. (This doesn't just include simple modal verbs but also constructions involving 'require*', 'recommend*', 'optional*', since we already indicate these are equivalent to must, should, may.) I note that this will take more work than you might think, the way many of these are phrased mean automatic replacement would be error-prone. I would suggest that this be an addendum to the current ticket to be done once I've finished going through and checking them. (Doing it in two phases also means I double-check, though also someone else could do that to double-check my work? Happy either way.) b) We note that we are basing our use of modal verbs on BCP14 not only in the Guidelines Style Guide http://teic.github.io/TCW/tcw24.html but also in the Guidelines themselves at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#AB-modal. To wit, I believe we already do what you are recommending. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Peter Stadler <stadler(a)edirom.de> Sent: 19 December 2018 08:21:42 To: Martin Holmes Cc: TEI Council Subject: Re: [Tei-council] Japanese translations incoming I wonder if we shouldn’t be marking up these verbs (and constructions?) ant to render these visually distinct? To me, that’d be a huge benefit for our meta language ODD in addressing technical documentation. Best Peter > Am 18.12.2018 um 17:33 schrieb Martin Holmes <mholmes(a)uvic.ca>: > > I do like the clarity of RFC 2119 and/or BCP 14, which seem to be pretty much identical. I wonder if we should state explicitly that our usage of modal verbs is intended to conform with one of them? > > Cheers, > Martin > > On 2018-12-18 7:29 a.m., James Cummings wrote: >> Hi Peter, Martin, etc. >> This ticket (https://github.com/TEIC/TEI/issues/1175#issuecomment-406592469) was something I was doing slowly when I got around to it. The actual work when you do it isn't difficult... Just double-checking that must/may/should etc. are all what we expect. Overall very few changes but mostly softening language (where we have said 'should' in past zealousness but even our own examples suggest 'may' is better). I'm happy to try to finish up the work sooner rather than later if desired. >> Many thanks, >> James >> -- >> Dr James Cummings, James.Cummings(a)newcastle.ac.uk >> Senior Lecturer in Late-Medieval Literature and Digital Humanities >> School of English, Newcastle University >> ------------------------------------------------------------------------ >> *From:* Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> >> *Sent:* 18 December 2018 15:17:29 >> *To:* Peter Stadler; Martin Holmes >> *Cc:* TEI Council >> *Subject:* Re: [Tei-council] Japanese translations incoming >> Hi, >> there is also a ticket https://github.com/TEIC/TEI/issues/1175 for that. James already started to work on that, but there are 4-5K hits to check. I think we should split the work, or James? I have put it on the agenda for our next call in January. >> Thanks Martin for merging the translations! >> Best wishes, >> Martina >> -----Ursprüngliche Nachricht----- >> Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Peter Stadler >> Gesendet: Dienstag, 18. Dezember 2018 07:39 >> An: Martin Holmes <mholmes(a)uvic.ca> >> Cc: TEI Council <tei-council(a)lists.tei-c.org> >> Betreff: Re: [Tei-council] Japanese translations incoming >> I couldn’t agree more! We currently mark technical terms (elements, classes) but not modal verbs which leads to confusion not only when translating. >> That’s quite an effort to go through the Guidelines and adjust (rephrase?) all those verbs but it would be a significant improvement. >> I’d like to put that on the agenda for our next f2f and see whether we can develop a plan for achieving this. What do you think? >> Best >> Peter >>> Am 17.12.2018 um 22:21 schrieb Martin Holmes <mholmes(a)uvic.ca>: >>> They're using the spreadsheets, and I'm transferring things back manually, one row at a time. There has been some discussion over the use of (for example) "may" in the Guidelines -- does it mean "be allowed to" or "can-if-you-wish" -- which makes me wonder whether it's time to look again at the modal verbs in TCW 24: >>> <http://teic.github.io/TCW/tcw24.html> >>> perhaps with an eye on RFC 2119: >>> <https://www.ietf.org/rfc/rfc2119.txt> >>> Cheers, >>> Martin >>>> On 2018-12-17 12:30 p.m., James Cummings wrote: >>>> That sounds excellent Martin! Thanks! >>>> Out of interest what process are they using to update the glosses, descs, etc. Those spreadsheets or something else? >>>> Many thanks, >>>> James >>>> -- >>>> Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University >>>> --------------------------------------------------------------------- >>>> --- >>>> *From:* Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Martin Holmes <mholmes(a)uvic.ca> >>>> *Sent:* 17 December 2018 17:07:14 >>>> *To:* TEI Council >>>> *Subject:* [Tei-council] Japanese translations incoming Hi all, Just a note to let everyone know that over the next little while I'll be slowly merging some new Japanese translations of glosses, descs and remarks into the dev branch. These are coming from some excellent work that Kiyonori and his team have been doing; they're about one-third of the way through the process of translating the spec files. >>>> I'm going to do this slowly and look at each item before I include it, mostly for my own learning purposes, but also in case I might catch the odd misunderstanding. >>>> Cheers, >>>> Martin >>>> _______________________________________________ >>>> Tei-council mailing list >>>> Tei-council(a)lists.tei-c.org >>>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >>> _______________________________________________ >>> Tei-council mailing list >>> Tei-council(a)lists.tei-c.org >>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council > _______________________________________________ > Tei-council mailing list > Tei-council(a)lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] Japanese translations incoming
by James Cummings 19 Dec '18

19 Dec '18

Hi Peter, Martin, etc. This ticket (https://github.com/TEIC/TEI/issues/1175#issuecomment-406592469) was something I was doing slowly when I got around to it. The actual work when you do it isn't difficult... Just double-checking that must/may/should etc. are all what we expect. Overall very few changes but mostly softening language (where we have said 'should' in past zealousness but even our own examples suggest 'may' is better). I'm happy to try to finish up the work sooner rather than later if desired. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 18 December 2018 15:17:29 To: Peter Stadler; Martin Holmes Cc: TEI Council Subject: Re: [Tei-council] Japanese translations incoming Hi, there is also a ticket https://github.com/TEIC/TEI/issues/1175 for that. James already started to work on that, but there are 4-5K hits to check. I think we should split the work, or James? I have put it on the agenda for our next call in January. Thanks Martin for merging the translations! Best wishes, Martina -----Ursprüngliche Nachricht----- Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Peter Stadler Gesendet: Dienstag, 18. Dezember 2018 07:39 An: Martin Holmes <mholmes(a)uvic.ca> Cc: TEI Council <tei-council(a)lists.tei-c.org> Betreff: Re: [Tei-council] Japanese translations incoming I couldn’t agree more! We currently mark technical terms (elements, classes) but not modal verbs which leads to confusion not only when translating. That’s quite an effort to go through the Guidelines and adjust (rephrase?) all those verbs but it would be a significant improvement. I’d like to put that on the agenda for our next f2f and see whether we can develop a plan for achieving this. What do you think? Best Peter > Am 17.12.2018 um 22:21 schrieb Martin Holmes <mholmes(a)uvic.ca>: > > They're using the spreadsheets, and I'm transferring things back manually, one row at a time. There has been some discussion over the use of (for example) "may" in the Guidelines -- does it mean "be allowed to" or "can-if-you-wish" -- which makes me wonder whether it's time to look again at the modal verbs in TCW 24: > > <http://teic.github.io/TCW/tcw24.html> > > perhaps with an eye on RFC 2119: > > <https://www.ietf.org/rfc/rfc2119.txt> > > Cheers, > Martin > >> On 2018-12-17 12:30 p.m., James Cummings wrote: >> That sounds excellent Martin! Thanks! >> Out of interest what process are they using to update the glosses, descs, etc. Those spreadsheets or something else? >> Many thanks, >> James >> -- >> Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in >> Late-Medieval Literature and Digital Humanities School of English, >> Newcastle University >> --------------------------------------------------------------------- >> --- >> *From:* Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf >> of Martin Holmes <mholmes(a)uvic.ca> >> *Sent:* 17 December 2018 17:07:14 >> *To:* TEI Council >> *Subject:* [Tei-council] Japanese translations incoming Hi all, Just >> a note to let everyone know that over the next little while I'll be >> slowly merging some new Japanese translations of glosses, descs and >> remarks into the dev branch. These are coming from some excellent >> work that Kiyonori and his team have been doing; they're about >> one-third of the way through the process of translating the spec files. >> I'm going to do this slowly and look at each item before I include >> it, mostly for my own learning purposes, but also in case I might >> catch the odd misunderstanding. >> Cheers, >> Martin >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council > _______________________________________________ > Tei-council mailing list > Tei-council(a)lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

3 2

Re: [Tei-council] Japanese translations incoming
by James Cummings 18 Dec '18

18 Dec '18

That sounds excellent Martin! Thanks! Out of interest what process are they using to update the glosses, descs, etc. Those spreadsheets or something else? Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Martin Holmes <mholmes(a)uvic.ca> Sent: 17 December 2018 17:07:14 To: TEI Council Subject: [Tei-council] Japanese translations incoming Hi all, Just a note to let everyone know that over the next little while I'll be slowly merging some new Japanese translations of glosses, descs and remarks into the dev branch. These are coming from some excellent work that Kiyonori and his team have been doing; they're about one-third of the way through the process of translating the spec files. I'm going to do this slowly and look at each item before I include it, mostly for my own learning purposes, but also in case I might catch the odd misunderstanding. Cheers, Martin _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

4 4

Re: [Tei-council] TEI Council chair elections
by James Cummings 18 Dec '18

18 Dec '18

Hi Elisa (etc.), My apologies. AOL stands for America Online. See http://catb.org/jargon/html/A/AOL-.html for an explanation of this reference. Apologies for being unintentionally cryptic. Best wishes, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Elisa Beshero-Bondar <ebb8(a)pitt.edu> Sent: 17 December 2018 13:28:54 To: James Cummings Cc: Scholger, Martina (martina.scholger(a)uni-graz.at) Vanessa Bigot-Juloux; TEI Council Subject: Re: [Tei-council] TEI Council chair elections James's last message is mysterious because I don't know what <aol> means...Google tells me: AOL Acronym Definition AoL Army of Light (Starwars Galaxies guild) AOL Age of Legends (Wheel of Time Series) AOL Airborne Oceanographic LIDAR AOL Absent Over Leave (See AWOL) which doesn't help much. Anyway, I, too, am glad Martina is willing to continue as chair. Elisa On Mon, Dec 17, 2018 at 1:23 PM James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>> wrote: <aol>Me as well </aol> Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> School of English Literature, Language, and Linguistics, Newcastle University From: Vanessa Bigot-Juloux Sent: Monday, 17 December, 12:22 Subject: Re: [Tei-council] TEI Council chair elections To: Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) Cc: TEI Council Dear all, I totally agree: May I encourage you (Martina) to stand for election once more?! Best, Vanessa Le 13 déc. 2018 à 18:58, Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)UNI-GRAZ.AT<mailto:martina.scholger@UNI-GRAZ.AT>> a écrit : Dear all, I realized that I haven’t said anything about running for Chair again yet, but I wanted to keep the announcement and my candidature separate. I'd be happy to serve as Chair of the TEI Technical Council for another year. I learned a lot this year and have no doubt that there is yet more to learn. Best wishes, Martina Von: Peter Stadler <stadler(a)edirom.de<mailto:stadler@edirom.de>> Gesendet: Donnerstag, 13. Dezember 2018 17:49 An: Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> Cc: TEI Council <tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org>> Betreff: Re: [Tei-council] TEI Council chair elections May I encourage you (Martina) to stand for election once more?! My feeling is you’re just about getting warm :) Best Peter Am 13.12.2018 um 14:19 schrieb Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>>: Dear all, this is a reminder for the upcoming election on the Council's chair for the next term. If you are interested in taking this position, please let us know before our next call on Monday (December 17) via the Council's mailing list. Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/>

2 1

Japanese translations incoming
by Martin Holmes 17 Dec '18

17 Dec '18

Hi all, Just a note to let everyone know that over the next little while I'll be slowly merging some new Japanese translations of glosses, descs and remarks into the dev branch. These are coming from some excellent work that Kiyonori and his team have been doing; they're about one-third of the way through the process of translating the spec files. I'm going to do this slowly and look at each item before I include it, mostly for my own learning purposes, but also in case I might catch the odd misunderstanding. Cheers, Martin

1 0

Call in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 17 Dec '18

17 Dec '18

Dear all, our call starts in 30 minutes. Agenda: https://docs.google.com/document/d/1fJ5nb5WgnwaMnt4WrgnDl-zC7A6LBEeqrIcUFwX… Hangouts:https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best, Martina

1 0

Re: [Tei-council] TEI Council chair elections
by James Cummings 17 Dec '18

17 Dec '18

<aol>Me as well </aol> Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University From: Vanessa Bigot-Juloux Sent: Monday, 17 December, 12:22 Subject: Re: [Tei-council] TEI Council chair elections To: Scholger, Martina (martina.scholger(a)uni-graz.at) Cc: TEI Council Dear all, I totally agree: May I encourage you (Martina) to stand for election once more?! Best, Vanessa Le 13 déc. 2018 à 18:58, Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)UNI-GRAZ.AT<mailto:martina.scholger@UNI-GRAZ.AT>> a écrit : Dear all, I realized that I haven’t said anything about running for Chair again yet, but I wanted to keep the announcement and my candidature separate. I'd be happy to serve as Chair of the TEI Technical Council for another year. I learned a lot this year and have no doubt that there is yet more to learn. Best wishes, Martina Von: Peter Stadler <stadler(a)edirom.de<mailto:stadler@edirom.de>> Gesendet: Donnerstag, 13. Dezember 2018 17:49 An: Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> Cc: TEI Council <tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org>> Betreff: Re: [Tei-council] TEI Council chair elections May I encourage you (Martina) to stand for election once more?! My feeling is you’re just about getting warm :) Best Peter Am 13.12.2018 um 14:19 schrieb Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>>: Dear all, this is a reminder for the upcoming election on the Council's chair for the next term. If you are interested in taking this position, please let us know before our next call on Monday (December 17) via the Council's mailing list. Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 1

TEI Council chair elections
by Scholger, Martina (martina.scholger＠uni-graz.at) 17 Dec '18

17 Dec '18

Dear all, this is a reminder for the upcoming election on the Council's chair for the next term. If you are interested in taking this position, please let us know before our next call on Monday (December 17) via the Council's mailing list. Best wishes, Martina

6 6

TEI conference 2019: program committee
by Scholger, Martina (martina.scholger＠uni-graz.at) 17 Dec '18

17 Dec '18

Dear Council, The preparations for the TEI conference in Graz from September 16 to 20 have already started and we would like to put together the program committee soon. As every year, we hope that some of the TEI Council members will support the PC. Please let me know if you want to be part of it. Your responsibilities would be: - comment on the call proposal which will be proposed by chair and local organizers - reviewing submissions - vote on (critical) split decisions concerning acceptance of submissions - review and comment on final program, which will be proposed by chair and local organizers Best wishes, Martina

5 5

Re: [Tei-council] Next call: December 17
by James Cummings 13 Dec '18

13 Dec '18

Bah, For some reason in my head this was an evening call and so I'm currently scheduled to be driving halfway across the country at this point. I may be able to join the text-chat or something but no promises. Entirely my fault, I apologise. I noticed that someone had suggested Issue 327 https://github.com/TEIC/TEI/issues/327 for discussion. I've updated that ticket with a list of the work I've done on it, and what I think is still to do. It seems basically feature complete to me but I'm sure people will have tweaks they want to make. I'd also be interested in more examples, so English descriptions of non-western but really famous objects. e.g. I added Tutankhamen's Mask as one of the examples (alongside the Alfred Jewel and Excalibur). Otherwise, if people want to skip discussing this in the call and do so on the ticket, I'm fine with that. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 13 December 2018 12:50:36 To: TEI Council Subject: [Tei-council] Next call: December 17 Dear all, this is the agenda for our next call on Monday, December 17 (09:00-10:30 EST, 14-15:30 GMT, 15:00-16:30 CET): https://docs.google.com/document/d/1fJ5nb5WgnwaMnt4WrgnDl-zC7A6LBEeqrIcUFwX…. Please add topics / issues to the agenda. @Elli: I hope we can use the Brown-Hangouts: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best wishes, Martina

1 0

Next call: December 17
by Scholger, Martina (martina.scholger＠uni-graz.at) 13 Dec '18

13 Dec '18

Dear all, this is the agenda for our next call on Monday, December 17 (09:00-10:30 EST, 14-15:30 GMT, 15:00-16:30 CET): https://docs.google.com/document/d/1fJ5nb5WgnwaMnt4WrgnDl-zC7A6LBEeqrIcUFwX…. Please add topics / issues to the agenda. @Elli: I hope we can use the Brown-Hangouts: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best wishes, Martina

1 0

Re: [Tei-council] Goodbye to Alex
by Alejandro Bia 11 Dec '18

11 Dec '18

Dear Martina, dear all, I'm really sad. My contribution to the TEI was null this time. When I applied to the Council in 2016, I made a big miscalculation, thinking that I would have a clean agenda and time to dedicate to the Council, but unexpected things happened that drew my attention away from the TEI. At the beginning, by the time of the Prague meeting, I was enthused with participating in the Council. It is important to say that the way the Council works now, with so many tickets, GitHub, Jenkins, etc., is very different to how it was back in 2006/2007 when we were dealing with migration from P3/P4 to P5. Tutorship is very important in this respect, to climb up the learning curve much quicker. But I cannot justify my low participation based on this. You all know by now that family health issues made me cancel many agenda events, starting with the Victoria meeting, and then the Cologne meeting. Attending meetings is vital to at least keep track of the Council whereabouts. By the time of the TEI conference in Japan I was completely out of everything. Now I'm in Uruguay, still sorting out family issues. Maybe in a few months I will return to "normal"... who knows? You are a very nice group, and I enjoyed the time we shared in Prague. I want to thank you all for your understanding and cooperation, and particularly to Elli and Elisa who were so kind to keep me connected to the Cologne meeting. My apologies for not contributing as much as expected. Wish you all the best, Alex.- At 18:56 07/12/2018, Scholger, Martina (martina.scholger(a)uni-graz.at) wrote: >Content-Language: de-DE >Content-Type: multipart/alternative; > >boundary="_000_04e841350d9045ecabbb5e480a79f652EX13MS02persadunigrazat_" > >Dear all, > >as the end of the year draws near, it is time to >say goodbye to our leaving Council member Alex Bia. >Thank you for your contribution to the TEI >Community and best of luck with your future undertakings! > >Best wishes, >Martina > > >_______________________________________________ >Tei-council mailing list >Tei-council(a)lists.tei-c.org >http://lists.lists.tei-c.org/mailman/listinfo/tei-council --------------------------------------------------------- ALEJANDRO BIA e-mail: abia(a)umh.es CIO - DEMI Centro de Investigación Operativa Departamento de Estadística, Matemáticas e Informática Área de Lenguajes y Sistemas Informáticos Universidad Miguel Hernández Ed. Torretamarit, Av. Universidad s/n, CP:03202, Elche, ESPAÑA Web: http://dhw.umh.es/alex-bia/ Tel: +34 966658973 Skype: alex-bia Twitter: @alex_bia --------------------------------------------------------- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Welcome Vanessa!
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Dec '18

08 Dec '18

Dear all, I'm happy to announce that Vanessa has agreed to start her work on the Council right away. She is already working on tickets with the help of her mentor James. Welcome again, Vanessa! Best wishes, Martina

3 2

Goodbye to Alex
by Scholger, Martina (martina.scholger＠uni-graz.at) 07 Dec '18

07 Dec '18

Dear all, as the end of the year draws near, it is time to say goodbye to our leaving Council member Alex Bia. Thank you for your contribution to the TEI Community and best of luck with your future undertakings! Best wishes, Martina

1 0

<tei:tagsDecl> for TEI P5
by Syd Bauman 03 Dec '18

03 Dec '18

I don't think this is in any way useful, but it was a bit of a pain to create, so I thought someone should see it besides me. In P4, the <tagsDecl> was supposed to contain "a sequence of <tagUsage> elements, one for each distinct element occurring within the outermost <text> element of a TEI document." In earlier releases of P5 this was updated to be namespace-aware: the <tagsDecl> should contain "at least one <namespace> element, containing a series <tagUsage> elements, one for each distinct element from that namespace occurring within the outermost <text> element of a TEI document." Someplace between P5 v. 2.0.0 and v. 3.0.0 we relaxed that restriction so that a <namespace> element contains "up to one for each element type from that namespace". But here is what a complete <tagsDecl> for TEI P5 (current version in GitHub) would look like if we had a <tagUsage> for each element type and included the @occurs and @withId attriubtes. ---------  <tagsDecl xmlns="http://www.tei-c.org/ns/1.0"> <namespace name=""> <tagUsage gi="anthology" occurs="05" withId="0"/> <tagUsage gi="heading" occurs="01" withId="0"/> <tagUsage gi="line" occurs="83" withId="4"/> <tagUsage gi="poem" occurs="06" withId="3"/> <tagUsage gi="poemRef" occurs="01" withId="0"/> <tagUsage gi="stanza" occurs="02" withId="0"/> </namespace> <namespace name="http://purl.oclc.org/dsdl/schematron"> <tagUsage gi="assert" occurs="44" withId="0"/> <tagUsage gi="let" occurs="13" withId="0"/> <tagUsage gi="ns" occurs="10" withId="0"/> <tagUsage gi="pattern" occurs="02" withId="0"/> <tagUsage gi="report" occurs="46" withId="0"/> <tagUsage gi="rule" occurs="31" withId="0"/> <tagUsage gi="value-of" occurs="22" withId="0"/> </namespace> <namespace name="http://purl.org/dc/elements/1.1/"> <tagUsage gi="creator" occurs="03" withId="0"/> <tagUsage gi="description" occurs="01" withId="0"/> <tagUsage gi="format" occurs="01" withId="0"/> <tagUsage gi="identifier" occurs="02" withId="0"/> <tagUsage gi="license" occurs="02" withId="0"/> <tagUsage gi="rights" occurs="01" withId="0"/> <tagUsage gi="source" occurs="20" withId="0"/> <tagUsage gi="subject" occurs="10" withId="0"/> <tagUsage gi="type" occurs="04" withId="0"/> </namespace> <namespace name="http://relaxng.org/ns/compatibility/annotations/1.0"> <tagUsage gi="documentation" occurs="4" withId="0"/> </namespace> <namespace name="http://relaxng.org/ns/structure/1.0"> <tagUsage gi="attribute" occurs="02" withId="0"/> <tagUsage gi="define" occurs="10" withId="0"/> <tagUsage gi="oneOrMore" occurs="09" withId="0"/> <tagUsage gi="optional" occurs="09" withId="0"/> <tagUsage gi="zeroOrMore" occurs="05" withId="0"/> </namespace> <namespace name="http://web.resource.org/cc/"> <tagUsage gi="License" occurs="2" withId="0"/> <tagUsage gi="Work" occurs="2" withId="0"/> <tagUsage gi="permits" occurs="6" withId="0"/> <tagUsage gi="requires" occurs="6" withId="0"/> </namespace> <namespace name="http://www.example.org/ns/nonTEI"> <tagUsage gi="amEntry" occurs="2" withId="0"/> <tagUsage gi="diaryEntry" occurs="8" withId="0"/> <tagUsage gi="paraphasia" occurs="1" withId="0"/> <tagUsage gi="pmEntry" occurs="2" withId="0"/> <tagUsage gi="sentenceBoundaryEnd" occurs="4" withId="0"/> <tagUsage gi="sentenceBoundaryStart" occurs="4" withId="0"/> </namespace> <namespace name="http://www.gram.org"> <tagUsage gi="adj" occurs="01" withId="0"/> <tagUsage gi="aux" occurs="01" withId="0"/> <tagUsage gi="itj" occurs="01" withId="0"/> <tagUsage gi="nom" occurs="01" withId="0"/> <tagUsage gi="pron" occurs="82" withId="7"/> </namespace> <namespace name="http://www.loc.gov/mods/v3"> <tagUsage gi="affiliation" occurs="008" withId="0"/> <tagUsage gi="copyrightDate" occurs="001" withId="0"/> <tagUsage gi="digitalOrigin" occurs="001" withId="0"/> <tagUsage gi="form" occurs="258" withId="0"/> <tagUsage gi="genre" occurs="001" withId="0"/> <tagUsage gi="languageTerm" occurs="001" withId="0"/> <tagUsage gi="mods" occurs="001" withId="0"/> <tagUsage gi="namePart" occurs="006" withId="0"/> <tagUsage gi="originInfo" occurs="001" withId="0"/> <tagUsage gi="physicalDescription" occurs="001" withId="0"/> <tagUsage gi="place" occurs="045" withId="30"/> <tagUsage gi="placeTerm" occurs="001" withId="0"/> <tagUsage gi="roleTerm" occurs="002" withId="0"/> <tagUsage gi="subTitle" occurs="001" withId="0"/> <tagUsage gi="titleInfo" occurs="001" withId="0"/> <tagUsage gi="typeOfResource" occurs="001" withId="0"/> </namespace> <namespace name="http://www.openarchives.org/OAI/2.0/oai_dc/"> <tagUsage gi="dc" occurs="1" withId="0"/> </namespace> <namespace name="http://www.opengis.net/gml"> <tagUsage gi="LinearRing" occurs="1" withId="0"/> <tagUsage gi="Polygon" occurs="1" withId="0"/> <tagUsage gi="exterior" occurs="1" withId="0"/> </namespace> <namespace name="http://www.tei-c.org/ns/1.0"> <tagUsage gi="abbr" occurs="00050" withId="0"/> <tagUsage gi="altIdent" occurs="00032" withId="0"/> <tagUsage gi="alternate" occurs="00358" withId="0"/> <tagUsage gi="anyElement" occurs="00008" withId="0"/> <tagUsage gi="att" occurs="02696" withId="0"/> <tagUsage gi="attDef" occurs="00532" withId="0"/> <tagUsage gi="attList" occurs="00293" withId="0"/> <tagUsage gi="attRef" occurs="00003" withId="0"/> <tagUsage gi="body" occurs="00079" withId="3"/> <tagUsage gi="byline" occurs="00026" withId="0"/> <tagUsage gi="cell" occurs="00552" withId="0"/> <tagUsage gi="cit" occurs="00063" withId="0"/> <tagUsage gi="classRef" occurs="00771" withId="0"/> <tagUsage gi="classSpec" occurs="00200" withId="77"/> <tagUsage gi="classes" occurs="00685" withId="0"/> <tagUsage gi="code" occurs="00619" withId="0"/> <tagUsage gi="constraint" occurs="00089" withId="0"/> <tagUsage gi="constraintSpec" occurs="00089" withId="0"/> <tagUsage gi="content" occurs="00651" withId="0"/> <tagUsage gi="dataFacet" occurs="00008" withId="0"/> <tagUsage gi="dataRef" occurs="00578" withId="0"/> <tagUsage gi="dataSpec" occurs="00035" withId="0"/> <tagUsage gi="datatype" occurs="00523" withId="0"/> <tagUsage gi="defaultVal" occurs="00057" withId="0"/> <tagUsage gi="desc" occurs="10586" withId="56"/> <tagUsage gi="div" occurs="00891" withId="658"/> <tagUsage gi="divGen" occurs="00021" withId="0"/> <tagUsage gi="docAuthor" occurs="00016" withId="0"/> <tagUsage gi="docDate" occurs="00012" withId="0"/> <tagUsage gi="docImprint" occurs="00023" withId="0"/> <tagUsage gi="docTitle" occurs="00032" withId="0"/> <tagUsage gi="eg" occurs="00082" withId="0"/> <tagUsage gi="elementSpec" occurs="00648" withId="93"/> <tagUsage gi="emph" occurs="00108" withId="2"/> <tagUsage gi="empty" occurs="00050" withId="0"/> <tagUsage gi="equiv" occurs="00037" withId="0"/> <tagUsage gi="exemplum" occurs="01897" withId="0"/> <tagUsage gi="expan" occurs="00028" withId="2"/> <tagUsage gi="figDesc" occurs="00019" withId="0"/> <tagUsage gi="figure" occurs="00069" withId="10"/> <tagUsage gi="foreign" occurs="00035" withId="1"/> <tagUsage gi="formula" occurs="00014" withId="1"/> <tagUsage gi="front" occurs="00050" withId="2"/> <tagUsage gi="gi" occurs="06315" withId="0"/> <tagUsage gi="gloss" occurs="03230" withId="1"/> <tagUsage gi="graphic" occurs="00133" withId="0"/> <tagUsage gi="head" occurs="01027" withId="2"/> <tagUsage gi="hi" occurs="00254" withId="1"/> <tagUsage gi="ident" occurs="00740" withId="0"/> <tagUsage gi="item" occurs="01632" withId="33"/> <tagUsage gi="label" occurs="00931" withId="0"/> <tagUsage gi="lb" occurs="00224" withId="1"/> <tagUsage gi="list" occurs="00374" withId="9"/> <tagUsage gi="listRef" occurs="00697" withId="0"/> <tagUsage gi="macroRef" occurs="00216" withId="0"/> <tagUsage gi="macroSpec" occurs="00008" withId="0"/> <tagUsage gi="memberOf" occurs="02046" withId="0"/> <tagUsage gi="mentioned" occurs="00668" withId="5"/> <tagUsage gi="moduleSpec" occurs="00023" withId="21"/> <tagUsage gi="note" occurs="00261" withId="5"/> <tagUsage gi="num" occurs="00049" withId="0"/> <tagUsage gi="p" occurs="06318" withId="27"/> <tagUsage gi="ptr" occurs="02686" withId="14"/> <tagUsage gi="publisher" occurs="00268" withId="0"/> <tagUsage gi="q" occurs="00710" withId="7"/> <tagUsage gi="ref" occurs="00445" withId="1"/> <tagUsage gi="remarks" occurs="01382" withId="0"/> <tagUsage gi="row" occurs="00195" withId="0"/> <tagUsage gi="seg" occurs="00268" withId="80"/> <tagUsage gi="sequence" occurs="00268" withId="0"/> <tagUsage gi="soCalled" occurs="00441" withId="0"/> <tagUsage gi="specDesc" occurs="01028" withId="0"/> <tagUsage gi="specGrp" occurs="00165" withId="152"/> <tagUsage gi="specGrpRef" occurs="00132" withId="0"/> <tagUsage gi="specList" occurs="00373" withId="0"/> <tagUsage gi="table" occurs="00021" withId="3"/> <tagUsage gi="tag" occurs="00128" withId="0"/> <tagUsage gi="term" occurs="00907" withId="6"/> <tagUsage gi="textNode" occurs="00077" withId="0"/> <tagUsage gi="title" occurs="01309" withId="2"/> <tagUsage gi="titlePage" occurs="00014" withId="1"/> <tagUsage gi="titlePart" occurs="00057" withId="0"/> <tagUsage gi="val" occurs="00819" withId="0"/> <tagUsage gi="valDesc" occurs="00009" withId="0"/> <tagUsage gi="valItem" occurs="00702" withId="0"/> <tagUsage gi="valList" occurs="00155" withId="0"/> </namespace> <namespace name="http://www.tei-c.org/ns/Examples"> <tagUsage gi="TEI" occurs="0030" withId="0"/> <tagUsage gi="ab" occurs="0033" withId="2"/> <tagUsage gi="abstract" occurs="0005" withId="0"/> <tagUsage gi="accMat" occurs="0004" withId="0"/> <tagUsage gi="acquisition" occurs="0014" withId="0"/> <tagUsage gi="activity" occurs="0009" withId="0"/> <tagUsage gi="actor" occurs="0127" withId="0"/> <tagUsage gi="add" occurs="0049" withId="5"/> <tagUsage gi="addName" occurs="0011" withId="0"/> <tagUsage gi="addSpan" occurs="0003" withId="0"/> <tagUsage gi="additional" occurs="0007" withId="0"/> <tagUsage gi="additions" occurs="0006" withId="0"/> <tagUsage gi="addrLine" occurs="0048" withId="0"/> <tagUsage gi="address" occurs="0027" withId="0"/> <tagUsage gi="adminInfo" occurs="0010" withId="0"/> <tagUsage gi="age" occurs="0003" withId="0"/> <tagUsage gi="alt" occurs="0035" withId="0"/> <tagUsage gi="altGrp" occurs="0007" withId="0"/> <tagUsage gi="altIdentifier" occurs="0015" withId="0"/> <tagUsage gi="am" occurs="0012" withId="0"/> <tagUsage gi="analytic" occurs="0117" withId="0"/> <tagUsage gi="anchor" occurs="0098" withId="82"/> <tagUsage gi="annotationBlock" occurs="0002" withId="2"/> <tagUsage gi="app" occurs="0069" withId="7"/> <tagUsage gi="appInfo" occurs="0005" withId="0"/> <tagUsage gi="application" occurs="0005" withId="0"/> <tagUsage gi="arc" occurs="0066" withId="9"/> <tagUsage gi="argument" occurs="0005" withId="0"/> <tagUsage gi="author" occurs="0771" withId="1"/> <tagUsage gi="authority" occurs="0006" withId="0"/> <tagUsage gi="availability" occurs="0024" withId="0"/> <tagUsage gi="back" occurs="0027" withId="0"/> <tagUsage gi="bibl" occurs="0637" withId="487"/> <tagUsage gi="biblFull" occurs="0004" withId="0"/> <tagUsage gi="biblScope" occurs="0377" withId="0"/> <tagUsage gi="biblStruct" occurs="0234" withId="199"/> <tagUsage gi="bicond" occurs="0004" withId="0"/> <tagUsage gi="binary" occurs="0069" withId="0"/> <tagUsage gi="binaryObject" occurs="0001" withId="0"/> <tagUsage gi="binding" occurs="0013" withId="0"/> <tagUsage gi="bindingDesc" occurs="0009" withId="0"/> <tagUsage gi="birth" occurs="0013" withId="0"/> <tagUsage gi="bloc" occurs="0008" withId="0"/> <tagUsage gi="broadcast" occurs="0008" withId="0"/> <tagUsage gi="c" occurs="0021" withId="6"/> <tagUsage gi="cRefPattern" occurs="0019" withId="0"/> <tagUsage gi="caesura" occurs="0016" withId="0"/> <tagUsage gi="calendar" occurs="0043" withId="43"/> <tagUsage gi="calendarDesc" occurs="0007" withId="0"/> <tagUsage gi="camera" occurs="0021" withId="0"/> <tagUsage gi="caption" occurs="0009" withId="0"/> <tagUsage gi="case" occurs="0002" withId="0"/> <tagUsage gi="castGroup" occurs="0019" withId="0"/> <tagUsage gi="castItem" occurs="0148" withId="0"/> <tagUsage gi="castList" occurs="0026" withId="0"/> <tagUsage gi="catDesc" occurs="0118" withId="0"/> <tagUsage gi="catRef" occurs="0010" withId="0"/> <tagUsage gi="catchwords" occurs="0005" withId="0"/> <tagUsage gi="category" occurs="0105" withId="101"/> <tagUsage gi="cb" occurs="0005" withId="0"/> <tagUsage gi="certainty" occurs="0054" withId="12"/> <tagUsage gi="change" occurs="0061" withId="21"/> <tagUsage gi="channel" occurs="0013" withId="0"/> <tagUsage gi="char" occurs="0017" withId="17"/> <tagUsage gi="charDecl" occurs="0008" withId="0"/> <tagUsage gi="charName" occurs="0008" withId="0"/> <tagUsage gi="charProp" occurs="0016" withId="0"/> <tagUsage gi="choice" occurs="0107" withId="4"/> <tagUsage gi="citedRange" occurs="0006" withId="0"/> <tagUsage gi="cl" occurs="0043" withId="4"/> <tagUsage gi="classCode" occurs="0009" withId="0"/> <tagUsage gi="classDecl" occurs="0004" withId="0"/> <tagUsage gi="climate" occurs="0005" withId="0"/> <tagUsage gi="closer" occurs="0018" withId="0"/> <tagUsage gi="collation" occurs="0010" withId="0"/> <tagUsage gi="collection" occurs="0013" withId="0"/> <tagUsage gi="colloc" occurs="0004" withId="0"/> <tagUsage gi="colophon" occurs="0008" withId="0"/> <tagUsage gi="cond" occurs="0007" withId="0"/> <tagUsage gi="condition" occurs="0011" withId="0"/> <tagUsage gi="constitution" occurs="0013" withId="0"/> <tagUsage gi="corr" occurs="0051" withId="1"/> <tagUsage gi="correction" occurs="0013" withId="6"/> <tagUsage gi="correspAction" occurs="0015" withId="0"/> <tagUsage gi="correspContext" occurs="0004" withId="0"/> <tagUsage gi="correspDesc" occurs="0003" withId="2"/> <tagUsage gi="country" occurs="0043" withId="0"/> <tagUsage gi="creation" occurs="0015" withId="0"/> <tagUsage gi="custEvent" occurs="0021" withId="0"/> <tagUsage gi="custodialHist" occurs="0011" withId="0"/> <tagUsage gi="damage" occurs="0008" withId="0"/> <tagUsage gi="damageSpan" occurs="0005" withId="0"/> <tagUsage gi="date" occurs="0870" withId="4"/> <tagUsage gi="dateline" occurs="0026" withId="0"/> <tagUsage gi="death" occurs="0009" withId="0"/> <tagUsage gi="decoDesc" occurs="0011" withId="0"/> <tagUsage gi="decoNote" occurs="0071" withId="0"/> <tagUsage gi="def" occurs="0112" withId="3"/> <tagUsage gi="default" occurs="0004" withId="0"/> <tagUsage gi="del" occurs="0065" withId="2"/> <tagUsage gi="delSpan" occurs="0007" withId="0"/> <tagUsage gi="depth" occurs="0011" withId="0"/> <tagUsage gi="derivation" occurs="0013" withId="0"/> <tagUsage gi="dictScrap" occurs="0004" withId="0"/> <tagUsage gi="dim" occurs="0004" withId="1"/> <tagUsage gi="dimensions" occurs="0019" withId="0"/> <tagUsage gi="distinct" occurs="0011" withId="0"/> <tagUsage gi="distributor" occurs="0013" withId="0"/> <tagUsage gi="district" occurs="0017" withId="0"/> <tagUsage gi="div1" occurs="0068" withId="11"/> <tagUsage gi="div2" occurs="0057" withId="10"/> <tagUsage gi="div3" occurs="0031" withId="2"/> <tagUsage gi="div4" occurs="0014" withId="0"/> <tagUsage gi="div5" occurs="0012" withId="0"/> <tagUsage gi="div6" occurs="0006" withId="0"/> <tagUsage gi="div7" occurs="0004" withId="0"/> <tagUsage gi="docEdition" occurs="0005" withId="0"/> <tagUsage gi="domain" occurs="0016" withId="0"/> <tagUsage gi="eLeaf" occurs="0043" withId="2"/> <tagUsage gi="eTree" occurs="0081" withId="38"/> <tagUsage gi="edition" occurs="0036" withId="0"/> <tagUsage gi="editionStmt" occurs="0013" withId="0"/> <tagUsage gi="editor" occurs="0235" withId="3"/> <tagUsage gi="editorialDecl" occurs="0014" withId="2"/> <tagUsage gi="education" occurs="0008" withId="0"/> <tagUsage gi="egXML" occurs="3329" withId="0"/> <tagUsage gi="elementRef" occurs="0594" withId="0"/> <tagUsage gi="email" occurs="0003" withId="0"/> <tagUsage gi="encodingDesc" occurs="0014" withId="0"/> <tagUsage gi="entry" occurs="0136" withId="7"/> <tagUsage gi="entryFree" occurs="0009" withId="0"/> <tagUsage gi="epigraph" occurs="0013" withId="0"/> <tagUsage gi="epilogue" occurs="0005" withId="0"/> <tagUsage gi="equipment" occurs="0013" withId="0"/> <tagUsage gi="etym" occurs="0032" withId="0"/> <tagUsage gi="event" occurs="0021" withId="5"/> <tagUsage gi="ex" occurs="0075" withId="1"/> <tagUsage gi="explicit" occurs="0017" withId="0"/> <tagUsage gi="extent" occurs="0040" withId="0"/> <tagUsage gi="f" occurs="0211" withId="39"/> <tagUsage gi="fDecl" occurs="0024" withId="2"/> <tagUsage gi="fDescr" occurs="0018" withId="0"/> <tagUsage gi="fLib" occurs="0005" withId="0"/> <tagUsage gi="facsimile" occurs="0019" withId="0"/> <tagUsage gi="factuality" occurs="0016" withId="0"/> <tagUsage gi="faith" occurs="0004" withId="0"/> <tagUsage gi="fileDesc" occurs="0020" withId="0"/> <tagUsage gi="filiation" occurs="0009" withId="0"/> <tagUsage gi="finalRubric" occurs="0008" withId="0"/> <tagUsage gi="floatingText" occurs="0007" withId="0"/> <tagUsage gi="floruit" occurs="0003" withId="0"/> <tagUsage gi="foliation" occurs="0007" withId="2"/> <tagUsage gi="forename" occurs="0572" withId="0"/> <tagUsage gi="forest" occurs="0004" withId="0"/> <tagUsage gi="fs" occurs="0101" withId="15"/> <tagUsage gi="fsConstraints" occurs="0004" withId="0"/> <tagUsage gi="fsDecl" occurs="0011" withId="2"/> <tagUsage gi="fsDescr" occurs="0005" withId="0"/> <tagUsage gi="fsdDecl" occurs="0006" withId="0"/> <tagUsage gi="fsdLink" occurs="0006" withId="0"/> <tagUsage gi="funder" occurs="0012" withId="0"/> <tagUsage gi="fvLib" occurs="0006" withId="3"/> <tagUsage gi="fw" occurs="0009" withId="0"/> <tagUsage gi="g" occurs="0056" withId="0"/> <tagUsage gi="gap" occurs="0042" withId="0"/> <tagUsage gi="gb" occurs="0001" withId="0"/> <tagUsage gi="gen" occurs="0020" withId="0"/> <tagUsage gi="genName" occurs="0014" withId="0"/> <tagUsage gi="geo" occurs="0013" withId="0"/> <tagUsage gi="geoDecl" occurs="0003" withId="2"/> <tagUsage gi="geogFeat" occurs="0013" withId="0"/> <tagUsage gi="geogName" occurs="0017" withId="0"/> <tagUsage gi="glyph" occurs="0013" withId="13"/> <tagUsage gi="glyphName" occurs="0009" withId="0"/> <tagUsage gi="gram" occurs="0010" withId="0"/> <tagUsage gi="gramGrp" occurs="0102" withId="0"/> <tagUsage gi="graph" occurs="0020" withId="10"/> <tagUsage gi="group" occurs="0024" withId="0"/> <tagUsage gi="handDesc" occurs="0013" withId="0"/> <tagUsage gi="handNote" occurs="0023" withId="19"/> <tagUsage gi="handNotes" occurs="0002" withId="0"/> <tagUsage gi="handShift" occurs="0009" withId="0"/> <tagUsage gi="headItem" occurs="0010" withId="0"/> <tagUsage gi="headLabel" occurs="0010" withId="0"/> <tagUsage gi="height" occurs="0033" withId="0"/> <tagUsage gi="heraldry" occurs="0004" withId="0"/> <tagUsage gi="history" occurs="0013" withId="0"/> <tagUsage gi="hom" occurs="0012" withId="0"/> <tagUsage gi="hyph" occurs="0016" withId="0"/> <tagUsage gi="hyphenation" occurs="0004" withId="0"/> <tagUsage gi="iNode" occurs="0030" withId="30"/> <tagUsage gi="iType" occurs="0003" withId="0"/> <tagUsage gi="idno" occurs="0148" withId="0"/> <tagUsage gi="if" occurs="0003" withId="0"/> <tagUsage gi="iff" occurs="0004" withId="0"/> <tagUsage gi="imprimatur" occurs="0004" withId="0"/> <tagUsage gi="imprint" occurs="0244" withId="0"/> <tagUsage gi="incident" occurs="0006" withId="0"/> <tagUsage gi="incipit" occurs="0024" withId="0"/> <tagUsage gi="index" occurs="0060" withId="0"/> <tagUsage gi="institution" occurs="0010" withId="0"/> <tagUsage gi="interaction" occurs="0014" withId="0"/> <tagUsage gi="interp" occurs="0045" withId="43"/> <tagUsage gi="interpGrp" occurs="0006" withId="0"/> <tagUsage gi="interpretation" occurs="0005" withId="0"/> <tagUsage gi="join" occurs="0026" withId="4"/> <tagUsage gi="joinGrp" occurs="0005" withId="0"/> <tagUsage gi="keywords" occurs="0013" withId="0"/> <tagUsage gi="kinesic" occurs="0005" withId="1"/> <tagUsage gi="l" occurs="0792" withId="47"/> <tagUsage gi="lacunaEnd" occurs="0005" withId="0"/> <tagUsage gi="lacunaStart" occurs="0001" withId="0"/> <tagUsage gi="lang" occurs="0036" withId="0"/> <tagUsage gi="langKnowledge" occurs="0009" withId="0"/> <tagUsage gi="langKnown" occurs="0018" withId="0"/> <tagUsage gi="langUsage" occurs="0011" withId="0"/> <tagUsage gi="language" occurs="0027" withId="0"/> <tagUsage gi="layout" occurs="0025" withId="0"/> <tagUsage gi="layoutDesc" occurs="0011" withId="0"/> <tagUsage gi="lbl" occurs="0011" withId="0"/> <tagUsage gi="leaf" occurs="0040" withId="40"/> <tagUsage gi="lem" occurs="0042" withId="8"/> <tagUsage gi="lg" occurs="0101" withId="5"/> <tagUsage gi="licence" occurs="0006" withId="0"/> <tagUsage gi="link" occurs="0100" withId="6"/> <tagUsage gi="linkGrp" occurs="0024" withId="2"/> <tagUsage gi="listApp" occurs="0002" withId="2"/> <tagUsage gi="listBibl" occurs="0018" withId="0"/> <tagUsage gi="listChange" occurs="0010" withId="1"/> <tagUsage gi="listEvent" occurs="0002" withId="0"/> <tagUsage gi="listForest" occurs="0001" withId="0"/> <tagUsage gi="listNym" occurs="0004" withId="0"/> <tagUsage gi="listObject" occurs="0005" withId="0"/> <tagUsage gi="listOrg" occurs="0002" withId="0"/> <tagUsage gi="listPerson" occurs="0018" withId="0"/> <tagUsage gi="listPlace" occurs="0006" withId="0"/> <tagUsage gi="listPrefixDef" occurs="0002" withId="0"/> <tagUsage gi="listRelation" occurs="0014" withId="0"/> <tagUsage gi="listTranspose" occurs="0003" withId="0"/> <tagUsage gi="listWit" occurs="0007" withId="1"/> <tagUsage gi="localName" occurs="0015" withId="0"/> <tagUsage gi="locale" occurs="0009" withId="0"/> <tagUsage gi="location" occurs="0018" withId="0"/> <tagUsage gi="locus" occurs="0101" withId="0"/> <tagUsage gi="locusGrp" occurs="0005" withId="0"/> <tagUsage gi="m" occurs="0020" withId="0"/> <tagUsage gi="mapping" occurs="0017" withId="0"/> <tagUsage gi="material" occurs="0033" withId="0"/> <tagUsage gi="measure" occurs="0050" withId="0"/> <tagUsage gi="measureGrp" occurs="0010" withId="0"/> <tagUsage gi="media" occurs="0004" withId="0"/> <tagUsage gi="meeting" occurs="0008" withId="0"/> <tagUsage gi="metDecl" occurs="0009" withId="5"/> <tagUsage gi="metSym" occurs="0041" withId="0"/> <tagUsage gi="metamark" occurs="0014" withId="0"/> <tagUsage gi="milestone" occurs="0040" withId="0"/> <tagUsage gi="mod" occurs="0007" withId="1"/> <tagUsage gi="model" occurs="0051" withId="0"/> <tagUsage gi="modelGrp" occurs="0008" withId="0"/> <tagUsage gi="modelSequence" occurs="0003" withId="0"/> <tagUsage gi="moduleRef" occurs="0062" withId="0"/> <tagUsage gi="monogr" occurs="0238" withId="0"/> <tagUsage gi="mood" occurs="0006" withId="0"/> <tagUsage gi="move" occurs="0005" withId="0"/> <tagUsage gi="msContents" occurs="0031" withId="0"/> <tagUsage gi="msDesc" occurs="0013" withId="3"/> <tagUsage gi="msFrag" occurs="0008" withId="0"/> <tagUsage gi="msIdentifier" occurs="0041" withId="0"/> <tagUsage gi="msItem" occurs="0052" withId="0"/> <tagUsage gi="msItemStruct" occurs="0003" withId="0"/> <tagUsage gi="msName" occurs="0016" withId="0"/> <tagUsage gi="msPart" occurs="0005" withId="0"/> <tagUsage gi="musicNotation" occurs="0008" withId="0"/> <tagUsage gi="name" occurs="0385" withId="9"/> <tagUsage gi="nameLink" occurs="0006" withId="0"/> <tagUsage gi="namespace" occurs="0007" withId="0"/> <tagUsage gi="nationality" occurs="0005" withId="0"/> <tagUsage gi="node" occurs="0100" withId="100"/> <tagUsage gi="normalization" occurs="0019" withId="4"/> <tagUsage gi="notatedMusic" occurs="0008" withId="0"/> <tagUsage gi="notesStmt" occurs="0006" withId="0"/> <tagUsage gi="number" occurs="0018" withId="0"/> <tagUsage gi="numeric" occurs="0021" withId="0"/> <tagUsage gi="nym" occurs="0026" withId="26"/> <tagUsage gi="oRef" occurs="0027" withId="2"/> <tagUsage gi="objIdentifier" occurs="0010" withId="0"/> <tagUsage gi="object" occurs="0008" withId="8"/> <tagUsage gi="objectDesc" occurs="0017" withId="0"/> <tagUsage gi="objectName" occurs="0028" withId="0"/> <tagUsage gi="objectType" occurs="0005" withId="0"/> <tagUsage gi="occupation" occurs="0013" withId="0"/> <tagUsage gi="offset" occurs="0020" withId="0"/> <tagUsage gi="opener" occurs="0013" withId="0"/> <tagUsage gi="org" occurs="0017" withId="13"/> <tagUsage gi="orgName" occurs="0067" withId="0"/> <tagUsage gi="orig" occurs="0051" withId="0"/> <tagUsage gi="origDate" occurs="0012" withId="0"/> <tagUsage gi="origPlace" occurs="0012" withId="0"/> <tagUsage gi="origin" occurs="0014" withId="0"/> <tagUsage gi="orth" occurs="0258" withId="12"/> <tagUsage gi="outputRendition" occurs="0014" withId="0"/> <tagUsage gi="pRef" occurs="0005" withId="0"/> <tagUsage gi="param" occurs="0036" withId="0"/> <tagUsage gi="paramList" occurs="0029" withId="0"/> <tagUsage gi="paramSpec" occurs="0045" withId="0"/> <tagUsage gi="particDesc" occurs="0006" withId="1"/> <tagUsage gi="path" occurs="0004" withId="2"/> <tagUsage gi="pause" occurs="0022" withId="0"/> <tagUsage gi="pb" occurs="0045" withId="24"/> <tagUsage gi="pc" occurs="0025" withId="5"/> <tagUsage gi="per" occurs="0006" withId="0"/> <tagUsage gi="performance" occurs="0013" withId="3"/> <tagUsage gi="persName" occurs="0187" withId="11"/> <tagUsage gi="person" occurs="0065" withId="55"/> <tagUsage gi="personGrp" occurs="0004" withId="4"/> <tagUsage gi="persona" occurs="0002" withId="0"/> <tagUsage gi="phr" occurs="0059" withId="0"/> <tagUsage gi="physDesc" occurs="0022" withId="0"/> <tagUsage gi="placeName" occurs="0160" withId="6"/> <tagUsage gi="population" occurs="0014" withId="0"/> <tagUsage gi="pos" occurs="0073" withId="0"/> <tagUsage gi="postBox" occurs="0005" withId="0"/> <tagUsage gi="postCode" occurs="0013" withId="0"/> <tagUsage gi="postscript" occurs="0003" withId="0"/> <tagUsage gi="precision" occurs="0009" withId="0"/> <tagUsage gi="prefixDef" occurs="0005" withId="0"/> <tagUsage gi="preparedness" occurs="0013" withId="0"/> <tagUsage gi="principal" occurs="0005" withId="1"/> <tagUsage gi="profileDesc" occurs="0016" withId="0"/> <tagUsage gi="projectDesc" occurs="0007" withId="0"/> <tagUsage gi="prologue" occurs="0004" withId="0"/> <tagUsage gi="provenance" occurs="0024" withId="0"/> <tagUsage gi="pubPlace" occurs="0239" withId="0"/> <tagUsage gi="publicationStmt" occurs="0030" withId="0"/> <tagUsage gi="punctuation" occurs="0001" withId="0"/> <tagUsage gi="purpose" occurs="0024" withId="0"/> <tagUsage gi="quotation" occurs="0014" withId="0"/> <tagUsage gi="quote" occurs="0136" withId="0"/> <tagUsage gi="rdg" occurs="0134" withId="11"/> <tagUsage gi="rdgGrp" occurs="0016" withId="0"/> <tagUsage gi="re" occurs="0025" withId="0"/> <tagUsage gi="recordHist" occurs="0012" withId="0"/> <tagUsage gi="recording" occurs="0015" withId="3"/> <tagUsage gi="recordingStmt" occurs="0005" withId="0"/> <tagUsage gi="redo" occurs="0001" withId="0"/> <tagUsage gi="refState" occurs="0010" withId="0"/> <tagUsage gi="refsDecl" occurs="0016" withId="4"/> <tagUsage gi="reg" occurs="0052" withId="0"/> <tagUsage gi="region" occurs="0029" withId="0"/> <tagUsage gi="relatedItem" occurs="0005" withId="0"/> <tagUsage gi="relation" occurs="0026" withId="0"/> <tagUsage gi="rendition" occurs="0035" withId="29"/> <tagUsage gi="repository" occurs="0039" withId="0"/> <tagUsage gi="residence" occurs="0018" withId="0"/> <tagUsage gi="resp" occurs="0081" withId="0"/> <tagUsage gi="respStmt" occurs="0079" withId="16"/> <tagUsage gi="respons" occurs="0013" withId="0"/> <tagUsage gi="restore" occurs="0002" withId="0"/> <tagUsage gi="retrace" occurs="0008" withId="2"/> <tagUsage gi="revisionDesc" occurs="0012" withId="0"/> <tagUsage gi="rhyme" occurs="0056" withId="8"/> <tagUsage gi="role" occurs="0126" withId="22"/> <tagUsage gi="roleDesc" occurs="0027" withId="0"/> <tagUsage gi="roleName" occurs="0019" withId="0"/> <tagUsage gi="root" occurs="0010" withId="8"/> <tagUsage gi="rs" occurs="0061" withId="5"/> <tagUsage gi="rubric" occurs="0022" withId="0"/> <tagUsage gi="s" occurs="0121" withId="53"/> <tagUsage gi="said" occurs="0051" withId="3"/> <tagUsage gi="salute" occurs="0022" withId="0"/> <tagUsage gi="samplingDecl" occurs="0006" withId="0"/> <tagUsage gi="schemaRef" occurs="0006" withId="0"/> <tagUsage gi="schemaSpec" occurs="0024" withId="0"/> <tagUsage gi="scriptDesc" occurs="0002" withId="0"/> <tagUsage gi="scriptNote" occurs="0003" withId="2"/> <tagUsage gi="scriptStmt" occurs="0002" withId="1"/> <tagUsage gi="seal" occurs="0006" withId="0"/> <tagUsage gi="sealDesc" occurs="0003" withId="0"/> <tagUsage gi="secFol" occurs="0004" withId="0"/> <tagUsage gi="secl" occurs="0002" withId="0"/> <tagUsage gi="segmentation" occurs="0002" withId="0"/> <tagUsage gi="sense" occurs="0125" withId="0"/> <tagUsage gi="series" occurs="0030" withId="0"/> <tagUsage gi="seriesStmt" occurs="0005" withId="0"/> <tagUsage gi="set" occurs="0013" withId="0"/> <tagUsage gi="setting" occurs="0009" withId="0"/> <tagUsage gi="settingDesc" occurs="0008" withId="0"/> <tagUsage gi="settlement" occurs="0089" withId="0"/> <tagUsage gi="sex" occurs="0008" withId="0"/> <tagUsage gi="shift" occurs="0014" withId="0"/> <tagUsage gi="sic" occurs="0049" withId="0"/> <tagUsage gi="signatures" occurs="0005" withId="0"/> <tagUsage gi="signed" occurs="0019" withId="0"/> <tagUsage gi="socecStatus" occurs="0007" withId="0"/> <tagUsage gi="sound" occurs="0011" withId="0"/> <tagUsage gi="sourceDesc" occurs="0026" withId="0"/> <tagUsage gi="sourceDoc" occurs="0005" withId="0"/> <tagUsage gi="sp" occurs="0162" withId="0"/> <tagUsage gi="spGrp" occurs="0006" withId="1"/> <tagUsage gi="space" occurs="0005" withId="0"/> <tagUsage gi="span" occurs="0024" withId="0"/> <tagUsage gi="spanGrp" occurs="0004" withId="0"/> <tagUsage gi="speaker" occurs="0138" withId="0"/> <tagUsage gi="sponsor" occurs="0007" withId="0"/> <tagUsage gi="stage" occurs="0102" withId="1"/> <tagUsage gi="stamp" occurs="0005" withId="0"/> <tagUsage gi="state" occurs="0012" withId="0"/> <tagUsage gi="stdVals" occurs="0004" withId="0"/> <tagUsage gi="street" occurs="0019" withId="0"/> <tagUsage gi="stress" occurs="0001" withId="0"/> <tagUsage gi="string" occurs="0033" withId="0"/> <tagUsage gi="styleDefDecl" occurs="0002" withId="0"/> <tagUsage gi="subc" occurs="0019" withId="0"/> <tagUsage gi="subst" occurs="0014" withId="2"/> <tagUsage gi="substJoin" occurs="0002" withId="0"/> <tagUsage gi="summary" occurs="0015" withId="0"/> <tagUsage gi="superEntry" occurs="0006" withId="0"/> <tagUsage gi="supplied" occurs="0015" withId="0"/> <tagUsage gi="support" occurs="0011" withId="0"/> <tagUsage gi="supportDesc" occurs="0014" withId="0"/> <tagUsage gi="surface" occurs="0045" withId="1"/> <tagUsage gi="surfaceGrp" occurs="0007" withId="0"/> <tagUsage gi="surname" occurs="0462" withId="0"/> <tagUsage gi="surplus" occurs="0004" withId="0"/> <tagUsage gi="surrogates" occurs="0007" withId="0"/> <tagUsage gi="syll" occurs="0003" withId="0"/> <tagUsage gi="symbol" occurs="0171" withId="8"/> <tagUsage gi="tagUsage" occurs="0017" withId="0"/> <tagUsage gi="tagsDecl" occurs="0008" withId="0"/> <tagUsage gi="taxonomy" occurs="0019" withId="13"/> <tagUsage gi="tech" occurs="0003" withId="0"/> <tagUsage gi="teiCorpus" occurs="0006" withId="0"/> <tagUsage gi="teiHeader" occurs="0044" withId="0"/> <tagUsage gi="terrain" occurs="0002" withId="0"/> <tagUsage gi="text" occurs="0095" withId="4"/> <tagUsage gi="textClass" occurs="0007" withId="0"/> <tagUsage gi="textDesc" occurs="0010" withId="0"/> <tagUsage gi="textLang" occurs="0022" withId="0"/> <tagUsage gi="then" occurs="0010" withId="0"/> <tagUsage gi="time" occurs="0040" withId="0"/> <tagUsage gi="timeline" occurs="0010" withId="3"/> <tagUsage gi="titleStmt" occurs="0029" withId="0"/> <tagUsage gi="tns" occurs="0011" withId="0"/> <tagUsage gi="trailer" occurs="0018" withId="0"/> <tagUsage gi="trait" occurs="0006" withId="0"/> <tagUsage gi="transcriptionDesc" occurs="0002" withId="0"/> <tagUsage gi="transpose" occurs="0004" withId="0"/> <tagUsage gi="tree" occurs="0008" withId="0"/> <tagUsage gi="triangle" occurs="0003" withId="0"/> <tagUsage gi="typeDesc" occurs="0006" withId="0"/> <tagUsage gi="typeNote" occurs="0008" withId="3"/> <tagUsage gi="u" occurs="0121" withId="52"/> <tagUsage gi="unclear" occurs="0026" withId="0"/> <tagUsage gi="undo" occurs="0004" withId="0"/> <tagUsage gi="unicodeName" occurs="0009" withId="0"/> <tagUsage gi="unit" occurs="0011" withId="0"/> <tagUsage gi="usg" occurs="0041" withId="0"/> <tagUsage gi="vAlt" occurs="0029" withId="0"/> <tagUsage gi="vColl" occurs="0018" withId="0"/> <tagUsage gi="vDefault" occurs="0011" withId="0"/> <tagUsage gi="vLabel" occurs="0006" withId="0"/> <tagUsage gi="vMerge" occurs="0004" withId="0"/> <tagUsage gi="vNot" occurs="0009" withId="0"/> <tagUsage gi="vRange" occurs="0022" withId="0"/> <tagUsage gi="value" occurs="0022" withId="0"/> <tagUsage gi="variantEncoding" occurs="0007" withId="0"/> <tagUsage gi="view" occurs="0022" withId="0"/> <tagUsage gi="vocal" occurs="0012" withId="0"/> <tagUsage gi="w" occurs="0299" withId="122"/> <tagUsage gi="watermark" occurs="0011" withId="0"/> <tagUsage gi="when" occurs="0044" withId="44"/> <tagUsage gi="width" occurs="0034" withId="1"/> <tagUsage gi="wit" occurs="0008" withId="0"/> <tagUsage gi="witDetail" occurs="0003" withId="0"/> <tagUsage gi="witEnd" occurs="0001" withId="0"/> <tagUsage gi="witStart" occurs="0002" withId="0"/> <tagUsage gi="witness" occurs="0030" withId="30"/> <tagUsage gi="writing" occurs="0007" withId="0"/> <tagUsage gi="xenoData" occurs="0006" withId="0"/> <tagUsage gi="xr" occurs="0024" withId="0"/> <tagUsage gi="zone" occurs="0048" withId="11"/> </namespace> <namespace name="http://www.w3.org/1998/Math/MathML"> <tagUsage gi="math" occurs="03" withId="0"/> <tagUsage gi="mfrac" occurs="05" withId="0"/> <tagUsage gi="mi" occurs="06" withId="0"/> <tagUsage gi="mn" occurs="12" withId="0"/> <tagUsage gi="mo" occurs="07" withId="0"/> <tagUsage gi="mrow" occurs="14" withId="0"/> <tagUsage gi="msup" occurs="02" withId="0"/> </namespace> <namespace name="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <tagUsage gi="Description" occurs="2" withId="0"/> <tagUsage gi="RDF" occurs="4" withId="0"/> </namespace> <namespace name="http://www.w3.org/1999/xhtml"> <tagUsage gi="a" occurs="4" withId="0"/> <tagUsage gi="html" occurs="1" withId="0"/> </namespace> <namespace name="http://www.w3.org/2000/svg"> <tagUsage gi="ellipse" occurs="1" withId="0"/> <tagUsage gi="image" occurs="1" withId="0"/> <tagUsage gi="rect" occurs="3" withId="0"/> <tagUsage gi="svg" occurs="5" withId="0"/> </namespace> <namespace name="http://www.w3.org/2001/SMIL20/Language"> <tagUsage gi="audio" occurs="6" withId="6"/> </namespace> </tagsDecl> ---------

1 0

Re: [Tei-council] who's Vanessa's mentor?
by James Cummings 02 Dec '18

02 Dec '18

Hello, yes. I thought it was me, though as they say "It takes a village" and if she wishes ask others for help, that is fine as well. Why? What's up? Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Elisa Beshero-Bondar <ebb8(a)pitt.edu> Sent: 01 December 2018 19:18:58 To: Bauman, Syd Cc: TEI Council Subject: Re: [Tei-council] who's Vanessa's mentor? As I understand it from previous meetings, James is mentoring Vanessa. Elisa On Sat, Dec 1, 2018 at 11:27 AM Syd Bauman <s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>> wrote: Subject says it all. :-) _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/>

1 0

who's Vanessa's mentor?
by Syd Bauman 01 Dec '18

01 Dec '18

Subject says it all. :-)

2 1

Re: [Tei-council] Jenkins dislikes my commit message?
by James Cummings 20 Nov '18

20 Nov '18

Hi Hugh, I think it is probably better just to make it common knowledge by reminding us lots that in writing good commit messages (not the crappy ones I tend to use) that avoiding the word 'error' and the word 'warning' are probably good ideas. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Hugh Cayless <philomousos(a)gmail.com> Sent: 20 November 2018 12:50:40 To: TEI Council Subject: Re: [Tei-council] Jenkins dislikes my commit message? FYI I'm pretty sure it is possible to tell Jenkins to ignore specific messages, so there's a workaround available if you have a case where you really WANT to say "error" :-). H On Tue, Nov 20, 2018 at 7:02 AM James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>> wrote: Hi Syd, I had that problem the other week with some otherwise benign changes where I mentioned "Error in listObject Example" (26 October) https://github.com/TEIC/TEI/commits you'll see immediately after I committed "inconsequential commit to trick Jenkins". This is because the way Jenkins flags whether there is an error or not is parsing the console output for the word 'error'. Imagine how fun this would be if one of our tests returned "No errors here!". Sigh. So having it do it again won't do anything but find the same error it thinks exists because your commit message is present. I'd suggest, if you haven't already, just making a trivial change, even just spacing, and re-committing/pushing without mentioning the word 'error'. ;-) Best wishes, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Syd Bauman <s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>> Sent: 19 November 2018 22:20:38 To: TEI Council Subject: [Tei-council] Jenkins dislikes my commit message? Could the Jenkins maintainers force the Stylesheets-dev job to re-build? My check-in from this morning's meeting built as well as can be expected on my local system. It fails in Jenkins, flagging my commit message itself (which contains the word "error"). I'm hoping that if Mr. Jenkins just does the work again, it will work. If not, I'll try committing some tiny tweak with a different commit message. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] Jenkins dislikes my commit message?
by James Cummings 20 Nov '18

20 Nov '18

Hi Syd, I had that problem the other week with some otherwise benign changes where I mentioned "Error in listObject Example" (26 October) https://github.com/TEIC/TEI/commits you'll see immediately after I committed "inconsequential commit to trick Jenkins". This is because the way Jenkins flags whether there is an error or not is parsing the console output for the word 'error'. Imagine how fun this would be if one of our tests returned "No errors here!". Sigh. So having it do it again won't do anything but find the same error it thinks exists because your commit message is present. I'd suggest, if you haven't already, just making a trivial change, even just spacing, and re-committing/pushing without mentioning the word 'error'. ;-) Best wishes, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 19 November 2018 22:20:38 To: TEI Council Subject: [Tei-council] Jenkins dislikes my commit message? Could the Jenkins maintainers force the Stylesheets-dev job to re-build? My check-in from this morning's meeting built as well as can be expected on my local system. It fails in Jenkins, flagging my commit message itself (which contains the word "error"). I'm hoping that if Mr. Jenkins just does the work again, it will work. If not, I'll try committing some tiny tweak with a different commit message. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 1

Re: [Tei-council] Jenkins dislikes my commit message?
by Syd Bauman 19 Nov '18

19 Nov '18

Sorry, should have just said "could Peter force Mr. Paderborn Jenkins to re-start the Stylesheets-dev job. It worked for Ms. Victoria Jenkins. > Could the Jenkins maintainers force the Stylesheets-dev job to > re-build? > My check-in from this morning's meeting built as well as can be > expected on my local system. It fails in Jenkins, flagging my > commit message itself (which contains the word "error"). I'm hoping > that if Mr. Jenkins just does the work again, it will work. If not, > I'll try committing some tiny tweak with a different commit > message.

1 0

Jenkins dislikes my commit message?
by Syd Bauman 19 Nov '18

19 Nov '18

Could the Jenkins maintainers force the Stylesheets-dev job to re-build? My check-in from this morning's meeting built as well as can be expected on my local system. It fails in Jenkins, flagging my commit message itself (which contains the word "error"). I'm hoping that if Mr. Jenkins just does the work again, it will work. If not, I'll try committing some tiny tweak with a different commit message.

1 0

Stylesheets meeting Mon 19 Nov
by Syd Bauman 19 Nov '18

19 Nov '18

Next Stylesheets meeting is scheduled for this coming Mon 19 Nov at 14:00Z. That means: * 06:00 PST * 09:00 EST * 14:00 GMT * 15:00 CET Agenda to follow.

2 2

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

16 Nov '18

Hi all, we start in 20 minutes. https://docs.google.com/document/d/1zE_BQbZQYqnj6nFhypeBrXvloURXbCvP3XUprDF… Martina

1 0

Next call on Friday 16
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 Nov '18

16 Nov '18

Dear all, this is the agenda for our next call on Friday 16 (16:00-17:30 EST, 21-22:30 BT, 22:00-23:30 CET): https://docs.google.com/document/d/1zE_BQbZQYqnj6nFhypeBrXvloURXbCvP3XUprDF… If I remember correctly Elisa, James, Raff and Vanessa cannot make it? But I would stick to our original date. Please add topics / issues that you want to discuss. No more scheduling on Friday - I promise :) Hangouts: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best wishes, Martina

3 4

location for F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 07 Nov '18

07 Nov '18

Dear all, we have a decision on the location for our F2F meeting, it is the Folger Library (Washington). The meeting will take place from May 6 to 8. Thanks to all who offered to host the meeting. It's good to know that the Council already has options for upcoming meetings. Raff, please let me know if you need anything for getting this organized. Best wishes, Martina

2 1

November 16 Monthly Hangout--probably missing
by Elisa Beshero-Bondar 07 Nov '18

07 Nov '18

Dear Council: I'm almost certainly going to miss the Council meeting on Friday November 16 due to a flight I'm taking to visit my old dissertation advisor in Maine that day. I'd tried to book it later in the evening but there weren't flights. I'd be arriving at a tiny airport in Rockland, Maine right around when the meeting starts, and with all the fuss of seeing an old mentor after more than a decade, I doubt I'm going to be able to join the Hangout. I'm bringing my headphones just in case it works out--there's a chance I could maybe join late. Sorry! 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

1 0

Re: [Tei-council] Reminder: Scheduling Spring F2F
by James Cummings 05 Nov '18

05 Nov '18

Hi all, I got an email back from the person who controls the spaces on the nice university building right on the beach on the coast outside Newcastle closer to where I live. It is available those dates, but because it is in such demand they charge 250 GBP a day for it. So instead we'd have the meetings on campus (free meeting rooms but maybe not the same each day). We could still go out to the coast some evening for supper or something. Just in case that sways your vote to/from Newcastle. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 04 November 2018 21:11:13 To: Mylonas, Elli; TEI Council Subject: Re: [Tei-council] Reminder: Scheduling Spring F2F Excellent, we have the date for our Spring F2F meeting. It is May 6-8. Please continue voting on locations until Tuesday. I was assuming that all the locations would be available on that dates. If that’s not the case, please let me know. Here is the link again: https://doodle.com/poll/fk6e3yi58zx2c6tt. It is an anonymous voting. Best wishes, Martina Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Mylonas, Elli Gesendet: Freitag, 2. November 2018 23:52 An: TEI Council <tei-council(a)lists.tei-c.org> Betreff: Re: [Tei-council] Reminder: Scheduling Spring F2F May 6-8 fine for providence On Fri, Nov 2, 2018 at 3:29 PM Elisa Beshero-Bondar <ebb8(a)pitt.edu<mailto:ebb8@pitt.edu>> wrote: That is to say, should those TEI Council members who are in contact with specific venues for hosting now check in with those venues to see which are actually available on the dates we've selected? And report back if they are not, so that we may narrow our options accordingly. E On Fri, Nov 2, 2018 at 3:27 PM Elisa Beshero-Bondar <ebb8(a)pitt.edu<mailto:ebb8@pitt.edu>> wrote: Hi all-- On locations for the Spring F2F, I wonder if some might eliminate themselves now that we've narrowed down the dates? Should we check that first before voting on locations? Cheers, Elisa On Fri, Nov 2, 2018 at 2:54 PM Hugh Cayless <philomousos(a)gmail.com<mailto:philomousos@gmail.com>> wrote: I'm Sorry Martina, I could have sworn I'd already done it. Yes, May 6-8 is fine. Hugh On Fri, Nov 2, 2018 at 1:22 PM Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> wrote: Hi Raff and all, I think you meant to add the Council for this as a recipient too… Actually, Hugh’s voting is missing. At the moment our best option is May 6-8. Hugh, would that be possible for you too? We have 4 great offers for locations, that makes it really difficult to decide. But keep in mind that every potential host offered to organize the Council meeting also in the following years. We have heard a number of arguments that speak for one or the other location: TEI/DH people we might meet there; meeting in conjunction with a workshop; easy to organize; not too expensive; easy to reach; the Autumn meeting is in Europe etc. I set up another doodle where everyone can vote for their preferred location: https://doodle.com/poll/fk6e3yi58zx2c6tt. Please do that until Tuesday, so that we have our final decision on Wednesday. If you think a blind voting is better, I can change the settings accordingly. Best wishes, Martina Von: Raffaele Viglianti <raffaeleviglianti(a)gmail.com<mailto:raffaeleviglianti@gmail.com>> Gesendet: Mittwoch, 31. Oktober 2018 20:24 An: Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> Betreff: Re: [Tei-council] Reminder: Scheduling Spring F2F Hi Martina and all, I think we all filled this in and can find dates that work. Should we have another doodle or something for voting on location? I told people at the Folger that I would let them know by the end of the month. No pressure if that doesn't happen, but either way it may be worth figuring out how we're going to decide sooner rather than later. Raff On Thu, Oct 25, 2018 at 7:50 AM Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> wrote: Dear Council, please fill out the doodle for the Spring F2F meeting in case you haven’t done yet: https://doodle.com/poll/yp3uucnqmmiqyc9v Thanks! Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/> -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/> _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] Reminder: Scheduling Spring F2F
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Nov '18

04 Nov '18

Hi Raff and all, I think you meant to add the Council for this as a recipient too… Actually, Hugh’s voting is missing. At the moment our best option is May 6-8. Hugh, would that be possible for you too? We have 4 great offers for locations, that makes it really difficult to decide. But keep in mind that every potential host offered to organize the Council meeting also in the following years. We have heard a number of arguments that speak for one or the other location: TEI/DH people we might meet there; meeting in conjunction with a workshop; easy to organize; not too expensive; easy to reach; the Autumn meeting is in Europe etc. I set up another doodle where everyone can vote for their preferred location: https://doodle.com/poll/fk6e3yi58zx2c6tt. Please do that until Tuesday, so that we have our final decision on Wednesday. If you think a blind voting is better, I can change the settings accordingly. Best wishes, Martina Von: Raffaele Viglianti <raffaeleviglianti(a)gmail.com> Gesendet: Mittwoch, 31. Oktober 2018 20:24 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Betreff: Re: [Tei-council] Reminder: Scheduling Spring F2F Hi Martina and all, I think we all filled this in and can find dates that work. Should we have another doodle or something for voting on location? I told people at the Folger that I would let them know by the end of the month. No pressure if that doesn't happen, but either way it may be worth figuring out how we're going to decide sooner rather than later. Raff On Thu, Oct 25, 2018 at 7:50 AM Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> wrote: Dear Council, please fill out the doodle for the Spring F2F meeting in case you haven’t done yet: https://doodle.com/poll/yp3uucnqmmiqyc9v Thanks! Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

5 6

Re: [Tei-council] Website bug.
by James Cummings 31 Oct '18

31 Oct '18

Hi Luis, Fair enough! Thought best to point it out just in case it was something that had slipped by! Happy Halloween! (My skull-like Luche Libra mask has frightened many a small child this evening.) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Luis Meneses <ldmm(a)uvic.ca> Sent: 31 October 2018 16:28:44 To: James Cummings Cc: TEI Council Subject: Re: Website bug. Hi James, This is something that we are working on right now. I am in the process of switching over to using Google Search on the site. I am waiting until we get verified by Google as a non-profit organization. Once that happens we can use their search engine for free and without ads. Best, ----- -Luis On Oct 31, 2018, at 9:16 AM, James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>> wrote: Hi Luis (CC'ing TEI-Council), I've just noticed that while on the TEI Website if I search for something. Let's say 'persName'. The URL is http://www.tei-c.org/?s=persName but this searches website-only content rather than including the Guidelines. Is this by design? Inherent limitation since the Guidelines are stored separately? There is a google site search on the generated Guidelines pages, e.g. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html which searches the Guidelines. I'm assuming the first search is a wordpress one which can't know about the Guidelines content (stored outside wordpress). The problem, obvious I hope, is that people don't know that the first search doesn't search the guidelines as well. Options that occur to me: a) Change the label of the first search ('website only' or similar) and the text on the results page (if possible) to point to the Guidelines search to say 'Or search in the Guidelines' and have a guidelines search box there. b) or replace with google site search throughout so that all search boxes search all the same content or something. Just thought I'd mention it. What do others think? Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> School of English Literature, Language, and Linguistics, Newcastle University

1 0

Website bug.
by James Cummings 31 Oct '18

31 Oct '18

Hi Luis (CC'ing TEI-Council), I've just noticed that while on the TEI Website if I search for something. Let's say 'persName'. The URL is http://www.tei-c.org/?s=persName but this searches website-only content rather than including the Guidelines. Is this by design? Inherent limitation since the Guidelines are stored separately? There is a google site search on the generated Guidelines pages, e.g. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html which searches the Guidelines. I'm assuming the first search is a wordpress one which can't know about the Guidelines content (stored outside wordpress). The problem, obvious I hope, is that people don't know that the first search doesn't search the guidelines as well. Options that occur to me: a) Change the label of the first search ('website only' or similar) and the text on the results page (if possible) to point to the Guidelines search to say 'Or search in the Guidelines' and have a guidelines search box there. b) or replace with google site search throughout so that all search boxes search all the same content or something. Just thought I'd mention it. What do others think? Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University

3 2

Re: [Tei-council] policy on grouping element name
by James Cummings 30 Oct '18

30 Oct '18

c.f. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#index-front.1_d… (Which btw is a horrible, presumably auto-created at some point, ID that we should change sometime.) Basically: "In TEI usage, a group is distinguished from a list in that the former associates several objects which act as a single entity, while the latter does not. For example, a linkGrp combines several link elements which have certain properties in common, whereas a listBibl simply lists a number of otherwise unrelated bibl elements." And I've got a memory of it in some TCW explaining naming of elements somewhere else but couldn't find that in a quick search. -James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 30 October 2018 18:33:11 To: TEI Council Subject: [Tei-council] policy on grouping element name Do we have a written policy on when a grouping elment for Xs is named <listX> vs <XGrp>? I think the policy should be that we use <listX> when the order of Xs does, or may, have significance; we use <XGrp> when the order of Xs does not, or should not, have significance. In alphabetic order by the part of the GI that says what is being contained, we have: * altGrp * listApp * listBibl * listChange * listEvent * listForest * gramGrp * interpGrp * joinGrp * linkGrp * locusGrp * measureGrp * modelGrp * listNym * listOrg * listPerson * personGrp /* not really the same sort of animal */ * listPlace * listPrefixDef * rdgGrp * listRef * listRelation * spanGrp * specGrp * specGrpRef * spGrp * surfaceGrp * listTranspose * listWit While I think several of these arguably do not fall into my definitions above, I still think it may be a useful guideline for future names. Unless, of course, we already have a guideline for future names. :-) _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

policy on grouping element name
by Syd Bauman 30 Oct '18

30 Oct '18

Do we have a written policy on when a grouping elment for Xs is named <listX> vs <XGrp>? I think the policy should be that we use <listX> when the order of Xs does, or may, have significance; we use <XGrp> when the order of Xs does not, or should not, have significance. In alphabetic order by the part of the GI that says what is being contained, we have: * altGrp * listApp * listBibl * listChange * listEvent * listForest * gramGrp * interpGrp * joinGrp * linkGrp * locusGrp * measureGrp * modelGrp * listNym * listOrg * listPerson * personGrp /* not really the same sort of animal */ * listPlace * listPrefixDef * rdgGrp * listRef * listRelation * spanGrp * specGrp * specGrpRef * spGrp * surfaceGrp * listTranspose * listWit While I think several of these arguably do not fall into my definitions above, I still think it may be a useful guideline for future names. Unless, of course, we already have a guideline for future names. :-)

1 0

objectName/listObject/object/idGrp and other changes
by James Cummings 26 Oct '18

26 Oct '18

Hi all, I've put a summary of the locations for testing of the various elements related to adding the object element (to provide descriptions of real or fictional objects) on the github issue at: https://github.com/TEIC/TEI/issues/327#issuecomment-433548949 with links to the reference pages, first draft of Guidelines prose (needs more work), etc. I made minor changes to some descriptions other elements (like physDesc or msContents) to include 'or other object' to make them usable for <object>. I wasn't doing a full build locally (just generating Relax NG schema to test) and so when checking into Jenkins I had a variety of errors pop up that I mention now just for shared experience. All fairly trivial: - ambiguous content models. I'd accidentally included listObject and model.objectLike (object, listObject) in the content model of listObject and sensibly it pointed out that would be ambiguous. - duplicate xml:id's -- I have (for now) used the same example in the object/listObject and Guidelines prose, and of course the xml:id's were duplicated so I had to go and change them -The most fun error was when I put in a commit message that it was correcting an error. Jenkins sees the word 'error' in its output and assumes this must mean there is an error and so fails the job overall! ;-) Needed: - Suggestions of some other named objects for examples - More and better examples, especially less anglo/western - More prose for the Guidelines - Proofreading corrections - Any problems... Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University

1 0

Re: [Tei-council] Council and Stylesheets Teleconferences
by James Cummings 26 Oct '18

26 Oct '18

Hi all, Between filling out the doodle poll and us deciding the date I've had a commitment that I can't move come up on the evening of 16 November, so will have to miss that meeting. My apologies. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 25 October 2018 15:21:51 To: tei-council(a)lists.tei-c.org Subject: [Tei-council] Council and Stylesheets Teleconferences Dear all, I added the dates for the Council and Stylesheets meetings to our shared google calendar. I hope I did not mix anything up. Council meetings (alternating 3rd Monday 13Z and 3rd Friday 20Z a month) Fri, 16 November 2018, 20Z Mon, 17 December 2018, 13Z Fri, 18 January 2019, 20Z Mon, 18 February 2019, 13Z Fri, 15 March 2019, 20Z Mon, 15 April 2019, 13Z Fri, 17 May 2019, 20Z Mon, 17 June 2019, 13Z Stylesheets meetings (alternating 3rd Monday 13Z and 3rd Friday 20Z a month, opposite of Council meeting) Mon, 19 November 2018, 13Z Fri, 21 Dezember 2018, 20Z Mon, 21 January 2019, 13Z Fri, 15 February 2019, 20Z Mon, 18 March 2019, 13Z Fri, 19 April 2019, 20Z Mon, 20 May 2019, 13Z Fri, 21 June 2019, 20Z Best wishes, Martina

1 0

Re: [Tei-council] Tokyo Per Diem
by James Cummings 26 Oct '18

26 Oct '18

Hi Syd, My recollection was that we used the 70% of the USA rate when in the USA and not externally because the rate often was misjudged outside... but it may be that I was entirely reversed on that recollection. Maybe it was the reverse. I honestly am not sure and haven't found any documentation on it. I've submitted mine already but happy to use whatever Hugh says is right. ;-) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 25 October 2018 18:27:29 To: TEI Council Subject: Re: [Tei-council] Tokyo Per Diem I came at it from a different direction, but get the same result as RV: The US Department of State Meals & Incidentals per diem rate for Tokyo is $227. (RV went to gsa.gov; I went to state.gov.) But I have a recollection that we are supposed to use 70% of that rate,[1] but cannot find documentation which says that, or which gives the division into breakfast, lunch, and dinner. RV, where did you find it? Anyone else know where it is? The documentation at https://wiki.tei-c.org/index.php/Travel_Reimbursement_Procedures_for_Counci… does not include this information. Notes ----- [1] Which would be $158.90, which is still an awful lot of money for one day of eating in Tokyo, at least where we were. Unless I hear otherwise, that's what I'm planning to use. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Council and Stylesheets Teleconferences
by Scholger, Martina (martina.scholger＠uni-graz.at) 26 Oct '18

26 Oct '18

Dear all, I added the dates for the Council and Stylesheets meetings to our shared google calendar. I hope I did not mix anything up. Council meetings (alternating 3rd Monday 13Z and 3rd Friday 20Z a month) Fri, 16 November 2018, 20Z Mon, 17 December 2018, 13Z Fri, 18 January 2019, 20Z Mon, 18 February 2019, 13Z Fri, 15 March 2019, 20Z Mon, 15 April 2019, 13Z Fri, 17 May 2019, 20Z Mon, 17 June 2019, 13Z Stylesheets meetings (alternating 3rd Monday 13Z and 3rd Friday 20Z a month, opposite of Council meeting) Mon, 19 November 2018, 13Z Fri, 21 Dezember 2018, 20Z Mon, 21 January 2019, 13Z Fri, 15 February 2019, 20Z Mon, 18 March 2019, 13Z Fri, 19 April 2019, 20Z Mon, 20 May 2019, 13Z Fri, 21 June 2019, 20Z Best wishes, Martina

2 1

Tokyo Per Diem
by Raffaele Viglianti 25 Oct '18

25 Oct '18

Hi folks, PSA about the per diem in Tokyo: US Dept. of State rate for Meal and Incidental Expense rate in Tokyo is $227 The breakdown (source: https://www.gsa.gov/travel/plan-book/per-diem-rates/fy2018-mie-breakdown#1h ): Breakfast: 34 Lunch: 57 Dinner: 91 Incidentals: 45 (but remember we're supposed to keep this under 20 or submit receipts) Syd (and others), which meals did you pay for the group? We had fewer lunches / dinners together this year IIRC. I covered the okonomiyaki dinner on 2018/09/07 with council members: RV (+1), SS, JC, EBB. Hope everyone had smooth travel back home! Raff

4 6

Reminder: Scheduling Spring F2F
by Scholger, Martina (martina.scholger＠uni-graz.at) 25 Oct '18

25 Oct '18

Dear Council, please fill out the doodle for the Spring F2F meeting in case you haven't done yet: https://doodle.com/poll/yp3uucnqmmiqyc9v Thanks! Best wishes, Martina

1 0

Rep: TEI workshop at Assyriologists conference
by Vanessa Bigot-Juloux 23 Oct '18

23 Oct '18

Dear Martina, Dear colleagues, I had a look at the minutes and saw that Vanessa added an item to the agenda that I missed during the meeting, sorry for that! No worries--I have added it belatedly. Regarding TEI workshop proposal: We haven’t received a call of session yet, so it is just something I would like to suggest to the organizers of this International conference. I think it can be a good opportunity to introduce TEI to neophytes. A suggestion of TEI workshop for Assyriologists which needs to be improved of course: - Morning session, TEI intensive overview based from Assyriological data: * What is TEI? * How TEI can help Assyriologists to improve their research wether it’s for philology, paleography, anthropology or other archaeological purposes (including a practical example with a list of goals for a specific project in order to be used (later during the morning session) to look for the good <elements> and @attributes). * What must a TEI practitioner need to know (TEI, ODD, XPath, XSLT, CSS) and why? * Short pratical examples: TEI (teiCorpus), XPath, XSLT (via Oxygen + preview in a browser). * How to read/use the guidelines (1) (used simultaneously with the practical examples). - Afternoon session: * How to read/use the guidelines (2). * What software to use and where to find assistance regarding this software? * Overview of TEI community and how to use Github in order to ask assistance to TEI community. * First step (suggestion to TEI tech council) to neophyte: TEI online mentoring, who, why and how? As for the morning session, I suggest working on a few practical examples (very short) that participants will send prior to the workshop in order to allow them to have a better idea of how TEI can help them. In addition, on a handout: a list of univ. who propose TEI/Xpath/XSLT training and online course (i.e.: Marjorie and Elena online training). After the sessions, I suggest giving a short questionnaire in order to list the needs of Assyriologists and how we can improve our guidelines/assistance to them. What do you think? Of course it means I’ll need support for this intensive day—from my university (i.e. Peter Stokes if he’s available during summer time) or a TEI tech council colleague (in Europe?). In advance, thanks for your kind advices. Best, Vanessa Le 23 oct. 2018 à 00:07, Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> a écrit : Dear Vanessa and all, I had a look at the minutes and saw that Vanessa added an item to the agenda that I missed during the meeting, sorry for that! It is about the TEI workshop for ancient Near Eastern (ANE) scholars during the international conference of Assyriologists in July (Paris) https://iaassyriology.com/past-rencontres/ Vanessa, is it something that we can discuss via email? Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 2

TEI workshop at Assyriologists conference
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Oct '18

23 Oct '18

Dear Vanessa and all, I had a look at the minutes and saw that Vanessa added an item to the agenda that I missed during the meeting, sorry for that! It is about the TEI workshop for ancient Near Eastern (ANE) scholars during the international conference of Assyriologists in July (Paris) https://iaassyriology.com/past-rencontres/ Vanessa, is it something that we can discuss via email? Best wishes, Martina

1 0

Scheduling Spring F2F
by Scholger, Martina (martina.scholger＠uni-graz.at) 22 Oct '18

22 Oct '18

Dear all, here is our doodle poll for scheduling the Spring F2F meeting: https://doodle.com/poll/yp3uucnqmmiqyc9v Our meeting is supposed to be three days. I hope we will find three days in a row, where everyone has time. Please vote! Best wishes, Martina

1 0

call in 30 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 22 Oct '18

22 Oct '18

Hi all, we start our call in 30 minutes. See the agenda: https://docs.google.com/document/d/1n_Zo-s-PQeMCKwJPmGYbs0F9CMD0VcQe4Vie_Yo… Hangouts: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best, Martina

2 1

open issues
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 Oct '18

19 Oct '18

Dear all, I've put the issues that we skipped last time into the agenda for Monday. Maybe you'll have time to look at one or the other: * https://github.com/TEIC/TEI/issues/1795 - Language of Schematron messages where @role="nonfatal" and @role="warning" * Related: Issue with merging https://github.com/TEIC/TEI/issues/1621 into dev branch--apparently something breaks the Jenkins build--investigating. * https://github.com/TEIC/TEI/issues/1707 : EB: quick update on measurement: Naoki's new sample code based on Tokyo decisions. * https://github.com/TEIC/TEI/issues/1805 - Suggestion for new uniHan element * https://github.com/TEIC/TEI/issues/1756 - event should have ptr and idno in its content model Best wishes, Martina

1 0

Next call: October 22
by Scholger, Martina (martina.scholger＠uni-graz.at) 18 Oct '18

18 Oct '18

Dear all, our next call is on Monday, October 22 from 09:00-10:30 EDT / 14-15:30 BST / 15-16:30 CEST. Please add your topics to the agenda: https://docs.google.com/document/d/1n_Zo-s-PQeMCKwJPmGYbs0F9CMD0VcQe4Vie_Yo… This is the hangouts link: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best wishes, Martina Martina Scholger Zentrum für Informationsmodellierung Austrian Centre for Digital Humanities Universität 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

Re: [Tei-council] thinking about oXygen
by James Cummings 15 Oct '18

15 Oct '18

Hi Peter, I guess that is a more reasoned approach. I'm not against it as a way forward, but if the money isn't too much (we don't know yet and how do we define 'much') and it helps a lot of people (again we don't really know, but certainly suspect it will), then it does seem reasonable. I'd be more concerned if it was taking a lot of time of council members. ;-) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Peter Stadler <pstadler(a)mail.uni-paderborn.de> Sent: 12 October 2018 17:09:45 To: James Cummings Cc: Martin Holmes; Syd Bauman; TEI Council Subject: Re: [Tei-council] thinking about oXygen I’d like to see Alex’ response on how much it would cost and some estimation on how easy it would then be to maintain. I completely agree with Martin that the main motivation is to support older oXygen versions (which is common with our users, AFAIK). Finally, I think that money would be wisely spent, i.e. it shouldn’t be much but plenty of people will benefit (saying this without knowing any statistics …). Best Peter Am 12.10.2018 um 18:02 schrieb James Cummings <James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk>>: I'm increasingly of the opinion that our provision of the oxygen-tei framework is an optional extra and that it should just keep pace with the current version of the TEI and the current release of oXygen. If changes in oXygen mean that older version of it are no longer supported, so be it. I say that as someone who now doesn't have an institutional subscription to oXygen. I'm not saying that is the fairest or best decision for overall impact and outreach, but it might be the easiest in terms of managing our meagre time resources. Willing to be convinced to change my mind though. ;-) James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk<mailto:James.Cummings@newcastle.ac.uk> School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> on behalf of Martin Holmes <mholmes(a)uvic.ca<mailto:mholmes@uvic.ca>> Sent: 12 October 2018 16:20:34 To: s.bauman(a)northeastern.edu<mailto:s.bauman@northeastern.edu>; TEI Council Subject: Re: [Tei-council] thinking about oXygen The ticket Alex raised has all the details: <https://github.com/TEIC/oxygen-tei/issues/27> I don't think I can explain it any better than that. My sense is that we're basically faced with: 1. Abandoning support for older versions of Oxygen in order to provide a fully-working interface with support for all the new features in the Oxygen interface in current versions. 2. Creating special tags for every version of Oxygen in which new features are introduced, and building a separate version of the plugin for each of those tags every time we build, with every build requiring the use of its own version of the oxygen.jar file. I don't like either of these options, frankly. #1 is bad because the only reason for maintaining the plugin at all is that people with older versions of Oxygen can keep their TEI and Stylesheets code up to date. #2 is a potential nightmare from the maintenance and bugfixing point of view. What happens if one particular version fails to build? Do we release all the other versions and not that one, or do we hold them all back till the bug is fixed? But the main problem is that we no longer have anyone with any expertise regarding the Oxygen plugin. A few years ago I taught myself enough about it to write a build file to create the various versions we currently maintain (the stable one, the bleeding-edge one, and the release one). I don't remember enough to feel confident about doing any of this work right now, and I don't have time to re-learn what I used to know (which probably wasn't enough anyway). Really, we need two or three people to take a deep dive into this and take responsibility for it. At the Council meeting, though, I think Magda was tasked with asking Alex if he would do the initial setup for us as a paid job. Cheers, Martin On 2018-10-11 09:29 AM, Syd Bauman wrote: > First, hope Michael didn't beat you up too badly, Sarah. > > Back in late Sep when we did a Stylesheets release we agreed to defer > a release of the oXygen plug-in for a bit. So we probably need to > have a discussion about what we are going to do. > > As a reminder, the results of this summer's survey on oXygen usage > is: > > | count majorVersion > | ----- ------------ > | 12 17 > | 6 18 > | 2 16 > | 2 14 > | 1 20 > | 1 15 > | 1 19 > > And of the 5 people using versions 16 or older, 2 or 3 of 'em hope we > continue to support the older version. > > Could Martin or James or someone else who understands this better > than I do kick off the discussion with a summary of the problem(s)? > _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

Re: [Tei-council] thinking about oXygen
by James Cummings 12 Oct '18

12 Oct '18

I'm increasingly of the opinion that our provision of the oxygen-tei framework is an optional extra and that it should just keep pace with the current version of the TEI and the current release of oXygen. If changes in oXygen mean that older version of it are no longer supported, so be it. I say that as someone who now doesn't have an institutional subscription to oXygen. I'm not saying that is the fairest or best decision for overall impact and outreach, but it might be the easiest in terms of managing our meagre time resources. Willing to be convinced to change my mind though. ;-) James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Martin Holmes <mholmes(a)uvic.ca> Sent: 12 October 2018 16:20:34 To: s.bauman(a)northeastern.edu; TEI Council Subject: Re: [Tei-council] thinking about oXygen The ticket Alex raised has all the details: <https://github.com/TEIC/oxygen-tei/issues/27> I don't think I can explain it any better than that. My sense is that we're basically faced with: 1. Abandoning support for older versions of Oxygen in order to provide a fully-working interface with support for all the new features in the Oxygen interface in current versions. 2. Creating special tags for every version of Oxygen in which new features are introduced, and building a separate version of the plugin for each of those tags every time we build, with every build requiring the use of its own version of the oxygen.jar file. I don't like either of these options, frankly. #1 is bad because the only reason for maintaining the plugin at all is that people with older versions of Oxygen can keep their TEI and Stylesheets code up to date. #2 is a potential nightmare from the maintenance and bugfixing point of view. What happens if one particular version fails to build? Do we release all the other versions and not that one, or do we hold them all back till the bug is fixed? But the main problem is that we no longer have anyone with any expertise regarding the Oxygen plugin. A few years ago I taught myself enough about it to write a build file to create the various versions we currently maintain (the stable one, the bleeding-edge one, and the release one). I don't remember enough to feel confident about doing any of this work right now, and I don't have time to re-learn what I used to know (which probably wasn't enough anyway). Really, we need two or three people to take a deep dive into this and take responsibility for it. At the Council meeting, though, I think Magda was tasked with asking Alex if he would do the initial setup for us as a paid job. Cheers, Martin On 2018-10-11 09:29 AM, Syd Bauman wrote: > First, hope Michael didn't beat you up too badly, Sarah. > > Back in late Sep when we did a Stylesheets release we agreed to defer > a release of the oXygen plug-in for a bit. So we probably need to > have a discussion about what we are going to do. > > As a reminder, the results of this summer's survey on oXygen usage > is: > > | count majorVersion > | ----- ------------ > | 12 17 > | 6 18 > | 2 16 > | 2 14 > | 1 20 > | 1 15 > | 1 19 > > And of the 5 people using versions 16 or older, 2 or 3 of 'em hope we > continue to support the older version. > > Could Martin or James or someone else who understands this better > than I do kick off the discussion with a summary of the problem(s)? > _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

2 1

thinking about oXygen
by Syd Bauman 12 Oct '18

12 Oct '18

First, hope Michael didn't beat you up too badly, Sarah. Back in late Sep when we did a Stylesheets release we agreed to defer a release of the oXygen plug-in for a bit. So we probably need to have a discussion about what we are going to do. As a reminder, the results of this summer's survey on oXygen usage is: | count majorVersion | ----- ------------ | 12 17 | 6 18 | 2 16 | 2 14 | 1 20 | 1 15 | 1 19 And of the 5 people using versions 16 or older, 2 or 3 of 'em hope we continue to support the older version. Could Martin or James or someone else who understands this better than I do kick off the discussion with a summary of the problem(s)?

2 1

Next call: October 22
by Scholger, Martina (martina.scholger＠uni-graz.at) 12 Oct '18

12 Oct '18

Dear all, the best option for our next call is Monday, October 22 from 9:00-10:30 EDT, 14-15:30 BST, 15-16:30 CEST. This is the link to the agenda, please add your topics: https://docs.google.com/document/d/1n_Zo-s-PQeMCKwJPmGYbs0F9CMD0VcQe4Vie_Yo… Elli, please let me know if you can start the call. Best wishes, Martina

2 2

Re: [Tei-council] Spring F2F meeting
by James Cummings 12 Oct '18

12 Oct '18

Apologies for the delay in responding. To confirm, I'd be willing to host a council meeting here in Newcastle. I could also do so in future years if that was preferable. Venues: There are two possible venues: A) One is the city centre campus, for which I could find one or more meeting rooms, downtown has plenty of hotels, airbnb, restaurants and that sort of thing. B) The other possible venue would be about 9 miles out of the city centre (direct metro line) in either a hotel conference room (at charge) or the Dove Marine Laboratory. This is a research institution in a victorian building right on the beach in Cullercoats bay https://goo.gl/maps/cJLSCEX8jHS2, a short walk south is Tynemouth (lots of trendy restaurants, cafes, lovely ruined medieval priory). I've been to university workshops at the Dove and will investigate the rules for booking it. No idea if it is free then. There is also a 'Premier Inn' hotel with conference rooms in Whitley Bay right next to the iconic recently refurbished Spanish City building (mentioned in a Dire Straits song if you are into such trivia). Travel: Newcastle Airport is connected to the city by a quick, fairly inexpensive and frequent metro system (that goes out to the coast and covers the whole metropolis area between Newcastle, the coast, and Sunderland.) Newcastle Airport is usually 1 hop to most major interchanges (via Heathrow, Schiphol, etc.) Dates: As we're really far North (literally, Hadrian's wall used to run through Newcastle), then later is better in terms of weather. In terms of the university calendar the Easter Break is from Friday 29 March to Monday 29 April. Good Friday is 19 April, Easter Monday: 22 April. I only mention it because these are probably not good days to travel or find open restaurants for large groups. I'm busy in the week 1-5 April doing a TEI workshop. This actually presents an opportunity where we might have budget to help with the travel for 1 (or 2 max) council members if they were also teaching on that workshop. This would mean maybe having it sometime in 6 - 12 April. According to weather.com historically that is like 9-10C/48-50F around that time of year (and windy on the coast). Some random videos: University promotional ones https://www.youtube.com/watch?v=E3jR3NvU-TY https://www.youtube.com/watch?v=htlYW8RppWA https://www.youtube.com/watch?v=Okf1pmDkem8 Cullercoats bay with Dove Marine Laboratory in the middle, boring drone footage https://www.youtube.com/watch?v=9BKf4hZNWRM Whitley Bay and Tynemouth, better drone footage https://www.youtube.com/watch?v=Hn5nx6VIAhw Spanish City (during refurb) boring drone footage: <https://www.youtube.com/watch?v=K4dHu_t9ETM>https://www.youtube.com/watch?v=CxHW3j83IDY Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Mylonas, Elli <elli_mylonas(a)brown.edu> Sent: 03 October 2018 23:23:52 To: TEI Council Subject: Re: [Tei-council] Spring F2F meeting I can host at Brown most of the spring term. Some better and some blackout dates: When students aren't here: Long weekend Feb 16-19 Spring break Mar 23-31 NOT POSSIBLE - April 4-5 best, --elli On Wed, Oct 3, 2018 at 4:05 PM Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> wrote: Dear all, picking up on the minutes from our last call I would ask everyone who offered to host the next Spring F2F meeting to confirm their willingness to do so and to set out the possibilities in terms of place and date before our next call. We should figure out what is feasible as soon as possible. We have offers from: Elli at Brown University in Providence James at Newcastle University Magdalena in Warsaw Raff at Folger Library in Washington D.C. Best wishes, Martina _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

6 6

Re: [Tei-council] oxgarage missing
by Peter Stadler 09 Oct '18

09 Oct '18

Hi Ian thanks for your immediate reaction! If I recall correctly, we regularly had some memory issues with OxGarage, thus restarting it every(?) night via a cron job. I don’t think that’s necessary, but we could improve it in a more docker-like way by adding a health check to the Dockerfile. Do you have some monitoring software which could read that information and restart the container if necessary? Best Peter > Am 04.10.2018 um 00:51 schrieb Ian Rifkin <irifkin(a)brandeis.edu>: > > Hi, > > Java heap memory issues in the log file. I restart the oxgarage docker and it seems to be back up and running. Peter, let me know if you think it was a fluke or if something needs to be adjusted. > > Thanks, > Ian > > On Wed, Oct 3, 2018 at 6:21 PM Peter Stadler <stadler(a)edirom.de> wrote: > Hi Nick, > > I can confirm that I’m unable to connect to oxgarage.tei-c.org, as well. > Seems to be a server issue and probably needs a restart of the service (which I can’t do, sadly) … > In the meantime, please use oxgarage2.tei-c.org. > > Thanks for reporting! > Peter > > >> Am 03.10.2018 um 21:42 schrieb Nick Thieberger <thien(a)UNIMELB.EDU.AU>: >> >> I'm getting '504 Gateway Time-out' on ox-garage, is there any update on its availability please? >> >> Thanks, >> Nick >> >> On Tue, 26 Jun 2018 at 01:43, Hugh Cayless <philomousos(a)gmail.com> wrote: >> I haven't heard anything about it yet, but it looks like OxGarage and Roma are back. >> >> Hugh >> >> On Mon, Jun 25, 2018 at 7:28 AM Hugh Cayless <philomousos(a)gmail.com> wrote: >> It looks to me like the site has been switched over to the new version that's been waiting in the wings for a while, but that none of the configuration for handling the Tools section has been set up. The good news is that OxGarage is still running, it's just temporarily inaccessible. I've emailed our sysadmin. I'm afraid I don't have the necessary permissions to actually fix (or even see) the web server configuration. >> >> Hugh >> >> On Mon, Jun 25, 2018 at 6:22 AM Toma Tasovac <ttasovac(a)humanistika.org> wrote: >> Hi, >> >> what happened to OxGarage? >> >> http://www.tei-c.org/oxgarage/ (which is the link given in the Tools dropdown menu) gives oops that page can't be found >> >> All best, >> Toma >> -- >> Belgrade Center for Digital Humanities >> http://humanistika.org >> > > > > -- > Ian Rifkin '04, MS '09 > Director of Data and Systems Integration > Brandeis University, Information Technology Services (ITS) > Email: irifkin(a)brandeis.edu | Phone: (781) 736-4216 | Fax: (781) 736-4577 > Learn more about our campus move to Workday

2 2

Monthly call
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Oct '18

09 Oct '18

Dear all, we still need to find a solution for our monthly call. Unfortunately there is no slot that suits all of us. I had again a closer look at our "best" options with 9 or 10 "yes/if need be" answers. This is it (initials in brackets indicate those members who voted "no, I can't make it"): Mon 13Z (VB, EB) Tue 19Z (MT, EB); 20Z (MT, HC); 21Z (MT, HC) Fri 19Z (MT, EB); 20Z (MT); 21Z (MT, HC) Narrowing this down to the smallest overlap of people who can't make it, Mon 13Z and Fri 20Z are remaining. Therefore, I suggest to alternate every month between Monday and Friday in order to enable everyone to at least attend once every second month. I created another doodle poll with dates in the 3rd and 4th week of October to set a starting date. Please vote! https://doodle.com/poll/vwdvmm67xztq4csk (I hope you can see it in your time zone) I am aware that this is hardly an ideal solution, but I don't see another option yet. Best wishes, Martina

2 1

Monthly call
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Oct '18

09 Oct '18

Dear all, looking at the doodle I am somewhat at a loss. There is no single date and time where everyone on the Council is available. The "best" we could do is Friday at 20:00Z, but Magdalena would not be able to join and three people would rather not. The next best would be Friday at 19:00Z, but with two people missing. I don't think that we should schedule a regular date where we already know that at least one person will not be able to make it. I would ask everyone to have one more look at the doodle and consider if you can possibly make more choices. Keep in mind that we are meeting just once a month. https://doodle.com/poll/kk9hsr6z9csxhkub If we can't find a common date that way, would it make a difference if the call would be just 60 instead of 90 minutes? Are there other suggestions to solve our dilemma? Best wishes, Martina

2 3

Travis ne Jenkins ne local
by Syd Bauman 05 Oct '18

05 Oct '18

The dev branch now has all the deprecations valid until 2018-10-01 removed, and its build working ala Travis. However, said build is not working in Jenkins (on either jenkins or jenkins2 -- for some reason the former does not have parsed console output, but it is the same error), and is working on my local system, after a fashion. The error on Jenkins, however, is completely mysterious. It has *nothing* to do with anything that I am aware of having changed. The ONVDL validation of Exemplars/tei_enrich.odd against Exemplars/tei_enrich.nvdl is failing with error: bad value for attribute "columns" where the value for @columns is "1", and thus is perfectly fine. I can, with some effort, reproduce this error on my local system. All of the @columns attrs in tei_enrich.odd are on elements in the teix: namespace, i.e. within <egXML>. I am pretty sure the only schema tei_enrich.nvdl runs against that namespace is tei_enrich-examples.rng. And lo and behold, when I look at that schema the definition of @columns of <layout> is obviously screwball: | <attribute name="columns"> | <a:documentation xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0">specifies | the number of columns per page</a:documentation> | <list> | <rng:empty xmlns:rng="http://relaxng.org/ns/structure/1.0"/> | </list> | </attribute> I poked around and found that the tei_enrich.odd file changes the definition of <layout> a teeny bit: | <elementSpec ident="layout" mode="change" module="msdescription"> | <attList> | <attDef ident="columns" mode="change" usage="req"/> | </attList> | </elementSpec> But that specification is in a paragraph of prose that essentially negates it: | <p>Note that if (as in the last example above) no value is given for | the <att>columns</att> attribute, the assumption is that there is a | single column of writing on each page. (And is incorrect, in that the prior example does have a value for layout/@columns.) So I claim that a) This is a Stylesheets issue. Somehow changing @columns to required has nuked its datatype, which is supposed to be ( data.count, data.count? ) b) The Enrich ODD has other problems, too I'm too tired now to do much more on this tonight.

4 5

cannot build
by Lou Burnard 04 Oct '18

04 Oct '18

I updated Stylesheets, and pulled the latest P5 sources, and ran "make clean; make" Everything worked up to the point where the "special purpose" validity checks began. At that point I got a shed load of annoying errors, starting with BUILD: Check validity with special-purpose XSL code, looking for bad links etc ANT_OPTS="-Xss2m -Xmx752m -Djava.awt.headless=true" ant -q -lib Utilities/lib/saxon9he.jar -f antbuilder.xml -DXSL=/usr/share/xml/tei/stylesheet validators [echo] Run Schematron script (normal part of Guidelines) [echo] Run Schematron script (Examples in Guidelines marked as valid) [echo] Run ad hoc XSLT validators BUILD SUCCESSFUL Total time: 27 seconds <Messages> <ERROR>Schematron error: The data.certaintyconstruct is outdated (as of 2018-10-01); ODD processors may ignore it, and its use is no longer supported [Test: @validUntil cast as xs:date ge current-date()] Location: /TEI[1]/text[1]/body[1]/div[1]/div[6]/macroSpec[1]</ERROR> <WARNING>Schematron warning: The data.certainty construct becomes outdated on 2018-10-01 [Test: @validUntil cast as xs:date ge $advance_warning_period] Location: /TEI[1]/text[1]/body[1]/div[1]/div[6]/macroSpec[1]</WARNING> [and so on for a few screens, concluding with] <WARNING>Schematron warning: The macro.anyXML construct becomes outdated on 2018-06-12 [Test: @validUntil cast as xs:date ge (current-date() + (60*xs:dayTimeDuration('P1D')))] Location: /TEI[1]/text[1]/body[1]/div[1]/div[4]/div[1]/specGrp[1]/macroSpec[7]</WARNING> > <ERROR>Schematron error: > Error: both the versionDate and xml:lang attributes on "remarks" are required when it is a child of "attDef". > [Test: not( @xml:lang and @versionDate )] Location: /TEI[1]/text[1]/body[1]/div[22]/div[3]/specGrp[1]/elementSpec[4]/attList[1]/attDef[1]/remarks[1]</ERROR> Makefile:185: recipe for target 'valid' failed make: *** [valid] Error 1 lou@foxglove:~/Public/TEI/P5$ Tell me, what have I done to deserve this?

3 6

Spring F2F meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Oct '18

04 Oct '18

Dear all, picking up on the minutes from our last call I would ask everyone who offered to host the next Spring F2F meeting to confirm their willingness to do so and to set out the possibilities in terms of place and date before our next call. We should figure out what is feasible as soon as possible. We have offers from: Elli at Brown University in Providence James at Newcastle University Magdalena in Warsaw Raff at Folger Library in Washington D.C. Best wishes, Martina

2 1

Re: [Tei-council] Stylesheets v7.46.0 released
by James Cummings 03 Oct '18

03 Oct '18

re: council responsibility. Council responsibility for stylesheets is for those that we use to generate the website and those that we use to process ODDs. Everything else is optional but nice for the community (IMHO) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Raffaele Viglianti <raffaeleviglianti(a)gmail.com> Sent: 02 October 2018 15:35:45 To: Peter Stadler Cc: tei-council(a)lists.tei-c.org; Martin Holmes Subject: Re: [Tei-council] Stylesheets v7.46.0 released I added a couple paragraphs to the document, let me know what you think. This conversation we're having echos the worry I expressed in my first email: > I don't know if stylesheets releases need to be announced on TEI-L, especially since we don't assemble a document listing changes besides a generated changelog. Perhaps the paragraph I added are enough, but it's easy to go down a rabbit hole. The Stylesheets are important, but it's still unclear how much of a responsibility council has towards them since our primary goal is maintaining and improving the TEI Guidelines. All best, Raff On Tue, Oct 2, 2018 at 8:18 AM Peter Stadler <stadler(a)edirom.de<mailto:stadler@edirom.de>> wrote: I agree that the current draft is not very helpful except for saying "there is a new release“. We should add a) the main motivation. It is unusual that we are doing a Stylesheets release out of sync with the Guidelines. AFAIK, the main motivation is Raff’s work on RomaJS and his need for p5subset.json, leading to various changes to odd2json.xsl in the Stylesheets repo. That need to be mentioned. @raff: could you elaborate a little bit on those changes? what’s different now in the resulting p5subset.json? (and what’s the difference to p5subset.js?) b) nothing more. The rest is indeed technical stuff and won’t improve any research. Best Peter > Am 02.10.2018 um 13:01 schrieb Vanessa Bigot-Juloux <vanessa.bigot-juloux(a)ephe.psl.eu<mailto:vanessa.bigot-juloux@ephe.psl.eu>>: > > Dear all, > > I have added a comment on the doc two days ago. However, it needs further explanations: > I have looked to TEI council profiles; from what I understood, you have a lot of knowledge in encoding, more than a lot of digital practitioners who use TEI (and other encoding languages needed to work with TEI) mostly for their investigation in a text/corpus/artefact. This is my case: I use TEI and other languages because I need these tools for investigating my corpus. By saying this, I have not the same background/knowledge (and goal) than most of you. Thus, if you agree, my first remarks will rather be (at least for now) to make sure than beginners or digital practitioners (but no experts in programming languages) will be able to understand not only encoding but also how it can help them to improve their research. In addition, I think we need to take advantage of each opportunity for doing a little pedagogy and the Stylesheets released is a good opportunity. > When you did the release of the Guidelines http://www.tei-c.org/release/doc/tei-p5-doc/readme-3.1.0.html (thanks James), you tried to give a few helpful information—although we can always be improved. > As for this Stylesheets release, I think we need to give further information regarding the issues resolved--not for all topics since a few of them will not be as much interest for beginners or average level. For example, something like: > “Among other issues resolved in the last stylesheets v7.46.0 released: > - In order to avoid a schematron [link] processor (in other words rule-based validation language) error regarding @ageAtDeath [link], rather used teidata.count [link] attribute group instead of teidana.numeric [link] (https://github.com/TEIC/Stylesheets/issues/322)”--I don’t know if it was updated on TEI website, but if this is the case, also add the TEI link updated. > - …” > > However, we need to ask ourselves the following question: how the issues resolved can be helpful to beginner and average level practitioners, in order to choose the issues which need more information. > Lastly, I’m not convince all readers will understand what is “stylesheets released.” —maybe under bracket something like “improvements according to issues resolved.” > > I suggest that the message has two sections: one for experts and one for beginners and average levels practitioners. > > Hope my explanation is clear enough… and that I’m not getting wrong in TEI council goals. > > Best, > Vanessa > > >> Le 30 sept. 2018 à 17:19, Scholger, Martina (martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>) <martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>> a écrit : >> >> Ah, thanks. Changed the milestone to 7.46 in Github. >> >> Best, Martina >> >> -----Ursprüngliche Nachricht----- >> Von: Tei-council <tei-council-bounces(a)lists.tei-c.org<mailto:tei-council-bounces@lists.tei-c.org>> Im Auftrag von Syd Bauman >> Gesendet: Samstag, 29. September 2018 21:56 >> An: tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org>; Martin Holmes <mholmes(a)uvic.ca<mailto:mholmes@uvic.ca>> >> Betreff: Re: [Tei-council] Stylesheets v7.46.0 released >> >> Sorry, hit "send" before I was even done writing, let alone editing, that. >> >> Martina -- I don't know if you created a 7.45, 7.46, or 7.47 milestone. You may need to tweak the GiHub milestones or the e-mail to fit. >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> _______________________________________________ >> Tei-council mailing list >> Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > _______________________________________________ > Tei-council mailing list > Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> > http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council

3 2

Adding or Editing an Appendix - TCW20
by Scholger, Martina (martina.scholger＠uni-graz.at) 03 Oct '18

03 Oct '18

Dear all, Martin asked me to forward a message: "I've added a section to TCW20 on how to add or edit appendices to the Guidelines, since Syd and I have just been figuring out how that works for issue #1657: <http://teic.github.io/TCW/tcw20.html#appendices>" Thanks Martin for adding this! Best wishes, Martina

1 0

Re: [Tei-council] TCW 20 Revision on Branch Practice?
by James Cummings 03 Oct '18

03 Oct '18

I'd say that not all tickets are Guidelines related (e.g. we have a label for TEI:Website and another for TEI:Build Process), so perfectly reasonable to have a ticket as a place for conversation about this that we might return to in the future. That is assuming that this is something that might have several iterations, tests, decision about which is the best way, etc. If it is a straightforward "Let's test this, oh look, it works now let's document that." then maybe a ticket is not needed. My two pence, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Elisa Beshero-Bondar <ebb8(a)pitt.edu> Sent: 03 October 2018 12:10:28 To: TEI Council Subject: Re: [Tei-council] TCW 20 Revision on Branch Practice? PS: Should I open that as a ticket? Since it's not specifically Guidelines-related, I'm not sure...figured I'd sound us out here first. Thanks, Elisa On Wed, Oct 3, 2018 at 7:08 AM Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com>> wrote: Dear Council, I was just re-reading TCW 20 to remind myself what we advise each other on working in feature branches, and how to update them. You may remember some excitement during our Tokyo face-to-face as I first nearly bungled a branch merge and then we fixed it. This was, I think, a bit too much excitement, and lots of us do work in branches. When it comes time to update them and/or merge them back into dev, we don't always know exactly what to do, and just relying on looking stuff up is, as we saw, a little brittle and error prone. We are pretty confident we can fix anything that goes wrong, but perhaps we can minimize the excitement with a little more guidance to our future selves. So, I'm writing this to propose some revision to this portion of TCW 20: "If you are working on a particularly complex change involving multiple files, it may be better to create a branch in which to work on your changes, and then to merge the branch when you are confident that the work is successfully completed. See any guide to git for instructions on how to approach that. Bear in mind that our Jenkins servers only build the dev branch, so you cannot depend on them to test-build your working branch." I'd like to propose rewriting that with some more detailed steps on our TEI Technical Council preferred process for reconciling branches with dev, to help prevent future excitement. :-) I've been reading about the "best" ways to keep branches updated, and the differences, for example, between rebase and merge for keeping a branch tip updated. Rebasing is pretty dangerous in that it "rewrites history" by resequencing commits, so I am not sure we ever want to use it for updating a branch from dev, before merging it back. Do we want to always advise, then, to update a branch by merging it with dev? I'm not 100% certain of that either. What I'd like to do is (very careful) test a few approaches and work with you all to try to plot out an excitement-proof set of safe guidelines for Council members on Best Practices for Working in Branches as part of TCW 20. What say you all? 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<mailto:ebb8@pitt.edu> -- 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<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/>

4 3