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

Agenda for F2F
by Hugh Cayless 27 May '15

27 May '15

Hi all, I’m putting together a draft agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-05 <http://wiki.tei-c.org/index.php/Council_Agenda_2015-05>. Items for discussion are to be found in the Minutes Google Doc at https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql… Please add any additional business items you have to that list. I’ll be working more on it and the agenda today and tomorrow. Martin had proposed talking about how to build the Oxygen plugin. Do we have any other possible technical talks? Anything for TEI Simple or Pure ODD, for example? Looking forward to seeing you on Thursday! Hugh

2 1

UVic Jenkins temporarily down
by Martin Holmes 27 May '15

27 May '15

Just for info: the UVic Jenkins machine is currently down because it's being cloned to create a new Jenkins build server for other projects. Should be up again soon. Cheers, Martin

1 0

Release of the Oxygen plugin
by Martin Holmes 26 May '15

26 May '15

Hi all, After some more testing with Ron, I've just released a new version of the Oxygen plugin, incorporating the latest Stylesheets release (7.35.0) and some changes to the plugin codebase that we had had to back out of before Oxygen 17 was released because they depended on Stylesheets changes which hadn't been released at that point. If you're subscribed to this version of the plugin, please let me know if you see any problems. One of the confusing issues I'll talk about when I do my little show-and-tell on the Oxygen plugin in Michigan will be version numbers. Right now, the plugin filename is derived from the P5 and Stylesheets versions incorporated in it: teioxygen-2.8.0-7.35.0.zip = P5 2.8.0 and Stylesheets 7.35.0. However, there also has to be a true version number for the plugin, which is inserted into the updateSite.oxygen XML file that handles the plugin updates for users. Oxygen's system only allows a version number consisting of three dotted digits: 1.2.3 Our practice up to now has been to name the plugin release after the P5 release on which it's based, so this would be: 2.8.0 but because the last one was already 2.8.0, I've had to increment it: 2.8.1 If we now go ahead and release a minor P5 update, which would be 2.8.1, we would confusingly have to increment the plugin version number to 2.8.2. So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based: 3.280.7350 This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based. Any see any problem with this? We could make the change at the same time that we switch the file naming from teioxygen to oxygen-tei, as we've discussed before. Cheers, Martin

7 14

Building (e.g. TEI All schema)
by Hugh Cayless 26 May '15

26 May '15

Can someone explain to me like I’m an idiot how to use the Stylesheets to generate, say, a TEI All schema using the Guidelines specs? I’m afraid the documentation doesn’t give me enough to go on. I thought I understood it, but I don’t. My understanding is that you use the transformtei script, but what inputs do you give it? Thanks, Hugh

6 12

Re: [tei-council] ROMA does not work
by Martin Holmes 26 May '15

26 May '15

Once the build process has gone through on Jenkins successfully, I'll test my new oxygen-tei plugin build script by doing "ant release" to see what happens. :-) Cheers, Martin On 15-05-26 09:09 AM, Sebastian Rahtz wrote: > Roma should be working again now. I made a new Stylesheets release and deployed it around. > > Many apologies for that. > > Sebastian Rahtz > Chief Data Architect > University of Oxford IT Services > +44 1865 283431 >

1 0

bad date example
by Syd Bauman 26 May '15

26 May '15

