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

more daft alternates
by Lou Burnard 10 Aug '15

10 Aug '15

Something similar occurs in <fvLib> which currently has a model <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <choice> <ref name="model.featureVal"/> </choice> </zeroOrMore> and in <classes> which currently is <choice xmlns="http://relaxng.org/ns/structure/1.0"> <zeroOrMore> <ref name="memberOf"/> </zeroOrMore> </choice> I'm regarding both of these as corrigible errors in the main P5 source and correcting them. But would appreciate feedback on the <langUsage> case.

1 0

default vals and mandatory attributes
by Lou Burnard 07 Aug '15

07 Aug '15

Just for a change, here's a technical query. The TEI Enrich ODD (part of the Exemplars suite) is riddled with things like this: <attList> <attDef ident="columns" mode="change" usage="req"> <defaultVal>1</defaultVal> </attDef> </attList> which are now generating error messages from Schematron like this E [ISO Schematron] It does not make sense to make "1" the default value of @columns, because that attribute is required. Well, Mr Smartypants Schematron, it may not make sense to you, but it did to the folks who defined this ODD, and making their ODD invalid is not going to win you any friends. Could we at least change this to a warning, so that the P5 test suite can run to completion?

3 8

Council's Future
by Hugh Cayless 06 Aug '15

06 Aug '15

As I hinted a couple of emails ago, I'd like to think about new models for how Council might work, with the following things in mind: 1. There is a push underway to improve the gender balance of the Council membership, which I'm fully in favor of, but which means we have a largish list of nominees and therefore the potential for a largish influx of new members in January, and possibly again the following year. My sense is that we could still be better at on-boarding new members. 2. I feel like having Council be purely an elected body carries with it both risks and rewards. The reward is clearly the periodic influx of new ideas and perspectives. The risk is that we lose expertise and continuity when Council members rotate off—and sometimes they rotate off for reasons like they forgot to submit a statement, or didn't read their email. We don't do a very good job of continuing to involve interested contributors after they've left. We say that new members don't have to be super-technical, and that's true, but there *are* wizard-level technical and conceptual components to the TEI and we need to have people who can manage them. As an aside, I'd like to see a push for making it *much* easier to do things like build the Guidelines, but I think we have enough on our plate at the moment. So what could we do to mitigate the risks and amplify the rewards? I've mentioned in the past that I'd like to see, besides the elected body of Council members, a group of committers who serve in much the same way as Council members but are there because they've been appointed and are willing to contribute. Committers might be subscribed to the Council mailing list, participate (as available) on teleconferences, and come to F2F meetings (perhaps subject to budgeting). They would be identified as Committers by the TEI—i.e. they would be listed on the website and could put it on their CVs. There's some precedent for this, of course: we've drafted Lou in the past when he wasn't technically on Council. My point is that, while former Council members don't lose their commit privileges now, they do get removed from the Council list, and are not included in meetings anymore, nor are they recognized in any way, so they lose the incentive to continue to contribute, with the result that they stop. That's not to say that people can't just serve their time on Council and then move on to other things, but that valuable, interested contributors should have a means to continue their work and should be recognized for doing so. Does this sound in any way sensible? What should be the benefits of being a Committer? How would they be appointed? What role(s) would they play? Should they be former Council members, or could we draft anyone (provided they have the ability and desire to contribute of course)? What do you all think? Obviously this would involve some rule changes and I assume we'd have to involve the Board, etc...

7 27

I've just test-migrated my CodeSharing project from SF to GH
by Martin Holmes 05 Aug '15

05 Aug '15

Hi all, especially Raff, our migration manager. I just migrated my project from SF to GitHub in the following steps: === 1. PREPARATION === Do a freeze (not a problem for my tiny project). Make sure you have complete backups and checkouts. Prepare a JSON file called users_sf2gh.json which consists of the equivalent user names from SF and GitHub, like this: { "martindholmes" : "martindholmes", "stadlerpeter" : "peterstadler" } (Obviously this needs a bit of research.) === 2. GETTING TICKETS ETC. OUT OF SF ========================== Do a full export of the SF project from here: https://sourceforge.net/p/[proj]/admin/export This is not instant; you'll get an email when it's complete and you can download it as a zip. That produced these files for me: admin.json discussion.json tickets.json wiki.json It doesn't include the code, of course. === MOVING CODE TO GITHUB ===================================== Go here: https://import.github.com/new/ and follow the instructions to import your code. This was quick for my tiny project, but would take a long time for the TEI codebase. The commit history is preserved correctly, as far as I can see. I provided the https URL for the SF repo: https://svn.code.sf.net/p/[proj] While that's going on, or after it's finished, you're offered the option to provide the list of SF/GitHub user equivalences you've already specified in the JSON file, through a web form (you'll use the JSON file itself later, when importing tickets). === MOVING TICKETS TO GITHUB ================================= I used this PERL script for this: https://github.com/cmungall/gosf2github Beware: there is a typo (occurring in two places) which omits a quotation mark in the example; I've added a patch and sent a pull request to fix it. There are several stages to this: 1. Set up an OAUTH token for the Git repo here: https://github.com/settings/tokens 2. Get a list of the project collaborators in JSON format from github like this: curl -H "Authorization: token YOURTOKEN" https://api.github.com/repos/[entity]/[project]/collaborators > [project]-collab.json 3. Run the PERL script, which pulls down each ticket from SF and pushes it up to GitHub -- this is my command line: perl gosf2github.pl -a martindholmes -u users_sf2gh.json -c codesharing-collab.json -r martindholmes/CodeSharing -s codesharing/tickets -t [MYTOKEN] tickets.json You can run it with the -k flag first to do a dry-run and see the curl statements that would be addressed to github without sending them. This successfully imported the two tickets I had created as a test, one open and one closed, with embedded XML code successfully preserved. Hope this helps. It's nice to be on vacation. There's time to actually do stuff. :-) Cheers, Martin

4 7

Test GLs repo on GitHub
by Hugh Cayless 03 Aug '15

03 Aug '15

All, I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like. Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard. Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future. GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.

5 19

Why are we using a pantor.com namespace?
by Martin Holmes 31 Jul '15

31 Jul '15

In Utilities/guidelines.xsl.model, I see this: xmlns:pantor="http://www.pantor.com/ns/local" and something similar in the following files: Query/simplify.xsl Utilities-1/colorsvg.xsl Utilities-1/divsplit.xsl Utilities-1/generate-label.xsl Utilities-1/guidelines-latex.xsl Utilities-1/guidelines-print.xsl Utilities~1/guidelines.xsl.model Utilities~1/odd2ebnf.xsl Utilities~1/odd2exodd.xsl Utilities~1/rng2ebnf.xsl Utilities~1/split.xsl Utilities/guidelines-print.xsl Sometimes it maps to the prefix "pantor" and sometimes to the prefix "local". pantor.com seems to be some kind of electronic stock trading platform: <http://www.pantor.com/> The Stylesheets repo contains a file called RngToRnc.xsl, which is an ancient stylesheet apparently dating back to 2002, last edited by Syd in 2010. But this does not appear to use the pantor: or local: prefixes, and neither prefix seems to be actually used anywhere. Does anyone have any recollection of what was going on here? If we're not using this namespace, it would be good to get rid of it, especially since it's usually rather confusingly mapped to the prefix "local". Cheers, Martin

2 3

svn:keywords
by Peter Stadler 29 Jul '15

29 Jul '15

It just occurred to me that GitHub won’t support svn:keywords such as $Date$ or $Rev$. Humans will probably adjust themselves but I don’t know whether any software piece in our (some) processing pipeline relies on this information? Best Peter

5 5

SF restore is not complete yet
by Martin Holmes 28 Jul '15

28 Jul '15

Hi all, Just an update on the SF situation: I just tried to upload a new release of Roma to the Files area and that functionality is not yet working; it fails when you try to do it over SSH from the command line, and the GUI which is supposed to be available to admins on the website is not there yet. That means we cannot yet release updated versions of anything. Me no like. I'm copying Kevin on this in case he knows anything about the bandwidth expectations/agreements/limits that might pertain to our shared hosting with ADHO; it seems to me that we might well want to serve our files from our own server if we can. We had 1117 downloads of P5 (which is about 256MB) from SF in the last year, which would amount to less than 300GB per year. Could our hosting deal handle that? Cheers, Martin

2 3

July Telecon
by Hugh Cayless 28 Jul '15

28 Jul '15

Hi all, A reminder that we need to schedule our July telecon in a week or so. Please fill out the poll at http://doodle.com/xy2hqrpk9swnzhzd <http://doodle.com/xy2hqrpk9swnzhzd> if you haven’t yet. I’ve been traveling for a while, so I’m running a little behind on organization, but I’ll try to have an agenda up this week. Possible agenda Items: Source Control and administration discussion Fall F2F App validation? Ticket review What else? /** * Hugh A. Cayless, Ph.D * Chair, TEI Technical Council * Duke Collaboratory for Classics Computing (DC3) * hugh.cayless(a)duke.edu * http://blogs.library.duke.edu/dcthree/ **/

9 16

Re: [tei-council] Something weird about tei-c.org
by Martin Holmes 28 Jul '15

28 Jul '15

Hi Kevin, Sebastian et al, I've just done a quick bugfix for the Roma PHP webapp: <https://sourceforge.net/p/tei/bugs/724/> and tested it locally and it seems to work fine. As far as I can tell from browsing around the projects/tei/web/Vault directory, the current deployed version of Roma on tei-c is 4.15; the new build is 4.18. The system looks similar to the setup for P5, where the "current" symlink points to whatever should be the current version. I think (but I'm not sure) that we can get a new version deployed like this: - Create new 4.18 directory - Get the latest build from Jenkins: <http://teijenkins.hcmc.uvic.ca/job/Roma/lastSuccessfulBuild/artifact/tei-ro…> and unzip it into there. - Change the "current' symlink to point at it. However, there's something slightly odd going on. As far as I understand it, tei-roma/roma.php requires a file called config.php in the same directory. That file is (I thought) created by copying the file config-dist.php to config.php and then customizing it as necessary for the local install. roma/roma.php contains this: require_once( 'config.php' ); so it it's definitely expected to be available. But in current/tei-roma/roma, there is no config.php; there are various versions of config-dist.php resulting from what appears to be an svn conflict, where the differences amount only to the version number and date. So my question is: am I wrong about the fact that config.php is expected to be created from config-dist.php? That is what I did on my local test install, and it worked fine. If I'm right, that would seem to suggest that Roma on tei-c.org has been running slightly misconfigured, and managing without the missing config.php somehow (perhaps error messages are being suppressed). Does anybody know anything about this? I'm not seeing any documentation on how to deploy the PHP Roma, so I've started a new section on the wiki page: <http://wiki.tei-c.org/index.php/Roma#Getting_the_Roma_server_running> Cheers, Martin On 15-07-27 01:44 PM, Kevin Hawkins wrote: > As you've probably seen by now, we did in fact get a notification from > Uptime Robot, and it's already back up. > > This is the first time I've seen the TEI site go down while I'm at my > computer. The ADHO site remained up during that time, and given how > often I've seen notifications that that site goes down while the TEI > site stays up, it appears that these two sites function independently > despite sharing a hosting service. > > Nick, I'm going to turn off the Uptime Robot notifications for the ADHO > site for now. > > Kevin > > On 7/27/15 3:42 PM, Martin Holmes wrote: >> Hi Kevin, >> >> I was just working on Roma on tei-c when it stopped responding. I then >> went to try tei-c.org, and the site doesn't seem to be responding. If >> you ping it, the ping is returned by digitalhumanities.org, so tei-c >> appears to be up for services like isup.me, but wget requests never get >> a response, and I see this proxy error message eventually in my browser: >> >> Proxy Error >> >> The proxy server received an invalid response from an upstream server. >> The proxy server could not handle the request GET /index.xml. >> >> Reason: Error reading from remote server >> >> Additionally, a 502 Bad Gateway error was encountered while trying to >> use an ErrorDocument to handle the request. >> >> Just letting you know, because I don't know whether uptimerobot will >> notice it. >> >> Cheers, >> Martin

