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

TCW 20 Revision on Branch Practice?
by Elisa Beshero-Bondar 03 Oct '18

03 Oct '18

Dear Council, I was just re-reading TCW 20 to remind myself what we advise each other on working in feature branches, and how to update them. You may remember some excitement during our Tokyo face-to-face as I first nearly bungled a branch merge and then we fixed it. This was, I think, a bit too much excitement, and lots of us do work in branches. When it comes time to update them and/or merge them back into dev, we don't always know exactly what to do, and just relying on looking stuff up is, as we saw, a little brittle and error prone. We are pretty confident we can fix anything that goes wrong, but perhaps we can minimize the excitement with a little more guidance to our future selves. So, I'm writing this to propose some revision to this portion of TCW 20: "If you are working on a particularly complex change involving multiple files, it may be better to create a branch in which to work on your changes, and then to merge the branch when you are confident that the work is successfully completed. See any guide to git for instructions on how to approach that. Bear in mind that our Jenkins servers only build the dev branch, so you cannot depend on them to test-build your working branch." I'd like to propose rewriting that with some more detailed steps on our TEI Technical Council preferred process for reconciling branches with dev, to help prevent future excitement. :-) I've been reading about the "best" ways to keep branches updated, and the differences, for example, between rebase and merge for keeping a branch tip updated. Rebasing is pretty dangerous in that it "rewrites history" by resequencing commits, so I am not sure we ever want to use it for updating a branch from dev, before merging it back. Do we want to always advise, then, to update a branch by merging it with dev? I'm not 100% certain of that either. What I'd like to do is (very careful) test a few approaches and work with you all to try to plot out an excitement-proof set of safe guidelines for Council members on Best Practices for Working in Branches as part of TCW 20. What say you all? Elisa -- Elisa Beshero-Bondar, PhD Associate Professor of English University of Pittsburgh at Greensburg Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu

2 1

two dates are not better than one
by s.bauman＠northeastern.edu 02 Oct '18

02 Oct '18

