September 2015 - Tei-council

Appcrit and stylesheets
by Hugh Cayless 25 Sep '15

25 Sep '15

After our meeting yesterday, I went digging to see what would need to be done to support the new app. crit. features in the stylesheets, and found that actually the support probably isn’t really up-to-date even for the current phrase-level-only apparatus (e.g. no support for @source; no support for <rdgGrp>s). I’ve made a bunch of updates that support, e.g., lines inside <app> and transpositions, but then on further investigation found that even though the existing app-handling has a couple of tests, they’re never run during testing, and there are no "expected-results" artifacts, so we can’t know what they’re supposed to do or if any regressions have occurred. There’s rather a lot of work to be done to produce output I’d consider acceptable. Given that state of things, I don’t consider updating the stylesheets to be a blocker for getting the app. crit. updates into 2.9.0. I do plan to work on it, and I think I can promise it will be better even in the upcoming release, but there’s a bunch more work to be done. It’s not really surprising: I bet anyone who’s doing critical editions is developing their own custom displays anyway, so these have never gotten a real workout.

1 0

Fwd: Re: [oxygen-tei] Synchronize with the upcoming Oxygen version 17.1 release (#5)
by Martin Holmes 25 Sep '15

25 Sep '15

Hi all, I raised the issue of the Oxygen release with Alex on the relevant oxygen-tei ticket, and had a response from him (below). Basically, he has taken the current stable releases of P5 and the Stylesheets and built the framework for Oxygen 17.1 already. The rest of his message gives another instance of how cautious we have to be here: it looks like changes to Oxygen 17.1 have percolated into changes to the plugin/framework code, and that some of these may not be compatible with older versions of Oxygen. This means we'll have to do some testing before releasing our own updated version of the plugin, and will probably have to change our "minimum version" information (which is currently at 15.2) to a later version. I don't believe we should branch the code; I don't want to be in the business of trying to maintain multiple versions of our TEI plugin for different versions of Oxygen. I believe this is the situation: - Most TEI+Oxygen users have a version of Oxygen with the standard framework and just use that. They'll see no change; if they update Oxygen they'll get the latest stable framework, and if they don't, they'll continue to have the one that was released with their Oxygen version. - A number of early-adopters with a specific reason to do so have installed the plugin to stay up to date with our releases. As active early-adopters, the majority of this group will presumably also be updating their Oxygen, so they'll have no problem. Where one of that group has an old version of Oxygen, they'll see that they're no longer able to update their version of the plugin (after our next release of it), but they can keep using the version they have until they update Oxygen, so they're no worse off; they just can't keep moving forward with us until they update Oxygen. Is everyone happy with this, or is there an appetite for forking the oxygen-tei project to support users of older versions of Oxygen? Cheers, Martin -------- Forwarded Message -------- Subject: Re: [oxygen-tei] Synchronize with the upcoming Oxygen version 17.1 release (#5) Date: Thu, 24 Sep 2015 23:02:04 -0700 From: AlexJitianu <notifications(a)github.com> Reply-To: TEIC/oxygen-tei <reply+0024d0495ca2da75646e4482232fdf1926b2102633127c8d92cf00000001121ca55c92a169ce065c2b82(a)reply.github.com> To: TEIC/oxygen-tei <oxygen-tei(a)noreply.github.com> CC: Martin Holmes <mholmes(a)uvic.ca> Hi Martin, I've went with option number 1. I've already integrated the current, stable version. On the branch I've created I also brought in the small changes that we've made to the TEI framework and Java sources in the current Oxygen development stream. One aspect that should be taken into account is that this framework might not be fully compatible with older versions of Oxygen. I'm expecting the TEI community to work with different versions of Oxygen so we should probably tag or branch the current project state. We'll see if we have time to integrate the release from October 8. If it doesn't make it perhaps we'll put it in a minor release afterwards. Alex — Reply to this email directly or view it on GitHub <https://github.com/TEIC/oxygen-tei/issues/5#issuecomment-143137410>.

1 0

making teideb repository
by James Cummings 24 Sep '15

24 Sep '15

As Martin predicted if I go into the teideb directory and 'make go' (which runs the apt-ftparchive, gzips the packages and signs them), it fails on the signing process. Martin was composing a list of questions to ask him... so this might be one of them if we wish to continue to release debian packages. (Or we figure it out enough to set up a new package repository, preferrably on www.tei-c.org rather than an Oxford machine.) === You need a passphrase to unlock the secret key for user: "Sebastian Rahtz <sebastian.rahtz(a)oucs.ox.ac.uk>" 1024-bit DSA key, ID 86A9A497, created 2001-11-27 gpg: Invalid passphrase; please try again ... === -James -- Dr James Cummings, Academic IT Services, University of Oxford TEI Consultations: tei(a)it.ox.ac.uk

4 11

antify branch
by Peter Stadler 24 Sep '15

24 Sep '15

Dear all, just an update on my work of antifying the build process of the Guidelines: * I more or less simply try to convert the current Makefile targets to ANT targets * I’m collecting all settings (params) in a build.properties file which can be overwritten by a local.build.properties file (which is excluded from version control) * during the build process, I’m creating a "build" folder for temporary stuff (currently, everything ends here). I envision to have a clean „dist“ folder in the end, where the to-be-distributed files are summoned, together with zipped archives. * so far I can create the Guidelines (Makefile target „teiwebsiteguidelines“) with all dependencies * leaves the hard stuff: PDF (via LaTeX) and various Tests … Best Peter

4 7

"New" Jenkins
by Hugh Cayless 24 Sep '15

24 Sep '15

Hi All, I’ve been working on getting an updated Jenkins install script that will run on Ubuntu 14.04 Trusty Tahr LTS (LTS means Long Term Support, meaning it will be supported through 2019). The current version runs on Ubuntu 12.04 Precise Pangolin, support for which ends in 2017. The new version, which is available on the hcayless-newJenkins branch, will install all the dependencies needed and launch a new Jenkins. It no longer depends on the TEI Debian repository (we’ve been discussing the feasibility of continuing this). I’ve only tested it in a local VMWare install of Trusty, but it seems to work fine. A slightly longer-term goal is to turn the install script into a Dockerfile, which would mean anyone who wanted to run a local copy of Jenkins for testing purposes could do so, on any platform, just by installing Docker-Machine (https://docs.docker.com/machine/ <https://docs.docker.com/machine/>). Personally, I’d very much like to have this capability, along with the capacity to just run the tests and get an understandable output from them.

2 1

Pure <egXML>
by Syd Bauman 24 Sep '15

24 Sep '15

Lou -- Not sure where you are in your Herculean task of updating the definitions to Pure ODD, but I noticed what seems to be an error in the content of <egXML> in the P5-Pure branch. The declaration is: <content> <alternate> <textNode/> <macroRef key="macro.anyXML"/> </alternate> </content> But since macro.anyXML is singular, only 1 child of <egXML> is permitted. However, multiple children are supposed to be permitted. (And indeed, by my quick count we have 140 <egXML>s w/ multiple children.) I.e., the content model of <egXML> is ( text | macro.anyXML* ) but P5-Pure only has ( text | macro.anyXML ) So I'm thinking it should be <content> <alternate> <textNode/> <macroRef maxOccurs="unbound" key="macro.anyXML"/> </alternate> </content> No? BTW, this seems egregious enough that back in the world of Subversion I might have just fixed it,[1] but this git stuff is somewhat intimidating. Am I correct that to fix this, I would make the change in the P5-Pure branch, check it in, and then go onto GitHub to issue a pull request to Lou? Or do I just push it up myself? Notes ----- [1] Actually, I likely would not have, or at least would have sent you mail saying so, since this may be a symptom of a larger ODD->PureODD problem.

3 6

Hangout Link
by Hugh Cayless 24 Sep '15

24 Sep '15

https://hangouts.google.com/call/qkvxhucxrcj6463e64trr6w4jma As always, let me know if you need to join by phone.

1 0

Fwd: formatting pure odd specs
by Lou Burnard 19 Sep '15

19 Sep '15

[not sure if the sf mailing list is still functioning, so apologies for re-send] -------- Forwarded Message -------- Subject: formatting pure odd specs Date: Sat, 19 Sep 2015 18:10:46 +0100 From: Lou Burnard <lou.burnard(a)retired.ox.ac.uk> To: tei-odds(a)lists.sourceforge.net <tei-odds(a)lists.sourceforge.net> The Guidelines HTML pages as currently produced don't do a good job of handling the changes introduced with Pure ODD. In particular, here's a (not necessarily complete) list of the things that ought to happen (in my view) but currently don't... 1. The <datatype> component of an attribute spec (whether in an attribute class or an element spec) currently produces some text saying "n to m occurrences of" (depending on the values of minOccurs and maxOccurs) , followed by an empty white box, optionally followed by the phrase "separated by whitespace". If you toggle the display of the empty white box from "compact" to "XML syntax", it will show the full content of the <content> of the <datatype> e.g. <datatypemaxOccurs="unbounded"> <dataRefkey="teidata.pointer"/></datatype> The box is redundant, I think. It should be replaced simply by the @key value from the <dataRef> which should be an HTML link to the appropriate teidata spec. 2. The "Declaration" component of an elementSpec currently (still!) displays its RelaxNg declaration, in either compact or XML syntax. I think this should be replaced by the pureODD content, displayed in the same way as an XML example. There is an argument for retaining the Relaxng declarations as well, as there is for also providing the XSD or DTD declarations, but I ain't making either of them. 3. Individual specs for the teidata definitions need to be generated and included in the lists of datatypes. I have been poking around in the stylesheets trying to see how to make these things happen, and have so far (more or less) succeeded in achieving no 3 above. The others are more of a challenge so offers of help would be much appreciated.

1 0

Completed test migration of SourceForge FRs and bugs
by Raffaele Viglianti 17 Sep '15

17 Sep '15

Dear all, First of all apologies if you have just been spammed by GitHub notifications :( I've tested migrating to https://github.com/TEIC/Guidelines-TEST/issues Feature Requests and bugs as exported by Hugh on July 28. That's a total of 564 FRs and 764 bugs. I'm happy to report that all have been imported successfully. This was done using the perl script gosf2gh, which I've adjusted a bit to work with our requirements. The code of my fork is here: https://github.com/raffazizzi/gosf2github Feel free to contribute! A few comments: - All issues and comments were created by raffazizzi because I used my API token. When we do this for real, we should use a TEITechnicalCouncil token. - Even though all issues and comments will appear created by the same user, the script carries over the original creator / commentator in the body of the issue/comment. If we have a GitHub user for it, the GitHub user will appear, otherwise the old username will. - Referencing users: I've avoided adding explicit references to GitHub users (eg @raffazizzi) because the script I used warns that too much spam could cause my token to be banned. The advantage of referencing users directly is that issues can be searched by mentioned users, but we may have to give this one up. - Issue assignment: if the ticket was not assigned in SF, it won't be assigned in GH. If it was assigned to a user that is currently not a collaborator, it will be assigned to TEITechnicalCouncil. A label is also added with the old sourceforge assignee in the form of sf_assignee-USER. I'm now realizing that it may be more useful to have these labels for the original *creators* not the assignees. Thoughts? - Formatting of the text looks pretty good, but code blocks are a bit broken. The script guesses by matching ~~~~ blocks, but sometimes they're marked wit more tildes. I can try to fix this, but it's probably going to be a bit unreliable. Not a big deal, though, IMO. If you notice any other formatting problems, let me know! Raff

4 6

SourceForge is down again
by Martin Holmes 16 Sep '15

16 Sep '15

Looks like we made the right decision; http://tei.sourceforge.net/ is down again, and the svn repo is unavailable. The Site Status page is not available either. Their last tweet was July 31, so whatever's wrong now, either they haven't noticed or they don't know enough to report anything. Cheers, Martin

3 4