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
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
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
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
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/>
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
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
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
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
(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