3 3

Looks like the SF svn repo is back up
by Martin Holmes 26 Jul '15

26 Jul '15

<http://sourceforge.net/blog/category/sitestatus/> I was able to do an svn update successfully on the TEI repo and my own CodeSharing repo. Cheers, Martin

1 0

F2F in Lyon in Oct
by Syd Bauman 24 Jul '15

24 Jul '15

Hugh -- Do we have definitve dates for the F2F in Lyon in 2015-10 yet? James and I are supposed to be at a meeting in Germany on Thu 10-22, Fri 10-23, and maybe Sat 10-24. The pre-conference workshops will be Mon 10-26, Tue 10-27, and Wed morning 10-28; conference proper from Wed afternoon 10-28 through Sat 10-31.

3 2

ODD question
by Hugh Cayless 22 Jul '15

22 Jul '15

Hello all, Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.x… <https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.x…> wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is… Thanks, Hugh /** * Hugh A. Cayless, Ph.D * hugh.cayless(a)duke.edu * Duke Collaboratory for Classics Computing (DC3) * http://blogs.library.duke.edu/dcthree/ **/

9 36

bug report: @rend vs @rendition
by Syd Bauman 20 Jul '15

20 Jul '15

Sourceforge is currently down, so I'm posting this here in lieu of a bug report. Will transfer it to a ticket assigned to me later. --------- The remarks associated with att.global.rendition say Where both @rendition and @rend are supplied, the latter is understood to override or complement the former. This seems correct to me. The prose of section 1.3.1.1.3 "Rendition Indicators" says In the TEI scheme, it is possible to supply information about the appearance of elements within a source document in the following distinct ways: 1. One or more properties may be specified as the default for all elements of a given type, using the @render attribute to point to rendition elements ; 2. One or more properties may be specified for individual element occurrences, using the @rend attribute with any convenient set of one or more sequence-indeterminate tokens; 3. One or more properties may be specified for individual element occurrences, using the @rendition attribute to point to rendition elements; 4. One or more properties may be supplied explicitly for individual element occurrences, using the @style attribute. If the same property is specified in more than one of the above ways, the one with the highest number in the list above is understood to be applicable. At the very least, 2 & 3 should be reversed, and use of the @selector of <rendition> needs to be added to the list. But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash. And why does @style override @rend? I think I'd prefer the reverse (but I'm not sure). Typo: extra space before semicolon in <item> #1.

4 9

question on <xenoData>
by Syd Bauman 14 Jul '15

14 Jul '15

First, <xenoData> should be a member of att.declarable. I think that's pretty much a no-brainer, but raise it here in case someone wants to object. But my next issue is at least non-obvious, if not controversial (and I hope it's not). How is a process to know whether the metadata supplied in <xenoData> applies to the TEI document or to the source thereof? Several possibilities jump to mind. 1) It doesn't. This is not our problem. Any project using <xenoData> will know what metadata they are using, so they'll figure it out just fine. 2) We add a new attribute to <xenoData>, @describes. Its possible values are "source" and "transcription" or some such. 3) We use a special @type (with values "source" and "transcription" or some such) for this, even though it's not quite right. 4) We add <xenoData> to att.typed and let projects come up with their own values of @type to assert this information. Maybe with suggested values (4a), maybe not (4b). 5) Instead of making <xenoData> a member of model.teiHeaderPart, and thus a younger sibling of <fileDesc>, we allow <xenoData> to occur as a child of <fileDesc> or as a child of <sourceDesc> (via membership in model.sourceDescPart). In the former case the metadata in <xenoData> is understood to apply to the TEI document; in the latter case the metadata in <xenoData> is understood to apply to the source from which the TEI document was derived. 6) Like (5), but leave <xenoData> as a member of model.teiHeaderPart instead of (6a) or in addition to (6b) a direct child of <fileDesc>. Personally, I'm leaning very strongly towards (2), (5), or (6a). That is, I think (1), (3), (4a), and (4b) are bad ideas, and prefer (6a) to (6b). That said, I'm open to thoughts, ideas, and suggestions.

8 36

feasibility and NVDL (and <xenoData>)
by syd＠paramedic.wwp.neu.edu 11 Jul '15

11 Jul '15

If the content model of <xenoData> is any.XML+, then the valid= of any <egXML> that contains a (valid) <xenoData> had better be "feasible" (or "false", I suppose), lest that <egXML> be flagged as having "error: unfinished element" by ./run-onvdl p5valid.nvdl v.xml If the content model of <xenoData> is any.XML*, then the valid= of the <egXML>s can be "true". This doesn't make sense to me, as the NVDL explicitly allows elements from the namespaces involved. But I'm guessing that before it checks the <egXML> itself for validity against the RELAX NG, it has removed elements from other namespaces (thus leaving an empty <egXML>). What is the difference between using "feasible" and "true" as far as processing is concerned? I.e., how does the feasibly-valid-checker (called p5.nvdl) know to apply the http://www.thaiopensource.com/validate/feasible to those <egXML>s flagged as "feasible" or "true", and how does the truly-valid-checker (called p5valid.nvdl) know not to? Must, of course, be that the latter is run against "v.xml", not p5.xml, but when and how is v.xml generated? For now I've checked in a version (to the P5-for-xenoData/ branch) with any.XML+ that uses "feasible" on its <egXML>s.

1 0

A quick question
by Martin Holmes 07 Jul '15

07 Jul '15

Can someone please remind me how to declare an attribute such that its content can be one or more of a set of values drawn from a fixed list? In other words, a closed valList, but allowing more than one item from the list. I'm sure I must have done this before, but I can't remember it. Cheers, Martin

2 1

readable xenoData
by Syd Bauman 04 Jul '15

04 Jul '15

I've put a complete copy of a P5-for-xenoData/ *with a built set of Guidelines and Exemplars* at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/. So see, e.g. http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Guidelin… (And someone let me know what the heck is the problem with the formatting -- it looks awful.) And use the schema at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Exemplar… to test it out.

3 5

link
by Hugh Cayless 29 Jun '15

29 Jun '15

https://docs.google.com/document/d/17EBZ56GTUpJM1pwhMYXx7NvKqA-W6OYZBv_GeHO…

3 5

App. Crit. discussion summary
by Hugh Cayless 29 Jun '15

29 Jun '15

Dear all, I’m trying to summarize the conclusions of the discussions Martin, Raff, and I had following the Ann Arbor meeting concerning what to do with block-level variation. If I’ve left out anything important, please correct me! * Syd’s suggestion that we allow more or less universal @wit and use that to distinguish between block-level variants doesn’t really fly, I’m afraid. It leads to a rather chaotic document, with a need for liberal use of @exclude attributes. It would be both hard to work with, and potentially quite hard to render. * The group feels that adding new app/lem/rdg elements for each level of block possible would also be too much. * We discussed at length whether a bending or breaking of the TEI Abstract Model† was in any way desired by structural app partisans. My own feeling is that it’s not, and Marjorie (the original filer of the bug) doesn’t want to do that sort of thing either: http://sourceforge.net/p/tei/bugs/753/#cd40/b53c <http://sourceforge.net/p/tei/bugs/753/#cd40/b53c> * Given that, we think some sort of structural app is needed. But we need to work on checking for Abstract Model violations and adding documentation warning against using structural app for evil. I’ve started to play with Schematron rules, but haven’t gotten as far as actually testing them yet. I may need some help generating a schematron document for my schema. For a bit of fun, you might want to check out the paper and demo I gave last week that uses HTML Custom Elements to render a TEI file with apps containing lines. The demo is at http://hcayless.github.io/appcrit/Propertius-1-15.html <http://hcayless.github.io/appcrit/Propertius-1-15.html> and the paper at https://github.com/hcayless/appcrit/blob/master/docs/DLL-seminar-paper.md <https://github.com/hcayless/appcrit/blob/master/docs/DLL-seminar-paper.md> † though I note that the actual definition is recursive (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#CFAM <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#CFAM>). The TEI Abstract Model is whatever the Guidelines says it is...

1 0

Google Hangout link
by Hugh Cayless 29 Jun '15

29 Jun '15

Here’s the link: https://plus.google.com/hangouts/_/g32giwnw3t5eqysbfveh5sd2lma I have also called in to the Economy Conference Call service, so you can join there if you prefer. Seems to work. It’s playing Vivaldi at me.

1 0

Next Telecon
by Hugh Cayless 29 Jun '15

29 Jun '15

We’ve had 7 participants in the Doodle poll for the next telecon, and the best date/time seems to be next Friday 6/19, at 09:00 EDT / 06:00 PDT / 14:00 BST / 15:00 CEST. I think this will be a relatively short meeting, mostly just followup on items from the F2F. Let’s do Google Hangouts again, but I will try to loop in the conference call as well, so that people can call into that if the internet isn’t playing nice. Hugh

8 12

Agenda for Monday
by Hugh Cayless 29 Jun '15

29 Jun '15

* Critical Apparatus Report * Status report on Standoff * Fall F2F update * Ticket Review from F2F If James is on the call, maybe he can tell us whether there’s anything new from Simple, but I don’t want to pressure the folks in Sydney to stay up half the night. You are excused unless you really want to join!

3 2

Monday's call
by Hugh Cayless 26 Jun '15

26 Jun '15

Hi all, I've been swamped this week prepping for and am now at a meeting in Oklahoma, so I've been slow getting agenda details out, but I will follow up on that later today. We will be meeting Monday the 29th at 07:00 PDT / 10:00 EDT / 15:00 BST / 16:00 CEST / 00:00 AEST in a Google Hangout, which I will initiate Monday morning and send the details out by email beforehand. I will also attempt to call into the Economy conference call system, so you can join that way if you need or prefer to. Details below: US: 866-906-0040 or 857-288-2640 Canada: Use US number. UK: 0800-016-3440 Germany: 0800-182-0270 France: 0800-916-758 Italy: 800-789-804 The access code is 5753850 (followed by the '#' key)

2 2

Re: [tei-council] Release of the Oxygen plugin
by Syd Bauman 26 Jun '15

26 Jun '15

Another post that did not make the list (and there are several more to follow), this one from 2015-06-02 10:18, and is now mostly irrelevant. > Sigh. That's too bad. Perhaps we should start with something > distinctly out of range. Kinda the way Apple did with the re-launch > of its signature operating system for Macintosh when it changed to > Unix-based. So we'd start with "10.0.0", and go up from there. > > Or perhaps not, and "3.0.0" will do just fine. > > > We can't start with a version below what's currently installed in > > people's Oxygens, I don't think, otherwise it won't show as an > > update.

2 1

Datatype quandary
by Lou Burnard 26 Jun '15

26 Jun '15