We have a single example (used twice with slight differences) that shows use of dating attributes in a way I think may be inappropriate: <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> I don't like the combination of @from and @notAfter. As I understand (or at least imagine) it: @from and @to: indicate a range of dates during which something happened -- the thing happens during the entire range. <persName from="1940-10-09" to="1969-04-21">Lennon, John Winston</> <persName from="1969-04-22" to="1980-12-08">Lennon, John Winston Ono</> or <occupation from="1991" to="1994">Provost, Duke University</> For the *entire period* from 09 Oct 40 to 21 Apr 69 his name was "John Winston Lennon", and for the *entire period* from the day he legally changed his name (22 Apr 69) to his death (08 Dec 80) his name was "John Winston Ono Lennon". Similarly, Tommy Langford was Provost from 1991 to 1994. We don't know what day he became Provost or what day he stepped down, so the values of @from and @to are given only to year precision. Fair enough. (If we knew more, we could provide more precision.) @notBefore and @notAfter: indicate the earliest and latest endpoints for a single event to have occurred. Typically, but not at all necessarily, that event is measured in the precision of a single day. E.g. <death notBefore="1831" notAfter="1840"/> indicates that Mary Clarke [nee Carr] died sometime between those dates. She died on one day[1] during those days, she did not spend all 9 years in the throes of death. I think these notions of @from and @to indicating a *duration* during which something happened continuously, and @notBefore and @notAfter indicating endpoints within which range something happened at a given point, is borne out by the definitions in the tagdocs: - notBefore: specifies the earliest possible date for the event - notAfter: specifies the latest possible date for the event - from: indicates the starting point of the period - to: indicates the ending point of the period Thus my unease with the example <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> To me, the @from indicates that she lived there for a 1-2 month long period starting 01 March; but the @notAfter (at least, taken alone) implies that she lived there for one day[2] some day before 01 May. So I'm sure I don't like this, although I'm not sure how to solve the problem, i.e. how this information should be indicated. Possibilities include: * State explicitly in the prose what @from & @notAfter or @notBefore & @to mean. (To wit, an entire duration of vague length, specified by one endpoint and a point over which the duration did not extend.) * Indicate the duration with a start point and a duration, then indicate the (lack of) precision of the duration: <residence xml:id="R" from="1857-03-01" dur="P46D"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@dur" atLeast="31" atMost="61"/> Don't like this as it sits, because it only works because we presume the unit @atLeast & @atMost refer to is days. Makes sense for this case, but if the dur= were "P1M15D" it would be less obvious. I presume if it were "P1.5M", one would have to use atLeast=1 atMost=2; i.e. the precision attrs apply to the lowest order component. So I guess we could make this work by making that the rule. * Fix <precision> so that it allows representation of precision (meaning the unit or number of significant digits to which a value may be measured reliably) rather than just precision (meaning vaguely how exact or accurate). Then <residence xml:id="R" from="1857-03-01" to="1857-04-15"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@to" dur="P15D"/> or whatever. * Create new attributes (egads!) to mean exactly what we want. E.g., @fromAfter and @toBefore. * Don't fix it. Caveat encoder. People tend to know what you mean. Besides, what possible automated processing will handle this stuff? Notes ----- [1] Actually one second, but let's not go nuts. [2] Or only one second, but let's not go nuts.

5 8

agenda item / bug
by Syd Bauman 26 May '15

26 May '15

Julia just reminded me that <event> still is not allowed as a child or grandchild of <org>. Off the top of my head, I don't see why <listEvent> is not a member of model.orgPart. Not quite so obvious how to make <event> an eligible direct child of <org>, but it seems like a reasonable request. I plan to submit a bug report shortly, with hopes that we can tackle this and solve it for next release. (Although I have my suspicions that this will bring up other thorny issues.)

3 3

Transcription of spoken language draft
by Martin Holmes 21 May '15

21 May '15

Hi all, I was just following up with Thomas Schmidt on this ticket: <http://sourceforge.net/p/tei/feature-requests/511/> which is one of at least two relating to the ISO/TEI spoken language proposal, and he's sent me a draft dated April 27, which is later than the last one mentioned on Lou's ticket: <http://sourceforge.net/p/tei/feature-requests/539/> He's still not happy with this being posted publicly, so we need a method of distributing it which is not public. The simplest thing would perhaps be to wait until the FtF and then just email it around. Does that work, or should be devise a password-protected location for it? Cheers, Martin

3 4

duplicate @rend error in generated RNG schema
by James Cummings 20 May '15

20 May '15

I was just bitten by the side effect of moving @rend to att.global.rendition. In taking an old and perfectly fine TEI ODD, and generating a fresh schema from it, the RNG was invalid because of a duplicate definition of @rend. Changing it so that I modified @rend on att.global.rendition rather than att.global solved this. Took me a good 10 minutes staring at it to realise what was wrong. doh. I'm just mentioning it to put it in the back of your brain in case anyone asks in the future. -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

