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

Oxgarage is out of date
by Martin Holmes 21 Dec '15

21 Dec '15

Hi all, If you convert an ODD file to a RelaxNG schema using OxGarage right now, you'll see this at the top of your file:  OxGarage hasn't been updated to use 2.9.1. I don't know what's actually involved here; perhaps OxGarage uses the P5 and Stylesheets versions from the debs, and the server hasn't been updated since 2.9.1 was released. Does anyone know how this works? Cheers, Martin

6 13

TEI Templates missing from Oxygen?
by Martin Holmes 20 Dec '15

20 Dec '15

Hi all, I just updated my Oxygen to the latest release, and I can't see any TEI P5 templates other than the JTEI template. This is an install which doesn't have the bleeding-edge version of the plugin installed. In the Framework folder I see all the relevant files, but I don't see anything other than JTEI when I go to File / New / Framework Templates. Can anyone else who's got the latest Oxygen check what you see? Thanks, Martin

3 3

GitHub Labels re-organized
by Raffaele Viglianti 18 Dec '15

18 Dec '15

Deal all, As promised at the F2F, Elli and I have re-organized the GitHub labels before the year end. You can see the current labels here: https://github.com/TEIC/TEI/labels Thank you for your feedback earlier this week - we took it into account, but made some executive decisions. None of this is set in stone, however, as changing and adjusting the labels is easy. Let's give this setup a test drive and see how it works for us. I've also gone through the issues that are currently open and made sure they all have at least one label for *Status:**, *TEI:** or *Tool*:*, and *Type:**. Best, Raff

1 0

Git question
by James Cummings 18 Dec '15

18 Dec '15

Hiya, Is there a way to copy the changes I've made on one branch to another? Or move one branch (off another branch) to be tracking a different branch instead? (e.g. I made the 'processing-model' branch off of Lou's original lb42-pureodd branch and I want to move it to his current one.) Suggestions? Or do I have to go do all the changes again? -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

4 18

and now...
by Lou Burnard 15 Dec '15

15 Dec '15

If we're reaching consensus on the meta-question of how issues should be labelled, could we now collectively consider at least some of the urgent outstanding issues themselves? In particular, I am still waiting for an explicit green light from at least one other council member who has successfully built using the lb42-pure-odd-2 branch? Martin set up a Jenkins job to do this, but it seems to have fallen over at the penultimate hurdle, and I don;'t know enough about Jenkins to see why. If we get that, then I could maybe issue a pull request (whatever that is) and get this stuff merged in... If we're looking for jobs for new council members to cut their teeth on, I'd be delighted to propose trying to build this branch! Much more fun than fixing a tedious bit of prose. I'd also appreciate some feedback on my ticket proposing a new anyXML element... L

5 13

Reorganizing labels on GitHub
by Raffaele Viglianti 14 Dec '15

14 Dec '15

Dear all, Elli and I spent some time this morning going through the labels on the TEI repository and discussed a new, simpler, system for organizing our tickets. Here is a spreadsheet with current labels and their proposed new name: https://docs.google.com/spreadsheets/d/1VhBYft_85F6x8J0YpGvqn-ZfIHbXqk9j8QV… We propose to have 4 higher level label categories: *component* or *tool*, *type*, *priority*, and *status. * When creating a new issue, one label from each category should be chosen. For example a new ticket about a badly misguiding example for the the "div" element would probably get these labels: "Component: Core schema" "Type: Bug" "Priority: High" "Status: Needs Discussion" There are a couple of extra labels that don't fit this system: - "sf-automigrated": identifies tickets migrated from SF. We suggest to keep it. - "SIG": identifies tickets about SIG organization (maybe we need a category for less technical discussions, "meta"?). Then we have a couple of specific questions for you: - Should we keep labels specific to each chapter in the guidelines? (e.g. MS, ND, PH, etc). We think they should go away. But if we keep them we can get group them under "Component: Guidelines", e.g. "Component: Guidelines: MS". - "sf_creator-*" tickets were introduced to facilitate finding migrated tickets by their original SF creator. Since that information is also recorded in the text of the ticket, we think they should go away. Thoughts? Many thanks for your comments - after we make some decisions here, we will also check labels in the Spreadsheets repository and implement a similar system. Best, Raff

5 19

Building the PureODD branch
by Martin Holmes 13 Dec '15

13 Dec '15

Hi all (but mainly Lou and Hugh), I notice there's a pureodd branch for the Stylesheets. Should my Pure ODD P5 build on Jenkins be using that branch of the Stylesheets rather than the dev branch? Cheers, Martin