We had agreed (fairly tentatively, but it is what Sebastian has since implemented) that in the new scheme of things, a purified attribute definition would simply embed a <dataRef> directly, rather than wrap it in some as-yet-unnamed alternative to the current <datatype> element. In testing this out against the Guidelines, I have now realised why this was not a good idea. Of the 466 instances of <datatype> in the current P5 source, a sizeable proportion (106) specify a @maxOccurs attribute to indicate that the attribute can (or cannot) take multiple instances of the datatype indicated. This can't be specified on <dataRef> itself at present, these attributes nopt being available. So we are left with the following choices: a) add @maxOccurs and @minOccurs to <dataRef> and cope with the ensuing chaos if the <dataSpec> being referenced permits multiple values b) define a whole raft of new <dataSpec>s and <dataRef>s, one for each combination of occurrence indicators and <dataref>, so that for example we will have teidata.pointer, teidata.pointers, teidata.atLeastTwoPointers etc etc. c) invent something which behaves just like <datatype> but has a different name and doesn't allow anything except <dataRef> as a child. d) permit <dataRef> as a child of <datatype> I bet smart chaps like you can tell which solution I am recommending... just for the record, the current model for <datatype> is an alternation of <macroRef> and "any-XML". In practice we use only the latter, as every <datatype> has a content resembling <rng:ref name="data.foo"/>. So proposal (d) above is arguably not really a change at all, since <dataRef> is just syntactic sugar for <macroRef> I'd like to move ahead on this this week, since it's holding up my testing of the purified version of the Guidelines. Can I ask for a quick response along the lines of EITHER "no problem" OR "hold on there I need to think about this" by Monday??? Or of course, "You idiot what about this completely different and much better solution"

2 4

Re: [tei-council] Datatype quandary
by Syd Bauman 26 Jun '15

26 Jun '15

I'm sure you've thought this through much more thoroughly than I, so I'm wondering if you can explicate this for me. Our end goal is to have a system in which the Guidelines, customization files, and non-TEI languages are expressed in PureODD, and all our processing chains work at least as well as they do now, right? But once we have the various processing working so that we can define one datatype using <dataSpec> and refer to it from a content model or attribute definition (or macro specification) with <dataRef>, why wouldn't we define them all that way? I realize that getting all our processing working is a tall order, as there is lots to do and some of it is very hard (or, at least, way beyond me). But if it works for one datatype, why not all? The answer might involve the fact that we're trying to build processing that can simultaneously handle *either* impure ODD or Pure ODD. While this seems nice to me, it doesn't strike me as a requirement. So perhaps I'm asking "why do we need co-existence?" If users are told "use all old or all new style ODD, submit old style to this process, new style to that process", I have no real problem with that. I guess I'm fuzzy on why co-existence is easier than big bang. If you could focus my lens on this, I'd appreciate it. > yes, if you want to go for co-existence you need all macroSpec and > new dataSpec coexisting in the same name pool. > > I dont think we are ready for a big bang conversion

1 0

Re: [tei-council] Touching Once (is so Hard to Keep)
by Syd Bauman 26 Jun '15

26 Jun '15

I think, or at least hope, this is the last of the "it didn't get delivered to list" re-posts. This one is from 2015-06-02 08:04, and was also sent to Sebastian, who answered me directly. Per his answer, reproduced below, I renamed the program 'Touch' to 'build-if-newer.sh' in r13246. (I post here in part because the commit message refers to this e-mail.) Since nothing has broken with the name-change (and some things work better), we could just delete the program entirely. > [Subject is the title of the last song on _Novella_, the 1977 > Renaissance album.] > > Can you tell me what the shell script "Touch" in directory P5/ is > for? It seems to do "If anything in ../P5/, ../Stylesheets/, or > ../I18N/ has been updated, then run a bunch of builds". But why, and > more importantly, why is it called "Touch"? Is it executed from some > other program(s) or only intended to be typed at the commandline? > > This turns out to be a real, if minor, problem, because while most > GNU/Linux systems default to case-sensitive file-systems, the Mac OS > X "Darwin" commandline defaults to a case-insensitive file-system. > Thus when running `make` on Mac OS X, this pgm gets executed when the > Makefile tries to execute a `touch`. > > I'd like to change the name of this cmd to > Touch.sh > build-if-updated.sh > make-if-updated.sh > or some such. > > P.S. I'm asking you, Sebastian, because no one but you has touched > this file (pardon the pun) in its entire Subversion hx on > current SF (i.e., since 2007-10 when you "put back executable > Touch"). SPQR> honestly, I have no memory of this script. i suggest you delete SPQR> it and see if anything breaks.

1 0

Re: [tei-council] bad date example
by Syd Bauman 26 Jun '15

26 Jun '15

This is from 2015-06-02 10:12, and is worth reading and reminding ourselves of the issue. > Indeed. Clearly there is controversy over this, although I thought it > would be pretty straigtforward. So that we don't forget to address > it, I've just created bug 762 and made it amber. > > BTW, yes, <precision> is, IMHO, the right answer. The problem there > is that @atLeast and @atMost are (appropriately) defined as > data.numeric, not a temporal datatype. > > Using LOC dates would also solve the problem. > > > Digging a little bit in the archives reveals that we had that sort > > of discussion before. Personally, I’m with Syd and would not mix > > notBefore/notAfter with from/to (nor with when) but this seems not > > to be agreed practice: > > * http://tei-l.970651.n3.nabble.com/Precision-of-time-information-for-state-t… > > * http://tei-l.970651.n3.nabble.com/datable-attributes-and-durations-of-uncer… > > BTW, for all sorts of fuzziness we have <precision>.

1 0

Re: [tei-council] New Jenkins build jobs for bleeding-edge and stable plugin
by Syd Bauman 26 Jun '15

26 Jun '15

This one from 2015-06-02 10:15. > > What do you see if you go to Help / Manage Add-ons? I see only one, > > the bleeding build. > > I see only one, but don't know which one it is. (Nor do I know how to > tell, unless I decipher the version #, which in this case is > "2.8.2".) > > > > I think the Preferences page just lists all updateSite.oxygen files > > that are known to Oxygen, not those which are active. > > > > Your post nicely copies my original post to the list, though, which > > I was supposed to re-send, so I'll consider it re-sent.

1 0

Re: [tei-council] repair 751, take 1
by Syd Bauman 26 Jun '15

26 Jun '15

I sent this 3 weeks ago (on 2015-06-05 23:32), but as far as I can tell, it never made it to the list itself. At least, it doesn't seem to be in the archives, and no one has responded. I realize some folks are off to my namesake city, but I'd like to get this off my plate. > Reminder to everyone to take a look at the solution in the branch at > https://svn.code.sf.net/p/tei/code/branches/P5/for-bug-751 Unless > there are objections, I'll plan to fold this in on or about Fri > 06-12. > > Problem: <event> is not allowed as a child of <org> > > Current ways <person> and <place> get child <event>: > > model.persEventLike => birth death event listEvent > model.placeEventLike => event > > > Proposed way <org>, <person>, and <place> get child <event> (in that > branch): > > new class, model.eventLike > > model.orgPart => model.eventLike > model.personPart => model.eventLike > place => model.eventLike > > removed model.placeEventLike and model.persEventLike (and made > <birth> and <death> directly members of model.personPart) > > > One might argue that we should keep model.persEventLike and > model.placeEventLike, and add model.orgEventLike. But since 2 of > those classes would have nothing but <listEvent> and <event> as > members, I took the slimmer route.

1 0

Fwd: Re: NVDL error from forums
by Martin Holmes 25 Jun '15

25 Jun '15

This is a patch from Radu. I've tested this and it works perfectly; our Spec and Guidelines files can now be validated. I'm waiting to hear if this is going to be part Oxygen 17.1. Either way, anyone editing specs or guidelines will probably want to install this. It seems to be the case that dataNode.xml, dataRef.xml, dataSpec.xml and interleave.xml are invalid, but I'm guessing it's because they reference each other, and can't validate against the last release of the schema. I'll try validating them against the latest Jinks NVDL. Cheers, Martin -------- Forwarded Message -------- Subject: Re: NVDL error from forums Date: Wed, 24 Jun 2015 09:19:02 +0300 From: Radu Coravu <radu_coravu(a)sync.ro> To: Martin Holmes <mholmes(a)uvic.ca> CC: Oxygen XML Editor Support <support(a)oxygenxml.com> Hi Martin, Applying the patch would be something like: 1) In the Oxygen installation folder there is a "lib" folder. In that folder you should create a new folder structure like: > endorsed/com/thaiopensource/validate/schematron/resources/ 2) In the "resources" folder copy the Schematron file I'm attaching. This patch should override the Schematron file which comes with the "jing.jar" library. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 6/23/2015 8:51 PM, Martin Holmes wrote: > Hi Radu, > > Many thanks for looking into the NVDL issue for us. On the board post: > > <http://www.oxygenxml.com/forum/topic11601.html> > > you mentioned a patch I could try out for you -- do you want to send it > over? > > The other solution (changing the prefix) is something we can fall back > to if we have to, but it will involve editing a lot of files (Schematron > is distributed all over our specification files), so I'd rather try > something else first. :-) > > Many thanks, > Martin >

1 1

interleave.xml?
by Martin Holmes 24 Jun '15

24 Jun '15

There's a file called interleave.xml in the Specs. Its log shows: r13221 | sbauman | 2015-05-27 18:03:01 -0700 (Wed, 27 May 2015) | 1 line Add the 'Id' Subversion keyword to source files that don't have it. ------------------------------------------------------------------------ r13076 | louburnard | 2014-11-21 04:18:32 -0800 (Fri, 21 Nov 2014) | 2 lines add interleave; fix bug #700 in tite Is it still an active part of the Pure ODD plan? Cheers, Martin

2 1

odd gotcha (or bug?)
by Lou Burnard 24 Jun '15

24 Jun '15

ODD processing always has a surprise up its virtual sleeve. Let's suppose your ODD wants to add <persName> and <orgName> and <placeName> from the namesdates module. Let's further suppose you want to see only W3C date values in your dating attributes. So your ODD has something like this <moduleRef key="namesdates" include="orgName persName placeName"/> <classSpec type="atts" ident="att.datable-iso" mode="delete" module="namesdates"/> <classSpec type="atts" ident="att.datable-custom" mode="delete" module="namesdates"/> Sound plausible? But it doesn't do what you expect. In the first place, the presence of the module attribute on <classSpec> generates the following entirely mysterious schematron error : E [ISO Schematron] Specification att.datable-custom: the value of the module attribute ("namesdates") should correspond to an existing module, via a moduleSpec or moduleRef In the second place, the moduleRef to namesdates will naturally include those classes along with the elements you've requested. In the third place, if you realise this is happening (and you are a smart ODD coookie if you do), you can replace the moduleref with elementRefs for the elements you want <elementRef key=orgName/> <elementRef key="persName"/> <elementRef key="placeName"/> Whereupon, huzza, those pesky classes disappear. Not because of your <classSpec>s of course, but because you've removed the moduleRef` In fact you can remove the classSpecs completely: if there is any way to delete a class which is specific to a module (i.e. not defined in the tei module), this isn't it, though it works fine for classes which *are* defined in that module.

4 16

pics from Ann Arbor
by Syd Bauman 23 Jun '15

23 Jun '15

No time to do anything nice with these, so this is just a pile (of reduced-size images) without any digital editing or album software. These two links are to the same set of 52 images: http://bauman.zapto.org/~syd/temp/4TEICouncil/Ann_Arbor_2015-05/ http://bauman.zapto.org/~syd/temp/4TEICouncil/Ann_Arbor_2015-05.tgz The all-at-once tarball is ~11 MiB.

1 0

NVDL validation of spec files
by Martin Holmes 23 Jun '15

23 Jun '15

