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

@prefix on <elementSpec>
by Lou Burnard 11 Oct '15

11 Oct '15

I gave up trying to get the HTML to look nice for the moment and went back to testing my purified datatypes, which threw up the following oddity. The attribute @prefix on <elementSpec> is currently defined (in RNG) as follows <rng:choice> <rng:value/> <rng:ref name="data.xmlName"/> </rng:choice> (or in compact form: attribute prefix { "" |data.xmlName <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.xmlName.html> }? ) I*think* this is so that you can distinguish (say) <elementSpec ident="foo" prefix=""/> from <elementSpec ident="foo" > but my question is WHY WOULD YOU WANT TO DO THAT? If no-one can come up with a persuasive case where this distinction might be necessary, I'd rather change this to <dataRef key="teidata.xmlName"/> than go to the trouble of defining a new <dataSpec> for this case. If I make that simplification, prefix="" would then be illegal; but wouldn't it be just as effective to say that if no prefix is supplied the implication is that the prefix is null?

3 3

Where we are
by Hugh Cayless 10 Oct '15

10 Oct '15

I think we’re at step #12 on http://www.tei-c.org/Activities/Council/Working/tcw22.xml#d429477e345 <http://www.tei-c.org/Activities/Council/Working/tcw22.xml#d429477e345> releasing the Debian packages, which James will have to do. Looks like there’s an issue with the Stylesheets—I suspect it’s that I missed a step in the release. We’ll have to write release documentation for them too. I’m out all day today, but should be able to work on it tonight/tomorrow. Hugh

4 7

Release? Bis
by Hugh Cayless 09 Oct '15

09 Oct '15

I backed out @scope last night. Can we drop 2.9.0, or do we need further discussion?

5 17

Release?
by Hugh Cayless 08 Oct '15

08 Oct '15

The modified xenoData sections are viewable at http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/re… and http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/re… Can at least some of you look them over and either approve or suggest/make corrections? Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with.

8 34

xenodata/@scope
by Hugh Cayless 08 Oct '15

08 Oct '15

I wanted to ask, before it’s too late, whether we’re all happy with @scope on <xenodata>. I’m not very fond of it, to be honest. I might use xenodata in the following scenarios: 1) I generated my TEI (particularly its metadata/header) from another source, and I want to capture that source. 2) I have related data in another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed. In nether case would @scope really help me...I was under the impression that we were going to defer categorizing xenodata until we had requests from people using it. What do we think?

7 46

Decision time for xenodata/@scope
by Hugh Cayless 07 Oct '15

07 Oct '15

We seem to be at a bit of an impasse, and we're releasing tomorrow. At this point we can: 1) release xenodata as-is, with @scope and the current value list. 2) release xenodata with @scope, but without a list of recommended values 3) release xenodata without @scope 4) back out xenodata and release without it My own preferences, in order, are 3, 2, 4, 1. I'm not convinced of the need for @scope, but I really think the value names have to be changed (and some removed) if we go with it. Thoughts? In addition, I do think we need to provide an example or two in the text of the Guidelines. I can come up with a non-XML one pretty easily.

7 9

matte lists
by Syd Bauman 07 Oct '15

07 Oct '15

If you search for the string "gloss" in http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/re… you will find that quite a few of our example <list>s that have type=gloss are not glossary lists at all. I'm not suggesting that we should try to fix this before release, but if I don't mention it now I'll forget. James -- BTW, this was discovered by Sarah Connell, who you met just a few hours ago. (She was the one in blue running the meeting.)

2 1

Release notes for 2.9.0
by Hugh Cayless 07 Oct '15

07 Oct '15

Dear all, I've updated the release notes for 2.9.0. Please have a look at them and feel free to add or modify anything I've missed or messed up. :-)

2 1

spam alert
by Lou Burnard 06 Oct '15

06 Oct '15

This suggests that TEI lists are about to be deluged with spam: how do we remove dirkschoenaers address from the TEI-MS-SIG list (and also tell him -- he seems to be a real person, or at least a medievalist, but clearly his address has been hijacked) ? -------- Forwarded Message -------- Subject: Fw: new message Date: Tue, 6 Oct 2015 06:26:53 -0700 From: TEI Text Encoding Initiative public discussion list <dirkschoenaers(a)SKYNET.BE> Reply-To: TEI Text Encoding Initiative public discussion list <dirkschoenaers(a)SKYNET.BE> To: TEI-MS-SIG(a)LISTSERV.BROWN.EDU Hello! *New message, please read* http://www.sdfholistic.com/telling.php <http://www.sdfholistic.com/telling.php?1m> TEI Text Encoding Initiative public discussion list

3 4

Decision time: exactly how and where will this release be released?
by Martin Holmes 04 Oct '15

04 Oct '15

HI all, I've updated TCW20 (How to Edit the Guidelines) and I'm beginning work on TCW22 (Building a TEI Release). These instructions, along with a lot of our automated processes, assume that the release will be pushed up to SourceForge (therefore requiring that the release technician have shell access to the SF repo). To me this really makes no sense any more; I think we should make this release the point at which we move our products over to both GitHub (for releases from each individual repository) and tei-c.org (for a catalogue of all releases, past and present, in downloadable format). All in favour say aye, all against say why, please. Since we haven't yet established a procedure for doing a release under the new conditions, I don't propose to make it up and describe it ahead of time. I suggest we go through the process, led this time by those with the most familiarity with our past and present systems rather than by a novice release technician, and then construct the documentation after the event, when we know what we ended up doing and what worked. Again, anyone think this is wrong? For the moment, then, what I propose to do with TCW22 is to comment out any references to SF, update any references to svn to refer to git, and leave the document in an incomplete state which retains only the bits that still make sense. Cheers, Martin

3 7