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

website archeology: symlinks
by Kevin Hawkins 16 Jul '18

16 Jul '18

Folks, The backup of the TEI's web presence didn't include symlinks, we Ian (copied here) is having to recreate these. He has some notes from when the TEI website was moved to the ADHO infrastructure, but there are still some open questions, especially regarding the configuration used for P5 releases. He's looked at tei-install.sh (used in the release process) but still has some questions. I'm not sure who knows this process best. It might even be someone no longer on Council like James Cummings or Martin Holmes. Could someone get in touch with him to answer some questions? Kevin

2 1

listObject, objectName, object
by James Cummings 15 Jul '18

15 Jul '18

Hi all, In case you didn't notice, I added a comment to https://github.com/TEIC/TEI/issues/327#issuecomment-405109022 detailing my work today on the listObject, objectName, and object element. I was tasked with producing a strawman proposal. However, this strawman is fairly complete, and is fully implemented (saving prose in the Guidelines...there are some placeholder div/p) in the jamescummings-object branch of the repo. What I'm intending to do here is give a way for people to describe objects (text-bearing or otherwise) with the minimal number of changes to the existing TEI but with the maximal amount of expressiveness. Since the ticket has been hanging around since 2011 (and was certainly discussed before that), and we discussed it in detail at the F2F in Victoria, I think it better to get something minimal into the Guidelines and the develop it based on requests thereafter. I'm hoping that *after* the current release we might get it into the dev branch with some tweaks. The objectName, listObject, and object have the same relational semantics as you'd guess from persName/listPerson/person or placeName/listPlace/place. The content model is sort of like msDesc but without msIdentifier (but with model.nameLike so the objectName and idno etc) and without msContents. The example I've used is the text-bearing object: the Alfred Jewel. In any case, thought I'd mention it in case any of you not frantically doing tickets before our upcoming freeze would want to check it out and suggest any (hopefully minor) changes that you think should change before it works its way into the Guidelines after the release, then let me know. Many thanks, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University

1 0

test
by Scholger, Martina (martina.scholger＠uni-graz.at) 15 Jul '18

15 Jul '18

Hi all, this is just a test to check if the Council list is affected by the disk failure as well... Best, Martina

1 0

Stylesheets group meeting 2018-07-03 summary
by Syd Bauman 03 Jul '18

03 Jul '18

Quick summary of today's meeting: * SB, EB, HC, MH, RV * Seems no one has made any significant progress * Discussed tickets 136 and 138 * Consensus was that we think it is right that 138 is a "go". * MH has already committed code that adds rend="outOfDateTranslation" to the TEI Lite intermediate stage in ODD processing. * As for display, we lean towards something relatively subdued: a following asterisk with a mouse-over of "translation may be out of date" or some such. * We also think it would be a good idea if the interface allowed the reader to provide a suggested translation on the spot. E.g., there could be a "provide improved translation" link, which would launch an e-mail (or perhaps a web form) with the English value and space for a suggested translation. We opened a new ticket for this suggestion: TEI#1780. * Spent quite a bit of time on the tangential issue as to whether or not *all* constructs (elements, attributes, attribute value enumerations) should have glosses. In doing so we discovered that there are a few elements that should have glosses under the current editorial rules do not (e.g., <macroRef> and <modelGrp>). I do not think we created ticket for either of these issues, though. * It was proposed that we try meeting a week before Council regularly. We decided to keep with the current schedule (of the Tue following Council) for the summer, and that SB will post a Doodle poll or some such to figure out a new meeting time-slot for the next semester.

1 0

Stylesheets group - when to meet?
by Syd Bauman 22 Jun '18

22 Jun '18

We hold our meetings the Tue following the TEI Council meeting. Thus we had originally scheduled Tue 07-03 (at 13:00Z). However, Council has moved their Thu 06-28 meeting to Mon 07-09. Do we want to keep our meeting at the same slot, or move it? A) Tue 07-03 (keep it the same) B) Tue 07-10 (move it to the Tue after Council) C) Tue 07-17 (move it to the Tue the week after Council) D) Something else (will probably require Doodle poll) Personally, I am currently available all 3 of those, so I don't really care.