As you may have noticed, our NVDL validation process for files in the P5 Source has been failing recently, with this error: "Attribute @xsl:dummy-for-xmlns is not allowed on element <xsl:stylesheet>" I raised this on the Oxygen forum, and we have two possible solutions suggested by Radu: <http://www.oxygenxml.com/forum/post34459.html> One involves a patch to Oxygen, which I'm going to try out first. If that works, I think we should just wait for it to come out in 17.1. The other involves changing the namespace prefix in our isosch file, which looks trivial but will need some investigation to make sure it will work just in that individual file, or whether there are other uses of that prefix that will need to be brought in line elsewhere in the specs. I don't think so (except for one in constraintSpec.xml), but some caution might be in order; there's a lot of stuff in Utilities that looks like it might be affected. Cheers, Martin

1 0

Re: [tei-council] Three kinds of data ref
by Lou Burnard 19 Jun '15

19 Jun '15

But why would you bother to do that when you can put a valList in dreckly? (could use xinclude if v lazy) On 19/06/15 18:56, Sebastian Rahtz wrote: > @ref could point to a remote TEI doc with a dataSpec which is just a valList > > Sebastian

1 0

dataSpec content
by Lou Burnard 12 Jun '15

12 Jun '15

I had proposed defining dataSpec without any wrapper element for the parts of it which actually define the datatype itself i.e. with an (alternate|dataRef|valList) in its content model. Sebastian points out, reasonably enough, that this makes life difficult for someone wishing to modify or change the "content" of an existing dataSpec, and is not consistent with our previous practice. I take the point, but find it hard to imagine anyone wanting to write an ODD which would modify one of our existing datatypes, when defining a new one with a different name would be much simpler and more transparent. Indeed, maybe you shouldnt be allowed to modify existing datatypes. Thanks to Sebastian's much-appreciated late night activity, the Pure ODD branch on SF (P5-Pure) now has a test file and we have a test implementation to test.... yours in purity L

3 2

p5odds-examples-odd
by Lou Burnard 10 Jun '15

10 Jun '15

I just noticed that recent changes have made p5odds-examples.odd invalid. This is the ODD file that defines the schema which is used by nvdl to validate examples in the body of the Guidelines, so it's fairly crucial that it continue to function. The error is only detected by schematron, and relates to defaultVal fiddling: I have corrected the ODD and checked it in, but I am now wondering at what stage exactly in the build process does the corresponding RNG file get generated. Simply running Make doesn't hack it, so it must be amongst the arcana involved in doing a new distribution. anyone else noticed this?

2 3

F2F Minutes Frozen
by Hugh Cayless 10 Jun '15

10 Jun '15

I’m getting ready to publish the minutes from Ann Arbor, so I have frozen the Google Doc. If you have any remaining changes you want to put in, you should let me know immediately. Thanks, Hugh /** * Hugh A. Cayless, Ph.D * Chair, TEI Technical Council * Duke Collaboratory for Classics Computing (DC3) * hugh.cayless(a)duke.edu * http://blogs.library.duke.edu/dcthree/ **/

1 0

Re: [tei-council] dataypes: the never ending story
by Syd Bauman 09 Jun '15

09 Jun '15

I understand completely that conversion to Pure ODD is a big deal, but is converting <datatype> to <dataSpec> going to have a much larger impact than using <elementRef> instead of <rng:ref>, etc.? My point is that conversion to Pure ODD is a big deal either way, no? I think you're right, project management, and maybe even some money, is in our future. (And I can already hear Hugh muttering "git-fork" under his breath. :-) > my heart slightly fails me when I start thinking about the side > effects of dropping <datatype> and converting all the Guidelines to > <dataSpec>. The existing .odd files out there stop working > (potentially), Roma stops working, as does its little cousin > Byzantium, the documentation of the Guidelines probably gets hosed, > a small myriad of utilities fall over. > > I hate to say it, but changes of this scale need a bit of project > management. > > else you need a team of dedicated people fixing things on the fly.

2 1

dataypes: the never ending story
by Lou Burnard 09 Jun '15

09 Jun '15