3 4

May F2F. Hotel information.
by Paul Schaffner 11 May '15

11 May '15

I have received the attached confirmation from the hotel, listing Council members and their intended arrival and departure dates. I would appreciate it if you could check to make sure yours is correct. As for payment, I am told that the library entered an "accounting nightmare" the last time they tried to pay for everyone as a package deal. Is everyone willing to pay their own bill and ask for TEI reimbursement? If not, I could conceivably pay for everyone personally in advance, and then ask TEI to reimburse. But that would be quite a lot to put on my personal credit card. pfs -- Paul Schaffner Digital Library Production Service PFSchaffner(a)umich.edu | http://www.umich.edu/~pfs/

10 17

Notes on standoff
by Hugh Cayless 08 May '15

08 May '15

I’m finally getting a chance to look seriously at the standoff ODD and so I wanted to pull together my own notes and get some discussion going here that we can feed back to the proposers. 1) Why such an elaborate header? (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>) I can understand wanting to have some description of the content of <stdf> (or <ldb> as Syd proposed—I happen to like that better), but this seems maybe a bit overboard. Why can’t the document’s own revisionDesc serve to document revisions to the standoff section, for example? 2) Since standoff elements can nest, why do we need the <annotations> element? (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>). Wouldn’t it be simpler to allow the standoff element just to contain a heading and its content, optionally including more standoff elements? 3) I can sort of guess what <mapStruct> might be for, but it isn’t very clear (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>). Do we not already have sufficient mechanisms for attaching standoff markup to its targets? That’s all I’ve got for now. What do you think? We’re going to beam Laurent in for a discussion at the F2F on Friday the 29th at 10:00.

3 5

Problems with the UVic Jenkins server
by Martin Holmes 05 May '15

05 May '15