4 3

Connecting to teic.org?
by Hugh Cayless 19 Jun '18

19 Jun '18

Can anyone else connect to tei(a)teic.org? It's timing out for me. Just trying to figure out whether the problem's on my end or the server's. Thanks, Hugh

1 1

Re: [tei-council] TEI to Spanish meet-up at DH Mexico
by Alejandro Bia 16 Jun '18

16 Jun '18

Yes. I can also send it to the members of the HDH Association. Let me know the email address you prefer to use. Estimados colegas, En un esfuerzo por promover la disponibilidad y distribución plurilingüe de la Guía/manual del TEI, el Consejo Técnico del TEI desea invitarlo a una reunión informal y a una sesión de planificación a realizarse durante la próxima conferencia anual ADHO-DH que se celebrará en la Ciudad de México, para planificar y debatir la traducción de las especificaciones de la Guía del TEI al español. Nos encantaría contar con su participación en este esfuerzo después de la recepción inaugural del congreso DH el martes 26 de junio a las 8 pm. Si desea unirse a nosotros, por favor escriba una breve confirmación a martina.scholger(a)uni-graz.at <mailto: martina.scholger(a)uni-graz.at>. Best, Alex.- At 14:57 14/06/2018, you wrote: >Hi all, > >I'd like to send out the invitation for the >informal TEI to Spanish meet-up tomorrow and have some questions: > > 1. Alex, could you help me with the > translation? I think it would be nice to have one for Spanish mailinglists. > 2. I can remember that James recently told > me that there is an email address for the > Council chair which I can use for such > purposes. Can you tell me again what it is? I cannot find it... > 3. Does anyone have more ideas for channels: > TEI-L, redHD (mailinglist), Humanidades > Digitales on Slack, http://listserv.uleth.ca/mailman/listinfo/globaloutlookdh-l > 4. See the draft below... > >I'm glad to report that Gimena del Rio Riande and Luis Meneses will join us! > >Dear colleagues, > >in an effort to promote the multi-lingual >availability and distribution of the TEI >Guidelines, the TEI Council would like to invite >you to an informal meet-up and planning session >at the upcoming ADHO DH annual conference in >Mexico City, to plan and discuss the translation >of the TEI Guidelines specifications into Spanish. >We would be delighted if you would participate >in this endeavor after the DH Opening Reception >on Tuesday 26 June, at 8 pm. If you would like >to join us, please write a brief confirmation to >martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>. > >Best wishes, >Martina > > > >Martina Scholger >Zentrum für Informationsmodellierung >Austrian Centre for Digital Humanities >Universität 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/> > >Institut für Dokumentologie und Editorik e.V. | https://www.i-d-e.de/ >Chair of the TEI Technical Council | http://www.tei-c.org/ > >-- >tei-council mailing list >tei-council(a)lists.tei-c.org >http://lists.lists.tei-c.org/mailman/listinfo/tei-council > >PLEASE NOTE: postings to this list are publicly archived --------------------------------------------------------- ALEJANDRO BIA e-mail: abia(a)umh.es CIO - DEMI Centro de Investigación Operativa Departamento de Estadística, Matemáticas e Informática Área de Lenguajes y Sistemas Informáticos Universidad Miguel Hernández Ed. Torretamarit, Av. Universidad s/n, CP:03202, Elche, ESPAÑA Web: http://dhw.umh.es/alex-bia/ Tel: +34 966658973 Skype: alex-bia Twitter: @alex_bia --------------------------------------------------------- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 3

TEI to Spanish meet-up at DH Mexico
by Scholger, Martina (martina.scholger＠uni-graz.at) 14 Jun '18

14 Jun '18