If we are to abide by Martin's eminently suggestion of permitting the new pure odd dataRef to coexist with the current <dataype> mechanism, I can't see any way out of doing the following a) make a set of new <dataSpec> elements corresponding with the existing <macroSpec type="dt">s b) since @ident values are supposed to be unique, these new things will all have to have different names (I suggest teidata.foo rather than data.foo) c) the current section 1.4.2 on datatype macros (#DTYPES, in #ST) will also need to be cloned, or substantially revised, since this is where the pesky things are actually defined Anyone got any better ideas?

3 11

unencoded words that maybe should be
by Syd Bauman 08 Jun '15

08 Jun '15

I'm going over the minutes, and strolled across bug 740. It lists an instance where a few words that should have been encoded as <gi> were not. I wondered about others. So I created http://bauman.zapto.org/~syd/temp/4TEICouncil/list-of-PCDATA-idents.html In principle, it is probably a useful task for someone to go through this set and find the few that really should be encoded as <gi> or <ident> and fix them. In fact, it's obviously a huge task that would take multi-person coordination and lots of time for little benefit.

1 0

iso schemaron syntax
by Lou Burnard 08 Jun '15

08 Jun '15

Does this look vaguely right <sch:assert test="name(parent(.))='dataSpec' and not(contains(dataRef))">An alternate element inside a dataSpec may contain only dataRef children </sch:assert> ? #tooLazyToLookItUp

2 2

oxygen-tei plugin
by Martin Holmes 08 Jun '15

08 Jun '15

Hi all, Sebastian released a new version of the Stylesheets yesterday, prompting a new version of the oxygen-tei plugin, so I've taken the opportunity of this release to enact some changes we agreed on a while ago: The new version number of the plugin is 3.0.0; this disentangles its version numbering from P5 releases. The new location and file name for the plugin is: http://sourceforge.net/projects/tei/files/oxygen-tei/oxygen-tei-3.0.0.zip The file is now named oxygen-tei-x.x.x.zip to match the actual project name and to distinguish it from the debian package, and it's in a new folder called "oxygen-tei". I've left the old "tei-oxygen" folder on SF in place for the moment, just in case, so right now there's additional potential confusion, but if all is well after a couple of days I'll do two things: 1. Move the last couple of releases with the old filenames into the new folder and give them new filenames, adjusting the updateSite.oxygen file accordingly. 2. Remove the old folder and the rest of the old versions. Please yell if you don't think I should do either of those things. Cheers, Martin

2 2

Implementation of @selector on <rendition>
by Martin Holmes 08 Jun '15

08 Jun '15

At the FtF I got the go-ahead to implement the feature request described in detail here: <http://wiki.tei-c.org/index.php/Proposal_for_@selector_attribute_on_renditi…> with the proviso that I should once more call it to everyone's attention for any final objections before I go ahead and do it. If I don't hear objections in the next few days I'll make this change. Cheers, Martin

1 0

nvdl validation of Spec files in Oxygen not working
by Martin Holmes 08 Jun '15

08 Jun '15

Lou and I discovered the other day that the current setup by which Oxygen validates Spec files when you're editing them does not work for some reason. That means that when you're editing a Spec file, you have to be extra careful not to screw anything up. We don't know why it's not working; it looks like something changed around the time of the release of Oxygen 16.1. Cheers, Martin

1 0

defaultVal deprecation
by Martin Holmes 08 Jun '15

08 Jun '15

Hi all, I think a couple of messages got lost when the lists went weird last week, so I thought I should summarize something I need feedback on. I was under the impression that I had the go-ahead to remove defaultVals when the Council was convinced it was a good idea, but Syd reminded me that we should actually deprecate things for a couple of years before removing them. However, there is no mechanism for deprecating <defaultVal>; it's not a member of att.deprecated so it can't have @validUntil added to it. So I hereby recommend that <defaultVal> be added to att.deprecated. If I don't hear any shouts of objection within the next couple of days I'll do that. That of course will require that the Guidelines build then do something with @validUntil on <defaultVal>. That will be my next order of business on this ticket. Meanwhile, I've created this wiki page with all the current defaultVals: <http://wiki.tei-c.org/index.php?title=DefaultVal_candidates_for_removal> It turns out that there are no required attributes with defaultVal, so that low-hanging fruit doesn't exist. Cheers, Martin

1 0

New Jenkins build jobs for bleeding-edge and stable plugin
by Martin Holmes 04 Jun '15

04 Jun '15

Hi all, I have what looks like a working setup on my Jenkins box for building two versions of the Oxygen TEI plugin. The original build job, "oxygen-tei", to which some of you may have subscribed, is now replaced by "oxygen-tei-bleeding", to which you can subscribe here: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei-bleeding/lastSuccessfulBuild/…> while there is also now "oxygen-tei-stable", to which if you want you can subscribe here: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei-stable/lastSuccessfulBuild/ar…> The idea is that oxygen-tei-bleeding builds with the latest plugin code against the latest trunk builds of P5 and the Stylesheets, enabling us to see if any change to any of these has broken the plugin; oxygen-tei-stable builds with the latest plugin code, but against the current release versions of P5 and the Stylesheets, enabling us to see what a release version of the plugin would look like if either we or Syncro built one right now. The build is now being done with ant, and in addition to these two targets, there's also: ant syncro which builds a version for the Syncro folks using the latest stable P5 and Stylesheets, as they would do when creating a build for a new Oxygen release. Up to now they've been using our original update-and-upload.sh script, and then preventing it from uploading to SourceForge as it tries to do. That script also requires that you _know_ the correct versions of P5 and the Stylesheets, and supply them correctly on the command line; the new ant build script works that information out for itself. Finally, there is: ant stable which is what our release technician would use during a P5 release process, or what we would use to release an official build of our version of the plugin. This builds in the same way as the version above, but also offers to upload the result to SourceForge, and creates a new version of the updateSite.oxygen file which it offers to upload to tei-c.org. This should make releasing a new plugin version much easier, I hope (although it can only truly be tested for real when we come to release a version, so I'd like to be the one who runs it for real the first time in case something goes wrong). I've added the new job configs for Jenkins to SVN, where James can find them for the Oxford Jenkins, when he has the time. This is all brand-new and only gently tested, so let me know if you try anything, and please report any problems with as much detail as you can. Cheers, Martin

3 4

Minutes Doc and scheduling
by Hugh Cayless 04 Jun '15

04 Jun '15

Hope that by now everyone’s made it home safely. Can we all look over the minutes doc while the meeting is still fresh in our memories and correct/add anything that’s missing? I will plan to freeze the document on Friday June 5th and convert the minutes over for the website. Re scheduling the next telecon: Do we want to try to stick with Fridays at 09:00 or 10:00 EDT? That’s 06:00/07:00 PDT, 14:00/15:00 BST, 15:00/16:00 CEST. I’m flexible as to day of the week during the summer—when I’m not actually away, of course. Fridays in June/July look particularly difficult. I’ll either be on vacation or away on business for several of them. Doodle poll for June telecon: http://doodle.com/q5ixp76erdceeydk <http://doodle.com/q5ixp76erdceeydk> Doodle poll for July telecon: http://doodle.com/xy2hqrpk9swnzhzd <http://doodle.com/xy2hqrpk9swnzhzd> Doodle poll for August telecon: http://doodle.com/txi5p2cn3mhmfizr <http://doodle.com/txi5p2cn3mhmfizr> Thanks to all of you for your hard work last week. It felt to me like we covered a lot of ground. All the best, Hugh

8 10

defaultVals for removal
by Martin Holmes 03 Jun '15

03 Jun '15

Hi all, Re this ticket: <https://sourceforge.net/p/tei/feature-requests/546/?page=1> I was under the impression from our discussion at the FtF that my job was to present the case for removing defaultVals one by one, and then remove them if Council did not object. However, Syd points out that this should be done through deprecation, so I've now added @validUntil on <defaultVal> on att.fragmentable/@part. We'll see what shows up in the Guidelines build as a result -- I'm not sure whether there's adequate handling in the Stylesheets for it. Meanwhile, I've generated a complete list of atts with defaultVal here: <http://wiki.tei-c.org/index.php/DefaultVal_candidates_for_removal> since that seems to be what Syd was expecting. He was tasked with removing those which are on required attributes, but there don't seem to be any of those. Cheers, Martin

1 1

Re: [tei-council] [tei:feature-requests] #546 <defaultVal> should be removed from all specs
by Syd Bauman 02 Jun '15

02 Jun '15

Martin -- We'll talk tomorrow, I'm sure, but I'm not sure this is OK. I know you hate default values, as do I, and we want to get rid of them. But I'm not sure it's acceptable to yank them out w/o warning. DTD users might be upset. Besides, changing the semantics of a value like that is the sort of thing users need warning about. Those who actually have part="N" explicitly expressed may well be using it to say "I can't tell if this is a fragment or not". MH> att.fragmentable's @part now has no defaultVal, and the "N" value MH> now actually means "no", as it should. Rev 13232.

2 6

dataSpec content
by Lou Burnard 31 May '15

31 May '15

I'm still poking away at my datatype replacement ticket ... We agreed that <dataSpec> should be used to fully specify a TEI-defined datatype and also noted in passing that its existing <content> child needed additional constraints (e.g, it shouldnt allow you to supply elementRefs) In fact it seems to me that the "content" of a dataSpoe should be much more restrictive: I'd like for it to contain just <alternate>, <sequence>, <valList>, or <dataRef>, with the additional constraint that <alternate> and <sequence>s it contains can contain only one or more <dataRef>s If no-one has any counterproposal that's what i am planning to try to implement anyway.

2 1

Fast-track a simple ticket
by Martin Holmes 31 May '15

31 May '15

Hi all, This ticket: <https://sourceforge.net/p/tei/feature-requests/561/> arose out of our re-working yesterday of Laurent's standoff proposal. I'd like to fast-track it if we can; it seems straightforward to me, and doesn't involve any Birnbaum issues. While I get around to figuring out the actual change to the Spec file, could you all check to see if you have any objections to it in principle? Cheers, Martin

6 7

rng:group but no rng:choice
by Peter Stadler 31 May '15

31 May '15

I just stumbled across the content model of climate (and there are more …) which looks like <content> <rng:group> <rng:zeroOrMore> <rng:ref name="model.headLike"/> </rng:zeroOrMore> <rng:choice> <rng:group> <rng:oneOrMore> <rng:ref name="model.pLike"/> </rng:oneOrMore> </rng:group> <rng:group> <rng:oneOrMore> <rng:ref name="model.labelLike"/> </rng:oneOrMore> </rng:group> </rng:choice> <rng:zeroOrMore> <rng:choice> <rng:ref name="model.noteLike"/> <rng:ref name="model.biblLike"/> </rng:choice> </rng:zeroOrMore> <rng:zeroOrMore> <rng:ref name="climate"/> </rng:zeroOrMore> </rng:group> </content> My question is: is there some magic to the surrounding rng:group or could that be deleted? (I don’t intend to do so but was just wondering …) Best Peter

2 2

rework of standoff proposal
by Peter Stadler 31 May '15

31 May '15

Dear all, a Council working group (PFS, LB, MH, FC, SM, PWS) just created an alternative proposal as the "Ann Arbor" branch at https://github.com/laurentromary/stdfSpec/tree/AnnArbor. The changes in detail: * killed mapStruct * renamed annotationGrp —> listAnnotation * renamed model.annotationPart —> model.annotation * got rid of dash in module name * removed class att.confidence in favor of https://sourceforge.net/p/tei/feature-requests/561/ * added some more elements to model.annotation * removed standOffHeader in favor of teiHeader(!!) We did not update the examples yet. I’m curious about Laurent’s reaction and will probably have a conf call in the next week with him (— Laurent?!) Best Peter

5 12

Recommendations on values of @xml:id (FR #540)
by Raffaele Viglianti 31 May '15

31 May '15

Hi all, Martin Mueller asked on the list for recommendations on good uses of xml:ids, which resulted in a good discussion and a FR. I summarized the main suggestions on the ticket on SourceForge, but I post them here as well because I think we need to discuss this further, see below. The Guidelines already have some recommendations (numbering based on doc structure): * The Guidelines already suggest numbering based on doc structure ( http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CORS2) * Use 3 letters (e.g. from the title)+ 3 digits, incremental. E.g. HOL001, HOL002, etc.. * Same as above, but no fix number of digits. E.g. HOL1, HOL2, etc. * Prefix an id with name of element (this is simpler version of what the Guidelines already recommend) * Give tei:TEI an id and prefix every other id in the document with it (to guarantee cross-corpus uniqueness) These are all reasonable suggestions and there can be plenty more - which is why I think that the TEI should *not* give any recommendation on best practices for xml:id because it's a project management issue, not an encoding one. Myself, I prefer random ids, a practice that avoids introducing yet another level of complexity and data management. I understand the human readability, but sequences are too easily broken. And when parsing, relying on ID content instead of TEI content sounds like a bad idea.

7 16

Next defaultVal to be nuked
by Martin Holmes 30 May '15

30 May '15

I hereby nominate att.divLike/@org's defaultVal: <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.divLike.html> This has its own novel brand of silliness: There are two values, and the first value, "composite", means "no claim is made about the sequence in which the immediate contents of this division are to be processed, or their inter-relationships." Yet THIS IS NOT THE DEFAULT VALUE; the _other_ one, "uniform", which _does_ make a claim, is the default. Well FFS. It shall die unless I hear otherwise in the next few hours. cheers, Martin

3 5

eXist-db password changed
by Peter Stadler 29 May '15

29 May '15

Sid argued strongly that we should change the admin password for the eXist-db that serves Roma (the issue arose around the discussion of tickets [feature-requests:#527] and [bugs:#747]). Hence, I duly changed the password and documented it as described in [1] and briefly checked that Roma still works. If you encounter any side effects, please let me know! Best Peter [1] http://www.tei-c.org/Activities/Council/Working/tcw22.xml

2 1

Reconvene at 14:30
by Hugh Cayless 29 May '15

29 May '15

Sent from my phone.

1 0

First defaultVal for the chopping block
by Martin Holmes 29 May '15

29 May '15

My first candidate for an annoying and pointless defaultVal is @part. This has the defaultVal "n", which means: (no) either the element is not fragmented, or no claim is made as to its completeness. [Default] If it means "No claim is made as to its completeness", then there's no point whatsoever -- and actually the fact that this means _both_ "not fragmented" _and_ "I'm not saying whether this is fragmented or not" is just silly. Unless anyone gives me a good reason within the next 24 hours, I'm going to delete the defaultness and remove the latter part of the definition. I don't believe anyone has ever explicitly applied this attribute with the value "no" to mean the second part of its definition, so I don't see that any difference could be made to anyone's existing projects. Shout if you think I'm missing something. Cheers, Martin

1 0

Minutes Doc
by Hugh Cayless 28 May '15

28 May '15

https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql… <https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql…> Stefanie, ping me on skype when you’re able to join in. /** * Hugh A. Cayless, Ph.D * hugh.cayless(a)duke.edu * Duke Collaboratory for Classics Computing (DC3) * http://blogs.library.duke.edu/dcthree/ **/

3 4

DTW-Ann Arbor ride
by Lou Burnard 27 May '15

27 May '15

Anyone else arriving about 18h15 (or as the Americans say "6.30 pm") in DTW next Weds? Interested in sharing a cab rather than waiting for the 19h45 bus (or bemoaning the departure of the 18h02 one)?

12 46

Stand-off proposal
by Martin Holmes 27 May '15

27 May '15

Very minor niggle on the stand-off spec: <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…> If the intention is to create a new module in TEI rather than add the new elements to an existing module, the module ident should be "standoff" rather than "stand-off", to align with existing modules ("namesdates", "textstructure"). Cheers, Martin

1 1

TEI Simple: Executive summary
by James Cummings 27 May '15

27 May '15

Dear Council, Please find attached an executive summary of the work of TEI Simple project and its proposal to Council. (The proposal really being the proto-ODDs on the github website.) Best wishes, James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

1 0

Agenda for F2F
by Hugh Cayless 27 May '15

27 May '15

Hi all, I’m putting together a draft agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-05 <http://wiki.tei-c.org/index.php/Council_Agenda_2015-05>. Items for discussion are to be found in the Minutes Google Doc at https://docs.google.com/document/d/1V7RB54nYMKeXPqPAGxjbKmXwViz0vLFfwzGo4Ql… Please add any additional business items you have to that list. I’ll be working more on it and the agenda today and tomorrow. Martin had proposed talking about how to build the Oxygen plugin. Do we have any other possible technical talks? Anything for TEI Simple or Pure ODD, for example? Looking forward to seeing you on Thursday! Hugh

2 1

UVic Jenkins temporarily down
by Martin Holmes 26 May '15

26 May '15

Just for info: the UVic Jenkins machine is currently down because it's being cloned to create a new Jenkins build server for other projects. Should be up again soon. Cheers, Martin

1 0

Release of the Oxygen plugin
by Martin Holmes 26 May '15

26 May '15

Hi all, After some more testing with Ron, I've just released a new version of the Oxygen plugin, incorporating the latest Stylesheets release (7.35.0) and some changes to the plugin codebase that we had had to back out of before Oxygen 17 was released because they depended on Stylesheets changes which hadn't been released at that point. If you're subscribed to this version of the plugin, please let me know if you see any problems. One of the confusing issues I'll talk about when I do my little show-and-tell on the Oxygen plugin in Michigan will be version numbers. Right now, the plugin filename is derived from the P5 and Stylesheets versions incorporated in it: teioxygen-2.8.0-7.35.0.zip = P5 2.8.0 and Stylesheets 7.35.0. However, there also has to be a true version number for the plugin, which is inserted into the updateSite.oxygen XML file that handles the plugin updates for users. Oxygen's system only allows a version number consisting of three dotted digits: 1.2.3 Our practice up to now has been to name the plugin release after the P5 release on which it's based, so this would be: 2.8.0 but because the last one was already 2.8.0, I've had to increment it: 2.8.1 If we now go ahead and release a minor P5 update, which would be 2.8.1, we would confusingly have to increment the plugin version number to 2.8.2. So I'd like to suggest that we detach the plugin versioning count entirely from the P5 version, and simply increment it independently; but with the second and third digits representing collapsed versions of the P5 and Stylesheets versions on which it's based: 3.280.7350 This would mean that we could have meaningful plugin version numbers simply incrementing in position 1, and still record the versions of P5 and the Stylesheets on which they're based. Any see any problem with this? We could make the change at the same time that we switch the file naming from teioxygen to oxygen-tei, as we've discussed before. Cheers, Martin

7 14

Building (e.g. TEI All schema)
by Hugh Cayless 26 May '15

26 May '15

Can someone explain to me like I’m an idiot how to use the Stylesheets to generate, say, a TEI All schema using the Guidelines specs? I’m afraid the documentation doesn’t give me enough to go on. I thought I understood it, but I don’t. My understanding is that you use the transformtei script, but what inputs do you give it? Thanks, Hugh

6 12

Re: [tei-council] ROMA does not work
by Martin Holmes 26 May '15

26 May '15

Once the build process has gone through on Jenkins successfully, I'll test my new oxygen-tei plugin build script by doing "ant release" to see what happens. :-) Cheers, Martin On 15-05-26 09:09 AM, Sebastian Rahtz wrote: > Roma should be working again now. I made a new Stylesheets release and deployed it around. > > Many apologies for that. > > Sebastian Rahtz > Chief Data Architect > University of Oxford IT Services > +44 1865 283431 >

1 0

bad date example
by Syd Bauman 26 May '15

26 May '15

We have a single example (used twice with slight differences) that shows use of dating attributes in a way I think may be inappropriate: <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> I don't like the combination of @from and @notAfter. As I understand (or at least imagine) it: @from and @to: indicate a range of dates during which something happened -- the thing happens during the entire range. <persName from="1940-10-09" to="1969-04-21">Lennon, John Winston</> <persName from="1969-04-22" to="1980-12-08">Lennon, John Winston Ono</> or <occupation from="1991" to="1994">Provost, Duke University</> For the *entire period* from 09 Oct 40 to 21 Apr 69 his name was "John Winston Lennon", and for the *entire period* from the day he legally changed his name (22 Apr 69) to his death (08 Dec 80) his name was "John Winston Ono Lennon". Similarly, Tommy Langford was Provost from 1991 to 1994. We don't know what day he became Provost or what day he stepped down, so the values of @from and @to are given only to year precision. Fair enough. (If we knew more, we could provide more precision.) @notBefore and @notAfter: indicate the earliest and latest endpoints for a single event to have occurred. Typically, but not at all necessarily, that event is measured in the precision of a single day. E.g. <death notBefore="1831" notAfter="1840"/> indicates that Mary Clarke [nee Carr] died sometime between those dates. She died on one day[1] during those days, she did not spend all 9 years in the throes of death. I think these notions of @from and @to indicating a *duration* during which something happened continuously, and @notBefore and @notAfter indicating endpoints within which range something happened at a given point, is borne out by the definitions in the tagdocs: - notBefore: specifies the earliest possible date for the event - notAfter: specifies the latest possible date for the event - from: indicates the starting point of the period - to: indicates the ending point of the period Thus my unease with the example <residence from="1857-03-01" notAfter="1857-04-30">From the 1st of March to some time in April of 1857.</residence> To me, the @from indicates that she lived there for a 1-2 month long period starting 01 March; but the @notAfter (at least, taken alone) implies that she lived there for one day[2] some day before 01 May. So I'm sure I don't like this, although I'm not sure how to solve the problem, i.e. how this information should be indicated. Possibilities include: * State explicitly in the prose what @from & @notAfter or @notBefore & @to mean. (To wit, an entire duration of vague length, specified by one endpoint and a point over which the duration did not extend.) * Indicate the duration with a start point and a duration, then indicate the (lack of) precision of the duration: <residence xml:id="R" from="1857-03-01" dur="P46D"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@dur" atLeast="31" atMost="61"/> Don't like this as it sits, because it only works because we presume the unit @atLeast & @atMost refer to is days. Makes sense for this case, but if the dur= were "P1M15D" it would be less obvious. I presume if it were "P1.5M", one would have to use atLeast=1 atMost=2; i.e. the precision attrs apply to the lowest order component. So I guess we could make this work by making that the rule. * Fix <precision> so that it allows representation of precision (meaning the unit or number of significant digits to which a value may be measured reliably) rather than just precision (meaning vaguely how exact or accurate). Then <residence xml:id="R" from="1857-03-01" to="1857-04-15"> From the 1st of March to some time in April of 1857. </residence> <precision target="#R" match="@to" dur="P15D"/> or whatever. * Create new attributes (egads!) to mean exactly what we want. E.g., @fromAfter and @toBefore. * Don't fix it. Caveat encoder. People tend to know what you mean. Besides, what possible automated processing will handle this stuff? Notes ----- [1] Actually one second, but let's not go nuts. [2] Or only one second, but let's not go nuts.

5 8

agenda item / bug
by Syd Bauman 25 May '15

25 May '15

Julia just reminded me that <event> still is not allowed as a child or grandchild of <org>. Off the top of my head, I don't see why <listEvent> is not a member of model.orgPart. Not quite so obvious how to make <event> an eligible direct child of <org>, but it seems like a reasonable request. I plan to submit a bug report shortly, with hopes that we can tackle this and solve it for next release. (Although I have my suspicions that this will bring up other thorny issues.)

3 3

Transcription of spoken language draft
by Martin Holmes 21 May '15

21 May '15

Hi all, I was just following up with Thomas Schmidt on this ticket: <http://sourceforge.net/p/tei/feature-requests/511/> which is one of at least two relating to the ISO/TEI spoken language proposal, and he's sent me a draft dated April 27, which is later than the last one mentioned on Lou's ticket: <http://sourceforge.net/p/tei/feature-requests/539/> He's still not happy with this being posted publicly, so we need a method of distributing it which is not public. The simplest thing would perhaps be to wait until the FtF and then just email it around. Does that work, or should be devise a password-protected location for it? Cheers, Martin

3 4

duplicate @rend error in generated RNG schema
by James Cummings 20 May '15

20 May '15

I was just bitten by the side effect of moving @rend to att.global.rendition. In taking an old and perfectly fine TEI ODD, and generating a fresh schema from it, the RNG was invalid because of a duplicate definition of @rend. Changing it so that I modified @rend on att.global.rendition rather than att.global solved this. Took me a good 10 minutes staring at it to realise what was wrong. doh. I'm just mentioning it to put it in the back of your brain in case anyone asks in the future. -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

3 4

May F2F. Hotel information.
by Paul Schaffner 11 May '15

11 May '15

I have received the attached confirmation from the hotel, listing Council members and their intended arrival and departure dates. I would appreciate it if you could check to make sure yours is correct. As for payment, I am told that the library entered an "accounting nightmare" the last time they tried to pay for everyone as a package deal. Is everyone willing to pay their own bill and ask for TEI reimbursement? If not, I could conceivably pay for everyone personally in advance, and then ask TEI to reimburse. But that would be quite a lot to put on my personal credit card. pfs -- Paul Schaffner Digital Library Production Service PFSchaffner(a)umich.edu | http://www.umich.edu/~pfs/

10 17

Notes on standoff
by Hugh Cayless 08 May '15

08 May '15

I’m finally getting a chance to look seriously at the standoff ODD and so I wanted to pull together my own notes and get some discussion going here that we can feed back to the proposers. 1) Why such an elaborate header? (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>) I can understand wanting to have some description of the content of <stdf> (or <ldb> as Syd proposed—I happen to like that better), but this seems maybe a bit overboard. Why can’t the document’s own revisionDesc serve to document revisions to the standoff section, for example? 2) Since standoff elements can nest, why do we need the <annotations> element? (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>). Wouldn’t it be simpler to allow the standoff element just to contain a heading and its content, optionally including more standoff elements? 3) I can sort of guess what <mapStruct> might be for, but it isn’t very clear (see https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof… <https://github.com/laurentromary/stdfSpec/blob/master/Specification/standof…>). Do we not already have sufficient mechanisms for attaching standoff markup to its targets? That’s all I’ve got for now. What do you think? We’re going to beam Laurent in for a discussion at the F2F on Friday the 29th at 10:00.

3 5

Problems with the UVic Jenkins server
by Martin Holmes 05 May '15

05 May '15

Hi all, Just a heads-up that a router update early this morning screwed up a bunch of our virtual machines when their filesystems became inaccessible; and then on restarting, an old obsolete machine was substituted accidentally for our current Jenkins server, and the latter may have been lost completely. Don't ask how such a thing could happen. Anyway, it means we may not have a UVic Jenkins for a while (I'm leaving town for a conference tomorrow morning). The Oxford Jenkins, meanwhile, has run out of disk space. :-( This may mean that I end up doing something I was hoping to put off till the summer: writing the new Jenkins build script and testing it. But that's hard to do on a crappy old laptop that can't run VMs, so it'll have to wait till I get back next week. There's a chance Systems can salvage our Jenkins, though. Keep your fingers crossed. Cheers, Martin

3 3

Fall F2F Dates
by Hugh Cayless 29 Apr '15

29 Apr '15

Hi All, Emmanuelle Morlock asks if we can nail down dates for the Fall F2F ASAP so that she can reserve rooms. Workshop dates may fall on Oct. 26, 27, or the morning of the 28th. There will probably be an EpiDoc one that I may need to help run. Options I see are: 1. Meeting on Sunday (25th) and Monday (26th) 2. Meeting the weekend before the conference (24th–25th) 3. Meeting concurrently with the workshops, and have some council members drop out for some of the time to deal with their workshops 4. Don't do any workshops 5. Don't meet before the conference. So what do you think? Is anyone else proposing a workshop?

7 9

updated framework not used in conversion
by Lou Burnard 29 Apr '15

29 Apr '15

I'm puzzled... I have installed all the recent updates to the TEI framework from the TEI site, and my local .com.oxygen.xml directory contains an updated version of one of the XSLT scripts provided as a result: -rw-rw-r-- 1 lou lou 13520 Apr 29 12:02 ./.com.oxygenxml/extensions/v16.1/frameworks/http___www.tei_c.org_release_oxygen_updateSite.oxygen/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl However, when I actually run the conversion from within oXygen, it does not use this version, but instead the one released ages ago, which is still in the installation directory: -rw-r--r-- 1 lou lou 9612 Jan 22 13:43 ./OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/from_common.xsl The Ant script I am running in my transformation says "Loading stylesheet /home/lou/OxygenXMLEditor16/frameworks/tei/xml/tei/stylesheet/profiles/oulipo/docx/from.xsl" It also uses the build-from.xml file from the same directory, rather than the one one in the .com.oxygml tree, which is however identical. But since it uses relative paths, maybe that is the problem? Any advice much appreciated...

2 3

Teleconference April 24
by Hugh Cayless 24 Apr '15

24 Apr '15

Hi All, We have a telecon scheduled for next Friday, April 24th. Any chance we can push it back to 06:00 PDT / 09:00 EDT / 14:00 BST / 15:00 CEST? I have a conflict at 8:30 due to my own carelessness. We could make this change permanent in fact, if no-one objects. It would mean Martin doesn't have to get up so brutally early. I no longer have a conflict at 10:00 every Friday, so we could push it later. We're (as previously decided) going to attempt to do this in a Google Hangout. I will send an invite to the list a few minutes before start time. I've started an agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-04 to which you should feel free to add items for discussion. I've got a couple more to put in myself. May's telecon will obviously be canceled because we'll be in Ann Arbor. Thanks, Hugh

12 19

Oxygen release
by Martin Holmes 20 Apr '15

20 Apr '15

George Bina confirms there will be no new Oxygen release before 17, scheduled for the end of April/beginning of May. That's perfect timing for us. It gives a window of three weeks for our version of the plugin to be out in the wild and in general use before the Oxygen guys build the version they'll be including with the Oxygen distro. Cheers, Martin

5 6

Fwd: [tei:bugs] #749 fatal bug in 2.8.0 apropos att.global.rendition
by Martin Holmes 14 Apr '15

14 Apr '15

Do we need a 2.8.1 to be done fairly quickly for this? This really is my fault, but I must admit I had no idea what @predeclare was about; I was assuming the regular tests would pick up anything problematic, and I had no trouble working with @rend and @rendition in my projects for several months before release. I don't use DTDs, of course. Cheers, Martin -------- Forwarded Message -------- Subject: [tei:bugs] #749 fatal bug in 2.8.0 apropos att.global.rendition Date: Tue, 14 Apr 2015 17:19:19 +0000 From: Sebastian Rahtz <rahtz(a)users.sf.net> Reply-To: Ticket 749 <749(a)bugs.tei.p.re.sf.net> To: Ticket 749 <749(a)bugs.tei.p.re.sf.net> --- ** [bugs:#749] fatal bug in 2.8.0 apropos att.global.rendition** **Status:** open **Group:** AMBER **Created:** Tue Apr 14, 2015 05:19 PM UTC by Sebastian Rahtz **Last Updated:** Tue Apr 14, 2015 05:19 PM UTC **Owner:** nobody I am afraid the `<classSpec>` at.global.rendition is missing the vital attribute predeclare="true". I have committed the appropriate change to fix it. This means that any ODD which redefines @rend, @rendition etc is going to fail when it comes to making a DTD. You may now formally curse the day DTDs were invented. I might note that a few existing ODD users are going to be mighty confused when they find their code to change @rend globally simply fails to work these days. In retrospect, it would have been good to highlight this in the release notes. --- Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/tei/bugs/749/> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

2 2

Fall meeting
by Martin Holmes 13 Apr '15

13 Apr '15

Hi all, The CfP for the fall Members Meeting is out, and we have to start making plans. I'd like us if we can to agree soon whether we want to have the fall Council meeting along with it (I think we'd all like to do that), and if so, whether it's going to be before or after, so we can plan work absences and travel. Can we have a show of hands on who would prefer before the main meeting and who would prefer after? I'd rather have Council meet before, so I'm fresh going into the Council meetings and so we can report informally on what we've been doing during the members meeting. Cheers, Martin

7 6

Release freeze *lifted*
by Raffaele Viglianti 06 Apr '15

06 Apr '15

Dear council, The release of 2.8.0 is completed and the commits freeze is now *lifted*. We are now working on 2.8.1a. Please feel free to go back to your bug fixing and general peruse of the SVN repository. Thanks, Raff

4 3

Release day instructions
by Martin Holmes 06 Apr '15

06 Apr '15

Hi all, This is meant mainly for Raff, James, Hugh and anyone else likely to be helping with the release process. I took a quick look through TCW 22, the release instructions, in advance of the release, and noticed some problems. The most obvious is that the oxygen-tei instructions were out of date; they pointed to the Google Code project. I've fixed that, but when I went to test out the rest of that instruction block, I found it doesn't work; the structure of the Vault seems to have changed a bit since those instructions were written, or perhaps they were never actually right. The instructions talked about a file x.x.x/updateSite.oxygen, where x.x.x is the version number, but actually the update file at in x.x.x/oxygen/updateSite.oxygen. I've fixed that. Since James's blog post has the right URL for the file: <http://blogs.it.ox.ac.uk/jamesc/2014/04/02/auto-update-your-tei-framework-i…> I assume the instructions have not been right for some time. James, you'll have to update your blog post to point to the new GitHub location for the oxygen-tei source code. Those same instructions in TCW 22 only take account of major releases (which luckily this is -- it's 2.7 -> 2.8) so they'll have to be elaborated a bit for situations in which you're actually changing a version within the same folder, as minor point-releases do. There's one other thing we'll need to work on. The original version of the instructions has point 8 like this: <quote> 8. Still in ~/private/P5/Utilities, run ./tei-database-rebuild.sh This will update the eXist-db used by Roma. The script takes no parameters but expects a configuration file in the user’s home directory at ~/etc/tei-exist.conf with the appropriate paths and credentials. For the main server at tei-c.org this should already be set and no adjustments should be needed. This is the database used by Roma, so this operation will ensure that Roma is using the new version. Temporary measure for version 2.7.0 only: ask Martin, Peter, James or Sebastian to check the version of P5 used by Roma, to ensure that this has succeeded, and fix it manually if it has not. This procedure is undergoing revision right now, so it has to be done there may be a problem here. Following the release of 2.7.0, a new process will be put in place and this instructions will be updated. </quote> We obviously dropped the ball there. I've edited this a bit so that it's less confusing, but we'll still have to make sure we know how to check the version of P5 which is in eXist when the script has been run. I know the URL to go to in order to do that, but we can't put it in the documentation for various reasons; I'd like to make sure enough other people know it so that there's always someone available to check when the time comes. I'm going to raise a bug that forces us to work on this; it's an aspect of the whole shebang which is very fragile. Anyone else likely to be on duty for the release might want to check that TCW 22 makes sense to them too: <http://www.tei-c.org/Activities/Council/Working/tcw22.xml> Raff, are you already set up with your SSH key for tei-c.org? Cheers, Martin

4 4

Release freeze *in place*
by Raffaele Viglianti 06 Apr '15

06 Apr '15

Hi all, Just another reminder that there is a commit freeze on the repository. Please do not commit anything until further notice. Raff

1 0

Release Notes
by Hugh Cayless 04 Apr '15

04 Apr '15

I will XMLify and commit the release notes at https://docs.google.com/document/d/1U1z6eCbJKVmu8k1KWB4ht6qqZxcTXXycKaVYqzh… later this weekend (maybe this evening, more likely tomorrow). Please look them over and make any changes you think necessary before then. Thanks, Hugh

2 1

Hangout link
by Hugh Cayless 03 Apr '15

03 Apr '15

https://plus.google.com/hangouts/_/g374p6twebxmmcxkwkpgdgdciaa Let's see if this works...

5 5

Freeze reminder
by Raffaele Viglianti 03 Apr '15

03 Apr '15

Hello, I think you are all aware of this, but here's a reminder anyway: there is currently a *temporary freeze of commits* to the repository. This is because of the release scheduled for Monday April 6. Please do not commit anything else to the repository until the freeze is lifted (likely sometime on Monday). Thanks, Raff

4 4

Release Notes
by Hugh Cayless 03 Apr '15

03 Apr '15

Since this is my first time writing them, I don't have a very clear idea of what to put in and what to leave out, so I've started a google doc: https://docs.google.com/document/d/1U1z6eCbJKVmu8k1KWB4ht6qqZxcTXXycKaVYqzh… to which I invite you to add things you've worked on that you'd like to be in the release notes. Thanks, Hugh

1 0

@degree deprication
by Syd Bauman 31 Mar '15

31 Mar '15

We're scheduled to remove @degree in 7.5 months. Should we be removing it from examples now? It occurs in 6 of them, all in "Certainty, Precision, and Responsibility": .../div[1]/div[2]/div[4]/specGrp[1]/elementSpec[1]/exemplum[1]/teix:egXML[1]/teix:precision[1] .../div[1]/div[2]/div[4]/specGrp[1]/elementSpec[1]/exemplum[1]/teix:egXML[1]/teix:precision[2] .../div[2]/p[5]/teix:egXML[1]/teix:precision[1] .../div[2]/p[5]/teix:egXML[1]/teix:precision[2] .../div[2]/p[6]/teix:egXML[1]/teix:residence[1]/teix:precision[1] .../div[2]/p[7]/teix:egXML[1]/teix:precision[1]

3 4

Poll for dataNode discussion
by Hugh Cayless 31 Mar '15

31 Mar '15

Dear all, At the meeting this morning we decided to try to kill two birds with one stone: we want to have a proper discussion of Lou's proposals for pointing to datatypes in Pure ODD (see http://sourceforge.net/p/tei/feature-requests/530/) and we want to see if Google Hangouts are a suitable medium for meetings. We agreed to try to do this next week, at around the same time as we hold Council meetings, with as many people as we can manage. Here's the poll: http://doodle.com/nbhyigzs94vqida8 It would be nice if we could get a bunch of you in, just so that we'll have a proper test and discussion. I don't think this will take a full hour, though of course it depends how chatty/argumentative we are. :-)

4 5

Fwd: Build failed in Jenkins: TEIP5-Test #2588
by Martin Holmes 30 Mar '15

30 Mar '15

Raff, your commit seems to have failed to build, and the email that Jenkins tried to send you to let you know bounced (the SF server says rviglianti(a)users.sourceforge.net does not exist). Could you take a look at the error message below and see if you can fix the problems? It looks as though: < <ERROR>egXML points to non-existent #VESA-eg-1 < (TEI[1]/text[2]/body[3]/div["VE"]/div["VESA"]/p[6]/) </ERROR> you didn't actually add VESA-eg-1 to the Bibliography. < <ERROR>id 'said1297' used more than once</ERROR> < <ERROR>id 'said1298' used more than once</ERROR> < <ERROR>id 'said1299' used more than once</ERROR> xml:ids were used multiple times, which I think is a no-no, even in examples; they're also validated. Cheers, Martin -------- Forwarded Message -------- Subject: Build failed in Jenkins: TEIP5-Test #2588 Date: Mon, 30 Mar 2015 01:17:28 +0100 From: tei(a)oucs.ox.ac.uk To: sebastian.rahtz(a)it.ox.ac.uk, mholmes(a)uvic.ca, rviglianti(a)users.sourceforge.net See <http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/2588/changes> Changes: [rviglianti] Added subsection suggesting strategies to encode textual structures across verses. Fixes bug #705 ------------------------------------------ Started by an SCM change Building in workspace <http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Test/ws/> Updating svn://svn.code.sf.net/p/tei/code/trunk/P5 at revision '2015-03-30T01:15:08.397 +0100' U Source/Guidelines/en/VE-Verse.xml At revision 13190 [workspace] $ /bin/sh -xe /tmp/hudson6312426556303253728.sh ++ pwd + make INJENKINS=true XSL=/srv/hudson/jobs/TEIP5-Test/workspace/../../Stylesheets/lastSuccessful/archive/dist/xml/tei/stylesheet clean validate test (cd Exemplars; make clean) make[1]: Entering directory `/srv/hudson/jobs/TEIP5-Test/workspace/Exemplars' rm -f *.xsd *.dtd *.doc.* *.rnc tei*.xsl tei*.rng *.compiled* *~ *.xi *.isosch *.epub *.pdf *.html *.nvdl *-examples* rm -f exnames.xml rm -f enrich.rng isofs.rng rm -f names.xml *properties rm -f [A-Z]*xml make[1]: Leaving directory `/srv/hudson/jobs/TEIP5-Test/workspace/Exemplars' (cd Test; make clean) make[1]: Entering directory `/srv/hudson/jobs/TEIP5-Test/workspace/Test' rm -f test*.doc.xml test*.rnc test*.dtd test*.compiled.* test*.xsd test*.rnc test*.rng test*.xsl test*.isosch rm -rf LOG *~ *.xsd Schema RomaResults DTD rm -rf *.doc.* rm -f detest.log detest.log.all rm -f *-examples.rng *-examples.rnc *test*.nvdl *-ex.odd rm -f detest.rnc detest.rng detest.dtd detest.isosch make[1]: Leaving directory `/srv/hudson/jobs/TEIP5-Test/workspace/Test' rm -rf release Guidelines Guidelines-web Schema DTD dtd Split rm -rf Guidelines.??? Guidelines-* rm -f *.isosch.xsl rm -f *.stamp rm -f *.xsd rm -f Exemplars/stdout rm -f Test/*.isosch rm -f Test/detest.dtd Test/detest.rnc Test/detest.rng Test/detest.xsl rm -f Test/stdout rm -f Utilities/guidelines.xsl rm -f anything buildweb.xml rm -f p5.sch p5.isosch p5.xml p5subset.xml p5subset.json p5subset.js rm -f p5attlist.txt rm -f p5odds-examples.rng p5odds-examples.rnc p5odds.rng p5odds.rnc p5odds.isosch rm -f pdfbuild.log rm -f stripspace.xsl.model rm -f tei-*.zip rm -f tei-p5-*_*build rm -f tei-p5-*_*changes rm -f tei-p5-*_*deb rm -f teiwebsiteguidelines.zip rm -rf FASC-* rm -rf catalogue.* modList rm -rf valid v.xml ValidatorLog.xml Utilities/pointerattributes.xsl graphics.sh missfont.log v.body v.header Schematron1.xml Schematron2.xml Checking you have running XML tools and Perl before trying to run transform... Ant:/usr/bin/ant Perl:/usr/bin/perl Java:/usr/bin/java xmllint:/usr/bin/xmllint touch check.stamp get latest date: if [ svn = "svn" ] ; \ then \ if [ true ] ; \ then svn info --xml svn://svn.code.sf.net/p/tei/code/trunk/P5 ; \ else svn info --xml ; \ fi > repodate.xml ; \ fi if [ svn = "git" ] ; \ then \ git log --max-count=1 --pretty=format:"<info type=\"git\"><entry><commit revision=\"%h\"><date>%ai</date></commit></entry></info>" > repodate.xml ; \ fi BUILD: Generate modular DTDs, Schemas, Schematron and miscellaneous outputs ANT_OPTS="-Xss2m -Xmx752m -Djava.awt.headless=true" ant -q -lib Utilities/lib/jing.jar:Utilities/lib/saxon9he.jar -f antbuilder.xml -DXSL=/srv/hudson/jobs/TEIP5-Test/workspace/../../Stylesheets/lastSuccessful/archive/dist/xml/tei/stylesheet -DDRIVER=Source/guidelines-en.xml base subset outputs [echo] make modular DTDs, RELAXNG schemas, json, odd schemas, schematron files [echo] Using /srv/hudson/jobs/TEIP5-Test/workspace/../../Stylesheets/lastSuccessful/archive/dist/xml/tei/stylesheet for XSL stylesheets [echo] Do ODD processing for p5odds.odd [echo] Do ODD processing for p5odds-examples.odd BUILD SUCCESSFUL Total time: 1 minute 16 seconds BUILD: Generate modular RELAX NG (compact) schemas using trang (cd Schema; for i in *rng; do java -jar ../Utilities/lib/trang.jar $i `basename $i .rng`.rnc;done) touch schemas.stamp BUILD: Check validity with rnv if we have it command -v rnv && rnv -v p5odds.rnc p5.xml /usr/bin/rnv rnv version 1.7.10 p5.xml BUILD: Check validity with special-purpose XSL code, looking for bad links etc ANT_OPTS="-Xss2m -Xmx752m -Djava.awt.headless=true" ant -q -lib Utilities/lib/saxon9he.jar -f antbuilder.xml -DXSL=/srv/hudson/jobs/TEIP5-Test/workspace/../../Stylesheets/lastSuccessful/archive/dist/xml/tei/stylesheet validators [echo] Run Schematron script (normal part of Guidelines) [echo] Run Schematron script (Examples in Guidelines marked as valid) [echo] Run ad hoc XSLT validators BUILD SUCCESSFUL Total time: 33 seconds <Messages> <ERROR>egXML points to non-existent #VESA-eg-1 (TEI[1]/text[2]/body[3]/div["VE"]/div["VESA"]/p[6]/) </ERROR> <ERROR>egXML points to non-existent #VESA-eg-1 (TEI[1]/text[2]/body[3]/div["VE"]/div["VESA"]/p[6]/) </ERROR> <ERROR>id 'said1297' used more than once</ERROR> <ERROR>id 'said1298' used more than once</ERROR> <ERROR>id 'said1299' used more than once</ERROR> <WARNING>Schematron warning: WARNING: use of deprecated method — the use of the altIdentifier element as a direct child of the msPart element will be removed from the TEI on 2016-09-09 [Test: child::tei:altIdentifier] Location: /TEI[1]/text[1]/body[1]/div[10]/div[10]/specGrp[1]/elementSpec[1]/exemplum[2]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/msDesc[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/msPart[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[1]/div[2]/div[4]/specGrp[1]/elementSpec[1]/exemplum[1]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[1]/div[2]/div[4]/specGrp[1]/elementSpec[1]/exemplum[1]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][2]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[2]/p[5]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[2]/p[5]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][2]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[2]/p[6]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/residence[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]</WARNING> <WARNING>Schematron warning: WARNING: use of deprecated attribute — @degree of the precision element will be removed from the TEI on 2015-11-12. [Test: @degree] Location: /TEI[1]/text[1]/body[1]/div[21]/div[2]/p[7]/egXML[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]/precision[namespace-uri()='http://www.tei-c.org/ns/Examples'][1]</WARNING> </Messages> (grep -q "<ERROR>" ValidatorLog.xml;if [ $? -ne 1 ] ; then echo "Oh dear me. ERROR found";diff ValidatorLog.xml expected-results/ValidatorLog.xml;false; fi) Oh dear me. ERROR found 2,8d1 < <ERROR>egXML points to non-existent #VESA-eg-1 < (TEI[1]/text[2]/body[3]/div["VE"]/div["VESA"]/p[6]/) </ERROR> < <ERROR>egXML points to non-existent #VESA-eg-1 < (TEI[1]/text[2]/body[3]/div["VE"]/div["VESA"]/p[6]/) </ERROR> < <ERROR>id 'said1297' used more than once</ERROR> < <ERROR>id 'said1298' used more than once</ERROR> < <ERROR>id 'said1299' used more than once</ERROR> make: *** [valid] Error 1 Build step 'Execute shell' marked build as failure

2 2

datatypes coming back to bite us
by Syd Bauman 29 Mar '15

29 Mar '15

As you may recall, on our conference call Fri we agreed I'd try to get Schematron checks for the default value problems Lou pointed out in FR 546[1] ready for inclusion in next release. The cases that we'd like to check are * If the attribute being defined is required, a default value should not be defined. * If the attribute being defined has a closed list of values, then the default value should be among the enumerated list. That second one causes a problem; I've hit a predictable snag. We have explicitly (and unwisely IMHO) permitted whitespace in the value of an attribute defined as a member of an enumerated set of values. Thus it is perfectly legal in TEI to have <valItem ident="Bono"/> <valItem ident="Enya"/> <valItem ident="Diana"/> <valItem ident="Prince"/> <valItem ident="Madonna"/> <valItem ident="Pat Benetar"/> <valItem ident="Diana Prince"/> <valItem ident="Michael Jackson"/> As I've argued before, this makes it difficult to differentiate multiple singleton values from single multiples. E.g., presume the above list is associated with <datatype minOccurs="1" maxOccurs="3"> <rng:ref name="data.enumerated"/> </datatype> Then is the value "Diana Prince" one value or two?[2] This problem comes up because we actually have a <defaultVal> that has multiple singleton values: namely the default for the optional @type of <metDecl>, is "met real". (AFAIK we don't have any @ident of <valItem> that contain whitespace.) Now, since the attributes allows 1-3 occurrences of its closed value list of "met", "real", and "rhyme", we (humans) know that the default value must be two singleton values, "met" and "real". But the Schematron check is a different story. If I write the test to match the datatype, I would use string( chlid::defaultVal ) = child::valList/valItem/@ident But that means "met real" doesn't match. If I write the test to presume whitespace-separated singletons, I would use tokenize( normalize-space( child::defaultVal ),' ') = child::valList/valItem/@ident (And remember, these are XPath 2 expressions, so the '=' operator operates on sequences, not single values.) The problem with writing the test that 2nd way is that then a user who takes advantage of the fact that we allow spaces in enumerated lists will get a false error message when she tries <attDef ident="Q1" mode="add"> <defaultVal>one two</defaultVal> <valList type="closed"> <valItem ident="one two"/> <valItem ident="three four"/> </valList> </attDef> (And, I'd have to do better than normalize-space() if we wanted to take possible leading or trailing space into account.) I'm really not sure what to do about this. Possibilities include: 1) Use the first method (string), and change the build process so that the error on "met real" is ignored. 2) Change the definition of <metDecl> so that the default value of @type is discussed in prose, not given in <defaultVal>. 3) Change the test to use the first method (string) iff maxOccurs is 1 (or unspecified), and to use the second method (tokenize) iff maxOccurs is 2+ (or "unbounded"). Other suggestions? I think (1) and (2) are pretty much cop-outs, but not crazy. I think either may be acceptable as a temporary hack, but neither is a good long-term solution. I think (3) does the easy cases right, but I haven't thought through the harder cases. (That said, probably no one should be using the harder cases.) Notes ----- [1] https://sourceforge.net/p/tei/feature-requests/546/?page=0 [2] To complicate things we've (very unwisely IMHO) defined @ident of <valItem> and the content of <defaultVal> as rng:string and <rng:text>, respectively, as opposed to rng:token (or better yet, something that does not allow whitespace like data.word). That said a) our ODD processing software silently converts the value of @ident of <valItem> from rng:string to rng:token b) even using rng:token doesn't really fix this problem c) no matter what you do, you probably don't get the results you expect Let me know if you want evidence of (c).

