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

first draft release notes
by Scholger, Martina (martina.scholger＠uni-graz.at) 24 Jan '19

24 Jan '19

Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

4 8

Re: [Tei-council] first draft release notes
by James Cummings 24 Jan '19

24 Jan '19

I notice in the Release Notes that we seem to be putting both <ref> and <gi> around element names? This only seems to have started in the last few releases where before we just put <gi> and the magic of the build process turned this into a link in the release notes. Can someone confirm/deny whether we need to do this or not? If we do it seems like we should change the script rather than the encoding. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 23 January 2019 23:41:16 To: TEI Council Subject: [Tei-council] first draft release notes Dear all, I made a first draft of the release notes: https://github.com/TEIC/TEI/blob/dev/P5/ReleaseNotes/readme-3.5.0.xml. There are still some TEI issues missing (from #1479 to #1645), which I will add tomorrow. For the Stylesheets release notes: should we add them to the same document? Martina

1 0

Refridge
by Scholger, Martina (martina.scholger＠uni-graz.at) 23 Jan '19

23 Jan '19

Dear all, this is a reminder that we are in the middle of the "refridge phase". This means that it is fine to fix typos and do small changes in prose, but please don't change the schema any more. Freeze is on Thursday, Elli will do the release branch on Friday. Best wishes, Martina Mag. Dr.phil. Martina Scholger Zentrum für Informationsmodellierung - Austrian Centre for Digital Humanities Elisabethstraße 59/III 8010 Graz Austria martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at> https://informationsmodellierung.uni-graz.at<https://informationsmodellierung.uni-graz.at/> | https://gams.uni.graz.at<https://gams.uni.graz.at/> Institut für Dokumentologie und Editorik e.V. | https://i-d-e.de<https://i-d-e.de/> Chair of the TEI Technical Council | http://tei-c.org

1 0

Re: [Tei-council] cancel Stylesheets meeting?
by James Cummings 21 Jan '19

21 Jan '19

Hi, I can be there if people want. Otherwise, happy to open a chat and just work on tickets. ;-) Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Syd Bauman <s.bauman(a)northeastern.edu> Sent: 18 January 2019 21:36:59 To: TEI Council; Lou Burnard; Martin Holmes Subject: [Tei-council] cancel Stylesheets meeting? For various reasons it looks like Martin, Elisa, and myself are the only ones who will make the Stylesheets meeting this coming Mon 21 Jan 19 at 14:00Z. (James? Maybe you will be there?) Thus perhaps we should cancel this one, especially since Mon is the last day to work on tickets (other than typos) before release. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

3 3

cancel Stylesheets meeting?
by Syd Bauman 18 Jan '19

18 Jan '19

For various reasons it looks like Martin, Elisa, and myself are the only ones who will make the Stylesheets meeting this coming Mon 21 Jan 19 at 14:00Z. (James? Maybe you will be there?) Thus perhaps we should cancel this one, especially since Mon is the last day to work on tickets (other than typos) before release.

1 0

Call in 20 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 18 Jan '19

18 Jan '19

Dear all, Our call starts in 20 minutes. https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh…<https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh…> Best wishes, Martina

1 0

tei:object updates
by James Cummings 17 Jan '19

17 Jan '19