Hi all, Just a heads-up that a router update early this morning screwed up a bunch of our virtual machines when their filesystems became inaccessible; and then on restarting, an old obsolete machine was substituted accidentally for our current Jenkins server, and the latter may have been lost completely. Don't ask how such a thing could happen. Anyway, it means we may not have a UVic Jenkins for a while (I'm leaving town for a conference tomorrow morning). The Oxford Jenkins, meanwhile, has run out of disk space. :-( This may mean that I end up doing something I was hoping to put off till the summer: writing the new Jenkins build script and testing it. But that's hard to do on a crappy old laptop that can't run VMs, so it'll have to wait till I get back next week. There's a chance Systems can salvage our Jenkins, though. Keep your fingers crossed. Cheers, Martin

3 3

Fall F2F Dates
by Hugh Cayless 29 Apr '15

29 Apr '15

Hi All, Emmanuelle Morlock asks if we can nail down dates for the Fall F2F ASAP so that she can reserve rooms. Workshop dates may fall on Oct. 26, 27, or the morning of the 28th. There will probably be an EpiDoc one that I may need to help run. Options I see are: 1. Meeting on Sunday (25th) and Monday (26th) 2. Meeting the weekend before the conference (24th–25th) 3. Meeting concurrently with the workshops, and have some council members drop out for some of the time to deal with their workshops 4. Don't do any workshops 5. Don't meet before the conference. So what do you think? Is anyone else proposing a workshop?

7 9

updated framework not used in conversion
by Lou Burnard 29 Apr '15

29 Apr '15

I'm puzzled... I have installed all the recent updates to the TEI framework from the TEI site, and my local .com.oxygen.xml directory contains an updated version of one of the XSLT scripts provided as a result: -rw-rw-r-- 1 lou lou 13520 Apr 29 12:02 ./.com.oxygenxml/extensions/v16.1/frameworks/http___www.tei_c.org_release_oxygen_updateSite.oxygen/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl However, when I actually run the conversion from within oXygen, it does not use this version, but instead the one released ages ago, which is still in the installation directory: -rw-r--r-- 1 lou lou 9612 Jan 22 13:43 ./OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl The Ant script I am running in my transformation says "Loading stylesheet /home/lou/OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/docx/from.xsl" It also uses the build-from.xml file from the same directory, rather than the one one in the .com.oxygml tree, which is however identical. But since it uses relative paths, maybe that is the problem? Any advice much appreciated...

2 3

Teleconference April 24
by Hugh Cayless 24 Apr '15

24 Apr '15

Hi All, We have a telecon scheduled for next Friday, April 24th. Any chance we can push it back to 06:00 PDT / 09:00 EDT / 14:00 BST / 15:00 CEST? I have a conflict at 8:30 due to my own carelessness. We could make this change permanent in fact, if no-one objects. It would mean Martin doesn't have to get up so brutally early. I no longer have a conflict at 10:00 every Friday, so we could push it later. We're (as previously decided) going to attempt to do this in a Google Hangout. I will send an invite to the list a few minutes before start time. I've started an agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-04 to which you should feel free to add items for discussion. I've got a couple more to put in myself. May's telecon will obviously be canceled because we'll be in Ann Arbor. Thanks, Hugh

12 19

Oxygen release
by Martin Holmes 20 Apr '15

20 Apr '15

George Bina confirms there will be no new Oxygen release before 17, scheduled for the end of April/beginning of May. That's perfect timing for us. It gives a window of three weeks for our version of the plugin to be out in the wild and in general use before the Oxygen guys build the version they'll be including with the Oxygen distro. Cheers, Martin

5 6

Fwd: [tei:bugs] #749 fatal bug in 2.8.0 apropos att.global.rendition
by Martin Holmes 14 Apr '15

14 Apr '15

Do we need a 2.8.1 to be done fairly quickly for this? This really is my fault, but I must admit I had no idea what @predeclare was about; I was assuming the regular tests would pick up anything problematic, and I had no trouble working with @rend and @rendition in my projects for several months before release. I don't use DTDs, of course. Cheers, Martin -------- Forwarded Message -------- Subject: [tei:bugs] #749 fatal bug in 2.8.0 apropos att.global.rendition Date: Tue, 14 Apr 2015 17:19:19 +0000 From: Sebastian Rahtz <rahtz(a)users.sf.net> Reply-To: Ticket 749 <749(a)bugs.tei.p.re.sf.net> To: Ticket 749 <749(a)bugs.tei.p.re.sf.net> --- ** [bugs:#749] fatal bug in 2.8.0 apropos att.global.rendition** **Status:** open **Group:** AMBER **Created:** Tue Apr 14, 2015 05:19 PM UTC by Sebastian Rahtz **Last Updated:** Tue Apr 14, 2015 05:19 PM UTC **Owner:** nobody I am afraid the `<classSpec>` at.global.rendition is missing the vital attribute predeclare="true". I have committed the appropriate change to fix it. This means that any ODD which redefines @rend, @rendition etc is going to fail when it comes to making a DTD. You may now formally curse the day DTDs were invented. I might note that a few existing ODD users are going to be mighty confused when they find their code to change @rend globally simply fails to work these days. In retrospect, it would have been good to highlight this in the release notes. --- Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/tei/bugs/749/> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

2 2

Fall meeting
by Martin Holmes 13 Apr '15

13 Apr '15

Hi all, The CfP for the fall Members Meeting is out, and we have to start making plans. I'd like us if we can to agree soon whether we want to have the fall Council meeting along with it (I think we'd all like to do that), and if so, whether it's going to be before or after, so we can plan work absences and travel. Can we have a show of hands on who would prefer before the main meeting and who would prefer after? I'd rather have Council meet before, so I'm fresh going into the Council meetings and so we can report informally on what we've been doing during the members meeting. Cheers, Martin

7 6

Release freeze *lifted*
by Raffaele Viglianti 06 Apr '15

06 Apr '15

Dear council, The release of 2.8.0 is completed and the commits freeze is now *lifted*. We are now working on 2.8.1a. Please feel free to go back to your bug fixing and general peruse of the SVN repository. Thanks, Raff

4 3

Release day instructions
by Martin Holmes 06 Apr '15

06 Apr '15