1 1

#705 <lg> cannot contain <q>, <seg>, etc.
by Raffaele Viglianti 28 Mar '15

28 Mar '15

Hi all, I've drafted a new section for chapter 6 Verse, to address bug #705 [1] The new section would come right after the section "Components of the Verse Line" [2] Here is the draft: https://gist.github.com/raffazizzi/c70e1565bc4b83d4a043#file-vesa Please let me know if you have any comments. If we're happy with it, I'd like to commit it before the freeze on Monday. Thanks! Raff [1] https://sourceforge.net/p/tei/bugs/705/ [2] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/VE.html#VESE

4 5

Bleeding-edge version of the Oxygen plugin
by Martin Holmes 27 Mar '15

27 Mar '15

Hi all, Following up on the meeting today: The plugin subscription URL is: <http://teijenkins.hcmc.uvic.ca/job/oxygen-tei/lastSuccessfulBuild/artifact/…> It gets updated frequently; if it breaks, let me know asap. The last ten builds are retained, so you can in theory easily roll back. Cheers, Martin

1 0

Reminder: telecon on Friday
by Hugh Cayless 27 Mar '15

27 Mar '15

This will be the one with the time shift: March 27, 8:30 am EDT, 5:30 PDT, 12:30 GMT, 13:30 CET. I've put up a stub agenda at http://wiki.tei-c.org/index.php/Council_Agenda_2015-03 Please add items you think should be discussed or reported on. I'm at a meeting Mon.-Wed., so won't be able to do much prep. We grumbled a bit about the medium at the last meeting and wondered about trying a Google Hangout instead. Is this something everyone would like to try next time? Sent from my phone.