Hi all, I'd like to send out the invitation for the informal TEI to Spanish meet-up tomorrow and have some questions: 1. Alex, could you help me with the translation? I think it would be nice to have one for Spanish mailinglists. 2. I can remember that James recently told me that there is an email address for the Council chair which I can use for such purposes. Can you tell me again what it is? I cannot find it... 3. Does anyone have more ideas for channels: TEI-L, redHD (mailinglist), Humanidades Digitales on Slack, http://listserv.uleth.ca/mailman/listinfo/globaloutlookdh-l 4. See the draft below... I'm glad to report that Gimena del Rio Riande and Luis Meneses will join us! Dear colleagues, in an effort to promote the multi-lingual availability and distribution of the TEI Guidelines, the TEI Council would like to invite you to an informal meet-up and planning session at the upcoming ADHO DH annual conference in Mexico City, to plan and discuss the translation of the TEI Guidelines specifications into Spanish. We would be delighted if you would participate in this endeavor after the DH Opening Reception on Tuesday 26 June, at 8 pm. If you would like to join us, please write a brief confirmation to martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at>. Best wishes, Martina Martina Scholger Zentrum für Informationsmodellierung Austrian Centre for Digital Humanities Universität 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/> Institut für Dokumentologie und Editorik e.V. | https://www.i-d-e.de/ Chair of the TEI Technical Council | http://www.tei-c.org/

1 0

example examples; where is our <schemaSpec>?
by Syd Bauman 13 Jun '18

13 Jun '18

I'm confused. I am trying to remove macro.anyXML from P5 per its deprecation message. You might think this would be trivial. Remove the one reference to it from Source/Guidelines/en/ST-Infrastructure.xml,[1] and `git mv Source/Specs/macro.anyXML.xml Source/Defunct/`. Presto. No such luck. I've been at this for hours, now, and I'm getting quite close. The problem I'm running into now is that (in my local directory) <egXML> is now defined by <anyElement>, not by macro.anyXML, as the latter does not exist. But when used in a content model, <anyElement> (for reasons I cannot explain and I doubt anyone can) does not permit elements from the TEI namespace or the <teix:egXML> element. In P5 itself, it makes sense to disallow elements from the TEI namespace in <teix:egXML>. But I don't think it makes sense to disallow <teix:egXML> from being used inside <teix:egXML> itself. In fact, *we use a <teix:egXML> inside a <teix:egXML> twice in P5*, both in the tagdoc for <egXML>. So I thought I would try removing the restriction for P5 itself that <anyElement> not allow <teix:egXML>. The tagdoc for <anyElement> says Default elements and namespaces to be excluded are set on the <att>defaultExceptions</att> attribute of the <gi>schemaSpec</gi>. <att>except</att> may be used when the exceptions need to be locally specified. So, I went off looking for the <schemaSpec defaultExceptions="teix:egXML http://www.tei-c.org/ns/1.0"> for P5. To my surprise, I could not find *any* <tei:schemaSpec> that seems to be the definition of our schema.[2] Anyone know where the <schemaSpec> generated by the source in Source/ is? I'm guessing there isn't one, and that's why you *always* need to use a customization file (if only tei_all), because it is what has the <schemaSpec>. But then, where are the default exclusions for @except of <anyElement> declared? I tried changing the <anyElement> in the <content> declaration of <egXML> to just except="http://www.tei-c.org/ns/1.0", in the hopes that that would override (rather than add to) the default. Didn't work. So I went back to re-defining <teix:egXML> in p5odds.odd. But I think that has always been a mistake, and hope we can find some other fix. Committed at b1e0267. Hope Mr. Jenkins is happy. Notes ----- [1] Like many other macros, it is part of ST via an XInclude, so you just have to delete the one line. [2] Excluding Exemplars/ and Test/, the following are all the .xml or .odd files that have a <schemaSpec>, and their attributes: | ---------Incubator/TBX/TEI-TBX.odd | ident=TBXBasic | start=TEI teiCorpus | | ---------P5/p5odds-examples.odd | ns=http://www.tei-c.org/ns/Examples | ident=p5odds-examples | prefix=TEI_ | start=p egXML | | ---------P5/p5odds.odd | ident=p5odds | prefix=TEI_ | start=TEI schemaSpec elementSpec classSpec macroSpec dataSpec div | | ---------Extensions/Menota/menota.odd | ident=menota | start=TEI teiCorpus | | ---------Extensions/Lite/teilite.xml | ident=teilite | start=TEI | | ---------Extensions/ProtestantCemetery/cem.odd | ident=teicem | start=TEI teiCorpus | | ---------Extensions/BNC/bncxml.odd | ident=bncxml | xml:lang=en | prefix= | ns= | start=teiHeader bncDoc teiCorpus | | ---------Extensions/Lampeter/lampext.xml | ident=lamptei | start=TEI teiCorpus | | ---------Documents/notatedMusic/notatedMusic.xml | ident=tei_notatedmusic | docLang=en | xml:lang=en | targetLang=en | start=TEI TEICorpus | | ---------Documents/TCW/anyXML.odd | ident=anyXML | | ---------Documents/oddmanual/index.xml | ident=oddex1 | start=TEI | | ---------Documents/oddmanual/teidoc.odd | ident=teidoc | | ---------Documents/Object/object.odd | ident=object | start=TEI | | ---------Documents/pureODD/chainingTuto/justTranscription.xml | ident=justTranscription | start=text | source=motherODD.compiled | | ---------Documents/pureODD/chainingTuto/motherODD.xml | ident=mother | start=TEI | | ---------Documents/pureODD/chainingTuto/justMetadata.xml | ident=justMetadata | start=teiHeader | source=motherODD.compiled | | ---------genetic/geneticTEI-0.xml | ident=geneticTEI | docLang=en | prefix=tei_ | start=teiCorpus TEI | xml:lang=en | targetLang=en | | ---------genetic/geneticTEI.xml | ident=geneticTEI | docLang=en | xml:lang=en | targetLang=en | | ---------genetic/p5genetic.xml | ident=testgenetic | start=TEI | | ---------I18N/examples.odd | ident=examples | prefix=TEI_ | start=TEI | | ---------I18N/testodd.xml | ident=test | start=TEI | | ---------I18N/teilite-es.xml | ident=teilite-es | start=TEI