Hi all, This is meant mainly for Raff, James, Hugh and anyone else likely to be helping with the release process. I took a quick look through TCW 22, the release instructions, in advance of the release, and noticed some problems. The most obvious is that the oxygen-tei instructions were out of date; they pointed to the Google Code project. I've fixed that, but when I went to test out the rest of that instruction block, I found it doesn't work; the structure of the Vault seems to have changed a bit since those instructions were written, or perhaps they were never actually right. The instructions talked about a file x.x.x/updateSite.oxygen, where x.x.x is the version number, but actually the update file at in x.x.x/oxygen/updateSite.oxygen. I've fixed that. Since James's blog post has the right URL for the file: <http://blogs.it.ox.ac.uk/jamesc/2014/04/02/auto-update-your-tei-framework-i…> I assume the instructions have not been right for some time. James, you'll have to update your blog post to point to the new GitHub location for the oxygen-tei source code. Those same instructions in TCW 22 only take account of major releases (which luckily this is -- it's 2.7 -> 2.8) so they'll have to be elaborated a bit for situations in which you're actually changing a version within the same folder, as minor point-releases do. There's one other thing we'll need to work on. The original version of the instructions has point 8 like this: <quote> 8. Still in ~/private/P5/Utilities, run ./tei-database-rebuild.sh This will update the eXist-db used by Roma. The script takes no parameters but expects a configuration file in the user’s home directory at ~/etc/tei-exist.conf with the appropriate paths and credentials. For the main server at tei-c.org this should already be set and no adjustments should be needed. This is the database used by Roma, so this operation will ensure that Roma is using the new version. Temporary measure for version 2.7.0 only: ask Martin, Peter, James or Sebastian to check the version of P5 used by Roma, to ensure that this has succeeded, and fix it manually if it has not. This procedure is undergoing revision right now, so it has to be done there may be a problem here. Following the release of 2.7.0, a new process will be put in place and this instructions will be updated. </quote> We obviously dropped the ball there. I've edited this a bit so that it's less confusing, but we'll still have to make sure we know how to check the version of P5 which is in eXist when the script has been run. I know the URL to go to in order to do that, but we can't put it in the documentation for various reasons; I'd like to make sure enough other people know it so that there's always someone available to check when the time comes. I'm going to raise a bug that forces us to work on this; it's an aspect of the whole shebang which is very fragile. Anyone else likely to be on duty for the release might want to check that TCW 22 makes sense to them too: <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> Raff, are you already set up with your SSH key for tei-c.org? Cheers, Martin

4 4

Release freeze *in place*
by Raffaele Viglianti 06 Apr '15

06 Apr '15

Hi all, Just another reminder that there is a commit freeze on the repository. Please do not commit anything until further notice. Raff

1 0

Release Notes
by Hugh Cayless 05 Apr '15

05 Apr '15

I will XMLify and commit the release notes at https://docs.google.com/document/d/1U1z6eCbJKVmu8k1KWB4ht6qqZxcTXXycKaVYqzh… later this weekend (maybe this evening, more likely tomorrow). Please look them over and make any changes you think necessary before then. Thanks, Hugh

2 1

Hangout link
by Hugh Cayless 04 Apr '15

04 Apr '15

https://plus.google.com/hangouts/_/g374p6twebxmmcxkwkpgdgdciaa Let's see if this works...

5 5

Freeze reminder
by Raffaele Viglianti 03 Apr '15

03 Apr '15

Hello, I think you are all aware of this, but here's a reminder anyway: there is currently a *temporary freeze of commits* to the repository. This is because of the release scheduled for Monday April 6. Please do not commit anything else to the repository until the freeze is lifted (likely sometime on Monday). Thanks, Raff

4 4

Release Notes
by Hugh Cayless 03 Apr '15

03 Apr '15

Since this is my first time writing them, I don't have a very clear idea of what to put in and what to leave out, so I've started a google doc: https://docs.google.com/document/d/1U1z6eCbJKVmu8k1KWB4ht6qqZxcTXXycKaVYqzh… to which I invite you to add things you've worked on that you'd like to be in the release notes. Thanks, Hugh

1 0