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

Translathon in Vienna
by Scholger, Martina (martina.scholger＠uni-graz.at) 26 May '16

26 May '16

Hi all, I want to raise the issue again whether we should invent a "translathon" for translating the guidelines to German at the TEI Conference in Vienna. Basically, I think the translation of the Guidelines is a good idea and will definitely reach yet a broader community. However, I feel a bit ambivalent about this topic: I know that there are people who would be glad of having a German translation since they feel lost when they start to learn XML/TEI. But I think it is a big challenge to provide an appropriate German version which can be better understood than the English version. It will be a big effort to do the initial translation and then keep it consistent with subsequent changes... As far as I know there have been at least two attempts to translate the Guidelines and they failed due to the lack of common translations of concepts and definitions. German is a bit of an "awkward" language. On the other hand we should probably grasp the opportunity of having three German speaking members at the TEI Council and having this year's members meeting in Vienna. I think we can invite and motivate some colleagues to participate and one can definitely learn a lot by translating. And, as we said, this could provide a possible motivation for other translation attempts... What do you think? How should we proceed to achieve the best result? Best, Martina ---- Martina Scholger Centre for Information Modelling Austrian Centre for Digital Humanities Elisabethstraße 59/III 8010 Graz Austria

2 2

tei not so simple
by Lou Burnard 26 May '16

26 May '16