1 0

Re: [tei-council] Fwd: oxygen-tei plugin versioning and release process
by Syd Bauman 08 Jun '18

08 Jun '18

From: Martin Holmes <mholmes(a)uvic.ca> Subject: oxygen-tei plugin versioning and release process Hi all, I've been talking with Alex from Oxygen on a ticket on the oxygen-tei plugin repo about something that Council really needs to decide on. One of the reasons we release the stable plugin is so that people who use older versions of Oxygen and can't afford to upgrade can still get the latest TEI and Stylesheets code. For that reason, we've tried to keep our plugin compatible with older versions (currently we still support 15.2). The problem with that is that as Oxygen moves forward and adds new features, we're still building our plugin against an older Oxygen codebase, and therefore installing the plugin can't take advantage of newer features that might be available (such as the Image Map functionality that's recently been added). What I hadn't really realized before Alex explained it is that you can have multiple versions of a plugin which are targeted at different versions of Oxygen. That would enable us to do something like this: 1. Make a tag of the current master branch as 15.2-compatible (so master can be moved forward later without confusion). 2. Create tags for each significant Oxygen version change which may prevent an older version from installing the plugin, or will impact its behaviour. The Oxygen folks will help us with that. 3. Build stable versions of the plugin for release based on each of these, and link to them in the update file, with their maximum supported Oxygen version number specified. 4. Build our "bleeding edge" plugin version against the oxygen_integration branch, which is up to date with the latest Oxygen dev code, so that we get some warning of any upcoming changes to Oxygen that may affect the plugin. Pros: End-users should have more reliable Oxygen functionality within the plugin, and be able to take advantage of all the Oxygen features supported by whatever version they're using. Cons: More complexity in the build process, and more versions of the plugin to version, store, serve and explain. Does this make sense to everyone? Do we want to continue to maintain compatibility with version 15.2, or should we move that forward a bit, and if so how much? Cheers, Martin

1 0