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

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 27 Jun '15

27 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 27 Jun '15

27 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