I've been passing my happy whitsun reading and scribbling increasingly irritated notes on a copy of the current state of the TEI Simple documentation, currently located in the P5/Exemplars branch of the TEI-simple branch. It contains the following discrete chunks of verbiage: 1. Some polemic about why TEI Simple is a good thing, and its design goals 2. A simple introduction to XML 3. A presentation of the elements used by Simple along with examples, almost entirely copied from the equivalent part of the TEI Lite document we all know and love (but extended with some ruminations on e.g. hyphenation) 4. A table showing frequency of Simple elements in various corpora/collections 5. A discussion of the processing model elements, and how they are used in Simple (and indeed how some of them are not used in Simple) 6. A schemaSpec which actually defines the TEI Simple schema. Here's the thing. How much of this do we think should be maintained by the Council as an Exemplar? How much of it should be regarded as of historical interest? How much should be published/archived/maintained elsewhere? The part of this which matters is of course the schemaSpec and (probably) the associated prose describing and instantiating the elements. So my first step was to make that valid (the spec had not been updated to reflect our decision that <param> should be an empty element). At the same time I did my best to make the document as a whole follow our usual praxis as regards depiction of XML constructs (i.e. use of <gi>, <tag>, <att>, <ident>, <code> etc. (Regrettably, this led to my reading (2) above more closely than I would have liked) Next, I checked to see whether the doc contained a <specDesc> for each <elementRef> in the ODD. This is a good way of ensuring that the schema contents match the documentation -- that everything the schema makes available is actually discussed or instantiated somewhere. There are 166 elements in Simple, all but 33 of which have a <specDesc>. Which is definitely not bad, but could be improved. In addition, it occurred to me that since the ODD has to provide specs for all the elements that specify a PM, these could also be enhanced to provide examples better tailored to Simple. I still have some reservations about the way Simple treats the Header -- it really doesn't provide much help to beginners to say "oh there's the header you can put anything you like in there. Good luck." But I can see I'll have to wait for the next release to see those addressed. I found DOZENS of examples of verbiage that needs straightening out -- whether to conform to what I consider a sensible consistent style for this kind of writing, or to address errors of fact, or to remove redundant waffle or to make hand-waving generalities more precise. So what's the way forward? As James said at the FTF, Martin Mueller wants to see Simple "replace" or "merge with" TEI Lite in some vague way, We discussed that, and I don't recall any agreement that this would on the face of it be advisable, and certainly in its current state I would vote against doing so on the basis of this document. On the other hand, we really ought to be putting some effort into making Simple a bit more visible and accessible for its target audience. So I propose the following: -- we work on a slimmed down non-polemical straightforward version of the Simple ODD -- revise the discussion of TEI customisations on the website so that it makes clear which ones are in the Council's remit (I make that Lite, Simple, Tite, Enrich, and possibly -- if they ever get their dung collected -- the ISO spoken one) I'll volunteer for a first cut at the former task. Unless of course you all say, no we like the document as it is just fine thanks.

3 7

Fwd: A proposal for a SIG
by Hugh Cayless 25 May '16

25 May '16

I’m forwarding a proposal to form a SIG around the encoding of Japanese texts. Personally, I think this would be a Very Good Thing. Thoughts pro or con? Hugh > Begin forwarded message: > > From: "Kiyonori Nagasaki" <nagasaki(a)dhii.jp> > Subject: A proposal for a SIG > Date: May 14, 2016 at 3:13:02 EDT > To: "Hugh Cayless" <philomousos(a)gmail.com> > Cc: nagasaki(a)dhii.jp, acmuller(a)l.u-tokyo.ac.jp > > Dear chair of the TEI Technical Council, > > We would hereby like to submit our proposal, in the attached file, for the creation of a TEI SIG for the markup of Japanese texts. Through our discussions and experiments of encoding Japanese texts according to the TEI guidelines, we have come to the conclusion that it would be quite useful to create a SIG within the TEI consortium to develop a consensus of guidelines for encoding Japanese texts. The creation of such a research unit would also no doubt be effective toward the encouragement of Japanese researchers to get involved in the TEI. Moreover, as we write in the proposal, we also are quite open to the idea of expanding this SIG to becoming an "East Asian SIG" for those research communities that share similar writing systems. It might be a model to expand the TEI guidelines to multi-languages and multi-cultures. > > Please do let us know if you need any further detailed explanations regarding the content of our proposal. > > Regards, > > Kiyonori Nagasaki > > -- > Kiyonori Nagasaki, Ph.D. > > Senior fellow > International Institute for Digital Humanities: http://www.dhii.jp/

6 11

Next telecon
by Hugh Cayless 25 May '16

25 May '16

Hello All, Our next meeting will be at 09:00 EDT / 14:00 BST / 15:00 CEST. I’ve posted the beginnings of an agenda here: https://docs.google.com/document/d/1o6Mhb4LrCvzkq0I9IDpyTdTERl4lqtvarid9RHx… We’ll plan to do it as a Google Hangout, with Elli initiating, as she has an account through Brown, and so can bypass the 10-person limit on the call. See you then! Hugh

10 14

Locally defined defined attributes - Issue #386
by Mylonas, Elli 24 May '16

24 May '16

Syd and Elli have regenerated a new version of the list of duplicate attributes.[1] It shows the locally defined elements and the classes they belong to. There are 36 attributes which both belong to a class and are locally defined, many of them on more than one element. For example, @type is locally defined 51 times. We recommend that someone(s) volunteer to look at the various single attributes and classify them as follows: 1. should remain locally defined 2. should become member of an existing attribute class 3. the attribute and other locally defined instances should form a new class 4. should become member of an existing attribute class but its description may need more detail than is provided in the class description. In the last case, we can either try to reword the class description to account for the special case, keep the locally defined attribute, or develop a features that allows an element to belong to an attribute class, but to over-ride the description. Syd and Elli are offering start with some of the simpler examples to test the process, but are happy to hand this off or to work together with others. [1] https://bauman.zapto.org/~syd/temp/4TEICouncil/duplatts.html Elli (for Syd and myself)

1 0

Fw: Mail delivery failed: returning message to sender
by Lou Burnard 22 May '16

22 May '16

Sent from my Honor Mobile -------- Original Message -------- Subject: Re: Mail delivery failed: returning message to sender From: Laurent Romary To: Lou Burnard CC: Hi Lou, I will look at this. Could you pass around the information that I have not been a member of Loria since 2006 and that my stable employer is Inria, hence the address…. THanls. Laurent Le 22 mai 2016 à 16:47, Lou Burnard <lou.burnard(a)retired.ox.ac.uk<mailto:lou.burnard@retired.ox.ac.uk>> a écrit : Sent from my Honor Mobile -------- Original Message -------- Subject: Mail delivery failed: returning message to sender From: Mail Delivery System To: Lou Burnard CC: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: Laurent.Romary(a)loria.fr<mailto:Laurent.Romary@loria.fr> SMTP error from remote mail server after RCPT TO:<Laurent.Romary(a)loria.fr<mailto:Laurent.Romary@loria.fr>>: host mail2-smtp-roc.national.inria.fr<http://mail2-smtp-roc.national.inria.fr/> [192.134.164.81]: 550 #5.1.0 Address rejected. ------ This is a copy of the message, including all the headers. ------ ------ The body of the message is 10371 characters long; only the first ------ 8192 or so are included here. Return-path: <lou.burnard(a)retired.ox.ac.uk<mailto:lou.burnard@retired.ox.ac.uk>> Received: from hub03.nexus.ox.ac.uk<http://hub03.nexus.ox.ac.uk/> ([163.1.154.216] helo=HUB03.ad.oak.ox.ac.uk<http://ad.oak.ox.ac.uk/>) by relay15.mail.ox.ac.uk<http://relay15.mail.ox.ac.uk/> with esmtp (Exim 4.80) (envelope-from <lou.burnard(a)retired.ox.ac.uk<mailto:lou.burnard@retired.ox.ac.uk>>) id 1b4Uel-0002zw-mO; Sun, 22 May 2016 15:47:03 +0100 Received: from MBX01.ad.oak.ox.ac.uk<http://ad.oak.ox.ac.uk/> ([169.254.1.225]) by HUB03.ad.oak.ox.ac.uk<http://ad.oak.ox.ac.uk/> ([163.1.154.216]) with mapi id 14.03.0248.002; Sun, 22 May 2016 15:47:02 +0100 From: Lou Burnard <lou.burnard(a)retired.ox.ac.uk<mailto:lou.burnard@retired.ox.ac.uk>> To: "tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org>" <tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org>>, "s.bauman(a)neu.edu<mailto:s.bauman@neu.edu>" <s.bauman(a)neu.edu<mailto:s.bauman@neu.edu>> CC: Piotr Banski <bansp(a)o2.pl<mailto:bansp@o2.pl>>, Laurent Romary <Laurent.Romary(a)loria.fr<mailto:Laurent.Romary@loria.fr>> Subject: Re: [tei-council] content of <f> in testbasic Thread-Topic: [tei-council] content of <f> in testbasic Thread-Index: AQHRs66KXBdRDhMUjE+Nr79odukgv5/D9y4AgAETDkQ= Date: Sun, 22 May 2016 14:47:02 +0000 Message-ID: <762A68C71238E2469EBDCDF70ADB249460E84DE3(a)MBX01.ad.oak.ox.ac.uk<mailto:762A68C71238E2469EBDCDF70ADB249460E84DE3@mbx01.ad.oak.ox.ac.uk>> References: <900185842.2.1463685216080.JavaMail.jenkins@teijenkins1204> <50368006.3.1463866357697.JavaMail.jenkins@teijenkins1204> <22336.56913.720640.827100(a)paramedic.wwp.neu.edu<mailto:22336.56913.720640.827100@paramedic.wwp.neu.edu>>,<5740EDBA.1090500(a)uvic.ca<mailto:5740EDBA.1090500@uvic.ca>> In-Reply-To: <5740EDBA.1090500(a)uvic.ca<mailto:5740EDBA.1090500@uvic.ca>> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_" MIME-Version: 1.0 --_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The key phrase here is "schematron tests we care about" of course. As noted= earlirr on this thread it's not clear that XML validation of any kind is r= eally useful in this case since proper validation entails something more co= mplicated using the fsd. The fact that our processes depend on the presence= of some arbitrary word in a message seems a bit lame however. Sent from my Honor Mobile -------- Original Message -------- Subject: Re: [tei-council] content of in testbasic From: Martin Holmes To: s.bauman(a)neu.edu<mailto:s.bauman@neu.edu>,tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org> CC: Piotr Banski ,Laurent Romary I have always assumed that tests intended to fail should be in detest, not in the other tests. But to be honest I think the whole set of tests was assembled in a piecemeal manner without much of a guiding plan, so I wouldn't be surprised to discover that there are intentional invalidities elsewhere. But in this particular case, I see the problem. If you look at the parsed log of the last successful build (<http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/parsed_console/>), you'll see this: validateschematron: [echo] Validate using Schematron [xslt] Processing /var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xml to /dev/null [xslt] Loading stylesheet /var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xsl [xslt] A feature value cannot contain both text and element content (tei:* and text()[normalize-space(.) ne '']) [xslt] A feature value can contain only one child element (count(tei:*) gt 1) In other words, these tests DO fail the Schematron check; but because the Schematron error message does not contain the trigger word ERROR, the build is not marked as having failed. In other words, the wrong test is being done in the wrong place the the results are being ignored. Two takeaways from this: 1. All Schematron rules we care about should have "ERROR" in their error messages, otherwise Jenkins is not going to notice them. If that's deemed too scary for end users, we need to find another trigger string that's not so bad, and then configure the Jenkins log parser to pay attention to it. 2. We need to go through all the tests and make sure they're actually working properly. There could be many more examples of this. Cheers, Martin On 2016-05-21 03:16 PM, Syd Bauman wrote: > The Jenkins build of P5 is failing because of the following test in > .../P5/Test/testbasic.xml: > > <fLib xmlns=3D"http://www.tei-c.org/ns/1.0"> > <f name=3D"xxx">A feature may have untyped content</f> > <f name=3D"yyy"> > <string>or typed</string> > </f> > <f name=3D"notgood"> > <string>multiple types</string> > <symbol value=3D"doubleplusungood"/> > </f> > <f name=3D"alsonotgood">mixed content > <symbol value=3D"doubleplusungood"/> > </f> > </fLib> > > I think these are tests that are *supposed* to fail, and thus should > be in the detest/ suite, not here in testbasic.xml. > > 1) Can someone (Martin?) affirm for me that testbasic.xml is > supposed to be valid? > > 2) Can someone (Laurent?, Lou?, Piotr?) affirm for me that an <f> is > supposed to have at most 1 child element (from class > model.featureVal, i.e. one of <fs>, <vColl>, <vMerge>, <vNot>, > <binary>, <default>, <numeric>, <string>, <symbol>, <vAlt>, or > <vLabel>)? > > If I've got this right, I'll just move these tests out of testbasic, > and we'll be up and running again. > -- tei-council mailing list tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived --_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <style></style> </head> <body> <div>The key phrase here is "schematron tests we care about" of c= ourse. As noted earlirr on this thread it's not clear that XML validation o= f any kind is really useful in this case since proper validation entails so= mething more complicated using the fsd. The fact that our processes depend on the presence of some arbitrary word in a= message seems a bit lame however. Sent from my Honor Mobile -------- Original Message -------- Subject: Re: [tei-council] content of in testbasic From: Martin Holmes To: s.bauman(a)neu.edu<mailto:s.bauman@neu.edu>,tei-council(a)lists.tei-c.org<mailto:tei-council@lists.tei-c.org> CC: Piotr Banski ,Laurent Romary </div> <div class=3D"PlainText">I have always assumed that tests intended to fail = should be in detest, not in the other tests. But to be honest I think the whole set of tests <br= > was assembled in a piecemeal manner without much of a guiding plan, so I <b= r> wouldn't be surprised to discover that there are intentional invalidities elsewhere. But in this particular case, I see the problem. If you look at the parsed log of the last successful build (<<a href=3D"http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/pars= ed_console/">http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/parsed_= console/</a>>), you'll see this: validateschematron:       [echo] Validate using Schematron       [xslt] Processing /var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xml to <br= > /dev/null       [xslt] Loading stylesheet /var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xsl       [xslt] A feature value cannot contain both t= ext and element content (tei:* and text()[normalize-space(.) ne ''])       [xslt] A feature value can contain only one = child element (count(tei:*) gt 1) In other words, these tests DO fail the Schematron check; but because the Schematron error message does not contain the trigger word ERROR, the build is not marked as having failed. In other words, the wrong test <b= r> is being done in the wrong place the the results are being ignored. Two takeaways from this: 1. All Schematron rules we care about should have "ERROR" in thei= r error messages, otherwise Jenkins is not going to notice them. If that's deemed too scary for end users, we need to find another trigger string that's not so bad, and then configure the Jenkins log parser to pay attention to it. 2. We need to go through all the tests and make sure they're actually working properly. There could be many more examples of this. Cheers, Martin On 2016-05-21 03:16 PM, Syd Bauman wrote: > The Jenkins build of P5 is failing because of the following test in<br= > > .../P5/Test/testbasic.xml: > >          <fLib xmlns= =3D"<a href=3D"http://www.tei-c.org/ns/1.0">http://www.tei-c.org/ns/1.= 0</a>"> >            <= f name=3D"xxx">A feature may have untyped content</f><br= > >            <= f name=3D"yyy"> >           &nbsp= ;  <string>or typed</string> >            <= /f> >            <= f name=3D"no Laurent Romary Inria, team Alpage laurent.romary(a)inria.fr<mailto:laurent.romary@inria.fr>

1 0

next telcon?
by Syd Bauman 21 May '16

21 May '16

When is our next teleconference? (And for that matter, when are they in general?)

2 3

PureODD question
by Raffaele Viglianti 16 May '16

16 May '16

Hello, I think this is mostly a question for Lou, and any other who was involved in getting PureODD together. I've started converting the MEI ODD to PureODD, so I expect to find a few issues, most of which will likely be caused by my ineptitude, so apologies in advance. Here's the first obstacle I found: In MEI the datatypes of some attributes are defined in <datatype> itself. There a few cases for this: 1. the datatype is very specific to the element and it doesn't need to be re-used. Example: <attDef ident="tab.strings" usage="opt"> <desc>Provides a *written* pitch and octave for each open string or course of strings.</desc> <datatype> <rng:list> <rng:oneOrMore> <rng:data type="token"> <rng:param name="pattern" >[a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?([a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?)*</rng:param> </rng:data> </rng:oneOrMore> </rng:list> </datatype> </attDef> Solution: bite the bullet and move it to a dedicated <dataSpec> 2. The datatype combines a number of pre-defined datatypes Example: <datatype> <rng:list> <rng:oneOrMore> <rng:data type="decimal"/> <rng:data type="decimal"/> </rng:oneOrMore> </rng:list> </datatype> Solution: again create a dedicated <dataSpec>, but it's a bit annoying since this it's just a matter of combining already defined datatypes in a specific way. 3. The datatype involved a choice between a number of pre-defined datatypes Example: <datatype> <rng:choice> <rng:data type="decimal"> <rng:param name="minInclusive">1</rng:param> </rng:data> <rng:data type="time"/> </rng:choice> </datatype> Solution: like 2., but there is also another question: we're relying on the rng datatype for time. Will we have to define our own? Can we use rng's or xsd's definition without breaking the Durand Conondrum? General question: What's the reason to not allow <content> in <datatype>? It also seems a bit strange to allow either dataRef or textNode - it seems to me that it's mixing a reference and a definition, but only if it's a text node. It would seem more logical to just replace <datatype> with <dataRef> and use it to refer to a text datatype. Or, better, just allow datatype to define the datatype there and then like it used to :) Thanks, Raff

2 3

TEI Issue 1454
by James Cummings 10 May '16

10 May '16

Hi Council, In https://github.com/TEIC/TEI/issues/1454 Jakub Simek has asked that <msPart> (and when prompted <msFrag) should claim membership in att.typed. Our normal test for att.typed membership (to reduce unwarranted proliferation and lest we just make it global) is twofold: 1) Is the element repeatable? 2) Can we think of some reasonable examples of how someone might want to classify this element (both generally (@type) and specifically (@subtype) The first is true, and the second seemed obvious to me and Jakub has come back to me on the issue with examples of how they might classify them (and I'm sure many other manuscript cataloguers could come up with additional classifications depending on their approaches and school of cataloguing. I think this is uncontroversial and I've assigned it to me and marked it Status: Go. If there are no comments on the issue objecting before 1 June, I'll implement. -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

1 0

Photos from Providence Face 2 Face
by James Cummings 09 May '16

09 May '16

By the way, if anyone is interested, here are my photos of the Providence face 2 face. I really should take more photos of us working! As usual it looks like all we did was eat and drink and have some nice walks. https://goo.gl/photos/vjiznp3Bs4Ab9NVx6 -James -- Dr James Cummings, Academic IT Services, University of Oxford, Registration Open: Digital Humanities at Oxford Summer School, 4-8 July 2016 http://digital.humanities.ox.ac.uk/dhoxss/2016

1 0