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

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

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 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