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

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