6 9

Agenda/Minutes Doc
by Hugh Cayless 27 Mar '15

27 Mar '15

https://docs.google.com/document/d/1Pu_EFOSHMcoOsXfhUEcx9M9OUJJMbueXspLsiVG… Just grabbing some coffee. I'll go ahead and set the call up now.

1 0

conference call in 6 hours
by Syd Bauman 26 Mar '15

26 Mar '15

I may be a bit tired, but I plan to attend. (To see why, check out http://bauman.zapto.org/~syd/albums/2015-03-27_car_fire/; interesting to note that the table of metadata is generated with XSLT 1.0.) Can someone post * the phone number to call and conferene number to punch in; and * the URL of the minutes, if we're doing that in GoogleDocs again? Thanks.

1 0

Re: [tei-council] Google Code shutting down
by Martin Holmes 22 Mar '15

22 Mar '15

On 15-03-22 03:04 PM, Sebastian Rahtz wrote: >> On 21 Mar 2015, at 18:00, Martin Holmes <mholmes(a)uvic.ca> wrote: >> While we're looking at these downloads on SF, I think we should now >> remove TEIOO: >> >> <http://sourceforge.net/projects/tei/files/> > yes please. zap it dead. Done. I have copies of the last downloads just in case. They should probably go somewhere for archive, but we're against "obsolete" folders in repos IIRC, so I don't know where we should put them. What about tei-emacs? Cheers, Martin > -- > Sebastian Rahtz > Chief Data Architect > University of Oxford IT Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > >

1 0