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

oXygen TEI plugin and debian packages
by Scholger, Martina (martina.scholger＠uni-graz.at) 21 Aug '20

21 Aug '20

Dear TEI Community, The oXygen TEI plugin has been updated with the latest version of the TEI Guidelines 4.1.0 and Stylesheets 7.50.0. A description on "How to automatically update your TEI framework in oXygen" can be found here: https://github.com/TEIC/oxygen-tei/blob/master/oxygen-tei-plugin.md Furthermore, the Debian packages are available at https://packages.tei-c.org/deb/. Best, Martina Martina Scholger Centre for Information Modeling Austrian Centre for Digital Humanities University of Graz A-8010 Graz | Elisabethstraße 59/III +43 316 380 2291 martina.scholger(a)uni-graz.at<mailto:martina.semlak@uni-graz.at> http://informationsmodellierung.uni-graz.at<http://informationsmodellierung.uni-graz.at/> | http://gams.uni-graz.at<http://gams.uni-graz.at/> Chair of the TEI Technical Council | http://www.tei-c.org/ Institut für Dokumentologie und Editorik e.V. | https://www.i-d-e.de/

1 0

No masters
by Hugh Cayless 20 Aug '20

20 Aug '20

Hi All, I have deleted the master branches for TEI and Stylesheets, and plan to gradually work through the remainder. My inclination on most of them is probably to wait until there's an automated migration tool, as I understand pull requests may break, etc. Hugh

2 2

Release 4.1.0 complete
by Hugh Cayless 19 Aug '20

19 Aug '20

Dear All, especially Martina who can now announce it, We (Jessica, Nick, and I) have completed the release. You are free to commit to dev again. Thanks to all who dropped in on Slack to help out. The only remaining bits are the Oxygen plugin, which I can't build, and the Debian packages, because I was a bad release technician and forgot to ask Peter for the passphrase. All the best, Hugh

4 7

release minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 19 Aug '20

19 Aug '20

Dear release technicians, here is a document were you can take notes during the release (in case this is necessary). It also contains the email to the TEI-L https://docs.google.com/document/d/1PJryKNeKIzUEpdFlaQaJAhO9F3XM23IU66lB3QR… Best, Martina

2 1

release notes
by Syd Bauman 19 Aug '20

19 Aug '20

I updated the release notes *in the release-4.1.0 branch* (because that's what Martina did). While there are always improvements to be made, I think they are mostly good to go. Still need a release code name (why do we have those -- they are fun for us, but since we do not actually use them ...?). And I think we should consider deleting the prhase "to represent primary source materials" from the 1st bullet point.

2 1

Deb build warning
by Martin Holmes 17 Aug '20

17 Aug '20

Hi all, I'm still getting this warning on the release branch of the Stylesheets: dh_clean: warning: Compatibility levels before 9 are deprecated (level 5 in use) Didn't we decide to push that compat value up to 9? Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

1 0

Release branches
by Hugh Cayless 17 Aug '20

17 Aug '20

Dear All, I've created release branches "release-4.1.0" for the Guidelines, and "release-7.50.0" for the Stylesheets. All the best, Hugh

3 3

Annotations and impasses
by Hugh Cayless 17 Aug '20

17 Aug '20

Hi All, Since we essentially have today to make the go/no-go decision for getting Annotations into this release. We seem to be deadlocked in a couple of ways, and I would like to see if we can un-jam things. Syd and I are arguing over whether annotations should look like: <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <respStmt xml:id="HAC"> <resp>creator</resp> <persName>Hugh Cayless</persName> </respStmt> <ptr target="http://example.org/description1"/> <note>tag1</note> </annotation> or <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <annMeta> <respStmt xml:id="SB"> <resp>creator</resp> <persName>Syd Bauman</persName> </respStmt> </annMeta> <annBody> <ptr target="http://example.org/description1"/> <note>tag1</note> </annBody> </annotation> Syd's argument (and you should correct me if I'm misrepresenting your opinion, Syd) is that it's cleaner to partition things this way and we might want in the future to say virtually any TEI element could be an annotation body. My counter to this is that we set out here to implement the Web Annotation Data Model (or parts of it at least) in TEI, and that WADM doesn't have extra containers for annotation metadata or bodies. Further, WADM doesn't do specialized body types. They have text and they have URIs. I'm certainly in favor of adding useful features to TEI annotations, but if we want to do that in the next round of work on annotations, we'll have to do it by adding new TEI functionality (probably via new elements), and I don't think partitioning the content of annotation will buy us anything. It might make it worse, because the extra-sparkly new TEI functionality won't be compatible with WADM:body and therefore probably shouldn't go in an <annBody> element. To compound this, Laurent seems to say that WADM was only ever meant to be an inspiration and actual interoperability with Web Annotation wasn't a goal they had in mind in requesting this feature. I'm just going to go cry for a bit...excuse me. Ok. I will sum up: I would really like to have WADM compatibility this year because I have things I want to do with it. My proposal is that we proceed with WADM-compatible annotations and then begin work on more powerful TEI annotations. I would like to keep the content model of <annotation> as simple and as close to WADM as possible, but I won't pout if I'm voted down on that. What do you all think? Hugh

7 12

Freeze
by Scholger, Martina (martina.scholger＠uni-graz.at) 16 Aug '20

16 Aug '20

Dear all, I would like to remind you that we had agreed to freeze starting tonight. Please keep that in mind and check with the release technicians in case of late changes. Best, Martina Von meinem Huawei-Mobiltelefon gesendet

2 1

Stylesheets 454 and thus TEI 1848
by Syd Bauman 16 Aug '20

16 Aug '20

I have put multiple days of debugging work into Stylesheets 454, the release-blocking error that means a <classRef>, or at least a <classRef> with an @except, is ignored when processing an ODD. While I have made serious progress (some of which is in the sydb-454 branch), it is looking like I will not have a viable solution by the end of the day. Thus I think we need an alternate solution, which would be to back out [1] and either leave title page stuff out of <lem> and <rdg> for this release, or use some other ODD mechanism to put them in there. Possibilities (listed in my order of preference) include: 1. Use a bunch of <elementRef>s 2. Use <classRef> w/o @except, and add a <constraint> to flag <binaryObject>, <graphic>, and <castList> as invalid 3. Make a new class "model.frontPart.apparatusable" and put the needed elements in it. 4. Use <classRef> w/ @include (but I am highly suspicious that this will fail in exactly the same way). We can change any of the above back to <classRef> w/ @except after 454 is fixed. The other possibility, of course, is that someone else will take a look at this and fix the bug in the next few hours. If anyone wants to join my for a screen-sharing debugging session, speak up. That said, I really have other things I need to do today, too. :-| Notes ----- [1] TEI repo commit 193e6283321aeeb68b9a93b0d95b10a82148ef74

1 0