When I went to actually nuke data.*.xml, I ran into a problem. There were two that were still referenced in the Guidelines: data.temporal.iso.xml and data.duration.iso.xml from ND.[1] I initially "fixed" this by just changing "data." to "teidata." on those two instances in ND. This broke the build horrifically -- the definitions of various attrs (like att.temporal.when.iso) now had *two* lists of possible values. Took some digging around but I found that the "correct" datatypes (teidata.duration.iso.xml, and teidata.temporal.iso.xml) were (incorrectly, I think) still being referenced from ST. I commented out those references in ST, and the build was back to normal (and matches the prose). So that all seems good. BUT, there is still a problem. This means that there are several validation errors that have now crept in: memberOf points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso specDesc points to non-existent att.duration.iso I am not quite sure what to do about this. While technically validation problems, they don't (I don't think) actually cause any difficulties when building outputs from the source. So rather than check these changes into dev, I have (with Hugh's help) checked them into a new branch, sydb-endDeprecation_2018-10-01. But we should decide what to do about this soon (measured in hours to days), as the deprecation period is now over. One possibility (that I am leaning towards right now): These errors are generated by the special-purpose validation routine P5/Utilities/validator.xsl, referred to in the Makefile with "Check validity with special-purpose XSL code, looking for bad links etc". We could simply update that code so it "knows" about these particular cases, and does not flag them as errors. But before we even think of that, either a) someone else who builds locally should checkout the sydb-endDeprecation_2018-10-01 branch and check that the build is working. (I only tested validate, html-web, and exemplars, I think.), or b) we'll have to ask MH or PS to set up a Jenkins job for this branch. (Seems like overkill to me.) Note-for-Vanessa ---------------- [1] The vast majority of the source files to Guidelines chapters are each stored in an XML file that starts with a 2-letter code. Thus I am using "ND" as shorthand for .../P5/Source/Guidelines/en/ND-NamesDates.xml where "..." is wherever on your system you keep the TEIC/TEI git repo. The chapter files are: * AB-About.xml * AI-AnalyticMechanisms.xml * CC-LanguageCorpora.xml * CE-CertaintyResponsibility.xml * CH-LanguagesCharacterSets.xml * CO-CoreElements.xml * DI-PrintDictionaries.xml * DR-PerformanceTexts.xml * DS-DefaultTextStructure.xml * FS-FeatureStructures.xml * FT-TablesFormulaeGraphics.xml * GD-GraphsNetworksTrees.xml * HD-Header.xml * MS-ManuscriptDescription.xml * ND-NamesDates.xml * NH-Non-hierarchical.xml * PH-PrimarySources.xml * SA-LinkingSegmentationAlignment.xml * SG-GentleIntroduction.xml * ST-Infrastructure.xml * TC-CriticalApparatus.xml * TD-DocumentationElements.xml * TS-TranscriptionsofSpeech.xml * USE.xml * VE-Verse.xml * WD-NonStandardCharacters.xml

5 5

Stylesheets v7.46.0 released
by Raffaele Viglianti 02 Oct '18

02 Oct '18

Dear council, Syd and I, with the help of Martin Holmes and Peter Stadler, have just completed a new release of the stylesheets v7.46.0. In the process, we've also made a couple of updates to tcw22 and the utility script tei-install.sh. I don't know if stylesheets releases need to be announced on TEI-L, especially since we don't assemble a document listing changes besides a generated changelog. The freeze on the dev branch is now over, code away. Raff

5 7

validity of newly <msDesc>-only elements
by s.bauman＠northeastern.edu 01 Oct '18

01 Oct '18

Per previous deprecation (see #1479), I went to change the deprecation of the use of <secFol>, <signatures>, or <catchwords> outside of <msDesc> to an error. HOWEVER, when we do that we get validation errors on <egXML> that has only one of those three elements without any context. SO I changed the actual Schematron to <sch:assert test="ancestor::tei:msDesc or parent::teix:egXML"> The <sch:name/> element should not be used outside of msDesc. </sch:assert> and changed the 2 <egXML>s that had <catchwords> as a descendant, but not child, so that they each contain an <msDesc> wrapper. I'm not entirely sure why that works -- I thought example validation was done by changing the namespace of each example to the TEI namespace and then validating against a (modified) TEI schema. But perhaps I'm wrong about that, or perhaps it's smart enough to change the teix: prefix to be the TEI namespace, too. Anyway, it seems to be working now, but because of other problems is only checked into the new sydb-endDeprecation_2018-10-01 branch. (Thanks to Hugh for helping me straighten out my git headaches.)

1 0

Customization section of TEI
by Mylonas, Elli 01 Oct '18

01 Oct '18

There is a section of TEI under the "Guidelines" menu item called Customization. Issue 1813 https://github.com/TEIC/TEI/issues/1813 points out some problems that are eminently fixable. However, what Syd and I were unable to determine is where the source lives (other than on disk) and how to edit the file(s). Help appreciated. Signing off as the September Issue Assigner. best, --elli

1 0

changing branch tracking?
by Syd Bauman 01 Oct '18

01 Oct '18

Attn: Hugh I made a lot of changed to my local dev branch today for tomorrow's removal of macroSpec/@type allowing <catchwords>, <secFol>, and <signatures> outside of <msDesc> data.*.xml There were problems that will probably break the build (more about those later -- probably as soon as this is dealt with :-), so I decided I should have used a different branch. So I issued: $ git reset --keep HEAD~3 $ git checkout -t -b sydb-deprecationEnd_2018-10-01 $ git cherry-pick ..HEAD@{2} It looks like it *mostly* worked: $ git status -uno | Your branch is ahead of 'dev' by 3 commits. | (use "git push" to publish your local commits) | nothing to commit (use -u to show untracked files) But there are 2 problems: 1) A typo. That "HEAD~3" was supposed to be a "HEAD~5" 2) The 'dev' in that status output makes me worry that if I do a `git push`, these changes would get pushed to dev, not the new sydb-deprecationEnd_2018-10-01 branch. I was smart enough to make a backup of my entire repository before doing this, so I can go back and fix my 3/5 mistake easily. But I thought the point of the -t switch was to set up tracking so that my local sydb-deprecationEnd_2018-10-01 tracks a similarly named branch on the remote (GitHub). Apparently not. What do I do to make that work?

2 1

reminder doodle poll
by Scholger, Martina (martina.scholger＠uni-graz.at) 01 Oct '18

01 Oct '18

Dear Council, this is a reminder for the doodle poll for scheduling our TEI Council calls: https://doodle.com/poll/kk9hsr6z9csxhkub Please add possible dates if you haven't done it yet. Best, Martina

1 0