Hi TEI Council, Minor changes: As you know I'm finishing off the tei:object element introduction and I've made a number of requested changes. I modified objIdentifier to objectIdentifier, added some more prose including a note in the prose of the Guidelines saying: "Please note: The object<https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rel…> element is a recent addition to the TEI Guidelines and as such may be more prone to further revision as its use develops. This may be particularly evident where its contents borrowed from msDesc<https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/rel…> have yet to be generalized from their use in the context of manuscript descriptions." (I've made a note to myself to remove this at a later date.) Perhaps I should also put it as a remark on the object element specification page. Lots of minor changes: One of the legacy problems about basing object descriptions on (and as a more general form of) manuscript description is that numerous of the descendants of object specify in their descriptions that they are specifically to do with manuscripts. Often quite unnecessarily so. This is *already* out of date because with elements like typeDesc and typeNote we explicitly recommend the use of msDesc for objects which are not manuscripts (but early printed books, clay tablets, etc.). To solve this problem I've gone through all of the elements instantiated by the manuscript description chapter and rephrased any manuscript-specific terminology in the most minimal way possible. In almost all the cases this involved merely inserting 'or other object' after the word 'manuscript'. In some cases the description already said 'manuscript or manuscript part' and I changed this to 'manuscript, manuscript part, or other object'. Generally the changes were fairly simple, for example with the 'institution' element I changed it from: === <desc versionDate="2007-04-26" xml:lang="en">contains the name of an organization such as a university or library, with which a manuscript is identified, generally its holding institution.</desc> === to: === <desc versionDate="2019-01-17" xml:lang="en">contains the name of an organization such as a university or library, with which a manuscript or other object is identified, generally its holding institution.</desc> === A list of all of the changes as a single commit is at: https://github.com/TEIC/TEI/commit/41e7ce9ff35fd584eb3b314398a223987a04f5b0 if anyone wishes to check through them. In some cases (such as institution above) it might be better if instead of a phrase like 'manuscript or other object' or indeed 'manuscript, manuscript part, or other object' we just changed it to 'object'. i.e. above "contains the name of an organization such as a university or library, with which an object is identified, generally its holding institution". The reason I've not done this at the moment is to maintain the transparency of the legacy of these elements originating from the manuscript description module. (And indeed, one does not get these elements inside object unless that module is loaded -- which is fine to me.) Dimensions: On a related but slightly different issue, while going through the elements instantiated by the manuscript description module I reminded myself that dimensions, dim, height, width, and depth are all instantiated by this module even though I believe they are used by people not doing manuscript descriptions. I believe it might be worth revisiting their descriptions and consider moving them to the core module or similar at some point. One of the things that I noticed is that the descriptions of height, width, and depth are specific to text-bearing objects. So without change, for example, I could not provide the height, width, depth of an object that has not got any text on it. The descriptions are: === <depth> contains a measurement measured across the spine of a book or codex, or (for other text-bearing objects) perpendicular to the measurement given by the width element. <height> contains a measurement measured along the axis at right angles to the bottom of the written surface, i.e. parallel to the spine for a codex or book. <width> contains a measurement measured along the axis parallel to the bottom of the written surface, i.e. perpendicular to the spine of a book or codex. === I'm happy to put in an issue about this but potential generalising rewording might be: === <depth> contains a measurement from the front to the back of an object, perpendicular to the measurement given by the <width> element. <height> contains a measurement measured along the axis at a right angle to the bottom of the object. <width> contains a measurement of an object along the axis parallel to its bottom, e.g. perpendicular to the spine of a book or codex. === I'll stick this last bit in an issue. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk Senior Lecturer in Late-Medieval Literature and Digital Humanities School of English, Newcastle University

1 0

Travel to and Accommodation in DC
by Raffaele Viglianti 17 Jan '19

17 Jan '19

Dear Council, As you start planning for your trip to DC in May, I thought I would send over some recommendations. Here is a map summarizing the information below: https://goo.gl/bqEA4k You have writing access to add hotels / AirBnBs you find if you so wish. Here is a google doc with the same text as below: https://goo.gl/nDzGq9 Both are in our TEI Council shared folder on Google Drive. *Airports*See if you are able to arrive to and leave from National Airport (DCA). You may find good flights via NYC or other East Coast cities, but no direct international flights except Canada. This airport is very close to downtown and very easy to reach by public transport or by a very affordable ride with a rideshare app. The main international airports are Dulles airport (IAD) and Baltimore-Washington (BWI). IAD has shared shuttle services (e.g. https://www.supershuttle.com/) as the metro to the airport is still under construction. BWI has shared shuttles and a train to Union Station. It also has a bus to the nearest DC metro station (Greenbelt), cash only https://www.bwiairport.com/to-from-bwi/transportation/transit/wmata. *Accommodation* DC hotels can be expensive. I would recommend to keep an eye out for deals. AirBnB is a more affordable alternative, where I see options under USD$100 per night. I recommend booking soon. Given that we'll spend most of our time at the Folger, I would recommend staying in these areas. *Walking distance*: Eastern Market, Capitol HIll, H Street Corridor, Union Station *Easy metro or bus access* (see below): Penn Quarter, Chinatown, Mt Vernon Sq/Convention center, NoMa, Southwest Waterfront, Navy Yard *Travel within the city* The DC area transport authority is called WMATA. The metro is frequent but will be packed downtown at peak times (if the government is open, lol). Buses are frequent, reliable and go everywhere. Find routes and a trip planner here: https://www.wmata.com/ . Google Maps is fairly reliable too as it uses their API. I strongly recommend purchasing a SmartTrip card at the dedicated machines in metro stations. They cost $10 with $8 credit. A bus ride will be around $2, while metro rides start at $2 and will cost more based on distance traveled. NB If your card credit goes negative after a metro ride, you will have to top up the card in order to exit the station. *Food* There will be plenty of lunch options around Folger at a 5-10 minute walk. For dinner, if we want to stick together, we'll likely hang around Eastern market (10min walk), H street (25min walk), or Chinatown (30min walk) depending on where people's hotels are, etc. I would love to have you all over at my place in the Columbia Heights neighborhood for dinner one evening. It's easily accessible via metro or bus. I'm not sure what would be the best evening for that, though. Suggestions welcome! Hope this helps and I look forward to having you in DC! Let me know if you have questions. Raff

1 0

Next call: January 18
by Scholger, Martina (martina.scholger＠uni-graz.at) 15 Jan '19

15 Jan '19

Dear all, this is the agenda for our next call on Friday, January 18 (16:00-17:30 EST, 21-22:30 GMT, 22:00-23:30 CET) https://docs.google.com/document/d/1n84gm-VcqR-UjBV1mDyd-l5PN-cgKYM2CD5QPAh… Please add topics / issues to the agenda. @Hugh: can we use this meet link again: https://meet.google.com/rnm-hjax-dgg ? Best wishes, Martina

1 0

unihanProp element #1805
by Scholger, Martina (martina.scholger＠uni-graz.at) 14 Jan '19

14 Jan '19

Dear Council, Last week we (SB, RV, HC, MS) had a productive call with Martin Holmes and Duncan Paterson on issue #1805 (https://github.com/TEIC/TEI/issues/1805), the new <uniHan> element. These are the full minutes (https://docs.google.com/document/d/1JsEaZU1H7EJMwXJmNgRLjOZoJOg6AHzMcDM41zb…) and here is the summary of our proposal (please correct me if I forgot something): We have all agreed that the introduction of a new element is a good idea. But we then came to the conclusion to better call it <unihanProp>. In the course of this, we would suggest to introduce two more elements, <localProp> and <unicodeProp>. The three elements should be child elements of <char> and <glyph> and have @name and @value (instead of the property name in <localName>/<unicodeName> and <value>). Consequently, this would necessitate to deprecate <charProp>. * Phase 0: Create att.gaijiProperties with @name and @value, to be used by <unicodeProp>, <localProp>, and <unihanProp>. * Phase 1: add the new <unicodeProp>, <unihanProp>, and <localProp> elements with closed valList for unicodeProp/@name and unihanProp/@name, along with prose changes. * NOTE: The entry for "charProp" in the content models of <char> and <glyph> becomes instead " ( charProp* | ( unicodeProp | unihanProp | localProp )* )", and a) <charProp> is deprecated (for some years), and b) the three new elements are members of a new class that has a required @name (which used to be the content) and a maybe required @value (which used to be the sibling <value>). * Phase 2: Test the more aggressive validation of all @values based on @name and regexes from TR 38. If it's not too onerous to run and to maintain, integrate it. * Phase 3: Update prose and specs for <unicodeName> and <localName> to deprecate the old mechanisms and recommend the new attributes. * Phase 4: Write scripts to pull values from Unicode documents as part of the TEI build process to validate @name and @value. This is the current mechanism: <charProp> <localName>daikanwa</localName> <value>36</value> </charProp> And this would be the new one: <char> ... <localName property="daikanawa" value="36" /> ... </char> And here a <unihanProp> example: <char> ... <unihanProp property="kRSUnicode" value="r1"/> ... </charProp> Please let us know what you think of our proposal soon. As soon as we give Duncan the green light, he will work on the implementation. Just for clarification: this will not go into the January release. Best wishes, Martina

1 0