2 2

Pure ODD progress
by Lou Burnard 09 Dec '15

09 Dec '15

I am now at the stage of being able to generate web pages in the lb42-pureodd-2 branch. To get there, I have had to comment out of the makefile the two "EXTENDED" test files testp4compat.xsd and testi18n.xsd (the latter was already commented out in fact). Can anyone remember/reconstruct what these tests were intended to do? I am also now using Hugh's latest Stylesheets, so have some further comments to make on them: Firstly, what appears to be a bug: in the pureODD section, I see nothing at all inside the <content> element. e.g. in emph. This looks OK at http://teic.github.io/TEI/ref-emph.html but not in the version I have locally generated, so either the former is not up to date, or I have messed something up. Secondly, I still don't want to see class declarations inside that section Thirdly, I don't want to see element names clickable inside examples. This is not what we currently do; I find it distracting; and it's strictly speaking wrong, since example contents are not in the TEI namespace! :-) [this also doesn't happen in the github.io version]

4 13

anyone for @exclude ?
by Lou Burnard 08 Dec '15

08 Dec '15

Wandering the anyXML rabbit warren, I came upon a new side passage which may be worth considering. This is to define in pure ODD a new attribute @exclude on the <content element, the effect of which is to specify one or more elements which should be excluded from said content model. We could implement this in DTD land (if we still did DTDs) with an exclusion exception; in Relaxng of course it has to be a schematron rule. It would enable us to do two things we currently do rather obscurely (1) prevent <teix:egXML> from containing <teix:egXML> (2) prevent <s> from containing <s>. And there may well be others. Unless anyone can plausibly show that this is bonkers, I will create a ticket.

1 0

Contributors
by Hugh Cayless 07 Dec '15

07 Dec '15

Dear All, Thanks for the productive meeting earlier today. I’d said I wanted to broach the topic of keeping Contributors engaged over email, partly because it’s been a little contentious in the past and partly because I think it’s something that deserves more deliberation than we can give it in a single meeting. I’ll start by setting out how (as I understand it) things work now and then paint a picture of things as I’d like them to be. I mean the latter as something for you all to react to, so don’t hesitate to do so. I’d particularly like reactions from those of you who are new to Council. This is really going to be an ongoing conversation, I believe, and not something we can just fix. Martin has volunteered to be a champion for Contributors and I’m hoping that he and any other outgoing members who want to remain active participants will be vocal about what works and what doesn’t work for them. Council is a highly effective group that does a lot of good work, so we need to find a balance that doesn’t mess with our effectiveness and cohesiveness. The status quo: Engagement with TEI work happens via the TEI and Stylesheets repos on GitHub. Each of these has issue trackers, and there are two teams that have access to make changes to TEI, the Technical Council and "TEI Contributors". Incidentally, if the new folks will send me their github ids, I’ll add you to the Council team. The Tech Council team is for current Council members and the Contributors team is for a) former Council members who wish to remain active and b) anyone else we decide should have the ability to push directly to the TEI repo. This being GitHub, we can also take pull requests from people on neither team. Discussion of TEI stuff happens on this mailing list, on the issue trackers, in our monthly telecons, and in our Face to Face meeting. Only current Council members are on the mailing list, and people are removed as they cycle off Council. Only Council members attend the telecons and the F2F meetings, though occasionally "outside experts" are invited. Council tends to operate on consensus, though from time to time contentious issues are put to a vote. My ideal world: Contributors would be able to be as involved as they want to be in ongoing TEI development. That might include staying on or joining the mailing list, attending telecons, and even F2F meetings (though the TEI wouldn’t be able to pay for them unless they were formally invited of course). The main difference between Council Members and Contributors would be that the former have a vote when things come to a vote and would in general have more responsibility for development and maintenance. I feel that we don’t do enough to foster an active community of people who are TEI experts, and I think part of that is Council being a bit mysterious and exclusionary. It’s hard to get onto Council, especially if you’re not already part of a community of TEI users (so that you have name recognition in the elections) and people who leave have tended to just drift away (often leaving unfinished business). As I mentioned above, we’ve had a version of this discussion before, and I think mine was a minority view then, but I wanted to raise it again now to get the reactions of our incoming members and the perspectives of our outgoing members. What should we do? As you might have guessed, I have strong opinions, so I’m going to shut up for a while in the hope that a productive discussion develops without me driving it :-).

10 17